[00:41] SpamapS: All the recent talk about concussions surely isn't for nothing. But not saying anything about you, specifically. ;) === dendrobates is now known as dendro-afk [01:03] Merry christmas slangasek :) https://bugs.launchpad.net/ubuntu/+source/defoma/+bug/905055 [01:03] Ubuntu bug 905055 in xfonts-utils (Ubuntu) "Package needs to be Multi-Arch enabled so Multi-Arch packages can depend on it" [Undecided,New] [01:04] YokoZar: er, there's no reason those packages need to be marked Multi-Arch: foreign for this [01:05] *only* the immediate dependency of your package does [01:05] does need to be, I mean [01:05] slangasek: I may have confused the issue from reading the M-A spec then :/ [01:06] Yeah, this bit: https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages -- I thought that meant the transitive dependencies would matter too [01:07] slangasek: but thanks for the correction then [01:07] "foreign-architecture package" here is the binary-only i386 package you're working on [01:08] to satisfy that package's dependency on ttf-mscorefonts-installer, ttf-mscorefonts-installer needs to be marked Multi-Arch: foreign [01:09] that's all [01:11] ok so it's nice it doesn't recurse === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === bladernr_afk is now known as bladernr_ [07:30] good morning [07:30] infinity: I had to wait for the others to time out, which took like 12 hours [07:31] infinity: but I finally debugged/fixed it last night, so I'll just do another -propoosed upload [07:45] hi pitti, sorry, I'm still waiting for a final release tag, chrisccoulson told me there are l10n differences between beta and release [07:50] micahg: ack; I can start the langpack build tomorrow morning, no problem [07:51] pitti: last release the tag didn't come until midnight UTC Sat morning [07:51] ah, is that what you meant? [07:51] yes, I meant I can start it on saturday morning [07:53] pitti: ok, well, there's a caveat, if I don't get it before around 21:00 UTC, I won't be able to upload until midnight Sun morning UTC [07:53] micahg: if we want to speed it up, I could also temporarily hack the code to have a hardcoded language list [07:53] micahg: if you can just send me the list of firefox-l10n-* packs that will be built, that's sufficient [07:54] pitti: I don't really need to inherently rush as long as it's ready sometime next week [07:54] then I can do the actual work today, and then on Sunday just hit the "upload" button [07:54] micahg: ok [07:54] pitti: ok, let me see if I have that already [08:00] pitti: I think this is it: http://bazaar.launchpad.net/~mozillateam/firefox/firefox.maverick/view/head:/debian/config/locales.all [08:05] micahg: perfect, thanks! [08:10] good morning [08:11] * soren is very confused this morning [08:11] http://paste.ubuntu.com/771954/ <--- Why does it try to apply those patches twice? [08:12] soren: quilt rule + source format 3? [08:13] micahg: Nope. [08:13] http://paste.ubuntu.com/771955/ [08:13] It also seems that it's dpkg-source doing it both times. [08:16] micahg: Oh.. [08:16] I think I may know why. [08:18] micahg: Apparently the orig.tar.gz accidentally had the patches applied. Weird. [08:19] soren: ah, I think I've seen that before [08:44] apw, smb`: FYI, -5 kernel binNEWed, ready for -meta upload [08:44] I'll update seeds and d-i [09:09] micahg: oh, I figure it's the same list for lucid? [09:10] pitti: should be I think [09:23] cjwatson: do you want to move d-i to 3.2.0-5, or want me to? (already updated the seeds, this time also including s-kernel-common) [09:24] pitti: go ahead [09:24] cjwatson: waiting for the metapackage to land, though [09:24] you don't need to wait for that before doing d- [09:24] i [09:25] cjwatson: wouldn't that make alternate builds uninstallable? === bladernr_ is now known as bladernr_afk [09:26] pitti: no [09:26] because d-i builds against -5, but the altearnate image has -4 in /pool ? [09:26] Who cares [09:26] ok [09:26] Worst case it installs an older kernel than it ran with [09:27] But the ABIs don't need to be in sync there [09:41] Hi [09:41] I was in the middle of reporting a crash bug, when about a third of the way through a lengthy upload I got this error: [09:41] 'Cannot connect to crash database, please check your Internet connection. [09:41] ' [09:42] Clicking OK then cancels the upload [09:43] is this a bug? where should I report it? [09:43] jml: how big is that report? [09:43] jml: LP has an unfortunate habit of resetting the connection once you try to upload more than 50 or 100 MB [09:43] pitti: it said 33MB [09:44] pitti: but I have a lousy internet connection. [09:48] also, now I don't know how to actually report this crasher bug in Qt Creator :) [10:17] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #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:27] * pitti hugs dholbach [10:27] pitti: 10 minutes before your mail I sent an updated dpkg patch [10:27] did you saw it? [10:27] buxy: right, I noticed too late, sorry [10:28] buxy: many thanks, you rock [10:28] buxy: I updated the bug, too; new dpkg uploaded, and I'm unable to break it now [10:28] tried with different packages, installing in one or two steps, multiple times, etc. [10:28] ah ok, LP mails tend to lag a bit apparently [10:29] (at least LP mails through the PTS) [10:29] buxy: they lag for about 5 minutes, so that you can do several bug state changes without triggering one mail for each [10:29] buxy: but it was mostly my lag, I just saw Steve's response in my mailbox and then re-uploaded the workaround [10:29] then saw you'rs [10:29] your's (argh typing is hard) [10:58] I'm trying to do an upgrade test from oneiric->precise, but do-release-upgrade is failing with various "Encountered a section with no Package: header" errors. Is this expected? [11:02] rbasak: not expected, in fact we also get it in the automatic dist-upgrader [11:02] ... tester [11:02] no idea what's causing it, though [11:03] apparently that started happening a few days ago only [11:03] * ajmitch gets that in pbuilder, it's always to do with TranslationIndex [11:03] so I disabled apt fetching translations to get around it [11:03] jibel: ^ FYI === _salem is now known as salem_ [11:14] thanks pitti, ajmitch. Is it possible to use that workaround in do-release-upgrade? I tried Acquire::Languages { "none"; }; in apt.conf but that doesn't seem to have any effect [11:18] rbasak: unsure, I did have to delete the translation files in /var/lib/apt/lists as well - afaik apt tries to fetch languages that it already has, ignoring the config option in those cases [11:18] it was a bit of an ugly hack I was only using for the chroot, I don't think it's suitable for upgrade testing [11:19] ajmitch: yeah, doesn't seem to work. I tried clearing out /var/lib/apt/lists but it still seems to be fetching TranslationIndex files if that's a suitable indiciation? Perhaps do-release-upgrade causes apt to ignore some of its config? It was always a bit of a mysterious black box to me [11:20] seb128, I 'ate the desktop team branches [11:20] just saying :) [11:20] dholbach, *hug* ;-) [11:23] dholbach, you hate things that are light to checkout and easy to use? ;-) [11:24] not quite how I'd put it :) [11:26] OK, it seems dist-upgrade is sufficient for my testing needs today, so my workaround was just to run dist-upgrade instead of do-release-upgrade ignoring the apt-get update warnings before it [11:28] dholbach, you are just old and grumpy :p [11:36] perl patch for broken doc-base trigger, take III *sigh* [11:36] jibel: ^ that's for bug 902553, hopefully *really* fixed now [11:36] Launchpad bug 902553 in perl (Ubuntu Precise) "package doc-base 0.10.3 failed to install/upgrade: ErrorMessage: /usr/bin/perl: symbol lookup error: /usr/lib/perl5/auto/UUID/UUID.so: undefined symbol: Perl_xs_apiversion_bootcheck" [High,Triaged] https://launchpad.net/bugs/902553 [12:08] can somebody reject https://code.launchpad.net/~snicksie/ubuntu/precise/libgda4/fix-for-typo/+merge/86025 for me? [12:08] (fix forwarded to upstream instead) [12:09] ah, sorry dholbach, didnt know it had to be somewhere else :$ [12:09] hey Snicksie [12:09] thanks for your work on this [12:09] dholbach: done [12:09] thanks pitti [12:09] Snicksie, no worries - good work on the fix - I hope the fix can get into upstream soon [12:09] and then we'll get it for free :) [12:10] where should I put it next time? :) [12:10] (I linked to the upstream bug in the merge proposal) [12:10] Snicksie, if it's a fix we should immediately get into Ubuntu it's totally fine to file a merge proposal just like you did [12:11] okay, and if its just a typo? :) [12:11] in any case it makes sense that if you modify code (and not just the packaging in ./debian/), you send the fix upstream [12:11] Snicksie, in that case we usually send it to upstream (the software authors) and get the fix for free with the next version update [12:11] okay, should I send it upstream myself next time or...? :) [12:12] I wouldn't want to impose it on you, we're grateful for all the fixes we get - but if you have the time and don't mind doing it, then that's cool [12:13] and if you run into any issues, feel free to just ask in here, or #ubuntu-motu [12:13] will do :) [12:14] thanks for explaining :) [12:14] no worries :) === MacSlow is now known as MacSlow|lunch [12:27] ev, do you think you can have a look at the patch in bug 897933 and apply it upstream (the merge proposal gives me "bzr: ERROR: None 0.2 was not found in Launchpad bug 897933 in libtimezonemap (Ubuntu) "FTBFS: undefined reference to `{tan,log,pow}'" [High,Triaged] https://launchpad.net/bugs/897933 [12:28] could we lower the required dpkg Pre-Depends for xz-compressed packages to 1.15.6~? at least 2 Debian packages use that version. [12:30] oh, 0.2.1 in precise seems to have fixed the issue - it seems the fix just needs to go upstream as well [12:31] dholbach, sorry for the incorrect email... seems like I had a small mistake in my bashrc. thanks for notifying :) [12:31] :-) [12:36] i wonder if someone could stroke the new linux-ti-omap4 binaries, then i can get the meta up [12:39] debfx: sure, file a Launchpad bug please and I'll take care of it [12:40] (unless somebody beats me to it) [12:40] debfx: preferably include an example package name (for QA) [12:47] "Your computer does not have enough free memory to automatically analyse the problem and send a report to the developers."! [13:04] Hi all. I'm trying to build a CVS release of Gutenprint in as a .deb package. I'm having a few problems with this, mainly with paths... can anyone help out? [13:06] These are the last few lines from my buildlog: http://paste.ubuntu.com/772169/ [13:07] It seems to be looking for '../../../src/xml/xmli18n-tmp.h' from a CSD of 'gutenprint-5.2.7cvs20111216/debian/build/po'. This file is actually in the build directory -- gutenprint-5.2.7cvs20111216/debian/build/src/xml/xmli18n-tmp.h [13:09] cjwatson: thanks, I've filed bug #905322 [13:09] Launchpad bug 905322 in Launchpad itself "Lower required dpkg version for xz-compressed packages" [Undecided,New] https://launchpad.net/bugs/905322 === MacSlow|lunch is now known as MacSlow [13:10] basically, I want a version of gutenprint which works with the Canon CP-800 mini photo printer... the current ubuntu release does not, but CVS does. [13:14] apw: done [13:25] pitti, thanks :) [13:29] Laney, ping [13:30] hello [13:30] hey :).. I saw your answer at bug #905304 [13:30] Launchpad bug 905304 in Oneiric Backports "Please backport ruby-rack 1.3.1-1 (universe) from precise" [Undecided,New] https://launchpad.net/bugs/905304 [13:30] problem is ruby-rack does not exist in oneiric [13:30] what do you suggest ? [13:31] I would introduce transitional package... what do you think ? [13:31] it was renamed from libruby-rack [13:31] Laney, → http://anonscm.debian.org/gitweb/?p=pkg-ruby-extras/ruby-rack.git;a=commitdiff;h=885afe575fb0b04505c64f908dd364180cbd5bb4 [13:32] which we do have in oneiric [13:32] yep, you 're right :( [13:32] so somehow fix that or the depending (broken) package [13:33] i mean librack-ruby, not libruby-rack [13:33] oh, I missed that it was a rename, sorry l3on [13:34] tumbleweed, np :) I'm here to learn :P [13:34] and at any rate it is always fishy to fix bugs via backports [13:36] I was tihnking of it as a new package, not a bug fix [13:37] but the purpose of it is to fix an uninstallability in the main archive [13:38] anyway, no harm done [13:40] Laney, I'm trying to build ruby-sinatra depending on librack-ruby instead of rack-ruby [13:40] we'll see [13:41] cool, thanks for your work === yofel_ is now known as yofel [13:47] Laney, ok, seems works fine.. installs and runs [13:48] is it a -proposed ? [13:48] +ruby-sinatra (1.2.6-1ubuntu1) oneiric; urgency=low === TeTeT_ is now known as TeTeT [14:07] No, it does not work properly because: [14:07] $ apt-file search /usr/lib/ruby/vendor_ruby/rack [14:07] returns nothing in oneiric [14:12] Hello, may someone give a one-line summary of how the LiveCD makes itsself persistent through the casper-rw partition? Is it just a matter of rsyncing shellscripts that syncronize the FS upon shutdown or is it something more complicated like a sort of Union-FS? [14:16] ManDay: it's a union filesystem, specifically (at the moment) overlayfs [14:17] Ah okay [14:17] Thank you [14:17] you're welcome === bladernr_afk is now known as bladernr_ [14:32] stgraber, hello! I have a work item to talk to you about whether ARB still uses /opt/extras.ubuntu.com/? Last I heard it did, but just confirming for Quickly support [14:34] mterry: yes, we still use /opt/extras.ubuntu.com [14:34] stgraber, cool, thanks [14:35] stgraber, and it's still useful to the ARB for quickly to create a package that puts things there (i.e. you don't have some other preferred solution to help developers with that)? === bladernr_ is now known as bladernr_afk [14:47] broder, I had a look at the atkmm multiarch update - it seems debian/compat needs to be updated to 9. I can add that if you like [14:47] (still reviewing it) [14:50] mterry: we have some scripts to force a package to put everything in /opt/extras.ubuntu.com but we still prefer if the source package we receive is right to begin with [14:50] stgraber, awesome, OK [15:19] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:20] debfx: OK, branch for that up for review. It won't be deployed until at least Monday now, though [15:21] assuming that we can still manage further deployments this year [15:34] could somebody set https://code.launchpad.net/~jconti/ubuntu/oneiric/webkit/fix_doc_path/+merge/85054 to merge? [15:34] it was uploaded but the merge request targetted oneiric rather than oneiric-proposed [15:49] seb128: done [15:49] pitti, danke [15:49] (how come you have access to that and not me? ;-) [15:49] seb128: presumably through ~techboard as the owner of ubuntu branches or somethign like that [15:49] (or said differently, where do I need to apply to be able to do it?) [15:49] ok [15:49] and yes, it's a bug [15:50] it's a bug but maybe you could be added to ~ubuntu-branches or something as a workaround? [15:50] actually, why don't I do that. TB people, any objections? [15:50] would that make me receive emails for every merge request? ;-) [15:50] yes [15:51] so please don't [15:51] I delete a lot of mail [15:51] OK [15:51] I will maybe ask you after the holidays, but I'm away starting tonight and I don't want to subscribe to some new spamming while i'm not around to set filters etc if needed ;-) [15:51] actually, I think I'll deactivate myself from that team; I'm already a member via techboard, and that way all the mail should land in techboard's moderation trap rather than my inbox where I don't want it [15:52] could we subscribe like ubuntu-dev or something to do? [15:52] to *it* [15:52] maybe but it would need to have a contact address that discarded mail [15:53] (and I'd prefer if the UDD folks signed off on something like that) [15:53] ok, seems like ~ubuntu-core-dev would be a good fit [15:53] contact email is ubuntu-core-review@luc [15:57] cjwatson: right, tb@ has tons of merge proposals, always fun to listadmin them away [16:02] ubuntu-dev would be good [16:10] pitti, any idea where upstream udev repos are, the links we have in the package point to dead web pages (since the kernel.org debackle) [16:11] apw: http://git.kernel.org/?p=linux/hotplug/udev.git;a=summary works quite fine? [16:11] apw: I also commit to it every now and then [16:11] i have some fixes i want to upstream, so thought i'd better base on that [16:29] cjwatson: of course ti-omap got an abi bump an hour after I uploaded d-i; guess I'll upload another one? [16:31] pitti: if you like [16:31] version numbers are cheap ... ish [16:31] huge NBS and current images and all that [16:32] How many people will be upset if they cannot use d-i with ti-omap until the next upload happend to happen? [16:32] Daviey: well, it's an update I can do while the meeting and it eases my mind to see http://people.canonical.com/~ubuntu-archive/nbs.html get smaller again :) [16:33] lol, ok. :) [16:34] cjwatson: cheap> at ubuntu94 now -- soon we'll need another byte for it! [16:35] Daviey: at least I like to do that for the "normal" kernel -- we then get timely feedback through the QA autotests [16:35] I would have merged a while back but upstream moved to git; while I've managed to rewrite most of the other d-i component branches on git imports, that one has defeated me so far [16:35] not urgent, though [16:35] Daviey: now we don't have that (yet?) for arm images, but I think it's still better to not drag it for too long [16:36] cjwatson: (I was just kidding) [16:36] yeah :) [16:37] pitti: yet is correct :) [16:37] Daviey: oh, are there concrete plans to auto-test them? [16:48] pitti: not concrete, but a /want/. [16:48] Daviey: ah, ok; well, I /want/ a whole lot of things :) [16:48] The trouble is, the current testing is tied to libvirt and using ISO's. [16:49] we could port it to use qemu arm virtulisation, so still use libvirt.. but the ISO requirement refactoring might require some love. [16:49] I guess virtualization in ARM land is still a bit on the experimental/nonexisting side? [16:49] lxc perhaps? [16:49] ah no, that's not for image testing, just running test suites [16:49] which is a bandwidth issue. [16:49] lxc should be good [16:50] pitti: what tests are you interested in? [16:51] Daviey: they are preinstalled, so no installer testing, but e. g. the OEM setup tests apply, as well as simply "does that thing boot into a desktop" [16:51] well i'm leaning towards server testing :) [16:51] jibel and I were also discussign opening all /usr/share/applications/*.desktop files and see if the program starts or immediately crashes [16:52] Daviey: right; anythign other than 0 helps :) [16:56] pitti: I'm still wondering if the server-iso testing method makes sense, but suck in the tarball and boot that in qemu. [16:57] Gets around hardware limitations, and is a pretty well tested formula. [16:58] jamespage: thoughts? ^^ [17:00] hm.. [17:00] * jamespage thinks hard [17:00] so the mdadm debian maintainer has forcibly turned off -Werror .. suggesting that its bad because a toolchain update would break the build [17:00] yikes [17:00] thats sort of backward.. [17:01] Daviey, pitti: I agree that virtual arm testing is not a starter ATM [17:01] I think I'll disable that patch during the merge. :-P [17:02] good night everyone, have a nice weekend! [17:02] pitti: cheers! [17:02] micahg: lucid langpacks prepared, maverick langpacks are being created; so I'll check for a ping from you over the weekend when to upload them [17:02] pitti: o/ [17:03] Daviey: for server we could setup something with hardware [17:03] that uses network preseed installs [17:03] jamespage: you don't think it is worth pushing, or won't work currently? [17:03] Daviey: TBH my mind is a bit blown and I've not had time to think about it to hard [17:04] Daviey: it might work OK for the image testing I guess [17:04] jamespage: ah, ok - probably best not blow your mind on a Friday evening :) [17:04] Daviey: well at least I get the weekend to recover it :-) [17:05] The mess alone, would take all weekend to clean up. [17:05] lol [17:09] SpamapS: Yes, -Werror is not recommended, as it can break with new GCC's because the new GCC adds a warning more. [17:09] gnome broken to install :-/ [17:09] Software releases should never be build with -Werror [17:12] You don't want to break a build because a new GCC version suddenly thinks you forgot to initialize a variable. [17:13] dholbach: ah, sorry for not being explicit about that. debian/compat => 9 isn't necessary for non dh(1) packages; for multiarch stuff it only affects dh_auto_configure [17:14] slangasek: ^ is there anything i'm missing there? would you mind if i updated the wiki to not bump debian/compat on classic debhelper and cdbs packages? [17:15] broder, thanks for letting me know - rereading debhelper(7) what you say makes sense :) [17:15] dholbach: i didn't bump it to minimize the diff, but it's a noop [17:16] broder, if the fix lands in Debian, we should be able to just sync and adopt whatever the debian maintainers decided on having [17:16] thanks broder for your work on them [17:16] thanks for sponsoring :) [17:16] de nada [17:17] SpamapS: I agree with juliank - use -Werror when developing but it simply doesn't scale to 10000 packages in a distribution which some poor sod has to try to fix in bulk [17:17] Ah I thought we had it on by default or something. [17:17] we do not [17:18] * SpamapS makes a note to wait 10 minutes for the espresso to kick in before thinking. [17:18] we do have -Werror=format-security only [17:18] Right thats the one I was thinking of [17:18] * SpamapS turns patch back on. :) [17:19] Enabling -Werror for implicit declarations might make sense as well, though; if not already using C99 [17:20] broder: maybe you should check with the cdbs maintainer, which is who put that there :) [17:21] slangasek: ...really? i don't think cdbs even acknowledges the existence of compat 9 yet [17:21] cdbs shouldn't in general touch or care about debian/compat [17:21] so maybe it's cut'n'waste [17:22] it does at least know about it for its auto-generated build-dep feature [17:22] and to switch between dh_clean -k and dh_prep as appropriate [17:22] and how dh_strip works [17:22] but that appears to be it [17:23] pitti: thanks, will let you know when stuff is ready [17:23] slangasek: i'll go ahead and edit the wiki, then === dendro-afk is now known as dendrobates [17:57] Can any of the core developers please give back cups in oneiric-proposed on powerpc? [18:00] onkarshinde: I already told you that won't work, you need a new upload [18:00] we lost armel also in that build [18:01] micahg: Eh? Why wouldn't giving it back work? [18:01] micahg: I am talking about cups, not gnome-shell. [18:01] infinity: already in -updates :) [18:01] (I mean, assuming the ghostscript issue is worked out) [18:01] onkarshinde: ah, same issue though :) [18:01] micahg: Yes, so? [18:01] infinity: I thought you can't publish the same source record twice [18:02] micahg: ...? [18:02] Oh. I didn't know that if some binaries are moved to updates you can't give back those who FTBFS. [18:02] micahg: I'm not sure what you mean by that. [18:02] infinity: once a source has been published to a pocket, you can't recopy new binaries (at least that's what I was told before0 [18:02] micahg: It's published in both proposed and updates. And it can certainly still be built and the new binaries copied. [18:03] infinity: I was told that's not possible yet [18:03] micahg: We couldn't re-build and re-copy the i396 binaries (and wouldn't want to), but there's no technical reason the ppc/arm ones can't build. [18:03] micahg: Unless someone broke something when I wasn't looking, it used to be possible... [18:04] infinity: I've never seen an i396 build succeed TBH [18:04] Daviey: Typing is hard. [18:04] :) [18:05] infinity: I've had a few conversations with wgrant about this situation WRT copying from a native PPA to -security or -proposed, is -proposed to -updates different? [18:05] micahg: I could be misremembering soyuz brokenness. That's also possible. [18:07] infinity: it needs a rebuild anyways or different archs will be built against different versions of libgs9 [18:08] I'm okay with "soyuz is broken", but the libgs9 argument is meaningless. [18:08] If building against different versions breaks things, then we have HUGE problems with how we develop, well, the entire distribution. [18:09] I guess that might not be a problem in this case [18:09] It better not be. :P [18:10] If libgs9 broke ABI without an SOVER bump, we have slightly bigger concerns. [18:10] (Which I'm sure it didn't, just sayin'....) [18:12] infinity: eh, I guess 1 for 2 isn't too bad this "early" :) [18:13] micahg: So, the more curious question, if both these builds failed due to obvious archive skew, why was the copy to -updates done without retrying them first? :/ [18:13] infinity: indeed, was thinking the same thing [18:14] infinity: are you retrying the powerpc build just to see if it works? [18:14] Kinda curious what Soyuz will do. :P [18:15] I can actually create build records for that source in -updates, which would work around the issue as-described. [18:15] I'm wondering if in-archive is different [18:15] But the whole thing sounds just plain wrong. [18:15] since it's the same shared pool [18:16] While we are discussing this, I just build cups in oneiric chroot on my machine. [18:16] If you want I can try hplip as well. [18:16] * micahg wonders why it was allowed to get this broke [18:17] Dunno. And I can't find any obvious indication of who did the copy. [18:17] audit trails are for sissypanst [18:17] ts [18:18] Apparentyl. [18:18] That's hard to type on purpoes. [18:18] I know, rigth? [18:18] do the SRU copy scripts check for arch skew? [18:18] micahg: No, though they do tell you what they plan to do before you commit. [18:18] micahg: But at that point, it's too late, if someone's decided "ports don't matter". [18:19] micahg: But I'd like to think people aren't doing that. Security certainly don't. [18:19] infinity: our copy scripts warn if you're missing an arch :) [18:20] if 'ports don't matter', specifically powerpc then all the packages on this port should be in universe. So that people like me can take care of it. :-) [18:20] onkarshinde: Ports matter. [18:20] onkarshinde: and the archive doesn't work like that :) [18:21] I know. Just kidding. :-) === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [18:21] micahg: Actually... [18:21] micahg: Per-arch overrides are a fantastic soyuz misfeature. [18:21] infinity: the binaries could be, but we build from source, so I guess a better way to put it is Ubuntu doesn't work like that [18:22] Well, yes. [18:23] Either way. This sort of thing annoys me. I can understand people punting on terribly painful porting bugs in an SRU, but not "giving back builds is hard". [18:23] Or, perhaps, just "counting to four is hard". I dunno. ;) [18:24] maybe SpamapS can add a safeguard to check for that in the SRU scripts (we have that in our unembargo script) [18:24] There are fancy scripts other than copy-package.py on ftpmaster? [18:24] Am I living in the past again? [18:25] Me leaving now friends. Will bug again tomorrow for more give backs. [18:25] infinity: I have no idea, I just know he's been tweaking stuff to warn about possible issues [18:25] onkarshinde: thanks [18:25] infinity: there's an sru-accept script in ubuntu-archive-tools? [18:26] but I guess micahg's referring to the security-specific ones [18:26] infinity: maybe it can warn on the report page that it's not ready to be copied and why [18:26] slangasek: Ahh, never used it. Though I haven't been on the SRU team for years. [18:26] great work cjwatson, thanks [18:28] I doubt I'll ever personally reclaim the time spent [18:28] but maybe collectively we will :) [18:28] sru-release too [18:28] infinity,slangasek: ^- [18:29] right, that's the one that times out on kernels :) [18:29] heh, yeah [18:29] that's because it's using syncSource [18:33] micahg: can you summarize what I might be protecting against? The backscroll is dizzying [18:33] SpamapS: proposed->updates copies when not all arches are built. [18:33] That should be easy enough to build into sru-release [18:34] SpamapS: I'd suggest warning on the SRU report about it as well [18:34] SpamapS: It needs to be an annoying, flashing, over-the-top, Mardi Gras warning that tells people that they're Very Bad People for not looking at the failure logs. [18:35] SpamapS: Instead of a simple "You're about to shaft some users of !x86, do you care? [N/y]" [18:35] micahg: yes, thats a good plan.. no "green light" until all arches are built [18:35] infinity: we can make it just stop, dead. [18:36] I'm not against adding --ignore-unbuilt-arches for the urgent case [18:36] SpamapS: The problem with that is that it's sometimes valid to release without all arches (say, something that was never built correctly on armel). [18:36] SpamapS: well, if it's not a regression (i.e. the arch didn't build before), then it could be green, sometimes it's worth overriding though, i'd suggest a warning next to it, maybe yellow vs green or red [18:36] SpamapS: And if there's a force flag, people just add that to their workflow. [18:36] (Oh, how I wish the above weren't true) [18:37] infinity: in this case, there are 3 - 5 of us, all of which can be held to a lot higher standard than "people".. we're at least "SRU people" [18:37] But look at how often people type "rm -rf" instead of "rm -r" (when the latter would clearly work for 99% of your recursive deletion needs) [18:38] SpamapS: well, hplip and cups managed to migrate from -proposed to -updates w/out armel or powerpc [18:38] SpamapS: Well, yes. I do hold you to a higher standard, which is kinda why I wonder that warnings from tools are even necessary to avoid this sort of thing. :P [18:38] SpamapS: But, meh. Mistakes happen. Mitigating them is nice. [18:38] micahg: right, this seems serious enough and simple enough that it should be solved now, before we forget this atrocity. ;) [18:39] I like to think that the tools should not be expected to enforce the standards, but justs to remind us of our high standards [18:39] which is why the tool also puts up a big warning "HEY THERE IS ALREADY AN UNAPPROVED UPLOAD IN PROPOSED" [18:40] It reduces the steps necessary to do the job.. I don't have to go check, I just expect that the warning will tell me when I need to do that step. [18:40] I suspect ubuntu-archive-tools needs to grow a dependency on cowsay for all our warnings. [18:41] SpamapS: that's the problem with these checks though, they train us to rely on the tools [18:41]