[00:30] <YokoZar> Could someone manually move wine1.4 through britney
[00:30] <YokoZar> It's been waiting there for weeks now
[00:30] <YokoZar> and I have SRUs sorta depending on it
[00:32] <cjwatson> Let me just do a couple of manual checks then
[00:37] <infinity> Oh, meh, I'd meant to get to that.
[00:37] <infinity> And also to ask for a crash-source in hinting.
[00:37] <infinity> s/source/course/
[00:38] <cjwatson> infinity: Be my guest then.  Add "HINTS_ADCONRAD = all" (or whatever) in lp:~ubuntu-release/britney/britney2-ubuntu and create a file for yourself in lp:~ubuntu-release/britney/hints-ubuntu
[00:39] <cjwatson> infinity: For the hint syntax you tend to have to RTFS.  In this case I suspect it needs "force-hint wine1.4/1.4.1-0ubuntu2" once you're happy that the new uninstallabilities are solely due to multiarch.
[00:40] <cjwatson> (force-hint: "try anyway even if it increases uninstallability")
[00:40] <cjwatson> (as opposed to plain force which is "ignore excuses")
[00:41] <infinity> cjwatson: So, basically of the format "some-action: source/version"?
[00:41] <cjwatson> I guess it might need force as well as force-hint, but try it without first.
[00:41] <infinity> cjwatson: Where some-action is RTFS?
[00:41] <cjwatson> Minus the colon, but yes.
[00:41] <infinity> Oh, right.
[00:42] <infinity> Reading, not my strong suit.
[00:42] <infinity> But boy, you should see me type.
[00:42] <infinity> Totally makes up for it.
[00:42] <cjwatson> Oh look, found it.  http://ftp-master.debian.org/testing/hints/README
[00:43] <cjwatson> infinity: ^-
[00:43] <infinity> cjwatson: *nod*  Already read.
[00:43] <infinity> Or, skimmed.
[00:43] <infinity> Skum?
[00:43] <infinity> Already skum.
[00:44] <cjwatson> geskommen
[00:44]  * infinity salutes.
[00:44] <infinity> I think.
[00:50] <infinity> Hrm.  Looks like britney needs to learn what :any means.
[00:50] <infinity> Cause that wine output should really only be whining about "wine1.4/amd64 unsatisfiable Depends: wine1.4-i386", not the other two lines.
[00:56] <infinity> YokoZar: So, testing this in a raring chroot with proposed enabled, it's not installable anyway...
[00:59] <infinity> Oh, or this chroot is sad.  Sec.
[01:01] <infinity> Okay, that works better...
[01:04] <darkxst> Sarvatt, so I managed to get ppa-purge to correctly generate revert list on Precise, but it doesnt actually work since aptitude is horribly broken on precise.
[01:22] <YokoZar> infinity: Thank you :)
[01:22] <infinity> YokoZar: Also, I'm uploading to clean up that cruft that drives me insane every time I look at the diff.
[01:22] <infinity> YokoZar: But I'll make sure this all migrates. :P
[01:23] <YokoZar> infinity: Please do.  I was gonna decruft it myself but it took a while waiting ;)
[01:24] <infinity> YokoZar: Also, britney does warn of:
[01:24] <infinity> YokoZar: * i386: dssi-vst, lmms, pptview, pq, wine, wine1.4, wine1.4-dbg, wine1.4-dev, wine1.4-i386
[01:24] <infinity> YokoZar: Some of those are clearly from the source itself, but can you verify them all?
[01:25]  * infinity quickly does that himself for paranoia...
[01:25] <YokoZar> please install pq
[01:25] <YokoZar> it is a fantastic troll package
[01:28] <infinity> YokoZar: Yeah, it all appears to install fine.  Probably just more fallout from the "wine1.4-i386 appears to not be installable" confusion.
[01:28] <infinity> YokoZar: I'll pass on PQ for now. :)
[01:28] <cjwatson> pq is very very silly
[01:29] <infinity> The FAQ alone was silly.
[01:29] <infinity> I love how he treats the bugs in the game as features "sorry, corrupted character just means it's gotten old and senile" sort of thing.
[01:29] <YokoZar> infinity: it's because he literally lost the source
[01:30] <YokoZar> persia: I hope you're enjoying the fact that pq is affecting us again
[01:30] <infinity> YokoZar: https://bitbucket.org/grumdrig/pq implies he found it again. :)
[01:36] <infinity> Oh, wait, this may prove to be a self-solving problem, since britney attempts to just make sure uninstallable counts don't go up, and wine will continue to be "just as broken as before". :P
[01:36] <infinity> Still, would be nice if we could make it look less broken in the eyes of britney.
[01:37] <YokoZar> infinity: you could remove pq :P
[01:38] <infinity> No, no.  I mean it would be nice if wine itself didn't appear broken, but without allowing a free-for-all of cross-arch deps (which would be ungood, IMO)
[01:38] <infinity> But 2 of the 3 issues it claims could be solved by making britney 's/:any//' when looking at deps.
[01:38] <infinity> Then it's just the one cross-arch dep that'll take a head-scratch.
[02:09] <persia> infinity: Removing pq would really do everyone a favor.  Have you looked at the license?  The "source" is a windows executable binary.
[02:09] <persia> (yes, it's acceptable for multiverse, by special extension of policy when it was originally uploaded)
[02:11] <infinity> persia: The source can be anything you want it to be for multiverse, as long as the license allows distribution.
[02:12]  * infinity wonders why we're suddenly talking about removing something...
[02:12] <persia> Yeah, one of the aspects of UFSG that isn't precisely as I'd prefer.
[02:12] <infinity> persia: That has nothing to do with the FSG part, it's the same as Debian non-free.
[02:13] <infinity> persia: In that any old crap can be there as long as it's not actually illegal for it to be.
[02:14] <infinity> (From a licensing perspective, that is)
[02:17] <persia> As much as I'd enjoy a discussion about the difficulty of verification of license compliance in the absence of either textual representations or open-standard metadata specifications for identified binary blobs, I have to go have a tooth pulled now.
[04:17] <morphias> http://developer.ubuntu.com/packaging/html/packaging-new-software.html - i looked at this guide and i am trying to see how i would go about having one *.cpp file for my own program designed just using gedit to having all of the files that are included in the hello-2.7 tar so i would go about developing a debian package...
[04:18] <morphias> can someone help me in packaging like my own idea?
[04:54] <pitti> Good morning
[04:55] <pitti> cjwatson: thanks! I'll see whether I can reproduce them
[06:12] <pitti> xnox: so you are also awake on crazy hours?
[06:32] <smoser> infinity, have you thought any more about https://bugs.launchpad.net/debian/+source/e2fsprogs/+bug/978012
[06:32] <smoser> i was resizing a filesystem on precise from ~ 1.4G to 700+M and it was taking 10s of minutes (i gave up).
[06:33] <smoser> it takes quantal 8 seconds.
[06:40] <infinity> smoser: Hrm, I thought I'd left it in xnox's hands to do some patch auditing. :/
[06:40] <infinity> smoser: I'll catch up with him about it tomorrow and see what we can work out.
[07:51] <dholbach> good morning
[07:59] <pitti> cjwatson: the 2.7 tests run fine for me, and the 3.3 tests don't run at all (KeyError: None in "<frozen importlib._bootstrap>", line 1271, in _path_importer_cache, I'm looking into that)
[08:25] <rbasak> From https://wiki.ubuntu.com/SyncRequestProcess: "Do not change the Status of the bug or put it back to New as package sponsors use this field.". So can I mark a sync request as triaged to get it off a triage report, or will that confuse something?
[08:28] <infinity> rbasak: Sync requests kinda only have three states: new, invalid, fix released.  Cause the only people who should triage them are people who can actually just do the sync, IMO.
[08:28] <infinity> rbasak: With that in mind, bug number?
[08:29] <rbasak> infinity: bug 1080961
[08:30] <rbasak> I can just ignore sync requests in our triage report then. There aren't many of them. And then one day maybe we can modify it to exclude those
[08:30] <rbasak> infinity: dunno if you want to let zul look at it or maybe that doesn't matter
[08:31] <infinity> rbasak: I just synced it, based on the explanation in the bug.
[08:31] <rbasak> infinity: ok, thanks!
[08:31] <infinity> rbasak: It really was based on his work, including his changelog.  It's pretty obviously derivative.
[08:31] <rbasak> Yep
[08:40] <smb> Now how can we get infinity to bed quickly? ... "hot potato"? ;-P
[08:40] <pitti> cjwatson: oh, it's prepending None to sys.path, that's why; fixing..
[08:43] <infinity> smb: You can make my test builds finish so I can prove this glibc testsuite regression is a binutils bug.
[08:43] <infinity> smb: And then you can find the binutils bug.
[08:43] <infinity> smb: And then give me pie.
[08:44] <infinity> (The pie is not optional)
[08:46] <smb> infinity, You could make me core-dev then maybe I had some influence on 1, fur 2 I got no good excuse and about 3 those Canadians have some similar strict customs regulations than the other North Americans. So I am sure you are certain I cannot do it. :)
[08:46] <infinity> smb: core-dev won't help you with number 1, lending me a faster computer might.
[08:47] <infinity> (But I think I'll just watch another episode of Dexter and pass out)
[08:47] <persia> smb: There are 4 pie delivery services in Calgary (of which none are open at this hour)
[08:47] <infinity> persia: I'm shocked that there are any.
[08:47] <smb> infinity, Sounds like a plan.
[08:47] <persia> infinity: There's 6 cookie delivery services :)
[08:48] <smb> persia, Oh, I did not think of delivery service that is local
[08:48] <infinity> persia: My whois info isn't a lie.  Just sayin'.
[08:49] <smb> infinity, So not only strange wake hours... also strange places?
[08:49]  * persia fails at infinity tracking
[08:50] <brendand> whois infinity
[08:50] <smb> who knows
[08:51] <rbasak> dovecot is 1:2.1.7-1ubuntu2 in raring, and 1:2.1.7-5 in sid. So why doesn't it appear in merges.u.c? Is it because the upstream versions are the same, and we don't usually care about merging debian revisions? Except that I don't see anything but a straight version comparison in http://bazaar.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/view/head:/produce-merges.py
[08:53] <persia> rbasak: We actually do care about merging debian revisions: that's where we get the good bits (CVE fixes, cherrypicks for critical bugs, etc.)
[08:53] <persia> (but I don't know the answer to the actual question)
[08:53] <rbasak> OK, thanks. Here, I do (slightly) care about merging a debian revision since it backports a fix to a bug someone filed
[08:54] <persia> That's the common case: most Debian Maintainers don't bother to upload unless there's a good bug fix or a new upstream version.
[08:57] <persia> I think there's something special about dovecot: it doesn't show in mdt either (yes, mdt is tracking wheezy, but that has 1:2.1.7-2, which should list as a merge candidate anyway)
[09:21] <dholbach> diwic, happy birthday! :)
[09:21] <diwic> dholbach, thanks :-)
[09:22] <diwic> all communities needs someone to keep track of other people's birthdays :-)
[09:52] <mlankhorst> I'm playing around with the renamed stack a bit more, installing some -dev packages can wipe it. I think the best fix would be to make the unrenamed mesa dev packages installable with the renamed stack to fix it. Are there even other solutions?
[10:01] <pitti> cjwatson: FYI, jibel pointed out it's a proxy issue; I can reproduce it with http_proxy=http://nonexisting python3 test_auth.py
[10:01] <cjwatson> ah; maybe just unset the proxy for that test then?
[10:01] <pitti> cjwatson: yeah, but it shouldn't use the proxy for localhost in the first place
[10:01] <cjwatson> that too
[10:02] <cjwatson> ooh, I think I might actually have a working cloudy auto-cross-builder
[10:02] <pitti> I'll have a quick look first
[10:02] <cjwatson> minus interface for being able to tell what's going on, but you can't have everything
[10:02] <cjwatson> the important bit is that I can do 'juju add-unit sbuild' and extra builders magically attach themselves and start building stuff
[10:02] <pitti> \o/
[10:02] <pitti> that's the bit that we always wanted
[10:03] <cjwatson> not for LP mind :)
[10:03] <cjwatson> but it's pretty cool for test builds
[10:03] <pitti> cjwatson: like, now we could actually do test rebuilds using the technology we advertise everywhere? :-)
[10:03] <jibel> if proxy is not set, tests that need one will fail. python-apt should honor no_proxy
[10:03] <pitti> jibel: no_proxy is set to something like "localhost"?
[10:04] <cjwatson> well, uh, this is with sbuild + buildd + wanna-build, which ain't exactly the technology we advertise
[10:04] <pitti> cjwatson: right, I meant the cloud bit
[10:04] <pitti> it seems a bit sad to have this at hand, and still block our distro builders for a week for a test rebuild
[10:04] <cjwatson> jibel: python-apt isn't doing the network bits itself - that's gnupg
[10:05] <cjwatson> I'm not saying the test harness should stop setting the proxy
[10:05] <jibel> pitti, I tried it but it makes no difference
[10:05] <cjwatson> I'm saying that one test should unset the proxy for itself, since it knows it's always talking to localhost so it's irrelevant
[10:05] <jibel> right
[10:05] <pitti> jibel: right, I meant what is no_proxy set to in the DC?
[10:05] <jibel> pitti, it is not set
[10:06] <pitti> ah, ok
[10:06] <pitti> bug 789049 FTR
[10:10] <pitti> cjwatson: wrt. our discussion yesterday, we understood it like britney would calculate the reverse dependencies of the package and put them into the request file, minus the uninstallable ones, right?
[10:11] <pitti> cjwatson: in which case we would need test states "pass", "fail", "pending", and additionally "n/a" for pacakges which don't have tests, right? or do you want to look at the XS-Testsuite: field yourself?
[10:12] <pitti> cjwatson: or shall these be computed in the adt scripts?
[10:34] <dholbach> @pilot in
[10:36] <xnox> cjwatson: https://code.launchpad.net/~xnox/charms/precise/sbuild/add-more-options/+merge/135099
[10:36] <seb128> dholbach, \o/
[10:36] <xnox> cjwatson: it adds options to select $home, disabling the bts party thing, supplying custom .mk-sbuild.rc  & .mk-sbuild.sources
[10:37] <xnox> cjwatson: see if any of that fits your charms or not.
[10:53] <cjwatson> pitti: I was expecting britney to call some part of auto-package-testing to do that, which looks at XS-Testsuite; I would actively prefer not to make adt requests for packages that don't need it, since that involves a round trip to the lab before we get to migrate them
[10:54] <cjwatson> pitti: I think it's OK to simply not have any entry in the result file for the "pending" state
[10:54] <cjwatson> xnox: Thanks.  It doesn't conflict, but I think it also doesn't overlap much.  (Although I implemented a rough equivalent of the home handling by just moving /var/lib/buildd to /mnt/buildd in the install hook; yours is cleaner.)
[10:57] <xnox> cjwatson: yeah, that's what I though =) so when are you blogging about your wanna-build charms ? I want to run it for mingw & I bet wookey wants it too =)))))
[10:58] <cjwatson> xnox: I want to polish a bit more and I have some patches to send around
[10:58] <cjwatson> xnox: My understanding is that I'll eventually be taking over auto-cross-builder operation from wookey with this
[10:58] <xnox> cjwatson: also with juju you can share the admin password & then people who have access to the openstack project / ec2 environment can all then ssh into the juju deployment to check up on things.
[10:59] <pitti> cjwatson: ah, so britney would put the reverse depends into the request file, and adt would mark the ones without tests as n/a?
[10:59] <xnox> cjwatson: that you way you can share the cloud administration / poking / troubleshooting between multiple people =)
[10:59] <pitti> cjwatson: I thought you wanted britney to generate the rev dep list (adt could do it by itself as well, but I might have misunderstood you)
[11:00] <pitti> jibel: ^ FYI
[11:00] <pitti> cjwatson: no line for pending> ack, easier
[11:01] <cjwatson> pitti: Other way round - britney will ask some piece of auto-package-testing to generate the initial request file, and then britney will filter it
[11:01] <pitti> cjwatson: ah, ack
[11:02] <pitti> jibel: ^ ok for you?
[11:02] <cjwatson> pitti: that's what we discussed yesterday
[11:02] <cjwatson> xnox: Thanks, but this doesn't help much as the person I'd want to share auto-cross-builder operation with doesn't have access to the cloud in question
[11:02] <cjwatson> xnox: It's OK, I'll work it out :)
[11:02] <pitti> cjwatson: yeah, I initially had that in the "API" part as requests-tests or so, and then we removed it because we said "easier to just use a file format for exchange"; misunderstanding then
[11:03] <cjwatson> Yeah, we were going round in circles a bit
[11:03] <pitti> cjwatson: ok, seems clear now
[11:03] <cjwatson> Imagine the top half of trigger-adt-tests (or whatever it's called - minus the jenkins interaction) being called before the main body of britney starts
[11:03] <pitti> *nod*
[11:04]  * pitti throws a new python-apt archivewards and hopes for some green
[11:04] <cjwatson> Cool, thanks
[11:33] <dholbach> can somebody please reject https://code.launchpad.net/~logan/ubuntu/raring/strigi/debian-merge/+merge/134351 (was merged already)?
[11:35] <zequence> cjwatson: Hi, could I bother you for a moment? I've made a merge request here https://code.launchpad.net/~zequence/ubuntu/raring/jackd2/fix-for-956438/+merge/134771
[11:36] <zequence> I was wondering about the procedure for getting it merged a bit, how long it may take, etc
[11:36] <zequence> This is a fix, that I would like to backport into 12.10 and 12.04 as well
[11:37] <zequence> It's the first patch I've ever made, and may include some abundant code, but this is because I used the upstream commits as they were
[11:38] <cjwatson> zequence: https://wiki.ubuntu.com/SponsorshipProcess
[11:39] <zequence> cjwatson: Thanks
[11:45] <jibel> cjwatson, ok for me. Can I use the same package index files than britney on lillypilly?
[11:46] <jibel> i.e what's in data/raring*
[11:47] <Laney> dholbach: For some reason this was not automatically closed.(?)> that happens upon migration to release
[11:48] <dholbach> Laney, aha! I was too quick :)
[11:48] <dholbach> thanks Laney
[11:48] <Laney> kein problem
[11:51] <dholbach> :-)
[11:54] <zequence> cjwatson: Seems like sponsoring is an automatic procedure now, and a few things on that page are now obsolete. I did follow instructions here http://developer.ubuntu.com/packaging/html/udd-sponsorship.html, and I see that my merge proposal is listed here: http://reqorts.qa.ubuntu.com/reports/sponsoring/
[11:55] <zequence> I would also like to take the opportunity to highlight how important I think this bugfix is
[11:55] <zequence> Especially for 12.04, where people not used to Linux have a terrible time using jackd2
[11:57] <zequence> Backporting to 12.04 will be my next step, if I can get this merge accepted
[12:00] <cjwatson> jibel: Sure
[12:00] <cjwatson> jibel: Or ~/mirror/ubuntu/ if you prefer
[12:01] <cjwatson> zequence: Some bits of it may have been automated, but in general sponsoring is intrinsically non-automatable
[12:49] <zequence> dholbach: Could I ask you for advice on my merge request? I noticed that you are the author of many of those pages :).I'm wondering if there is anything more I should/could do https://code.launchpad.net/~zequence/ubuntu/raring/jackd2/fix-for-956438
[12:50] <zequence> Meaning, many of the doc pages concerning ubuntu development, bug fixing, etc
[12:50] <zequence> dholbach: btw, I'm previously known as ailo (was at UDS to represent Ubuntu Studio)
[13:06]  * mpt wonders how many of <https://bugs.launchpad.net/ubuntu/+source/update-manager?field.searchtext=ubuntu-minimal> are duplicates
[13:18] <brendand> does anyone know where to look for information about different video ports  such as LVDS, DVI, VGA? preferably under /sys
[13:39] <pitti> brendand: /sys/class/drm/card*, but it might not be present on non-KMS drivers
[13:50] <pitti> mvo, cjwatson: il est vert! :-) https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python-apt/
[13:53] <mvo> pitti: \o/
[13:55] <dholbach> zequence, it looks good as far as I can see and turns up in http://reqorts.qa.ubuntu.com/reports/sponsoring/
[13:55] <cjwatson> pitti: yay
[13:56] <xnox> pitti: nice =)
[13:56] <pitti> I have libarchive fixed locally as well
[13:57] <pitti> mvo: any idea what causes the wrong component order in release-upgrader?
[14:01] <zequence> dholbach: Ok, thanks. Then I suppose it will be processed in due time (looks like a que system there).
[14:02] <nobuto> Sweetshark: I would like this issue fixed to be SRUed for precise and quantal. but how can I make the raring task "Fix Released"? Should I make a specific patch to the raring package or do you have a plan to upload 3.6.4 rc1 or higher package (containing the fix) in a few weeks? https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/585910
[14:08] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/x11proto-randr/+bug/1081122
[14:08] <mlankhorst> bug create, now I just upload those packages for precise?
[14:08] <mlankhorst> created*
[14:08] <dholbach> zequence, uploaded
[14:08] <dholbach> @pilot out
[14:08] <dholbach> part 2 of my pilot shift tomorrow
[14:09]  * pitti hugs dholbach
[14:09]  * dholbach hugs pitti back
[14:09]  * OdyX points to new usb-modeswitch{,-*} versions in experimental and wishes the Ubuntu forker some fun. :)
[14:13] <pitti> argh, did upstream still not take the C rewrite?
[14:13] <zequence> dholbach: Thanks a million!
[14:13] <OdyX> why would he?
[14:13] <mvo> pitti: sorry, need to check that out
[14:14] <dholbach> zequence, anytime
[14:14] <pitti> OdyX: I thought cyphermox discussed that with upstream and they reached some agreement
[14:16] <pitti> I mean, there must be some more appropriate language than Tcl that is palatable to upstream..
[14:18] <OdyX> pitti: the libjim solution has a quite small overhead though
[14:18] <pitti> OdyX: if that avoids a tcl dependency, it's already a great step forward indeed
[14:18] <OdyX> 300k , granted.
[14:18] <pitti> it's still slow, but at least smaller
[14:18] <OdyX> pitti: well, that's in Debian since ages.
[14:18] <mlankhorst> I want to sru x11proto-dri2-dev which has 2.8-1 to precise which has 2.6-2, what would be the correct version number? I'm guessing 2.6-2+precise1 or something..
[14:19] <OdyX> we don't care if it's slow btw, it's forked by udev...
[14:19] <pitti> OdyX: right, AFAIR the C port was done "ages" ago, too :)
[14:20] <OdyX> pitti: that's why I'm pointing to regular updates done by upstream. An outdated fork loses interest IMHO.
[14:20] <OdyX> and as I'm not willing to maintain the C fork :-)
[14:21] <pitti> yes, it wasn't meant to be permanent
[14:44] <pitti> mlankhorst: you want to backport the full version, or apply a patch to 2.6-2?
[14:45] <pitti> mlankhorst: in the former case, 2.8-1~precise, in the latter 2.6-2ubuntu1
[14:46] <mlankhorst> ah I had tried 2.8.1~precise1 before I noticed xorg package set only applies to raring :-)
[14:46] <hrw> ok, finally started do-a-release.sh script to bootstrap whole armel/armhf cross compiler
[15:41] <hallyn> slangasek: bug 1080912 - if qemu-kvm.postinst does 'udevadm trigger --action=change' to reset /dev/kvm perms, then if upgading udev and qemu-kvm at the same time that fails.  But only doing that while udev is running doesn't suffice,
[15:41] <hallyn> slangasek: because 'stop udev; start udev' doesn't recalculate the rules
[15:42] <hallyn> is there a way to queue the udevadm trigger?
[15:44] <Sweetsha1k> nobuto: raring will have 4.0.x
[15:45] <apw> hallyn, as in if they are being upgraded at the exact same time ?
[15:46] <hallyn> apw: as in 'sudo apt-get install --reinstall udev qemu-kvm' (to mimic a dist-upgrade), yes
[15:47] <hallyn> apw: or will the udev upgrade do a better job than 'start udev' in reloading the rules?
[15:47] <hallyn> recon i should check its postinst
[15:47] <apw> hallyn, isn't there a dpkg header to say you need something complete before, for example some things say 'i need dpkg upgraded and complete before i start installing'
[15:48] <hallyn> dunno, but that would suffice, googling
[15:49] <hallyn> would that be the predepends?
[15:50] <hallyn> apw: thanks, i'll try that.
[15:52] <apw> hallyn, i cannot tell if you pre-depending on udev will make that complete before, or if that just means must have installed at least once before
[15:53] <hallyn> apw: http://www.debian.org/doc/debian-policy/ch-relationships.html seems to imply it'll complete the update.  but, i'll test here first.
[15:55] <apw> hallyn, i think the second half of the description may bite there, i think that implies 'has installed correctly at least once'
[15:56] <hallyn> apw: heck, maybe a depends would suffice for this.
[15:56] <hallyn> it says depends will ensure it's configured first...
[15:57] <hallyn> and clearly the depends is now required, so a depends would be correct regardless
[15:57] <nobuto> Sweetshark: If the next upload to raring is not scheduled in a few weeks, I would like to fix it in raring with a specific patch. Could you review and upload this debdiff if you have time? https://launchpadlibrarian.net/123530840/debdiff-for-raring.debdiff
[15:57] <apw> worth a short then
[15:58] <hallyn> apw: yup - thanks.
[15:58] <hallyn> (off to mtg)
[16:29]  * apw idly wonders if there is debhelper support for Built-Using in binaries
[16:30] <cjwatson> Doubt it
[16:43] <apw> cjwatson, what is the approved mechanism for adding a built-using to a binary package
[16:43] <apw> or indeed any additional header
[16:44] <cjwatson> apw: just put it in the control file.  see grub2-signed e.g.
[16:44] <apw> cjwatson, thanks
[16:44] <cjwatson> You can use substvars to construct the value
[16:44] <cjwatson> man deb-substvars
[16:46] <apw> cjwatson, oh that is very simplei
[16:46] <apw> indeed
[16:49] <slangasek> hallyn: interesting.  this has never been reported for any other packages that create udev rules
[16:49] <slangasek> (at least not AFAIK)
[16:50] <slangasek> hallyn: ah, solved by making qemu-kvm depend on udev so that the maintainer script ordering is always correct
[16:53] <hallyn> slangasek: right
[16:54] <hallyn> pushed to raring, just gotta get new sru candidates out for the rest :)
[17:02] <apw> cjwatson, i believe that this is what they intended thsi field to say, for raring: "Built-Using: linux (= 3.7.0-2.8)"
[17:06] <cjwatson> apw: seems fair
[17:07] <hrw> ah, b-u... I should start using it for cross compiler
[17:15] <apw> this is going to sound like a stupid question i am sure, but, i assume for a debian 3.0 package with multiple orig files, that all of those files are inviolate once uplaoded as the standard orig is
[17:17] <Daviey> apw: You need to add more detail..
[17:17] <Daviey> apw: You mean, uploading multipe upstream orig's works with our infra?
[17:18] <Daviey> Is that the question?
[17:18] <apw> i mean if a package has liek a foo_xxx.orig.tar.gz and a foo_xxx.orig-bar.tar.gz, i assume the latter is as imutable as the former once uploaded once
[17:19] <Laney> Yes, AFAIK.
[17:19] <Daviey> apw: Ah, you mean.. if you upload a subsequent upload, with the same upstream version, are you safe to upload the diff only?
[17:20] <apw> Daviey, well i am expecting that both orig files have to be the saem and can only be the same from then on, ie. i need to be careful its right
[17:20] <Laney> I would expect your upload to get rejected if they differ
[17:21] <apw> (that matches my expectations, great)
[17:34] <doko> cjwatson, I just did see that I accidentally bypassed -proposed with my doxygen sync from experimental ... should there be a warning?
[17:35] <cjwatson> doko: No, because it only affects archive admins and isn't worth it.  Please update your ubuntu-dev-tools
[17:35] <infinity> doko: You should upgrade ubuntu-dev-tools.
[17:35] <infinity> (This isn't the first time I've pointed it out...)
[17:36] <doko> ok, was using copy-package instead of syncpackage ...
[17:37] <cjwatson> Oh, OK - yes, feel free to add a warning to copy-package if copying into the release pocket of the current series
[17:37] <cjwatson> I think that'd be appropriate
[17:38] <stgraber> if os.environ['USER'] == "doko": print("Use syncpackage!"); sys.exit(1)
[17:40]  * doko slaps stgraber 
[17:43] <cjwatson> hmm, I think we may have lost a cross-build-dep-handling patch from apt ...
[17:43] <cjwatson> but in that case why isn't the test for it failing?
[17:46] <seb128> bdmurray, thanks for catching that gtk upload bug, that diff was not wanted, I've rejected that update and reuploaded a clean version
[17:46] <cjwatson> ah, I wonder if that test is actually run
[18:08] <xnox> stgraber: pyflakes says you are missing "import sys, os;" =)))
[18:08] <stgraber> ;)
[18:13] <hallyn> slangasek: so, if i merge qemu-kvm and qemu-linaro into one source package, with the intent of MIR-ing the packages from qemu-linaro (except qemu-kvm-spice), what order should i go in?  should i first MIR the packages from qemu-linaro source?  i can't have the qemu source produce both main and universe pkgs right?
[18:13] <hallyn> stgraber: ^ q to you as well if you have time
[18:15] <cjwatson> Nothing wrong with a source package in main producing binaries in both main and universe
[18:15] <hallyn> cjwatson: oh??  sorr i thought that wasn't possible,
[18:15] <cjwatson> It is possible.
[18:15] <hallyn> that it auto-promoted the binaries
[18:15] <cjwatson> No.
[18:15] <ScottK> Other way around is not possible
[18:15] <stgraber> hallyn: sounds to me like this is just the equivalent to a source rename (binary packages will be the same), so components for the binaries can remain the same
[18:15] <hallyn> cool!  so i don't really need to do anything in advance?
[18:16] <cjwatson> Exactly.  Binary in main => source in main, but not vice versa.
[18:16] <hallyn> awesome - thanks guys, i was fretting over this :)
[18:22] <kees> hallyn: around?
[18:32] <hallyn> kees: what's up?
[18:33] <hallyn> kees: leaving soon for lunch, so if i don't respond, i'll do so soon as i get back
[18:43] <hallyn> kees: heading off, ttyl
[18:45] <kees> hallyn: eek, missed you. I was curious about your comments on rcu_read_lock(). seems you're right, and I wanted to make sure I understood the requirements correctly.
[19:07] <hallyn> kees: rcu list traversals are always supposed to be done under rcu_read_lock or spinlock
[19:07] <hallyn> doing it under rcu_read_lock will protect you from del and add
[19:08] <hallyn> then the spinlock kjust protects simultaneous adds and dels from each other
[19:09] <kees> hallyn: okay, yeah. looks like there are examples in the kernel of list-walkers not being under rcu_read_lock
[19:09] <kees> (and they're wrong)
[19:10] <kees> docs for list_for_each_entry_rcu say:
[19:10] <kees>  * This list-traversal primitive may safely run concurrently with
[19:10] <kees>  * the _rcu list-mutation primitives such as list_add_rcu()
[19:10] <kees>  * as long as the traversal is guarded by rcu_read_lock().
[19:11] <kees> so, yeah, I think I'm good now -- all list walks are wrapped by rcu_read_lock, and all _del and _add are spinlocked
[19:11] <kees> my problem is that I have 2 list writers. for stuff with a single writer, that writer doesn't need to wrap the list walking in any rcu.
[19:12] <hallyn> kees: what were the bad examples?  i'm dying to know :)
[19:13] <hallyn> kees: note that most of my knowledge of sru is about the early (2004 and thereabouts) versions.  there have been a lot of changes since then.  SRU in parcitular.  that's why i was tentative in my email response :)
[19:14] <kees> hallyn: drivers/base/power/opp.c jumped out at me. walks an rcu list with no read lock
[19:14] <kees> but I couldn't find the writer, so maybe I'm wrong
[19:15] <hallyn> kees: the callers of the fn however say they must be called under rcu_read_lock
[19:16] <hallyn> opp_get_notifier being a notable exception
[19:17] <hallyn> which becomes exposed through an exit hook at drivers/devfreq/exynos4_bus.c
[19:18] <hallyn> i have no idea waht that thing is, but it's buggy :)
[19:18] <hallyn> kees: do you have time to follow up on that?
[19:47] <kees> hallyn: sure, I can do that
[19:51] <maxiaojun> hi, would it be nice if Ubuntu has something like Boot Camp? i'm not requesting work for others, i just want to discuss the idea
[19:51] <sarnold> what's Boot Camp?
[19:52] <micahg> grub?
[19:52] <maxiaojun> an OS X feature that allow users to shrink OS X partition and give room to Windows
[19:52] <micahg> oh, gparted then
[19:52] <sarnold> maxiaojun: lvm2 allows you to resize block storage..
[19:53]  * micahg thought the installer allows that as well
[19:53] <maxiaojun> i use Disk Utility in OS X to shrink OS X partition and install Ubuntu
[19:54] <maxiaojun> the use case i thought is like this
[19:54] <sarnold> micahg: it allows shrinking windows partitions to install ubuntu, though probably not much the other way around -- to shrink ubuntu to allow windows :)
[19:55] <maxiaojun> say non-Linux savvy people buy a computer with Ubuntu pre-installed
[19:55] <hallyn> kees: awesome, thanks
[19:55] <micahg> sarnold: gparted should depending on which fs (whether windows will use what it's given is another story)
[19:55] <sarnold> micahg: heh, good point there. :)
[19:56] <maxiaojun> if we have a nice tool like Boot Camp, Windows dependent people may keep Ubuntu longer
[19:56] <sarnold> I think it should, you're right, re-sizing filesystems has been around for ages (even though it feels like blackmagic to me...)
[19:58] <maxiaojun> but the boot loader can still be a trouble
[19:59] <sarnold> windows especially, it does plan on being the only OS on a machine.
[19:59] <maxiaojun> Mac machines seems to give Windows a emulated MBR environment
[20:01] <micahg> well, if grub could boot lxc containers...
[20:02] <maxiaojun> lxc?
[20:03] <maxiaojun> what's that?
[20:04] <micahg> maybe it's not the right thing....https://help.ubuntu.com/community/LXC
[20:41] <maxiaojun> i feel like a solution would be like this in theory
[20:41] <maxiaojun> so the user want to install Windows
[20:41] <maxiaojun> she use a tool to shrink Ubuntu partition and create a special boot entry in GRUB
[20:42] <maxiaojun> use that boot entry will load Windows installer from DVD-ROM and jail it somehow so it cannot overwrite existing boot loader
[20:43] <sarnold> it'd be easier to use the mbr package to install a known-good bootloader rather than let windows scribble over whatever it wants.. :)
[20:44] <maxiaojun> the problem is that windows installer just overwrite mbr
[20:44] <maxiaojun> you cannot stop it, i guess the same for recent Ubuntu installer
[20:45] <maxiaojun> the difference is that Ubuntu's GRUB try to detect other os and show them in menu, that's it
[21:58] <infinity> doko: You areound?
[21:58] <infinity> doko: Or around?
[21:58] <infinity> doko: Some headers (well, at least one) seem to have gone missing in your GCC package splitting shuffle.
[22:01] <infinity> doko: http://paste.ubuntu.com/1373503/
[22:01] <infinity> doko: Was the new location intended?  If so, glibc's testsuite needs mangling to cope, I think.
[22:10] <infinity> doko: Hrm, could be a bug in glibc's configure, going to test a patch here in a bit.
[22:47] <GunnarHj> slangasek: ping?
[22:50] <infinity> GunnarHj: Pretty sure he's on vacation, unless I have my dates mixed up.
[22:50] <GunnarHj> infinity: Aha, thanks for letting me know.
[22:52] <jdstrand> cjwatson: hey, I am setting up a machine with secure boot and it is telling me that secure boot prohibits use of the normal.mod and drops me to a rescue prompt. rmmod is not available there-- how do I disable normal.mod, or, better, where can I find a grub configuration that is compatible with secure boot?
[22:59] <doko> infinity, yes, intended. I assume it needs changes when -nostdinc is used
[22:59] <infinity> doko: Yeah, working on testing a fix to glibc.
[23:00] <infinity> doko: So, false alarm, sorry for the blame finger, etc. :P
[23:01] <infinity> jdstrand: Our grub2-signed should be compatible, which is vaguely the point of it.
[23:02] <jdstrand> maybe I didn't install everything I needed
[23:02] <doko> I filed a bug for clang, forgot about glibc
[23:04] <jdstrand> hmm, I have grub-efi-amd64-signed
[23:08] <mercury00> I think this is a channel to ask about reprepro?
[23:08] <infinity> mercury00: Seems unlikely.
[23:08] <mercury00> sorry
[23:09] <infinity> S'ok.  Not sure if they have a channel of their own, but user channels like #ubuntu (on freenode) and #debian (on oftc) might be a better choice.
[23:09] <mercury00> ok , thanks!
[23:13] <jdstrand> cjwatson: I think the actuall problem is I am not using grub-efi-amd64-signed correctly (I am setting up secure boot in an ovmf image after the fact)
[23:20] <doko> kees, jdstrand: there is a second issue, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55395
[23:21] <doko> this appears only when the compiler defaults to -fstack-protector
[23:21] <jdstrand> sbeattie, sarnold: ^
[23:21] <doko> kees, I assume the google test build were done without gfortran?
[23:33]  * sarnold rubs his eyes
[23:34] <sarnold> how would -fstack-protector cause a 'section type conflict' for a static const variable? O_o
[23:34] <sarnold> doko: have you had a chance to test that untested patch?
[23:35] <doko> sarnold, doesn't change anything
[23:36] <sarnold> doko: somehow I'm not too surprised.
[23:36] <doko> sarnold, the recent gcc-snapshot build has the same patches as my gcc-4.8 build, just the hardening patches disabled
[23:36] <doko> so I'd say miscompilation of cc1 with -fstack-protector
[23:45] <RAOF> doko: I'd like to push the gcc-4.6 SRU for precise into precise-proposed, but https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/972648 is missing instructions for the test case. Could you please clarify that bug, then I'll accept it from the queue?
[23:46] <doko> RAOF, let me look at this tomorrow, not tonight anymore
[23:46] <RAOF> doko: No problem; it just looked like it was an important SRU that's been waiting around for too long :)
[23:47] <doko> yeah, I wasn't following up as well
[23:52] <infinity> RAOF: Actually, doko had promised me a fresh upload fixing one more bug...
[23:53] <infinity> Though, he probably forgot. :P