=== cpg|away is now known as cpg [00:30] Could someone manually move wine1.4 through britney [00:30] It's been waiting there for weeks now [00:30] and I have SRUs sorta depending on it [00:32] Let me just do a couple of manual checks then [00:37] Oh, meh, I'd meant to get to that. [00:37] And also to ask for a crash-source in hinting. [00:37] s/source/course/ [00:38] 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] 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] (force-hint: "try anyway even if it increases uninstallability") [00:40] (as opposed to plain force which is "ignore excuses") [00:41] cjwatson: So, basically of the format "some-action: source/version"? [00:41] I guess it might need force as well as force-hint, but try it without first. [00:41] cjwatson: Where some-action is RTFS? [00:41] Minus the colon, but yes. [00:41] Oh, right. [00:42] Reading, not my strong suit. [00:42] But boy, you should see me type. [00:42] Totally makes up for it. [00:42] Oh look, found it. http://ftp-master.debian.org/testing/hints/README [00:43] infinity: ^- [00:43] cjwatson: *nod* Already read. [00:43] Or, skimmed. [00:43] Skum? [00:43] Already skum. [00:44] geskommen [00:44] * infinity salutes. [00:44] I think. [00:50] Hrm. Looks like britney needs to learn what :any means. [00:50] 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] YokoZar: So, testing this in a raring chroot with proposed enabled, it's not installable anyway... [00:59] Oh, or this chroot is sad. Sec. [01:01] Okay, that works better... [01:04] 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] infinity: Thank you :) [01:22] YokoZar: Also, I'm uploading to clean up that cruft that drives me insane every time I look at the diff. [01:22] YokoZar: But I'll make sure this all migrates. :P [01:23] infinity: Please do. I was gonna decruft it myself but it took a while waiting ;) [01:24] YokoZar: Also, britney does warn of: [01:24] YokoZar: * i386: dssi-vst, lmms, pptview, pq, wine, wine1.4, wine1.4-dbg, wine1.4-dev, wine1.4-i386 [01:24] 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] please install pq [01:25] it is a fantastic troll package [01:28] 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] YokoZar: I'll pass on PQ for now. :) [01:28] pq is very very silly [01:29] The FAQ alone was silly. [01:29] 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] infinity: it's because he literally lost the source [01:30] persia: I hope you're enjoying the fact that pq is affecting us again [01:30] YokoZar: https://bitbucket.org/grumdrig/pq implies he found it again. :) [01:36] 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] Still, would be nice if we could make it look less broken in the eyes of britney. [01:37] infinity: you could remove pq :P [01:38] 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] But 2 of the 3 issues it claims could be solved by making britney 's/:any//' when looking at deps. [01:38] Then it's just the one cross-arch dep that'll take a head-scratch. === attente is now known as attente_zzz [02:09] infinity: Removing pq would really do everyone a favor. Have you looked at the license? The "source" is a windows executable binary. [02:09] (yes, it's acceptable for multiverse, by special extension of policy when it was originally uploaded) [02:11] 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] Yeah, one of the aspects of UFSG that isn't precisely as I'd prefer. [02:12] persia: That has nothing to do with the FSG part, it's the same as Debian non-free. [02:13] persia: In that any old crap can be there as long as it's not actually illegal for it to be. [02:14] (From a licensing perspective, that is) === fenris is now known as Guest34244 [02:17] 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. === fenris is now known as Guest9079 === micahg_ is now known as micahg [04:17] 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] can someone help me in packaging like my own idea? [04:54] Good morning [04:55] cjwatson: thanks! I'll see whether I can reproduce them [06:12] xnox: so you are also awake on crazy hours? [06:32] infinity, have you thought any more about https://bugs.launchpad.net/debian/+source/e2fsprogs/+bug/978012 [06:32] Launchpad bug 978012 in e2fsprogs (Ubuntu Precise) "Please SRU micro bug fix release of e2fsprogs 1.42.4-3ubuntu1 (main) from Quantal (main)" [High,Confirmed] [06:32] 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] it takes quantal 8 seconds. [06:40] smoser: Hrm, I thought I'd left it in xnox's hands to do some patch auditing. :/ [06:40] smoser: I'll catch up with him about it tomorrow and see what we can work out. === jvw_ is now known as jvw [07:51] good morning [07:59] cjwatson: the 2.7 tests run fine for me, and the 3.3 tests don't run at all (KeyError: None in "", line 1271, in _path_importer_cache, I'm looking into that) === tkamppeter_ is now known as tkamppeter [08:25] 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] 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] rbasak: With that in mind, bug number? [08:29] infinity: bug 1080961 [08:29] Launchpad bug 1080961 in python-setuptools-git (Ubuntu) "Sync python-setuptools-git 0.4.2-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1080961 [08:30] 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] infinity: dunno if you want to let zul look at it or maybe that doesn't matter [08:31] rbasak: I just synced it, based on the explanation in the bug. [08:31] infinity: ok, thanks! [08:31] rbasak: It really was based on his work, including his changelog. It's pretty obviously derivative. [08:31] Yep [08:40] Now how can we get infinity to bed quickly? ... "hot potato"? ;-P [08:40] cjwatson: oh, it's prepending None to sys.path, that's why; fixing.. [08:43] smb: You can make my test builds finish so I can prove this glibc testsuite regression is a binutils bug. [08:43] smb: And then you can find the binutils bug. [08:43] smb: And then give me pie. [08:44] (The pie is not optional) [08:46] 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] smb: core-dev won't help you with number 1, lending me a faster computer might. [08:47] (But I think I'll just watch another episode of Dexter and pass out) [08:47] smb: There are 4 pie delivery services in Calgary (of which none are open at this hour) [08:47] persia: I'm shocked that there are any. [08:47] infinity, Sounds like a plan. [08:47] infinity: There's 6 cookie delivery services :) [08:48] persia, Oh, I did not think of delivery service that is local [08:48] persia: My whois info isn't a lie. Just sayin'. [08:49] infinity, So not only strange wake hours... also strange places? [08:49] * persia fails at infinity tracking [08:50] whois infinity [08:50] who knows [08:51] 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] 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] (but I don't know the answer to the actual question) [08:53] OK, thanks. Here, I do (slightly) care about merging a debian revision since it backports a fix to a bug someone filed [08:54] 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] 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] diwic, happy birthday! :) [09:21] dholbach, thanks :-) [09:22] all communities needs someone to keep track of other people's birthdays :-) [09:52] 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] 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] ah; maybe just unset the proxy for that test then? [10:01] cjwatson: yeah, but it shouldn't use the proxy for localhost in the first place [10:01] that too [10:02] ooh, I think I might actually have a working cloudy auto-cross-builder [10:02] I'll have a quick look first [10:02] minus interface for being able to tell what's going on, but you can't have everything [10:02] the important bit is that I can do 'juju add-unit sbuild' and extra builders magically attach themselves and start building stuff [10:02] \o/ [10:02] that's the bit that we always wanted [10:03] not for LP mind :) [10:03] but it's pretty cool for test builds [10:03] cjwatson: like, now we could actually do test rebuilds using the technology we advertise everywhere? :-) [10:03] if proxy is not set, tests that need one will fail. python-apt should honor no_proxy [10:03] jibel: no_proxy is set to something like "localhost"? [10:04] well, uh, this is with sbuild + buildd + wanna-build, which ain't exactly the technology we advertise [10:04] cjwatson: right, I meant the cloud bit [10:04] 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] jibel: python-apt isn't doing the network bits itself - that's gnupg [10:05] I'm not saying the test harness should stop setting the proxy [10:05] pitti, I tried it but it makes no difference [10:05] 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] right [10:05] jibel: right, I meant what is no_proxy set to in the DC? [10:05] pitti, it is not set [10:06] ah, ok [10:06] bug 789049 FTR [10:06] Launchpad bug 789049 in gnupg (Ubuntu) "gpgkeys doesn't find the key thru http proxy" [Undecided,Confirmed] https://launchpad.net/bugs/789049 [10:10] 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] 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] cjwatson: or shall these be computed in the adt scripts? [10:34] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [10:36] cjwatson: https://code.launchpad.net/~xnox/charms/precise/sbuild/add-more-options/+merge/135099 [10:36] dholbach, \o/ [10:36] cjwatson: it adds options to select $home, disabling the bts party thing, supplying custom .mk-sbuild.rc & .mk-sbuild.sources [10:37] cjwatson: see if any of that fits your charms or not. [10:53] 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] pitti: I think it's OK to simply not have any entry in the result file for the "pending" state [10:54] 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] 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] xnox: I want to polish a bit more and I have some patches to send around [10:58] xnox: My understanding is that I'll eventually be taking over auto-cross-builder operation from wookey with this [10:58] 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] 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] cjwatson: that you way you can share the cloud administration / poking / troubleshooting between multiple people =) [10:59] 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] jibel: ^ FYI [11:00] cjwatson: no line for pending> ack, easier [11:01] 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] cjwatson: ah, ack [11:02] jibel: ^ ok for you? [11:02] pitti: that's what we discussed yesterday [11:02] 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] xnox: It's OK, I'll work it out :) [11:02] 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] Yeah, we were going round in circles a bit [11:03] cjwatson: ok, seems clear now [11:03] 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] *nod* [11:04] * pitti throws a new python-apt archivewards and hopes for some green [11:04] Cool, thanks === _salem is now known as salem_ === Tonio_aw is now known as Tonio__ [11:33] can somebody please reject https://code.launchpad.net/~logan/ubuntu/raring/strigi/debian-merge/+merge/134351 (was merged already)? [11:35] 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] I was wondering about the procedure for getting it merged a bit, how long it may take, etc [11:36] This is a fix, that I would like to backport into 12.10 and 12.04 as well [11:37] 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] zequence: https://wiki.ubuntu.com/SponsorshipProcess [11:39] cjwatson: Thanks === Tonio__ is now known as Tonio_aw [11:45] cjwatson, ok for me. Can I use the same package index files than britney on lillypilly? [11:46] i.e what's in data/raring* === Tonio_aw is now known as Tonio__ [11:47] dholbach: For some reason this was not automatically closed.(?)> that happens upon migration to release [11:48] Laney, aha! I was too quick :) [11:48] thanks Laney [11:48] kein problem [11:51] :-) [11:54] 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] I would also like to take the opportunity to highlight how important I think this bugfix is [11:55] Especially for 12.04, where people not used to Linux have a terrible time using jackd2 [11:57] Backporting to 12.04 will be my next step, if I can get this merge accepted === Sweetsha1k is now known as Sweetshark [12:00] jibel: Sure [12:00] jibel: Or ~/mirror/ubuntu/ if you prefer [12:01] zequence: Some bits of it may have been automated, but in general sponsoring is intrinsically non-automatable === Quintasan_ is now known as Quintasan === mdeslaur_ is now known as mdeslaur === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ [12:49] 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] Meaning, many of the doc pages concerning ubuntu development, bug fixing, etc [12:50] dholbach: btw, I'm previously known as ailo (was at UDS to represent Ubuntu Studio) === attente_zzz is now known as attente === mcclurmc_ is now known as mcclurmc [13:06] * mpt wonders how many of are duplicates [13:18] does anyone know where to look for information about different video ports such as LVDS, DVI, VGA? preferably under /sys [13:39] brendand: /sys/class/drm/card*, but it might not be present on non-KMS drivers === cpg is now known as cpg|away [13:50] mvo, cjwatson: il est vert! :-) https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python-apt/ [13:53] pitti: \o/ [13:55] zequence, it looks good as far as I can see and turns up in http://reqorts.qa.ubuntu.com/reports/sponsoring/ [13:55] pitti: yay [13:56] pitti: nice =) [13:56] I have libarchive fixed locally as well [13:57] mvo: any idea what causes the wrong component order in release-upgrader? [14:01] dholbach: Ok, thanks. Then I suppose it will be processed in due time (looks like a que system there). [14:02] 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:02] Launchpad bug 585910 in libreoffice (Ubuntu) "[Upstream] Impress Font fuzzy in presentation mode when Use hardware acceleration enabled" [Medium,In progress] [14:08] https://bugs.launchpad.net/ubuntu/+source/x11proto-randr/+bug/1081122 [14:08] Launchpad bug 1081122 in x11proto-randr (Ubuntu) "x11proto-(gl,randr,dri2)-dev need to be updated for backport stack" [High,New] [14:08] bug create, now I just upload those packages for precise? [14:08] created* [14:08] zequence, uploaded [14:08] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [14:08] 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] argh, did upstream still not take the C rewrite? [14:13] dholbach: Thanks a million! [14:13] why would he? [14:13] pitti: sorry, need to check that out [14:14] zequence, anytime [14:14] OdyX: I thought cyphermox discussed that with upstream and they reached some agreement [14:16] I mean, there must be some more appropriate language than Tcl that is palatable to upstream.. [14:18] pitti: the libjim solution has a quite small overhead though [14:18] OdyX: if that avoids a tcl dependency, it's already a great step forward indeed [14:18] 300k , granted. [14:18] it's still slow, but at least smaller [14:18] pitti: well, that's in Debian since ages. [14:18] 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] we don't care if it's slow btw, it's forked by udev... [14:19] OdyX: right, AFAIR the C port was done "ages" ago, too :) [14:20] pitti: that's why I'm pointing to regular updates done by upstream. An outdated fork loses interest IMHO. [14:20] and as I'm not willing to maintain the C fork :-) [14:21] yes, it wasn't meant to be permanent [14:44] mlankhorst: you want to backport the full version, or apply a patch to 2.6-2? [14:45] mlankhorst: in the former case, 2.8-1~precise, in the latter 2.6-2ubuntu1 [14:46] ah I had tried 2.8.1~precise1 before I noticed xorg package set only applies to raring :-) [14:46] ok, finally started do-a-release.sh script to bootstrap whole armel/armhf cross compiler [15:41] 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] Launchpad bug 1080912 in qemu-kvm (Ubuntu Raring) "package qemu-kvm 1.0+noroms-0ubuntu14.4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Critical,In progress] https://launchpad.net/bugs/1080912 [15:41] slangasek: because 'stop udev; start udev' doesn't recalculate the rules [15:42] is there a way to queue the udevadm trigger? [15:44] nobuto: raring will have 4.0.x === Sweetsha1k is now known as Sweetshark [15:45] hallyn, as in if they are being upgraded at the exact same time ? [15:46] apw: as in 'sudo apt-get install --reinstall udev qemu-kvm' (to mimic a dist-upgrade), yes [15:47] apw: or will the udev upgrade do a better job than 'start udev' in reloading the rules? [15:47] recon i should check its postinst [15:47] 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] dunno, but that would suffice, googling [15:49] would that be the predepends? [15:50] apw: thanks, i'll try that. [15:52] 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] 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] hallyn, i think the second half of the description may bite there, i think that implies 'has installed correctly at least once' [15:56] apw: heck, maybe a depends would suffice for this. [15:56] it says depends will ensure it's configured first... [15:57] and clearly the depends is now required, so a depends would be correct regardless [15:57] 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] worth a short then [15:58] apw: yup - thanks. [15:58] (off to mtg) === deryck is now known as deryck[lunch] [16:29] * apw idly wonders if there is debhelper support for Built-Using in binaries [16:30] Doubt it [16:43] cjwatson, what is the approved mechanism for adding a built-using to a binary package [16:43] or indeed any additional header [16:44] apw: just put it in the control file. see grub2-signed e.g. [16:44] cjwatson, thanks [16:44] You can use substvars to construct the value [16:44] man deb-substvars [16:46] cjwatson, oh that is very simplei [16:46] indeed [16:49] hallyn: interesting. this has never been reported for any other packages that create udev rules [16:49] (at least not AFAIK) [16:50] hallyn: ah, solved by making qemu-kvm depend on udev so that the maintainer script ordering is always correct [16:53] slangasek: right [16:54] pushed to raring, just gotta get new sru candidates out for the rest :) [17:02] cjwatson, i believe that this is what they intended thsi field to say, for raring: "Built-Using: linux (= 3.7.0-2.8)" === yofel_ is now known as yofel === Tonio_ is now known as Tonio_aw [17:06] apw: seems fair [17:07] ah, b-u... I should start using it for cross compiler [17:15] 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] apw: You need to add more detail.. [17:17] apw: You mean, uploading multipe upstream orig's works with our infra? [17:18] Is that the question? [17:18] 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] Yes, AFAIK. [17:19] 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] 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] I would expect your upload to get rejected if they differ [17:21] (that matches my expectations, great) === doko_ is now known as doko [17:34] cjwatson, I just did see that I accidentally bypassed -proposed with my doxygen sync from experimental ... should there be a warning? [17:35] doko: No, because it only affects archive admins and isn't worth it. Please update your ubuntu-dev-tools [17:35] doko: You should upgrade ubuntu-dev-tools. [17:35] (This isn't the first time I've pointed it out...) [17:36] ok, was using copy-package instead of syncpackage ... [17:37] Oh, OK - yes, feel free to add a warning to copy-package if copying into the release pocket of the current series [17:37] I think that'd be appropriate [17:38] if os.environ['USER'] == "doko": print("Use syncpackage!"); sys.exit(1) [17:40] * doko slaps stgraber [17:43] hmm, I think we may have lost a cross-build-dep-handling patch from apt ... [17:43] but in that case why isn't the test for it failing? [17:46] 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] ah, I wonder if that test is actually run === deryck[lunch] is now known as deryck [18:08] stgraber: pyflakes says you are missing "import sys, os;" =))) [18:08] ;) [18:13] 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] stgraber: ^ q to you as well if you have time [18:15] Nothing wrong with a source package in main producing binaries in both main and universe [18:15] cjwatson: oh?? sorr i thought that wasn't possible, [18:15] It is possible. [18:15] that it auto-promoted the binaries [18:15] No. [18:15] Other way around is not possible [18:15] 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] cool! so i don't really need to do anything in advance? [18:16] Exactly. Binary in main => source in main, but not vice versa. [18:16] awesome - thanks guys, i was fretting over this :) [18:22] hallyn: around? [18:32] kees: what's up? [18:33] kees: leaving soon for lunch, so if i don't respond, i'll do so soon as i get back [18:43] kees: heading off, ttyl [18:45] 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] kees: rcu list traversals are always supposed to be done under rcu_read_lock or spinlock [19:07] doing it under rcu_read_lock will protect you from del and add [19:08] then the spinlock kjust protects simultaneous adds and dels from each other [19:09] hallyn: okay, yeah. looks like there are examples in the kernel of list-walkers not being under rcu_read_lock [19:09] (and they're wrong) [19:10] docs for list_for_each_entry_rcu say: [19:10] * This list-traversal primitive may safely run concurrently with [19:10] * the _rcu list-mutation primitives such as list_add_rcu() [19:10] * as long as the traversal is guarded by rcu_read_lock(). [19:11] 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] 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] kees: what were the bad examples? i'm dying to know :) [19:13] 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] hallyn: drivers/base/power/opp.c jumped out at me. walks an rcu list with no read lock [19:14] but I couldn't find the writer, so maybe I'm wrong [19:15] kees: the callers of the fn however say they must be called under rcu_read_lock [19:16] opp_get_notifier being a notable exception [19:17] which becomes exposed through an exit hook at drivers/devfreq/exynos4_bus.c [19:18] i have no idea waht that thing is, but it's buggy :) [19:18] kees: do you have time to follow up on that? === glebihan_ is now known as glebihan [19:47] hallyn: sure, I can do that [19:51] 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] what's Boot Camp? [19:52] grub? [19:52] an OS X feature that allow users to shrink OS X partition and give room to Windows [19:52] oh, gparted then [19:52] maxiaojun: lvm2 allows you to resize block storage.. [19:53] * micahg thought the installer allows that as well [19:53] i use Disk Utility in OS X to shrink OS X partition and install Ubuntu [19:54] the use case i thought is like this [19:54] 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] say non-Linux savvy people buy a computer with Ubuntu pre-installed [19:55] kees: awesome, thanks [19:55] sarnold: gparted should depending on which fs (whether windows will use what it's given is another story) [19:55] micahg: heh, good point there. :) [19:56] if we have a nice tool like Boot Camp, Windows dependent people may keep Ubuntu longer [19:56] 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] but the boot loader can still be a trouble [19:59] windows especially, it does plan on being the only OS on a machine. [19:59] Mac machines seems to give Windows a emulated MBR environment [20:01] well, if grub could boot lxc containers... [20:02] lxc? [20:03] what's that? [20:04] maybe it's not the right thing....https://help.ubuntu.com/community/LXC === Tonio_aw is now known as Tonio_ === cpg|away is now known as cpg === salem_ is now known as _salem === cpg is now known as cpg|away [20:41] i feel like a solution would be like this in theory [20:41] so the user want to install Windows [20:41] she use a tool to shrink Ubuntu partition and create a special boot entry in GRUB [20:42] use that boot entry will load Windows installer from DVD-ROM and jail it somehow so it cannot overwrite existing boot loader [20:43] 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] the problem is that windows installer just overwrite mbr [20:44] you cannot stop it, i guess the same for recent Ubuntu installer [20:45] the difference is that Ubuntu's GRUB try to detect other os and show them in menu, that's it === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ [21:58] doko: You areound? [21:58] doko: Or around? [21:58] doko: Some headers (well, at least one) seem to have gone missing in your GCC package splitting shuffle. [22:01] doko: http://paste.ubuntu.com/1373503/ [22:01] doko: Was the new location intended? If so, glibc's testsuite needs mangling to cope, I think. [22:10] doko: Hrm, could be a bug in glibc's configure, going to test a patch here in a bit. === pcarrier_ is now known as pcarrier [22:47] slangasek: ping? [22:50] GunnarHj: Pretty sure he's on vacation, unless I have my dates mixed up. [22:50] infinity: Aha, thanks for letting me know. [22:52] 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] infinity, yes, intended. I assume it needs changes when -nostdinc is used [22:59] doko: Yeah, working on testing a fix to glibc. [23:00] doko: So, false alarm, sorry for the blame finger, etc. :P [23:01] jdstrand: Our grub2-signed should be compatible, which is vaguely the point of it. [23:02] maybe I didn't install everything I needed [23:02] I filed a bug for clang, forgot about glibc [23:04] hmm, I have grub-efi-amd64-signed [23:08] I think this is a channel to ask about reprepro? [23:08] mercury00: Seems unlikely. [23:08] sorry [23:09] 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] ok , thanks! [23:13] 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] kees, jdstrand: there is a second issue, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55395 [23:20] gcc.gnu.org bug 55395 in fortran "[4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi" [Normal,Unconfirmed] [23:21]