[00:09] cjwatson: feel free to redirect to jibel, who's not currently online :) The u-m autopkgtest is failing on amd64, apparently because it's managing to be run while the dependencies aren't consistent on amd64 in -proposed. What's the right fix for this? https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-update-manager/ARCH=amd64,label=adt/37/ [00:20] psusi: so, if I change the version number field, the kernel rejects the partition table ;) [00:20] slangasek, ohh fudge... you also have to update the crc ;) [00:22] hm! [00:22] well [00:22] that will be a challenge, won't it [00:22] considering android's dd doesn't even want to write to a block device [00:25] https://bugs.launchpad.net/touch-preview-images/+bug/1190792 [00:25] Launchpad bug 1190792 in touch-preview-images "ueventd in a busy loop on container-flipped image" [Undecided,New] [00:25] oops, ECHAN [00:26] psusi: right, so I'm even less enthusiastic now about doing this all by hand rather than being able to use parted for the task ;) [00:27] however, I did manage to reset the bit to 0, so the N7 is bootable again [00:27] slangasek, then I'd say just comment out the version check in parted and build a local version for hacking purposes ;) [00:27] mmmk [00:28] psusi: but you won't want these patches in the Ubuntu build, I take it [00:28] because this is code that's meant to be part of the Ubuntu Touch bootstrap [00:28] well, it would be a dirty hack that you would have to key to the dmi of the device or something, and wouldn't be accepted upstream that's for sure [00:29] what about a patch to support writing only to the alternate gpt? [00:30] I don't think so [00:30] blah [00:31] I think if you really want ubuntu's parted to work on this thing it would take a dmi specific hack to notice that the existing partition is this screwed up thing with version 0 and mo primary, and set a flag to remember to write it back with 0 version and only to the backup [00:32] that really is terribly dirty of them not to have a primary at all... should at least have it located somewhere else [00:33] then at least it would be somewhat sane for parted to find the backup, and just note that hey, the primary is in a weird place, but otherwise looks valid, so ok... I'll leave it there [00:33] well, arguably the kernel patch they have declares that this *is* the primary gpt [00:34] ... and it just happens to be located in the defined location of the alternate gpt :P [00:34] I think the error gdisk gave would be different if that were the case [00:34] you can tell for sure by looking at the value of mylba and altlba in the header... [00:35] my_lba: FF EF D1 01; alternate_lba: 00 00 00 00 [00:36] er, sorry [00:36] my_lba: EF EF D1 01 00 00 00 00; alternate_lba: 01 34 00 00 00 00 00 00 [00:38] there was someone who was working on a patch lately that had to do with arm needing u-boot in sector 2 so the primary needed relocated [00:38] so that translates to 30535663, which is 17 sectors before the end of the disk? [00:38] (30535680 total sectors) [00:38] 16 sectors, rather [00:38] but that at least still had a pmbr and primary header in sectors 0-1, and the table started in sector 3 instead, which is odd, but valid [00:39] hrm.. it should be the last sector of the disk I thought? [00:40] dunno [00:40] this gives me a whole lotta zeroes: dd if=/dev/block/mmcblk0 of=/data/gpt-primary.img bs=512 count=4 skip=30535663 [00:41] is there some reason that would be offset from somewhere other than sector 0? [00:42] no, all offsets have to be relative to the start of the device [00:42] well, then I guess that field's invalid too ;) [00:43] I wonder what I'll find at offset 13313? [00:43] you sure you are looking at the right fields? one of them sure as shit should be the block number where you actually found the thing, which you said before was the last sector of the drive ;) [00:43] 00000600 45 46 49 20 50 41 52 54 00 00 00 00 5C 00 00 00 EFI PART....\... [00:43] 00000610 30 21 A2 EE 00 00 00 00 FF EF D1 01 00 00 00 00 0!.............. [00:43] 00000620 01 34 00 00 00 00 00 00 00 3C 00 00 00 00 00 00 .4.......<...... [00:43] and if it didn't, it looks like the kernel would reject it [00:44] FF EF D1 01 -> 30535663, which is 16 sectors short [00:45] and the kernel is booted with gpt_sector=30535679 [00:46] that is weird [00:50] yeah, and I can confirm that this kernel has a check for my_lba == lba [00:50] is is_gpt_valid() [00:50] (branch 'grouper' on git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git, fwiw) [00:51] oh, y'know what [00:52] I'm not sure how, but I got the hex->dec conversion wrong [00:52] FF EF D1 01 -> 30535679 after all [00:52] so - yes, it claims to be the primary gpt, not the alternate [00:53] and the address given for the alternate GPT is empty [00:54] iirc, that's actually what the alt is supposed to look like... it says my_lba = wherever it's at, and the alt points to the *other* copy [00:55] oh, then how can you tell the difference between the primary and the alt anyway? [00:56] whether you found it at the beginning of the disk, or (end of disk, or what the primary says is alt_lba) [00:56] so if the primary was just in an odd place, but the backup was at the end, then you could at least find the primary by what the backup says is the alt, and at least decide the situation is sane, just weird [00:57] but it looks like this guy just flat how has no primary [00:58] it has the "primary", which is at the end, which is where the kernel argument says to look for it [00:58] I don't see the point in calling it an alternate when it's not an alternate to anything [00:58] kernel argument just says find *one* here... not which it is [00:59] the other thing about the backup is that the header follows the table, instead of the other way around.. but really, which one is which is just semantics [01:03] well, but that's convention; the GPT header *could* point anywhere for the GPT entries, and in the case of a GPT header in the last sector, it will always point somewhere earlier [01:04] right... and in this case, it points to the normal location of 0, only there isn't another header there [01:04] err, wait... no... [01:04] nah, it points to 13313, which is empty [01:05] ahh... man... this just gets weirder and weirder... [01:05] they bothered pointing it somewhere, but didn't actually put a copy there === _salem is now known as salem_ [01:23] psusi: ok, so as near as I can tell, libparted doesn't actually care about the version field either [01:23] it only objects if the value is too new [01:25] weird.. looks to be that way [01:26] I wonder why it's rejecting it then... [01:26] dunno, checking now === Logan_ is now known as Guest85841 === Guest54086 is now known as Logan_ === Logan_ is now known as Guest128 === jono is now known as Guest3821 === salem_ is now known as _salem [03:47] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [05:28] Good morning [05:29] bdmurray: traditionally we have done it for alpha-2, but with our changed devel process that doesn't apply much any more; I'll ask the team TLs (Daviey, seb128, cjwatson) later today when they are online, and also ev [06:15] anyone know what 'unix-zany' refers to on libpam-cracklib's pam-config Conflicts? [06:57] good morning [07:05] hey dholbach, guten Morgen [07:17] hey pitti === smb` is now known as smb [07:34] seb128: Hey, guess whose compiz has crashed twice in the last two days? :/ [07:35] infinity, not me! [07:35] seb128: :P [07:36] infinity, I think Trevinho fixed the issue, but there was no bamf landing since... [07:36] * infinity loves how it resizes and scatters all his windows. [07:36] sil2100, ^ do you know what's blocking that fix to land? [07:38] seb128, infinity: hi! Sadly, bamf is part of the indicator stack, and it would be safest to land both unity and indicators together, since otherwise there is a chance things might get broken [07:38] sil2100, what is blocking unity and indicator from landing? ;-) [07:38] And we still had a lot of regressions in Unity due to HUD, but I guess there's a chance that today we'll be able to land [07:38] sil2100, oh, and hey ;-) [07:38] great! [07:39] Let me just check the stacks status right now, I'm hoping for the best :) [07:45] sil2100: hey! FYI, as you forced the merge of indicator-datetime yesterday, everything was stuck this morning (as libical is still not in the release pocket) [07:45] sil2100: so I added -proposed to the daily-build ppa (but we'll still need to convince upstream to add it to their CI) [07:47] didrocks: wait, so -proposed was not enabled for daily-build as well? [07:47] didrocks: my understanding was that it was missing from CI, but not from our PPA [07:47] sil2100: no, I didn't know that was possible, just checked this morning with infinity and enabled [07:48] sil2100: that's why https://jenkins.qa.ubuntu.com/job/cu2d-indicators-head-2.1build/216/console took so long [07:48] (however libdbusmenu FTBFS) [07:49] hum, seems to be a failure to upload, lauchpad issue then [07:49] launchpad* [07:58] barry: is your python3 dbus tree in active development? [08:02] sil2100: so, I guess for libdbusmenu, you would need to retry the build in launchpad and then rerun with "foo" to take it into account [08:04] didrocks: ACK, will do that, since I'm anyway doing the stackzz now [08:05] pitti, can you jump over to #ubuntu-mir? got a question around logind/systemd [08:07] tvoss, he said he had to go out for some errands half an hour ago, he might not be back yet [08:07] seb128, okay, thanks [08:42] slangasek: That update-manager autopkgtest run predated the proposed-migration integration; it should probably just be retried, which perhaps jibel can take care of (I'm not sure whether me abusing adt-britney to do so would have strange side-effects) [08:45] cjwatson, retrying update-manager [08:46] Thanks [08:47] jibel: Did you get anywhere with making the jenkins integration return running autopkgtests? I'm waiting to see that working properly before announcing this work [08:49] cjwatson, I'm on it this morning, expect something early afternoon. [08:49] Brilliant === Sweetsha1k is now known as Sweetshark [09:47] ev: looks like there is a segfault due to some weird reason. I have updated the MP with the backtrace. Even rico had the same segfault, but none of these segfaults happen on clean VMs. but they crash when used on regular installs (being used for some long time) [09:47] m4n1sh: yeah, I saw the MP. Working through it myself, but temporarily pulled over to some deployment work [09:47] ev: no issues, just thought of asking in case you were free. Anyway I need to sleep [09:48] m4n1sh: enjoy :) I'll have something done for you to review in your morning [09:54] tvoss: I'm back [09:54] pitti, hey there, can you hop over to #ubuntu-mir, we have got some systemd questions about seat management === iainfarrell1 is now known as iainfarrell === doko__ is now known as doko === vibhav is now known as Guest85528 === oSoMoN is now known as oSoMoN|afk [11:10] cjwatson: i assume there has been quite some discussion in debian etc. about maintainerscripts. do you remember a good overview what classes of things are done in maintainerscripts in practice? [11:11] from top of my head i see: initrd and bootloader poking, dkms, VM/bytecode compile, apt migration hacks/magic ... anything big missing? [11:12] alternatives ... [11:12] diversions ? [11:14] asac: I don't really have an overview. The main class of things you're missing is things that are handled by debhelper autoscripts, typically system integration hooks of various kinds [11:14] So things like updating icon caches when icons are installed [11:14] Lots and lots and lots of special cases, e.g. generating sshd host keys [11:15] Configuration file migration between versions [11:15] Adding system users [11:16] in a nontrivial number of cases, also configuring servers to the user's wishes (debconf) [11:16] (postfix, databases, wordpress, ...) === MacSlow is now known as MacSlow|lunch === greyback is now known as greyback|lunch [12:14] asac: everything to do with dynamically created system users/groups === oSoMoN|afk is now known as oSoMoN [12:15] doko: are you looking at p11-kit? [12:17] Laney, no, not yet [12:19] Laney, do you want to? [12:19] not particularly :-) [12:19] cjwatson: pitti: maxb: thx!! guess have a good picture now [12:19] ogra_: ^^ [12:19] u2 [12:20] :) [12:21] asac: In particular, chowning of files to dynamically created users happens in maintainer scripts too (since they can't be shipped that way in the package tarball since the users may not exist at unpack time) [12:21] Which surprised me when I encountered it at first [12:21] maxb: what class of packages does system user/group shuffling? i feel thats mostly server stuff, right? [12:22] Nah, all sorts of things, anything that needs a degreee of isolation by way of a dedicated user for instance [12:22] e.g. whoopsie === greyback|lunch is now known as greyback [12:23] I mean, server packages yes, but I don't think it can really be pigeonholed [12:23] libuuid is one of the more unexpected ones which does it [12:23] click-package is notably not server right now and does it :) [12:24] avahi-*, colord, dbus, hplip, pulseaudio, speech-dispatcher, ... [12:24] cups [12:24] virtualbox, wpasupplicant, bluez, lightdm [12:24] any daemon one might be running, and not as root [12:25] samba [12:25] only the server side of samba I think === _salem is now known as salem_ [12:37] ok. [12:47] cjwatson, r195 makes 'collect' return the list of running tests. [12:49] jibel: Great, thanks. Deployed. Let's see how it does on the next run ... [12:50] cjwatson, when you announce this work, could you mention that uploaders will be notified on first failure and I'll turn this feature on? Or you prefer if I do it separately [12:56] jibel: Oh, is that ready at the IS side? [12:57] oh yay, that sounds cool [13:00] yes, ATM these mails go to a list, jibel, and me [13:00] cjwatson, yes, it is since a week or so and tested it works. For the moment the blamee is copied in the notification message. There a variable to change to add it to the list of recipients. [13:01] jibel: If it's ready to enable, go for it [13:01] does it blame the right person for rdep breakage? [13:04] barry: ping [13:04] Laney, it blames the uploader of the package that broke, if the package is broken because of an rdep, I have no way to automatically identify the source of the breakage. [13:05] I guess he means if we upload libfoo to -proposed, this triggers the test of the rdep bar [13:06] if bar fails, then the uploader of libfoo shold be notified [13:06] and how is uploader calculated? e.g. for syncs from debian & sponsored uploads. [13:06] pitti, that'd mean for example it'd blame doko for all the broken packages depending on python or libc ;) [13:08] never! [13:08] jibel: well, if a new python3.3 breaks ubiquity, that would be kind of right? [13:08] or libc breaks apache, or what not [13:08] libc -> infinity [13:09] pitti: but it's me who has irc highlights for "ubiquity" =) ubiquity -> ubuntu-installer team [13:10] * xnox would still blame bar, apache, ubiquity, etc. As that's the person who TIL and should either fix it or punt it to the rdep uploader. [13:11] zyga: in a meeting === MacSlow|lunch is now known as MacSlow [13:11] barry: ok, when can I ping you next? [13:11] pitti, that's very difficult to determine the cause automatically. For example if symbols are deprecated in a lib and a package depending on this lib fails because warning are considered errors, then the uploader of the lib shouldn't be notified, should he? [13:11] zyga: 50m [13:11] xnox: then perhaps notifying both? if I upload a new pygobject that breaks ubiquity, then first and foremost I are to blame [13:12] it's still a matter of investigation and negotiation whether ubiquity should be adjusted to a new API or whatever, of course; same with glib or python [13:12] pitti: maybe =) [13:12] pitti: or maybe you can help me instead [13:12] pitti: I wrote some very cool code for python3-dbus, I was looking for some upstream devs to help me upstream it [13:13] jibel: I think he should be, to know why/that his package won't land in saucy in the usual 30 minute timeframe [13:13] pitti: I improved over the basic code to add support for properties with introspection, in a generic manner [13:13] zyga: I'm not a python-dbus developer I'm afraid [13:13] pitti: I'm about to work on ObjectManager interface [13:13] ok, thanks === dholbach_ is now known as dholbach [13:14] zyga: hm, wouldn't that fit better with using the Gio (introspected) bindings, not python-dbus? [13:15] pitti: gio? gobject introspection? [13:15] pitti: we're not using any gobject code in our app and the bindings could very well offer native python equivalent [13:16] zyga: then perhaps you mean something else with ObjectManager than I do [13:16] (as that's a GDBus concept in my world) [13:16] pitti: I meant the std dbus interfaces: org.freedeskto.DBus.{Properties,ObjectManager} [13:16] pitti, also when several rdeps are tested simultaneously, we do not trigger a package test with depA then depB and depA+depB but just depA+depB, in that case we don't know which is responsible for the breakage, who should be notified? [13:16] zyga: ah, ok [13:16] pitti: python3-dbus does not support exporting propeties (you have to code everything manually) [13:16] jibel: I think we shold notify all affected packages [13:16] pitti: nor object manager (which is a recent addition IIRC but simplifies stuff a lot) [13:17] jibel: even if the problem is in the rdep, one point of that notification is to tell that your upload won't land in Ubuntu without further investigation [13:18] effing powerpc -- you skip one failing test case, now the next one fails !? [13:19] has policykit changed in some subtle way? I would expect perm = Polkit.Permission.new_sync('com.ubuntu.apport.root-info', None, None); print perm.get_can_acquire(); to return True. === francisco is now known as Guest7324 [13:20] $ pkcheck --action-id com.ubuntu.apport.root-info --process $$ [13:20] Authorization requires authentication and -u wasn't passed. [13:20] with --allow-user-interaction it indeed succeeds [13:23] ev: polkit hasn't really changed in saucy, just that it switched from CK to logind for session tracking; the client-side behaviour shold be identical [13:23] pitti: it's entirely my fault [13:24] was running through a shell not in a desktop session [13:24] and failed to recall why that obviously wouldn't work :) [13:24] oh, do we only allow active sessions? [13:24] it appears so [13:24] hm, no, we don't [13:24] auth_admin [13:24] auth_admin [13:24] auth_admin [13:25] sounds like it still requires the calling process to be in _some_ session [13:29] * pitti goes to debug suspend, away from IRC for a bit === wedgwood_away is now known as wedgwood === wedgwood is now known as wedgwood_away === ckpringle_ is now known as ckpringle === kentbout is now known as kentb === sivatharman__ is now known as psivaa === oSoMoN_ is now known as oSoMoN [14:24] xnox: should i ping ftpmaster again? i havent seen any activity since youve uploaded it [14:25] stokachu: package count in NEW: 245 - see http://ftp-master.debian.org/new.html [14:25] ah [14:25] stokachu: i would not hold my breath. [14:26] stokachu: you are more than half way up the list =) [14:26] xnox: lol ok ill keep my eye on this list [14:34] barry: reping [14:37] zyga: hi. i think i'm recovered from my kernel panic now :) what's up? [14:39] barry: I was looking at someone to contact wrt python3-dbus [14:39] barry: I recall you have a repo on github with that, is that correct? [14:40] barry: I wrote a number of improvements over the stock thing, I've got working @dbus.service.propery + Get/GetAll/Set + Introspection XML [14:40] zyga: long ago merged into their trunk [14:40] barry: and I'm writing ObjectManager code [14:40] barry: I would like to contribute that all upstream [14:41] zyga: awesome. simon is very responsive to contributions. i'm also happy to take a look if you do a pull request [14:41] is there a nice way to detect as an upstart event when all network interfaces configured in /etc/network/interfaces have been started? [14:42] barry: how can I get in touch with simon and where is the real upstream repo for that? [14:44] zyga: let me track some stuff down for you [14:45] barry: thanks a lot! [14:53] zyga: oy, it's been a long time since i poked at this. http://cgit.freedesktop.org/dbus/dbus-python/ [14:53] zyga: https://bugs.freedesktop.org/index.cgi [14:53] barry: thanks a lot! [14:53] barry: I'll see how my code stacks on top of that [14:54] zyga: probably the best thing to do is to file a bug against dbus-python with the feature request. simon usually responds pretty quickly. you can also probably dig up his @debian.org address for direct contact [14:55] I'll start with the bug report [14:55] cool, my first contribution upstream :) [14:56] zyga: \o/ send me the bug url and i'll subscribe [14:58] barry: ok [14:59] cjwatson, sorry to bother you about that again, but we have having an hard time to have a grasp on what we should check for/verify/do to be able to move signon-ui from saucy-proposed to saucy [14:59] kenvandine, ^ moving the discussion here [14:59] barry: looking at https://bugs.freedesktop.org/enter_bug.cgi I don't see python-dbus, just dbus, is that the appropriate component [15:00] zyga: yes, i think so. here for example is one of my still open bugs: https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailreporter1=1&emailtype1=exact&email1=barry%40python.org&field0-0-0=bug_status&type0-0-0=notequals&value0-0-0=UNCONFIRMED&field0-0-1=reporter&type0-0-1=equals&value0-0-1=barry%40python.org&list_id=312978 [15:00] oh lovely [15:00] https://bugs.freedesktop.org/show_bug.cgi?id=55594 [15:00] Freedesktop bug 55594 in python "Documentation should mention that signatures of empty dicts cannot be guessed." [Normal,New] [15:01] zyga: so product dbus component python === ckpringle_ is now known as ckpringle [15:02] barry: got it, filing bug now [15:02] seb128, actually let me see if i can make it buildable on powerpc too [15:03] kenvandine, it will not work, that's cheating... :p [15:03] well it still has the non-qml code path there [15:03] so if i don't build with use-webkit2 config it might work [15:04] cool [15:04] * kenvandine sets up a ppc pbuilder [15:05] kenvandine, have no fear ;-) [15:11] barry: https://bugs.freedesktop.org/show_bug.cgi?id=65900 [15:11] Freedesktop bug 65900 in python "Python bindings should offer @dbus.service.property and automatically build proper introspection data" [Enhancement,New] [15:13] seb128: I'll have a look at it after this call [15:13] cjwatson, thanks [15:13] You caught me pretty near EOD yesterday [15:19] zyga: subscribed, thanks [15:20] barry: thank you! [15:29] seb128, cjwatson, Daviey, ev: What is your feeling about turning on apport crash reports in Launchpad for saucy? and when? [15:29] I get pinged about that from time to time [15:29] I'm agnostic on that [15:30] pitti, no strong opinion either, somebody was asking about it last week I think (bdmurray iirc) so maybe it's time for that? [15:32] we can certainly say at some point "errors.u.c. is the thing", depends on how intensive we want to deal with crash reporters this cycle? [15:33] hmm, working on upstream python-dbus requires dbus-1.6, I guess I need to try saucy or something recent [15:34] zyga: rolling releases! :) [15:35] zyga: saucy loves you! [15:35] or maybe now they should be called sauntering systems [15:43] pitti: I'm on 12.04 again, since my daily work is really only about 12.04 [15:43] pitti: I guess vagrant is the way forward for me :) === salem_ is now known as _salem [15:47] * psusi can't wait for HAL to die [15:51] Hi guys, hm, we seem to get some strange errors on the indicator stack when we enabled -proposed [15:51] RuntimeError: the sip module implements API v10.0 but the PyQt4.QtGui module requires API v9.2 [15:51] Do you think it might be related to some recent changes in -proposed? Or unrelated? [15:52] * sil2100 would need someone from the AP team [15:53] sil2100: new upstream release of sip4 was uploaded 3 hours ago, it is possible that python-qt4 needs a rebuild. [15:53] oh [15:53] xnox: hm, thanks for the info [15:53] didrocks: ^ [15:53] cjwatson: this is what happens when enabling -proposed for running the tests, not sure how we can safely get transitions while avoiding those ^ [15:53] ;/ [15:55] you could check installability before starting the test [15:55] infinity: any progress on bug 1187722 please? If not, can we apply a less complete workaround to dpkg-shlibdeps to get the golang FTBFS through? [15:55] bug 1187722 in golang (Ubuntu) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [High,Confirmed] https://launchpad.net/bugs/1187722 [15:55] and treat uninstallability separately from test failures [15:55] didrocks: well, case in point python-qt4 is missing a dep8 test which depends on sip4 which would catch the above problem and present sip4 from migrating to -release. So actually -proposed is not the problem here. As saucy-release is borked as well at the moment. [15:55] cjwatson: it's installable though [15:55] if it's uninstallable and busted that's a problem in itself! [15:55] er, installable and busted [15:55] rbasak: The fix needs to be in golang (well, and dpkg-shlibdeps, but that's trivial), not something we just "work around". [15:56] cjwatson: yep, but still this kind of issue will block our testing anyway, I have no idea how we can fallback to a safer bet in that case [15:56] didrocks: we do know that uploading foo can break tests of rdeps bar. and either foo or bar needs fixing. [15:56] rbasak: If we just work around it, half the archive will end up with a dependency on libsfgcc1. :P [15:56] xnox: not in proposed, after proposed, right [15:56] infinity: for now, why can we not just assume that if "readelf -A" returns nothing, then the binary's ABI is the same as the host ABI? I understand this breaks for multiarch cross-compile, but that's an edge case on top of an edge case. [15:57] didrocks: but you will not be able to land. as you have to land via proposed. so a safer bet is to fix python-qt4 asap, and add measures to prevent this breakage in the future. [15:57] sil2100: didrocks: where are the logs for this API version missmatch? [15:57] rbasak: We could just fix golang. It's not rocket science to do so. This isn't quite something worth panicking over yet, is it? [15:59] xnox: you mean, from our side? [15:59] where did you see that message? [15:59] sil2100: i mean the full log where " implements API v10.0 but the PyQt4.QtGui module requires API v9.2" error is visible. [16:00] xnox: one moment [16:00] xnox: right, but just enabling -proposed for the first time shows that we are getting an issue, I'm not sure if it's bad luck or that will make the tests failing too regularly [16:00] infinity: we'll have less time to test any other issues caused by the 1.1 bump. Given that the built binary works, I'd prefer to see it in the archive. But it's a good question. I'll try and find out if there's a reason we should fix it sooner. So that I understand the situation right, are you saying that my workaround would work, but you'd prefer to only put it in if we need golang into saucy sooner? [16:00] didrocks: sip4 migrated to saucy-release, so by enabling -proposed you saw the issue 3h earlier. [16:01] xnox: right, but it's just one issue, on potentially a lot :) [16:01] rbasak: Your workaround could have unintended side effects. As noted, if we just ignore the HF bits entirely, half the archive will end up depending on libsfgcc1. This isn't a theory, it happened once and I had to rebuild after fixing dpkg-shlibdeps. :P [16:01] didrocks: of course. but testing against release pocket, then uploading into -proposed pocket, then failing testing in -proposed, and blocking release is much longer, than doing it in -proposed straight away. [16:02] xnox: depends, we have a lot of components to land everyday, if the instability for us to retry too much, that's not going to scale [16:02] didrocks: as there were initial teething problems with just daily landing, there will be teething problems with using -proposed. But we can flag them up, resolve and minimise to gain an overall improvement. [16:02] rbasak: But the workaround is also a waste of time when we could just fix the problem. I only diagnosed this on Friday night, and spent most of Monday in a hospital, 1 working day seems like a pretty short timescale to go from "oh, hey, look, a bug" to "we need hackish workaround now". [16:03] Sorry, I didn't realise your perception on the problem was so short. I'd been looking at it since before I filed the bug a couple of weeks ago. [16:03] xnox: the only issue with using -proposed is that it's not one time breakage, it can be regular breakages :) [16:04] didrocks: Well, it's a classic velocity vs. quality trade-off; but I don't know how we can do effective quality checks if we aren't testing at least some things from -proposed [16:04] didrocks: Perhaps the CI tests should have -proposed enabled in apt sources, but pinned in apt preferences such that it's only used when necessary [16:04] didrocks: That way transitions would be possible in a useful way but you wouldn't pull in *everything* from -proposed [16:04] didrocks: However I agree with xnox that in this case it seems to have made no practical difference [16:04] infinity: can I help with the fix? Or shall I leave it to you? I'm not sure I understand the specifics of the ELF header change you're using (as opposed to the eabi section tags), but am happy to catch up. [16:05] Or very little, anyway [16:05] Seems weird to be having this argument when it wasn't actually a problem with proposed [16:05] cjwatson: in that case, we are quite stuck, as there is the sip transition (until qt4 is fixed), and indicator-datetimes can't be tested with new libical, right [16:06] But the sip transition is in release, so you'd have been stuck anyway. [16:07] And if sufficient attention had been paid, this could have pointed out that (it sounds like) sip4 is missing a Breaks field and we could have caught that before it affected users ... [16:07] Hrm. I haven't had a kernel panic in a long time. That was exciting. [16:07] cjwatson: ah ok, I missed that one (I thought it will transition soon, just not yet) [16:09] Damnit, I want 'dak rm -Rn' for this signon-ui thing [16:09] cjwatson: I think I a Ken who will be really interested as well :) [16:09] seb128: Were we going to rebuild empathy without signon support on powerpc to simplify this? [16:10] seb128: (I could take care of that if it would help - the fewer dependencies I need to trace by hand the better) [16:10] cjwatson, if that helps we can [16:10] cjwatson, we are bit lost on where to start [16:10] looking at http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/rdepends/signon-ui/signon-ui is hard [16:10] I'm starting by tracing the rdeps back with checkrdepends -a powerpc [16:11] Unfortunately it doesn't distinguish Depends and Recommends, so some manual checks too [16:11] And for each binary package working out what tearing out all binaries from that package on that architecture will do, recursively [16:11] quite tedious :/ [16:11] didrocks: sil2100: let me fix the python-qt4 problem. And I will ping you once it's uploaded. [16:11] Like I say this is a really boring way to spell 'dak rm -Rn -a powerpc -b signon-ui' [16:12] But oh well [16:12] xnox: thanks a bunch :) [16:12] xnox: thanks! We'll re-launch our machinery then [16:12] seb128: I'll sort out empathy now [16:12] cjwatson, would it help if we start by building empathy without uoa support on ppc? [16:12] cjwatson, ok, thanks, let me know if we can do anything to help [16:12] kenvandine, ^ [16:12] seb128: Yep, that was my plan [16:13] cjwatson, great, thanks! [16:23] mpt, bdmurray: a heads up. We're going to have to purge reports from the database that don't have a DistroRelease field. I'll have it increment a counter for the day period that these were written, so we have some history of how many such (bogus) reports we were getting [16:24] (in a critical disk space situation on the cluster) [16:24] ev, how much time will that buy? :-) [16:26] mpt: barely any [16:27] suggestions welcome on how we can further define a bogus report that can be sent to the abyss [16:27] this is in parallel to bringing up some more nodes in production [16:27] kenvandine: Something like http://paste.ubuntu.com/5777580/ look vaguely right? I'm going to test that shortly [16:27] to further spread the load [16:29] cjwatson, close [16:29] + DEB_CONFIGURE_EXTRA_FLAGS += --enable-ubuntu-online-accounts=yes [16:29] you want that to be =no for powerpc [16:29] unless you meant ifneq [16:30] I have that on the wrong side of the if, indeed [16:30] Is that the right set of build-deps to disable, and is removing that set of binary packages correct? [16:31] cjwatson, ues [16:31] yes even [16:40] kenvandine: can you approve some changelog-modding branches? [16:43] kenvandine: https://code.launchpad.net/~sil2100/bamf/add_bug_number/+merge/170134 [16:43] kenvandine: https://code.launchpad.net/~sil2100/gnome-control-center-unity/add_bug_number/+merge/170114 [16:46] sil2100, sure [16:47] kenvandine: thanks! === mmrazik is now known as mmrazik|afk [16:47] np [16:49] seb128, to get signon-ui to build on ppc, even without qtdeclarative, we'd need libqt5webkit5-dev for powerpc [16:50] which isn't available for powerpc either :/ [16:50] kenvandine, :-( [16:50] * kenvandine scratches the goal of building signon-ui for ppc [16:50] so we just need to kick uoa use out of desktop on ppc [16:50] seb128, yes === _salem is now known as salem_ [16:51] Now if cdbs would stop being appalling I might be able to disconnect empathy from this [16:51] it isn't useful anyway, since we only show the settings panel in unity [16:51] sil2100: didrocks: rebuilding python-qt4 resolves the sip api missmatch error. I have added an autopackage test in python-qt4 to literary do "python -c 'from PyQt4 import QtGui' " thus if sip breaks python-qt4 in the future, we would know about it straight away. It's building at the moment: https://launchpad.net/ubuntu/+source/python-qt4/4.10.1-1ubuntu2 so once that is published and the new autopkgtest pases it should be green light to restart everyt [16:51] hing that has failed. [16:51] xnox: excellent, thanks! :) [16:51] For clarity I consider removing signon-ui from powerpc to be agreed and will do it; I'm just trying to minimise the complexity [16:52] cjwatson, +1 [16:52] cjwatson, +1 [16:52] thanks! [16:52] cjwatson, i just took a stab and making it easier to deal with... but failed [16:53] * cjwatson nods [16:54] didrocks: i wonder if it makes sense to check reverse-dependancy autopkg tests for green light, before starting CI. As if reverse-dependancies are borked, there is little point in testing something higher up in the dependancy chain. [16:54] * xnox is not entirely sure about that atm. [16:55] Looks like setting DEB_ARCH_PACKAGES this way doesn't work - may have to settle for the crappy explicit list of architectures [16:57] test [17:00] when i start ubuntu ,it give me some message, "[ 15.117693] INFO @wl_cfg80211_attach : Registered CFG80211 phy" [17:01] i just know, it about wireless hardware, how to fix it ,or hide that message [17:03] AugustVento: you can set the loglevel kernel command line parameter to show only messages of a certain importance and higher: https://www.kernel.org/doc/Documentation/kernel-parameters.txt [17:03] ev: there is also that extra data in Counters for release source package crash counts [17:04]