=== Nisstyre-laptop is now known as Nisstyre === _salem is now known as salem_ === seiflotfy_ is now known as seiflotfy === Kk2 is now known as kk2 === salem_ is now known as _salem [04:25] Hey all, I've got a problem where libcunit1 builds and links, but when I run it gives me an error code 20 with error string "No Error." However, if I build a fresh copy of CUnit from SF directly, things work just fine. What is the best way to report this issue, keeping in mind that I'm willing to help if nobody is currently interested in maintaining that package? [04:30] manchicken: Did you build the new version as a debian package or from source directly? [04:30] manchicken: A bug on launchpad.net would be the most appropriate way to report the issue; I'd also check the bugs in Debian. [04:31] ScottK: Directly from source. [04:31] ScottK: That's how I built it on the Mac when I was testing this code there, too. [04:33] Next thing I'd do then is update the package to build the new upstream and see if the .deb you get when you build it works or not. [04:33] That should tell you then if it's a packaging issue or a new upstream issue. [04:34] Well, what I'm thinking of doing is just whipping up a quick test program, testing it with the source version to make sure it works, and then try it with the main package, and then include that source file in the bug report if it fails. [04:34] A reduced test case is always good. [04:35] Yeah, and an automated test seems strangely appropriate as a way of demonstrating a bug in an automated test framework. [04:36] It's automated tests all the way down. [04:39] I like automated tests. [04:59] hallyn: hey [04:59] good morning [06:40] good morning === smb` is now known as smb [08:33] doko_, hey, did you debug the gtk/gcc/arm issue further since yesterday? (don't want to dup work) [09:08] ev: can you please have a look at #1192777 and #1192778 when free [09:29] hi [09:29] I'm trying to understand why python3-requests is not in saucy [09:29] was it removed for any reason? [09:30] and if so, is there a record of such removals? [09:30] http://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=python-requests&searchon=names [09:30] this shows that python3-requests was in precise, quantal and raring [09:30] and up until recently I recall it was in saucy as well [09:30] https://launchpad.net/ubuntu/saucy/i386/python3-requests [09:30] looking at debian I can see the package is there [09:31] It's there [09:31] Don't trust packages.ubuntu.com [09:31] oh [09:31] too bad [09:31] btw, debian has a more recent version [09:31] and we found that the version in saucy is broken when you are using a http proxy [09:31] BTW, we're in Debian Import Freeze [09:31] will the package sync again? [09:32] oh [09:32] Or we were until that was due to be undone this morning :) [09:32] I just haven't got round to preflight checks before turning auto-sync back on [09:32] ah [09:32] thanks [09:32] so it should re-sync again? [09:32] Yes [09:32] cjwatson: btw, is there anything I could do to make packages.ubuntu.com reliable again? [09:32] I really like that service [09:33] Dunno, it's community-maintained [09:33] I think Rhonda runs it? [09:33] May be waiting for an IS deployment of some kind, I don't know; feel free to chase up [09:35] ok, thanks [09:42] mpt: when you have a chance, can you help me understand how we calculate the "rate for matching machines" in "what's unusual about this problem?" [09:42] In the case of evaluating whether the architecture is relevant, is it: [09:42] Take the reports for i386. Filter down to reports for the current day. Get the systems responsible for each of these reports. Divide the number of reports by the number of unique systems. Do the same for each other day, then average out across all days. [09:42] Compare the average value for i386 against the value for amd64 and armhf. If i386 is significantly greater, highlight it. [09:43] Apologies, I know we discussed this before, but I'm struggling a bit understanding how we get the error rate for a subset of instances in the bucket. === doko_ is now known as doko [10:01] Daviey,jamespage: copies of public source to archives owned by private teams should be fully safe now; the fix for /builders visibility is deployed [10:11] \O/ [10:22] cjohnston, hey there. We are running into static ctor/dtor issues right now. Could you give us a hand? [10:22] cjwatson, ^ that was meant for you :) [10:22] cjohnston, sorry for the noise [10:23] doko: ^- Could you help tvoss? You're probably better at this than I am [10:25] cjwatson, tvoss: vacation days today and tomorrow, so won't have much time [10:25] cjwatson: Super! Thanks :) [10:25] doko, ack, here is the issue in case you are bored during vacation :) http://pastebin.ubuntu.com/5798108/ [10:26] tvoss, has this something to do with the gmock build failure? [10:26] doko, nope, mir carries its own in-tree version of gmock for historic reasons [10:29] tvoss, just saucy, or raring as well? [10:30] doko, just saucy as far as I can tell === tvoss is now known as tvoss|quick_lunc [10:48] cjwatson, great! - thanks for fixing that up === MacSlow_ is now known as MacSlow [11:00] pitti: if and when you have a minute, I've got a small change to our apport packaging. It enables core dumps of setuid processes, now that kees says it's okay: https://code.launchpad.net/~ev/apport/raring-suid_dumpable/+merge/171270 [11:13] hey ev [11:14] ev: hm, doesn't that also affect normal core dumps? [11:14] ev: (and I guess that's for saucy then) === MacSlow is now known as MacSlow|lunch [11:15] oh whoops [11:15] yes, I'll apply it to saucy as well :) [11:15] pitti: affect normal core dumps how? 0 is the default, as I understand it. [11:15] ev: ah, =2 is only applied for pipes [11:16] ev: so, I haven't checked whether a suid program actually ends up being owned by the target user, but if that happens, that looks fine to me [11:16] nice, thanks! [11:17] ubiquity wrapper with pexec works: if .desktop specifies "Terminal=true", or if ubiquity wrapped with an extra shell script around it. [11:20] jibel: libreoffice autopkgtest failures are "build slave doesn't have enough disk space", aren't they? === ara is now known as Guest5314 [11:26] schedule amended to move DIF to week 13; mail sent to ubuntu-release@; auto-sync running [11:27] yay [11:34] [Updating] requests (1.2.0-2 [Ubuntu] < 1.2.3-1 [Debian]) [11:34] zyga: ^- [11:36] cjwatson: awesome, thanks! [11:42] automake1.11 binary is heading back into the archive, for whoever it was who was asking about that [11:45] cjwatson: ISTR it was seb128 [11:46] cjwatson, pitti: yeah, it was me, thanks === tvoss|quick_lunc is now known as tvoss [12:06] this build failed earlier, any idea who restarted it? https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4742188# [12:06] i hadn't had a chance to look at the old build log.... [12:07] I did, because it failed due to a broken builder [12:07] cjwatson, yes, I increased disk size already but it's clearly still not enough. I'll have to make a specific setup for LO to run it on a bigger partition. [12:07] heka chrootwaited its next eight builds after that, and the end of the chromium-browser log was all invalid-character-in-source-file stuff [12:07] cjwatson, ah, thanks [12:08] jibel: Right, thanks. I've forced proposed-migration to ignore (that version of) libreoffice for the time being [12:08] chrisccoulson: Now, unfortunately it got retried on heka, albeit after it was nominally fixed ... hopefully it won't eat it again [12:08] cjwatson, yeah, fingers crossed... [12:11] jibel: adt keyword: needs-libreoffice-amounts-of-disk-space ?! =) [12:11] chrisccoulson: https://launchpadlibrarian.net/143317414/buildlog_ubuntu-precise-armhf.chromium-browser_28.0.1500.52-0ubuntu1.12.04.1_FAILEDTOBUILD.txt.gz is still accessible if you have the URL, FWIW [12:12] So you can double-check me, but complaints about "WebGesttrdEvemt" are a pretty good sign of an insane builder [12:12] :) [12:14] doko, in case you are around: seems like saucy already has the binutils and gcc version you were mentioning: http://pastebin.ubuntu.com/5798341/ [12:14] doko, or do you want me to force the ppa version? [12:16] infinity, If you got not too much liquid related (or other issues), is there a possibility that you may get bored enough to look at the crash backports? === MacSlow|lunch is now known as MacSlow === tkamppeter_ is now known as tkamppeter [12:45] OdyX, hi [12:46] tkamppeter: hoy [12:51] pitti: *nods* I'll confirm it does [12:51] thanks === mmrazik is now known as mmrazik|afk [12:57] pitti: hey [13:03] OdyX, I would like to change the pstops priority again so that PostScript jobs for PostScript printers go through pstops instead of pstopdf+pdftopdf+pdftops. Do you know why "make test" fails then? Do you have an idea why the test fails and how one could fix it? Or should I change the cost factors after "make test" and before "make install" in the package build? [13:06] OdyX, see also https://bugs.linuxfoundation.org/show_bug.cgi?id=1138 [13:06] bugs.linuxfoundation.org bug 1138 in cups-filters "Filters should not specify artificially low costs" [Normal,New] [13:07] tkamppeter: I'm all for re-enabling the ps-to-ps, but we have to find a sane way to have the tests working; and having them run in a setup which is not what we ship is not something I'd be happy with. [13:12] tyhicks: hey, so I uploaded my apparmor packages to the ppa [13:12] * tyhicks looks [13:13] tyhicks: I'll be uploading another set to the archive in a few minutes (without dbus patches) [13:13] tyhicks: what is the timeframe for uploading dbus to saucy? [13:13] cjwatson, thanks! [13:14] (and by 'to the archive', I of course meant to saucy) === _salem is now known as salem_ [13:14] jdstrand: it is hard to say with the policy language still up in the air [13:14] jdstrand: there's not much left to do, but we do have to settle that first [13:15] tkamppeter: see Debian #712237 [13:15] Debian bug 712237 in cups-server-common "cups-server-common: The cost factor for pstops" [Normal,Open] http://bugs.debian.org/712237 [13:15] tyhicks: right. I thought we said that it didn't need to be finalized. ie, when sbeattie gets back, we can finalize it but in the meantime, upload. or are you saying we are still waiting on jj for the ipc implications? (I am a bit behind on email right this second) [13:16] jdstrand: yes, waiting on jj's input on future ipc implications [13:17] tyhicks: I see. ok. my thoughts are that this is talking too long and we need to get the code out there-- the only ones that will be affected by the policy changes is us for the most part in the short term. when the language is finalized and uploaded, then we can blog [13:17] s/talking/taking/ [13:17] hey hallyn [13:17] tyhicks: that came out wrong. the dbus syntax iterations are taking a long time, which conflicts with us getting things into the archive, on the images, etc [13:18] tyhicks: and the code exercised by others [13:18] jdstrand: so you're suggesting that we push what we have now into the archive something this week? [13:19] tyhicks: anyhoo-- this isn't anything against the good work you guys are doing, it is just taking longer than we planned [13:19] s/something/sometime/ [13:19] * jdstrand checks something [13:20] jdstrand: should uploading the userspace changes to dbus and apparmor depend on the kernel changes being in place? [13:21] pitti: did you want to talk about something? [13:21] hallyn: not from my side, but you said "hey" half an hour ago [13:21] jdstrand: to allow people to test the code, we'll need the aa3.0 patches in the saucy kernel [13:21] tyhicks: well, we have a monthly goal to have the syntax finalized. that won't be met unfortunately. I'd like for us to work through the ipc implications and then upload something based on that === mmrazik|afk is now known as mmrazik [13:22] tyhicks: and that shouldn't be blocked on sbeattie's vacation [13:22] tyhicks: but, it probably doesn't matter, sbeattie is back next week [13:23] tyhicks: re kernel patches> jj sent out pull requests for the phablet kernels a few minutes ago [13:24] pitti: that was bc you'd said hey about 8 hours ago :) probably bc I pinged you yesterday - ttyl :) [13:24] tyhicks: the desktop kernel we could keep waiting on [13:24] jdstrand: and sbeattie did respond to the thread - I don't think that we're blocked by his vacation at all [13:25] tyhicks: ok, it sounds like we just need to have the ipc implication discussion, then we can make the cahnges and upload? [13:25] hallyn: heh, fun; so, enjoy your day :) [13:25] tyhicks: then refine as needed [13:25] tyhicks: is that accurate? [13:25] jdstrand: yes, exactly [13:26] tyhicks: ok. I think some testing I did yesterday showed this to be the case, but if there are dbus rules present in the policy and we boot into a non-v3 kernel, everything works like it does now (ie, the dbus rules are effectively ignored). correct? [13:27] jdstrand: yes, dbus-daemon detects that /sys/kernel/security/apparmor/features/dbus/ does not exist and does not try to enforce any apparmor mediation [13:28] tyhicks: ok, perfect. so, actually, have phablet kernels with v3 and desktop kernels without exercises different code paths nicely [13:29] jdstrand: yes, both paths will be exercised [13:30] tyhicks: are you comfortable with the path forward then? [13:30] jdstrand: yes, it is clear [13:32] Is it possible for the PC/phone to know the battery charge level of a connected Bluetooth headset? (cyphermox?) [13:38] tyhicks: awesome, thanks! :) [13:40] OdyX, perhaps we should somehow change the cost factors in the cups-filters package to get the desired workflows? [13:41] mpt: in theory yes, I've seen it :) [13:41] excellent [13:42] mpt: I'll look up the details [13:44] tkamppeter: I don't oppose that, certainly. What I want is that the cups IPP tests run with the cost factors that are shipped in the packages. [13:50] cyphermox, https://wiki.ubuntu.com/Power#Indicator === Nisstyre-laptop is now known as Nisstyre === wedgwood_away is now known as wedgwood [14:02] ev, "average out across all days" will result in very-nearly-zero rates for every error that started less than a year ago. Probably you want to collect only the past week or something like that. [14:03] ah yes, but generally does that look like the right algorithm? [14:04] I'll rewrite it without looking and see if I get the same result... [14:06] Architecture is most important if absolute_value(rate(some_architecture) - rate(others)) > any_other_difference === davidcalle_ is now known as davidcalle [14:08] ev, i.e. for a given period, errors(architecture)/machines(architecture) - errors(all_other_architectures)/machines(all_other_architectures) === soren_ is now known as soren [14:10] mpt: was about to pastebin some code I already wrote to that effect, but immediately realised it looks like really bad Perl. :-/ [14:10] thank you though [14:10] Don't worry, I wouldn't be able to tell the difference between really bad Perl and really good Perl [14:11] No one can, it's write only. [14:11] amazing [14:12] there's really good Perl? === kentb-out is now known as kentb [14:12] Thanks ScottK, I thought it would take at least two minutes for someone to take that and run with it. ;-) [14:12] There is actually. [14:12] It's just rare. [14:13] hehe :P === LordOfTime is now known as LordOfTime|EC2 [14:22] hi, i just note that Ubuntu's 'chmsee' package struck at version 1.3.0-2ubuntu2 [14:22] can we re-sync with Debian? Debian has latest upstream version in sid [14:23] It's presumptively up to the last uploader (chrisccoulson) to either do it or delegate it [14:23] maxiaojun, we sure can, if you want to work on it please do and subscribe sponsors? [14:23] seb128, what do you mean by "please do"? [14:24] maxiaojun, if you want to update the package/rebase it on the current debian version that would be welcome help [14:25] i still don't understand what exactly should i do. file a bug? link a branch? [14:26] maxiaojun: http://developer.ubuntu.com/packaging/html/udd-merging.html [14:27] chmsee is a difficult package as it was patched to build with webkit instead of xulrunner [14:35] are the patches still needed? as the upstream is keeping up with Firefox change (though i think they should set slight larger MaxVersion) while webkit branch seems unmaintained === cr3_ is now known as cr3 === cr3 is now known as Guest74319 === Guest74319 is now known as cr3 === halfie_ is now known as halfie === mmrazik is now known as mmrazik|afk === mitya57_ is now known as mitya57 [15:21] ev: splendid, thanks! [15:32] pitti: sure thing. Tracking in https://bugs.launchpad.net/ubuntu/raring/+source/apport/+bug/1194541 [15:32] Launchpad bug 1194541 in apport (Ubuntu Quantal) "Create core dumps for setuid binaries" [Undecided,New] [15:37] ev: ah, the saucy one didn't have that bug ref, closing manually === micahg_ is now known as micahg === zumbi_ is now known as Guest82596 [15:40] thanks [15:43] jodh: hi! I can't remember, what was the eta for upstart/apparmor with mdeslaur's distro patch? [15:45] jdstrand: plan was "by tomorrow" as of last week, but we've had a nasty merge to perform which has slowed things rather I'm afraid. That merge is now done so once I've got an ack on a couple of other upstart branches we can get a new upstart release out. === mchro- is now known as mchro [15:49] jodh: ack, thanks for the update and your work on this :) === BenC_ is now known as BenC === Bluefoxicy_ is now known as Bluefoxicy === ion_ is now known as ion === masACC is now known as maswan [17:08] mdeslaur, hi :), could take a look at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0037 which would mean to get at least raptor2 2.0.7-1 into precise [17:08] Redland Raptor (aka libraptor) before 2.0.7, as used by OpenOffice 3.3 and 3.4 Beta, LibreOffice before 3.4.6 and 3.5.x before 3.5.1, and other products, allows user-assisted remote attackers to read arbitrary files via a crafted XML external entity (XXE) declaration and reference in an RDF document. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0037) [17:10] ricotz: we fixed that already: http://www.ubuntu.com/usn/usn-1480-1/ [17:11] mdeslaur, ok, this is about libraptor2-0 too [17:12] which librdf0 uses [17:12] ricotz: ah! I see, ok, I'll reopen the CVE and add raptor2 to it. Thanks! [17:13] mdeslaur, thanks === dpm is now known as dpm-afk === mhall119_ is now known as mhall119 === sraue_ is now known as sraue === manjo` is now known as manjo === bigon_ is now known as bigon === pbn_ is now known as pbn === Elbrus_try_again is now known as Elbrus === masACC is now known as maswan === lucas__ is now known as lucas === andreas__ is now known as ahasenack [18:56] G'day folks.... === mterry_ is now known as mterry [19:13] @pilot in === 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: barry [19:50] barry: since you're piloting, you saw my 2 mp's for xdiagnose, right? [19:51] jbicha: nope. they don't show up on the sponsoring page, but send me the urls and i'll take a look === thomi_ is now known as thomi [19:52] https://code.launchpad.net/~jbicha/xdiagnose/fix-installing-icon-and-tweak-desktop/+merge/170927 [19:52] https://code.launchpad.net/~jbicha/xdiagnose/mark-apply-close-translatable/+merge/170928 [19:54] jbicha: i don't want to step on bryce's toes (his review claim is pending). but maybe that was a few days ago [19:54] and he's on to other things? [19:55] never mind, I saw a B name and mixed you two up [19:55] jbicha: np [19:55] * barry will leave it to bryce then [19:56] jbicha: but it looks like you do have a few other things in the queue, so maybe it's your luck day :) [20:02] what was the story around GL and armhf? Or any pointers about fixing https://launchpadlibrarian.net/141550690/buildlog_ubuntu-saucy-armhf.qtiplot_0.9.8.9-4ubuntu1_FAILEDTOBUILD.txt.gz [20:02] as far as I can tell glu.h does exist during build ... [20:06] xnox: GL on armhf should be EGL, but that shouldn't matter; I don't see libglu1-mesa-dev being installed as part of that build log? [20:06] you need an additional -dev package for glu vs. gl [20:07] ok, thanks =) [20:12] robru, kenvandine okay, that was beautiful! i was just using the friends app to post a new message. i got as far as "say hell" and it crashed :) [20:12] barry, nuh uh!! nyanyanyanyanyanyanya i can't hear you!!!! [20:12] barry: you have the special version that's limited to 14 chars [20:12] robru: say hell! [20:13] * barry has a new motto for today [20:13] barry, yeah, I'm getting lots of crasher bug reports for friends-app lately. I can't reproduce it, and i don't know much about Qml to fix it. I think kenvandine needs to step in here... [20:13] humm [20:14] not much going on there to cause it to crash [20:14] i've seen it crash on startup if you don't have an account enabled [20:15] but while you're typing all it does it change the counter [20:15] barry, got a crash file? [20:16] kenvandine, also: https://bugs.launchpad.net/ubuntu/+source/friends-app/+bug/1176498 read the comments for two *different* crashes [20:16] Launchpad bug 1176498 in friends-app (Ubuntu) "friends app crashes on start." [Undecided,Confirmed] [20:17] kenvandine: i just ubuntu-bugged it [20:18] * Laney wanted to congratulate barry in #debian-devel but he's not there so couldn't [20:18] well done ;-) [20:21] Laney: thanks! [20:23] kenvandine: lp: #1194638 [20:23] Launchpad bug 1194638 in friends (Ubuntu) "friends crashed when I typed "Say Hell"" [Undecided,New] https://launchpad.net/bugs/1194638 [20:30] sw33t, the Foundations team has K DDs and can launch its own GRs now \o/ [20:30] barry: grats ;) [20:31] slangasek: \o/ [20:31] slangasek: right, I did a build with libglu1-mesa-dev before, and armhf FTBFS with this now http://paste.ubuntu.com/5799672/ which in turn means one shouldn't include both GLES2 and GL =/ [20:32] barry, thx [20:32] xnox: it's true that it should not... is glu GL-only? [20:34] slangasek: not sure. but I'm now discovering bug 707794 [20:34] bug 707794 in clementine (Ubuntu) "libqt4-opengl on armel should be compiled with OpenGL ES 2.x support" [Undecided,Triaged] https://launchpad.net/bugs/707794 [20:35] * slangasek nods [20:35] barry, you filed that against friends, is there a crash file for friends-app? [20:36] kenvandine: oops, sec [20:38] slangasek: looks like it was added for fit FTBFS with qt4.8 hmmm..... [20:38] https://bugs.launchpad.net/ubuntu/+source/qtiplot/+bug/925652 [20:38] Launchpad bug 925652 in qtiplot (Ubuntu) "please sync qtiplot (universe) from Debian main (unstable) 0.9.8.8-3 (fix crasher and FTBFS)" [Medium,Fix released] [20:44] kenvandine: oops, there was a crash reporter window buried. i'll use that to report the bug on friends-app [20:45] barry: ah, excellent, good to see advocatees make it through :) === vanhoof_ is now known as vanhoof [20:49] barry, thanks! [20:49] OdyX, I have changed the cost factors of cups-filters, now setting the cost factor of pstops in CUPS is not necessary any more. See current BZR state of cups-filters, rev. 7072. https://bugs.linuxfoundation.org/show_bug.cgi?id=1138 [20:49] bugs.linuxfoundation.org bug 1138 in cups-filters "Filters should not specify artificially low costs" [Normal,Resolved: fixed] [20:51] kenvandine: lp: #1194646 [20:51] Launchpad bug 1194646 in friends-app (Ubuntu) "Crashed when I typed "say hell"" [Undecided,New] https://launchpad.net/bugs/1194646 === Nisstyre-laptop is now known as Nisstyre === seb128_ is now known as seb128 [21:02] * xnox finds https://code.google.com/p/glues/ [21:12] hey slangasek [21:12] http://blog.utlemming.org/2013/06/psa-ubuntu-server-1104-natty-archives.html [21:13] If I wanted to file a bug like "we shouldn't break people's servers just because a distro is EOL" where should I file it? [21:13] or is this something I can bring up on the devel list? [21:18] jcastro: maybe -devel; it's not really a bug in the OS that we don't have infinite space to keep EOLed releases on the mirrors forever, and it's not clear to me we should actually be putting a lot of effort into making it a more pleasant experience to continue running a release with no security support [21:19] sure, I understand that. [21:19] I would think sharing slow bandwidth with all the other bad kids would be encouragement enough [21:20] jcastro: How do you propose we not break things? [21:20] or perhaps spit out a warning via apt or something instead of just 404'ing people [21:20] infinity: I would say something like "this distro is EOL, we've moved you to slow mirrors no one cares about, but this is the least of your problems, please see this wiki page" [21:21] right now we just 404 them [21:21] jcastro: Automatically editing people's sources.lists just because they start 404ing would be fraught with peril. [21:21] maybe we can do a motd or something? [21:21] jcastro: In fact, automatically doing it at any point (even based on a more clever meta-release hint) seems bad. [21:22] we already motd about new upgrades available, right? [21:22] jcastro: We already do an motd telling them there are new releases to upgrade to... Which they ignored for two years. [21:22] s/upgrades/releases/ [21:22] infinity: sure, but admins are going to "if it ain't broke I'm not upgrading" [21:22] which is reasonable [21:22] yeah but there's a difference between "new version, I don't care, this server works" and "if you don't listen apt will break." [21:22] and I think it would be a worthwhile improvement to have the motd have another check and announce "you're EOL" === jelmer_ is now known as jelmer [21:23] Yeah, we could add an motd hook to yell at you if you're running an EOL release. [21:23] Well, it would be in the same upgrade-check hook. [21:23] Since the same info comes from the same place. [21:23] right so I think it's probably better to not spend the cost on moving people to old-releases, but maybe instead being more in your face when you're EOL [21:23] should arguably be made part of the existing ubuntu-release-upgrader-core hook [21:23] infinity: ok so I can just do a wishlist on the motd package? [21:24] slangasek: I think I just said that. :) [21:25] So, check-new-release would need to grow an option (or a sister binary) for check-eol. [21:25] And the rest is trivial. [21:25] ubuntu-release-upgrader-core is the package I want? [21:25] jcastro: Wishlist on ubuntu-release-upgrader with proposed tasks for some stables as well. [21:25] yep [21:26] actually [21:26] /usr/lib/ubuntu-release-upgrader/check-new-release, line 116 [21:26] thanks fellas [21:26] if m.no_longer_supported is not None: [21:26] url = "http://www.ubuntu.com/releaseendoflife" [21:26] print(_("Your Ubuntu release is not supported anymore.")) [21:26] print(_("For upgrade information, please visit:\n" [21:26] "%(url)s\n") % { 'url' : url }) [21:26] Err, oh. [21:26] Indeed. [21:26] jcastro: So, it already claims to do this. :P [21:27] jcastro: already fixed; if these users were running a newer release they wouldn't have had this problem! [21:27] [21:28] though actually, the changelog implies this code should've been in natty [21:28] And it may well be. It could fail to trigger due to the stale lock bug. [21:28] the which? [21:29] The bug wherein, once you've been informed of an upgrade, that snippet never runs again. Ever. [21:29] (This is fixed in precise and onward in SRUs, I believe...) [21:29] ah [21:30] oh ok [21:30] so tldr, it's fixed in newer releases [21:30] yes [21:30] it would then make sense why ben sees people complaining about natty, but not q [21:30] Probably. Would be worth a bit of testing by artificially EOLing precise locally or something. [21:31] jcastro: Q isn't EOL, why would they complain about it? [21:31] infinity: because I suck at arithmetic [21:31] infinity: so theoretically, when Q EOLs, we shouldn't see this as much as with Natty [21:31] oneiric is EOL, but we've not removed it from the mirrors due to OEM SLAs. [21:32] jcastro: Well, even if the release-upgrader/motd bits are all working better now, I wouldn't bet we'd see people complain less. :P [21:32] * cjwatson awards software-properties the title of "most frustrating autopkgtest failures" [21:32] so ... close ... [21:32] jcastro: But I don't think forcefully mangling people's apt sources without warning is a particularly friendly thing to do either, so... [21:33] jcastro: We're going to get people whining about the 404s, and we always have had. [21:33] yeah I get that [21:33] (Yeah, I'm a pessimist) [21:34] Anyhow, given that the lock bug wasn't actually about fixing THIS, I doubt anyone's tested the EOL case specifically. Probably worth a poke to see if it works as expected for future releases. [21:34] XP is 11 years old and it's mirrors don't 404. They gracefully just stop updating it [21:34] Shame it's too late to SRU back to oneiric. [21:34] "gracefully" is up to interpretation there. === seb128_ is now known as seb128 [21:35] jcastro: If I could think of a reliable way to auto-rewrite people to old-releases, that would get us the same "doesn't 404, but doesn't update" thing. [21:35] I wonder if just a url rewrite would do the trick? [21:36] that only helps for mirrors we control [21:36] jcastro: despite appearances, MS says XP is supported for another 10 months or so.. [21:36] jcastro: But given that we specifically allow (and even encourage) people to mangle sources.list to their heart's content, it's not the easiest thing in the world to do sanely. release-upgrader tries (and when it fails, just gives up and writes a new one), but that's interactive, and it warns you. [21:36] * jcastro nods [21:37] I think the motd warning does the job [21:37] I didn't know we had fixed that [21:37] infinity: make an apt archive with the release name "eol" that has empty Packages/Sources/etc… and use mod_rewrite to just send dead releases to that? [21:37] dobey: I'm not sure how that solves... Anything. [21:38] dobey: Other than "ugliness", empty Packages files and 404s are the same thing. Can't install software anymore. [21:38] we should totally just turn the tty blood red with white text when something EOLs [21:38] jcastro: Then they'll just think they accidentally launched a NetWare installer. [21:38] (Okay, as if any kid in IT today remembers NetWare...) [21:38] U+1258930 LATIN SMALL LETTER I DRIPPING WITH BLOOD === seb128_ is now known as seb128 [21:39] wouldn't that be U+666? [21:39] dobey: Anyhow, if mod_rewrite tricks worked (as in, if we had control of the server side), we'd just rewrite people to old-releases. [21:39] dobey: Which we clearly can't, because mirrors. [21:40] well. it's ok. they just all go on askubuntu and ask jcastro to fix it for them anyway :) [21:41] only 23k views on the question [21:41] I'm okay with that solution. [21:41] which is neither a huge problem nor a trivial problem [21:41] Auto-rewrite: be careful of people within corporate networks where they can't talk to old-releases. [21:42] (Just one reason forceful mangling would be scary.) [21:44] infinity: in better news, I've seen the "problem with MergeList" problems nearly disappear [21:44] wrt. apt === seb128_ is now known as seb128 [21:44] jcastro: The one that was the hard limit on combined list sizes? [21:45] i think part of it was when you connected to a guest wifi with like a disclaimer page apt would append that text to a file or something crazy like that [21:45] so basically everyone who was in a hotel would hit the problem [21:46] Daviey: Say, weren't your minions meant to be attending to MIRs for all of puppets new deps? That seems to have been not happening for... Months. [21:46] jcastro: Ahh, yeah, I think the captive portal case is mostly catered for, except for a few corner cases. [21:46] jcastro: It's still not completely fool proof. We keep finding better fools. === dduffey_afk is now known as dduffey [21:55] infinity: err, yeah - we'll look at that this week. [22:01] So this autopackagetest block for britney blocks other packages too? [22:01] I'm looking at pykde4 and it's apparently blocked by an apport autopackagetest. [22:02] Reverse dependencies are checked as well as the packages themselves [22:02] However it's currently buggy and forgets about failures, so ... [22:02] pykde4 in the release pocket is currently broken. [22:02] You know about force-autopkgtest, right? :P [22:03] I put that there precisely so people wouldn't need to complain [22:03] * ScottK tries. [22:03] That said, by the time you've done that the test might well have completed [22:03] (Note that the thing to force-autopkgtest is the tested package, not the triggering package) [22:05] So in this case pykde4? [22:06] No, the tested package is apport/2.10.2-0ubuntu2, the triggering package is pykde4/4:4.10.80-0ubuntu1 [22:06] It is slightly frustrating to set something up, have to go offline for ~8 hours for $work and then come back to find yet another roadblock. [22:06] IOW the point is to test that the new pykde4 doesn't break apport [22:06] But it's possible to say "this autopkgtest is funted right now, ignore its failure" [22:07] What's "I don't care, migrate it." [22:07] I guarantee you it's broken in the release pocket right now. [22:07] (due to a new sip4 I messed up in Debian and it autosynced) [22:07] "force-autopkgtest apport/2.10.2-0ubuntu2, the triggering package is pykde4/4:4.10.80-0ubuntu1 [22:07] err [22:08] "force-autopkgtest apport/2.10.2-0ubuntu2" will make it eligible. But you really really need to let update_output look at things beyond that. [22:08] So how did sip4 get in and break it? [22:08] It should go if autopackagetest isn't stopping it. [22:08] I missed an API version change when I packaged it in Debian. [22:09] Ah, it's been broken for a week then? [22:09] plus added unfortunate timing in a rebuild from me to add autopkgtest. [22:09] yeah, for quite a while now. [22:09] Not to mention pykde4 from 4.10.80 hit the archive about one publisher cycle before it would have migrated. [22:10] Then it was blocked on the kde4libs/armhf mess. [22:10] I'm not wild about using maximum force to shove it in then. Use minimum force so that it actually happens right this time. [22:11] But as you say it does look as though force-autopkgtest should be enough. [22:11] OK. Fixed. [22:11] are there still bugs around tests being left at RUNNING? [22:12] BTW, this particular issue is proving harder to fix in Ubuntu than Debian. [22:12] I saw a bunch of armhf-only migrations while kde4libs/armhf was broken that went in suspiciously easily. I'm still concerned that those will be left uninstallable even after the dust settled. [22:12] Laney: I think that's fixed [22:12] The bug I know of at the moment is that failure states are forgotten after the run that initially collects them [22:12] Hmm, alright. I'm suspicious about glib2.0 -> bluez/firefox [22:13] Jenkins says they both ran at 17:20ish today [22:13] adt-britney collected statuses for those six minutes ago that said running [22:14] * ScottK needs to go retrieve a $CHILD from ballet lessons. [22:14] hm, but [22:14] Maybe jenkins is lying then [22:15] $ cat ../../autopkgtest/data/adt/saucy-proposed/amd64/archive/2013/06/25/saucy_amd64_bluez_20130625-172427.result [22:15] Probably remove some autopackage tests when I get back. Seems like more harm than good to me. [22:15]