[00:00] bug 1049028 [00:00] Launchpad bug 1049028 in evolution-data-server (Ubuntu) "Unable to create gmail account" [High,In progress] https://launchpad.net/bugs/1049028 [00:01] cjwatson, do you see any problem to include updates and rebuild an 12.10.1 iso for UGR? [00:02] Not in general but I haven't looked at how UGR is laid out [00:02] (Nor am I going to at 1am :-) ) [00:02] cjwatson, just one last question them [00:03] how did you guys build the ubuntu iso? is it a custom script or live-build? [00:03] live-build for the squashfs, a collection of stuff mostly involving debian-cd for the iso9660 container [00:05] humm, good to know, I will move our squashfs build to live-build for 13.04 [00:07] are you doing it by hand now or something? [00:07] cjwatson so its just a small script, that runs a bunch of apt commands in a ch-root [00:08] cjwatson, yes, debootstrap and apt-get install's on chroot [00:08] cjwatson, https://code.launchpad.net/~ubuntu-gnome-dev/+junk/iso-build-script [00:10] I haven't looked, but live-build should be able to obsolete most handwritten scripts of that kind, yes [00:11] cjwatson, any tutorial or sample about how you guys use live-build? === cpg|away is now known as cpg [00:38] everaldo: google for my post to ubuntu-devel about it a year or so back [00:40] got it https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html [00:41] cjwatson, so simple... thanks :) [00:51] everaldo: I think that's deceptively simple, at least I wasn't able to figure it out but maybe I'm too impatient [00:51] You'd have to hack on livecd-rootfs/live-build/auto/config a little [00:51] Shouldn't be desperately much [01:33] what's the package name of the thing that truncates changelogs on builds? [01:33] binary-pkg-mangler ? [01:33] that's it [01:34] but I searched for that and failed to find. [01:34] pkgbinarymangler [01:34] that thing :) [01:34] aha [01:34] it's vital for multiarch otherwise your changelogs don;t match up [01:35] do binNMUs have changelogs? [01:36] yes. There was some discussion of this on debian devel [01:37] you really want to take the binNMU change out of the changelog (and record it elsewhere) to avoid multiarch breakage [01:37] it's been bodged for the time being in dpkg, I think [01:44] wookey: But not so much of a problem for Ubuntu because we don't have single-arch binNMUs yet. [01:44] (And not planned for the near future.) === jtechidna is now known as JontheEchidna [01:58] cjwatson: I did a test for you to see whether you had regressed bug 803658 during Q cycle (and you had). [01:58] Launchpad bug 803658 in grub2 (Ubuntu) "grub-install /dev/mapper/isw_$UUID_$NAME0 failing with ICH10R raid 1+0" [High,Fix released] https://launchpad.net/bugs/803658 [01:58] cjwatson: I don't recall reverifying for you; did you end up reproducing the setup and validating that you didn't regress it ? [01:58] cjwatson: or should I be ultra paranoid about upgrading that machine to Q ? [02:03] lifeless: as I mentioned at the time, I managed to reproduce it in simulation with manual dmsetup commands, and I believe I fixed it, although it's true you never positively confirmed that [02:04] It's not explicitly in the changelog because I fixed it before releasing 2.00-3ubuntu1 [02:05] (which was the first of the 2.00 merges to hit Ubuntu proper) [02:10] Hm. The 12.10 desktop installer doesn't seem to see the existing Windows 8 partition on this system; it thinks both discs have no partition table. That's not wonderful. [02:12] I guess it's time to redo that liveusb with a persistent partition so I can grab the logs. [02:12] cjwatson: kk, thanks [02:14] RAOF: If I need to grab logs, and I used usb-creator to create the live USB drive, I go to a console, remount /cdrom read-write, copy logs, remount read-only to be safe, and shut down. [02:14] Thats worked for me in the past. [02:15] TheMuso: Sounds good. [02:15] cjwatson: Actually, you're awesome at everything - does apport work in the liveusb environment? [02:46] darkxst, everaldo: so bugs 1069475 and 1069908 that jbicha was calling my attention to earlier are bugs with the CD and not with the grub2 package, correct? [02:46] Launchpad bug 1069908 in grub2 (Ubuntu) "Ubuntu GNOME Remix image don't boot on EFI systems" [Undecided,Confirmed] https://launchpad.net/bugs/1069908 [02:46] Launchpad bug 1069475 in grub2 (Ubuntu) "grub fails to boot unsigned kernel" [Undecided,Confirmed] https://launchpad.net/bugs/1069475 [02:48] slangasek, yes [02:48] slangasek, we got stung by the late changes to secure boot ;( [02:50] darkxst: so I gather - sorry about that [02:50] darkxst: is there somewhere else those two bugs should be reassigned? [02:51] slangasek, we don't actually have a package for our build script currently, [02:51] slangasek, maybe just assign them to jbicha? [02:51] is there a launchpad project? (since bugs can be reassigned from packages to projects, now) [02:52] it lives in jbicha's + junk folder, but if that is the case we should make a project [02:52] would probably be a good idea to :) [02:57] I can has nexus? [02:57] Surely a howto for 13.04? [02:58] When? So I can set my OMG. [02:58] I'll be in the saltmines. Waiting, I suppose. [02:58] ;_; [02:59] Seven more days? [03:04] Bestturingssysteem. [03:07] As the proud father of a recently-newborn, than quit message is entirely wrong; there's nothing intuitive about the nipple :) [03:08] hehe [03:08] slangasek, how do I reassign bug to a launchpad project ? [03:08] (https://launchpad.net/ugr-iso-build) [03:09] darkxst: on the bug page, click the arrow next to 'grub2' under Affects; choose 'Project' and fill in the name [03:14] slangasek, ok, got it. thanks [03:30] Good morning [03:31] pitti: isn't it insanely early for you? [03:31] * slangasek waves to pitti [03:31] bdmurray: I reassigned 1053749 to davmail, as several people seem to have reproduced it with installing this package [03:31] hey slangasek [03:32] sarnold: it's a bit earlier than usual, yes; but my head started working, can't sleep any more [03:33] pitti: heh, if the brain is already spinning, you might as well use it... [03:45] pitti: there's no davmail package in the archive; furthermore, the bug is in failing to handle an existing dpkg database [03:46] indeed, just saw the LP error; I reassigned it to dpkg now and gave it a clearer title [03:47] it's not a dpkg bug either [03:47] this is existing data [03:47] dpkg can't possibly undo it; the consumer needs to cope with the encoding issue [03:51] slangasek: so, back to "invalid" again then? [03:51] how is it invalid? [03:52] there's a crash on non-unicode input; this is a legitimate real-world situation; the client needs to cope with this [03:54] ooh, I see, sorry [03:54] ok :) [03:55] so, I guess I'll just intercept/ignore it in u-d-common [04:05] where could I find the acer alps touchpad source code [04:08] skunk: Shared between the kernel and xserver-xorg-input-synaptics [05:20] is there anyway we can extpedite the evolution-data-server fix for gmail into -updates? Bug 1049028 [05:20] Launchpad bug 1049028 in evolution-data-server (Ubuntu) "Unable to create gmail account" [High,In progress] https://launchpad.net/bugs/1049028 [05:20] we are about to rebuild images to fix efi boot issues and would be nice to have that fix also [05:21] (images for ubuntu GNOME remix) === morphis is now known as morphis|away [05:22] darkxst: How sure are we that the patch is safe? [05:23] RAOF: very sure, its just installing missing files [05:23] that said I guess there could be backs in the modules that it installs, since it has been broken since July [05:23] s/backs/bugs/ [05:24] darkxst: Then I'll push it out now; it's had 3 days, and bugs in modules that weren't installed before are unlikely to be regressions. [05:25] RAOF, well they were moved in July , but no one even noticed since then [05:25] RAOF, and thanks [05:26] Yeah; we got UOA, which actually works :P [05:27] darkxst: RAOF: 3.6.0-0ubuntu3 is in the release pocket [05:28] micahg: Not according to my rmadison output? [05:29] oh, eds, neverming [05:29] *nevermind [05:29] micahg: Launchpad also seems to think that 3.6.0-0ubuntu3 is in quantal-proposed [05:29] * micahg was looking at evolution [05:29] * micahg really should go to sleep [05:29] Ah, yeah. [05:29] darkxst: Copied to quantal-updates (and raring). [05:30] RAOF, thanks [05:52] lol, how is this possible "UpgradeStatus: Upgraded to quantal on 2011-04-01 (529 days ago)" [05:54] System clock out of sync? [05:59] RAOF, yes that is a good explanation, but you might expect someone would notice that ;) [06:02] I have another patch that needs sponsoring bug 1064354, patch has been committed upstream also [06:02] Launchpad bug 1064354 in gnome-shell (Ubuntu) "When running lightDM user locking doesnt work" [Undecided,Confirmed] https://launchpad.net/bugs/1064354 [06:21] RAOF, micahg, perhaps you could upload ^^ for me? === guang_ is now known as haha === haha is now known as guang_ [07:01] doko_: python-apt is building again, but there is a test failure that looks like something in subprocess [07:03] good morning === morphis|away is now known as morphis === smb` is now known as smb === morphis is now known as morphis|away === tkamppeter_ is now known as tkamppeter [08:16] pitti, hi [08:23] anyone here got a sandy/ivy bridge chip and is running unity? === bencer is now known as heidita2 === mcclurmc_away is now known as mcclurmc === heidita2 is now known as bencer [08:24] yes [08:25] Laney: could you try running powertop and seeing the rc6 stats? [08:26] it's under the idle stats tab [08:26] on my laptop it's stuck at 90+% active [08:26] i'm wondering if that's supposed to be the case or if unity's sucking. [08:27] cc6? [08:27] O_o [08:27] no, it's RC6 [08:27] under GPU [08:27] don't see that [08:27] Active, RC6, RC6p, RC6pp [08:27] hmm [08:27] werid [08:28] C{1,3,6}-IVB [08:28] weird [08:28] anyway C6 is high [08:28] maybe you don't have rc6 enabled. [08:28] dunno what it means though [08:29] it's supposed to go down to C7 [08:29] mine spends most of the time in C7 for CPU [08:29] but the GPU is spending most of its time active [08:29] and since upgrading i've been getting these sporadic hangs [08:30] [16938.783806] [drm:__gen6_gt_force_wake_get] *ERROR* Force wake wait timed out [08:30] ugh === stan_ is now known as stan === doko_ is now known as doko [08:57] mvo: both for 3.2 and 3.3? [08:58] hyperair: Note that running powertop means that you'll have a blinking cursor on the screen, which means you'll be continually waking up the GPU for vsyncs. [09:00] RAOF: hmmm. meaning that it never goes into rc6 unless the screen is completely still? [09:01] hyperair: I don't know; I would assume that you'd still be able to get into rc6 even with a 60Hz timer. I'm just saying that powertop distorts the power metrics by running :) [09:01] RAOF: well i was working on emacs, and leaving powertop running in the background, so i don't think it really counts [09:01] but yes, blinking cursor [09:02] Yes, it does, because the blinking cursor still means wakeups even when it's not visible - because of composite, all windows are always “visible” [09:06] ah right. [09:07] i actually just closed my terminal while leaving powertop running in screen and went away for the past 5 minutes, but when i came back it was 100% [09:07] heh === quadrispro_ is now known as quadrispro [09:34] TheMuso, why is python3-louis an Arch: any package? === morphis|away is now known as morphis [09:57] doko: http://paste.ubuntu.com/1299692/ <- this fails in py3.3, but works fine in 3.2 and 2.7 - should it? [10:02] mvo, looking at the docs, it's found in 3.3.0 too [10:07] mvo: hmm, don't see anything documented. the only thing I read is: "When stdout or stderr are pipes and universal_newlines is True then the output data is assumed to be encoded as UTF-8 and will automatically be decoded to text. All line endings will be converted to '\n' as described for the universal newlines 'U' mode argument to open()." [10:07] but this is not 3.3 specific [10:08] doko: right, I can clarify with barry later if you want and add a workaround for now, but it seems like this is a unintended break in the new _save_input() in the subprocess modules [10:08] module [10:08] mvo: u"u" does work in 3.2?? [10:08] doko: no, just remove it there if you want to run the test [10:09] doko: its only needed for 2.7 and 3.3, its illegal on 3.0-3.2 [10:09] (and in 3.3 its just doing nothing but makes porting easier) [10:10] looks like _save_input was added for the new timeout parameter. looks like a bug [10:11] mvo, can you add an issue to the tracker? [10:11] doko: sure, let me do that === henrix_ is now known as henrix [10:16] mvo: I understood this as intentional - it certainly came up in python3-debian testing [10:17] It's documented in "Frequently Used Arguments" in subprocess [10:17] mvo,doko: http://paste.ubuntu.com/1299724/ [10:18] cjwatson: so it was a mistake that this was accepted before? [10:18] That's my understanding [10:18] ok, thanks [10:19] I think you need to either not support 3.2, drop universal_newlines and do manual encoding/decoding, or do something clever I haven't thought of [10:19] if sys.version_info[0] < 3 and sys.version_info[1] < 3: ... <- not very clever [10:20] can't remember if sending unicode to stdin with universal_newlines works with 3.2 [10:20] I will check === henrix_ is now known as henrix [10:33] mvo: not more clever, but shorter: if sys.version_info[:2] < (3, 3) [10:35] doko: good point! [10:36] mvo: at least for raring, it should be fine. we won't have 3.2 at the end of the cycle anymore, but 2.7 is another thing [10:36] sys.version < "3.3" [10:36] works too [10:36] * mvo nods [10:36] yeah, assuming every alpha has the same behaviour [10:37] for both cases ... [10:37] doko: ok, I prepare a upload [10:39] so now all public python3 modules in main should be available for 3.2 and 3.3 (pending apt, qt4, qscintilla2) [10:40] ScottK, ^^^ [10:42] doko: do you know if someone update the Ubuntu.info.in template already? [10:43] mvo: which package is this? [10:43] doko: python-apt === Ursinha is now known as Ursinha-afk [10:46] mvo: no [10:46] doko: ok, I do it now === morphis is now known as morphis|away [10:47] doko: I have python-qt4 mostly ready. [10:47] Should be ready later today. [10:48] will you work on qscintilla too? [10:48] I didn't look at it yet, but I will. No promises about today. [10:49] doko: its ready now, should I upload? [10:51] doko: Well done on the first FTBFS of the series. :P [10:51] doko: (Is python3-dev meant to be python3.3 now, cause it sure looks like it's 3.2) [10:52] infinity, yeah, you're just too late with the eglibc update ;-P === henrix_ is now known as henrix [11:00] doko: uploaded, I will be back, lunchtime [11:03] doko: python3-apparmor is a compiled extenstion in main and built against (default py3) 3.2 only as far as I can see. [11:04] note the "python3 (<< 3.3)" deps. [11:04] xnox, yes, according to pitti, it's only built for the default version (although I think it should be built for every one) [11:06] doko: Jamie and I were the last ones to look at it =) (providing py3 packages) and yes it cheats and builds against default only... [11:06] * xnox ponders if that automatically means I should be fixing it.... [11:08] xnox, heh, why not? [11:08] =_ [11:08] =) [11:08] * xnox creates a symlink in /usr/share/debootstrap/scripts === cpg is now known as cpg|away === _salem is now known as salem_ === cpg|away is now known as cpg [11:26] doko: will have a new fix in a minute. === morphis|away is now known as morphis [11:38] fire alarm in my house, will do that later [11:38] :) [12:07] ch /win 6 [12:30] doko: did you have to fix ac_python_devel.m4 anywhere yet to pick up multiarched/two python3.3-dev include locations? [12:30] xnox, pythonx.y-config --includes should be used, if present, else the hardcoded stuff should be used as a allback [12:31] but I don't know which ac_python_devel.m4 you refer to [12:32] doko: ack. didn't know about pythonx.y-config. Well ac_python_devel.m4 is a copy-pasted m4 macro from the autoconf-archive which tries to use pythonx.y -c "import distutils.sysconfig; print distutils..." [12:33] xnox, and print exactly what? [12:33] if test -z "$PYTHON_CPPFLAGS"; then [12:33] python_path=`$PYTHON -c "import distutils.sysconfig; \ [12:33] print distutils.sysconfig.get_python_inc();"` [12:33] if test -n "${python_path}"; then [12:33] python_path="-I$python_path" [12:33] fi [12:33] PYTHON_CPPFLAGS=$python_path [12:33] fi [12:35] xnox, well, this already fails with print not a statement anymore ... [12:35] haha true =) [12:36] it should work if that thing returns a single item though ;-) [12:36] or something like (single item tuple?!) [12:36] but fails with python3.3 due to two items returned. [12:36] * xnox will use -config in a sec. [12:37] xnox, so call the function a second time with plat_specific=1, and if the two values differ, append it [12:37] xnox: No, in Python 3 the requirement for parentheses in print() is a syntactic restriction, not dependent on the type of the argument [12:38] Try it yourself: foo = (1,); print foo -> SyntaxError [12:39] cjwatson: thanks. [12:39] doko: ack. [12:41] Bleh. Someone really should fix https://bugs.launchpad.net/ubuntu/+source/libnih/+bug/997359 [12:41] Launchpad bug 997359 in libnih (Ubuntu) "nih uses eglibc private symbol __abort_msg" [High,Confirmed] [12:41] * infinity decides to have some lunch instead of arguing with computers. [12:43] infinity, in the past, I did the upload of a new version as ~pre something to work around this === morphis is now known as morphis|away === Ursinha-afk is now known as Ursinha [12:46] doko: Yeah, I've tracked down the workaround, it's still awful. [12:46] * infinity really lunches. [12:51] * xnox should do quilt push before copy pasting snippets of code. I did re-write print statements with sys.stdout.write when porting to python3.... [12:52] Usually better to use from __future__ import print_function and then print(). [12:52] sys.stdout.write is pretty clunky most of the time. [12:52] cjwatson: apparmor maintains 2.3+ compat. [12:52] Yeah, if you insist on prehistoric compat then you may need clunky :-) [12:53] Gotta wonder what the point is though. [12:53] I mean, Ubuntu 5.04 had 2.4 ... [12:54] to make it "secure" ? I dunno. [12:54] I doubt it :-) [12:54] Probably nobody's thought about it properly. [12:54] well apparmor is not ubuntu specific? or are we upstream? [12:55] Err, the point is that if we were shipping 2.4 7.5 years ago then you'd think most systems actually capable of running current apparmor would have something a bit newer than 2.3. === cpg is now known as cpg|away [12:55] (OK, you want 2.6 for decent py3 compat, but even that we were shipping 3.5 years ago. [12:55] ) [12:56] Though as it happens we are upstream for apparmor. [12:59] I think part of my point is that it's kind of daft to require Linux >= 2.6.36 and also go through contortions to support an ancient Python. [13:03] =)))) [13:04] maybe nobody touched the python bits in a while... [13:05] so `date --utc --reference=/var/log/installer +%s` will tell me the installation date. Is there anything that will (stably) give me the time of upgrade? The ctime off /etc/lsb-release? === yofel_ is now known as yofel [13:06] ev: hm... something does add "upgraded on..." in apport hooks. I saw that on launchpad bugs. [13:11] ahhh, so it does [13:11] the mtime off /var/log/dist-upgrade/main.log [13:11] cheers xnox [13:12] =) [13:14] ev: for me the modification time is 4th of january, but I am running quantal. I did $ apt-get dist-upgrade, instead of upgrade-manager -d [13:15] so results from me are bogus :-P [13:15] yeah [13:16] yeah, I don't know of a 100% reliable and stable way [13:17] several semi-reliable and semi-stable ways which might produce something reasonable in aggregate :-) [13:20] hm, maybe we chould take the ctime off /etc/lsb-release if it's newer than /var/log/dist-upgrade/main.log? [13:22] /etc/lsb-release will get you any base-files upgrade, perhaps one more recent than the dist-upgrade. [13:23] Depends which way you want to err. [13:23] You could parse /var/log/dpkg.log* for base-files upgrade timestamps *shudder* [13:40] what is responsible for bringing in pkgbinarymangler? It's not part of build-essential, which kind of makes it seem like it shouldn be part of crossbuild-essential, but if I cross-build anything MA-same without it then it's uninstallable [13:40] so it is fairly essential [13:41] IS there any reason why it shouldn't be added to the crossbuild-essential dep-list? [13:43] ev, hi. should we schedule https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-fix-ddebs for usr-r? There are a lot of postponed items and this is still a huge concern for our team. thanks [13:43] arges: yes [13:44] arges: does it need re-discussion or just implementation time? [13:44] cjwatson, both. I think there should be a bit of discussion [13:44] Why? [13:45] Generally we try to avoid rescheduling UDS sessions when we already know what needs to be done but just didn't get to it. [13:45] cjwatson, well we got the extra space I believe on the ddeb server, so do we need to re instrument apport, or can we use the existing code? [13:45] We still ultimately need to replace this bodgy pile of hacks [13:46] yeah, I thought Adam or someone was going to teach the publisher to include ddebs? [13:46] cjwatson, yes. so perhaps there is still some value in discussion. [13:46] arges: I don't see any [13:47] It's been discussed to death [13:47] :-) [13:47] And another UDS session won't make it happen any faster :) [13:47] cjwatson, ok so basically its just time to get those work items done. so those get tracked in that same blueprint [13:47] So that's just "re-target to raring", I think [13:48] ooh it has a name [13:48] which I have now done [13:48] only 4 years till we run out of letters [13:49] (possibly not in an optimal way, I just renamed the spec and left the done items there) [13:49] cjwatson, ok that will be fine. the big thing that (i believe) has happened is that those older ddebs aren't being deleted [13:49] Until we run out of disk again [13:51] I mean, they weren't being deleted for fun, they were being deleted because there was nowhere left to go :-) [13:51] cjwatson, sure. so being proactive about it would be good. if we are close then add more disks [13:53] sorry, but pitti *was* proactive, he notified IS as soon as it started to be close to be a problem [13:53] about two months before he had to start deleting stuff [13:56] cjwatson, ok didn't know that [13:57] Why would anyone do "X-Python3-Version: << 3.3" ? it doesn't make sense.... as there is no version encoded paths with pure-python3 modules. === mcclurmc is now known as mcclurmc_away [14:00] xnox: maybe python3.3 broke something in that module? [14:00] * cjwatson is in the odd position of hoping that a build finishes slower [14:00] (because it'll give me a better migration test case that way ...) [14:01] <_jmp_> cjwatson: good to know, I saw pitti was stellar on it. I will talk w/ IS during UDS as its very important to us as well [14:02] dobey: how would the maintainer know that back in 2012-04-04? =) [14:02] The publisher changes are still the right longer-term fix, but they're a lot of work and they involve UE doing fairly significant Launchpad work, which we have some capacity for but only limited at this point [14:02] So if you can get by with just avoiding running out of disk for a cycle or two more, that would be very helpful [14:02] xnox: maybe they tried it against a local cpython build out of vcs? [14:03] arges, _jmp_: FYI, I got an ack from IS to give it loads more space RSN, and it already got plenty of extra space, so we don't need to kill ddebs anytime soon [14:03] <_jmp_> cjwatson: yeah, they actually told us they will add enough disks to be space-problem-free for a while :) lets see :) [14:03] pitti, : ) [14:03] speaking of which, /me sets up ddebs for raring [14:03] <_jmp_> pitti: awesome! [14:03] xnox: i'm only stating the only viable reason i can think of; not claiming to know why the person actually did it :) [14:03] <_jmp_> pitti :)) [14:03] pitti: Excellent, so hopefully infinity can spend time on the other zillion infrastructure things on his plate :) [14:04] dobey: I understand =) I'm trying to prove the maintainer wrong now. The unit-test passes fine [14:04] =) [14:04] * xnox calls it lies that 3.3 is not supported [14:05] xnox: no VCS logs or anything? [14:06] cjwatson: the python3 support was added with "<< 3.3" without any reasons stated. [14:06] python3-py package that is. === mcclurmc_away is now known as mcclurmc [14:37] doko: $ python2.7-config --includes = -I/usr/include/python2.7 -I/usr/include/python2.7 [14:37] which is funny [14:39] yes, know [14:39] n [14:39] ack =) doesn't hurt anything. === salem_ is now known as _salem [14:58] python3.3 support for public extensions is mostly done for raring [14:58] barry, xnox, ScottK, mvo: thanks for the help === _salem is now known as salem_ === mcclurmc is now known as mcclurmc_away [15:58] mitya57, any update on sphinx? [16:00] doko: the test suite fails with python3.3, I'm slooowly debugging it [16:00] ok === mcclurmc_away is now known as mcclurmc [16:01] doko: if it's urgent, we can just disable the failing tests (but I don't really like that idea) [16:02] as long as sphinx works in raring, that's fine [16:02] I mean, keeping the ftbfs, and using the existing binaries [16:03] slangasek, bdmurray, RAOF, SRU team: is there any plan to work on the queue backlog before UDS? [16:03] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin === morphis|away is now known as morphis [16:05] SpamapS, bug #1067356, come on .... [16:05] Launchpad bug 1067356 in geary (Ubuntu Quantal) "Missing .desktop file" [High,In progress] https://launchpad.net/bugs/1067356 [16:06] SpamapS, needed to file a full other paper work bug for a one liner included with the upload? [16:07] hum [16:07] who rejected my seahorse SRU and why? [16:07] I asked for it [16:07] because I uploaded the new upstream [16:08] http://launchpadlibrarian.net/120749544/seahorse_3.6.2-0ubuntu1_source.changes [16:09] seb128: As the last time we chatted over IRC about this turned rather emotional, I'll decline to respond here. Please take it up with someone else or we can chat about it face to face if you'll be here in CPH next week. [16:11] SpamapS, can you put those back in the queue for other SRU team members to pick if you are not wanting to. [16:11] ? [16:11] Laney, ok, comment on the bug would have been good === salem_ is now known as _salem [16:12] seb128: I don't know how, but I have been told there is a way to unreject. [16:12] you can accept from rejected [16:13] but not put stuff back into unapproved (AFAIK anyway) [16:13] grrr [16:13] so reupload if that's what you want to do :-) [16:13] yeah, doing that [16:14] hopping to get a SRU team reviewer more tolerant for the next review [16:14] that reminds me to reupload glib too [16:14] Laney, what was the issue with this one? [16:14] i rebased the changelog instead of merging it [16:15] SpamapS, I've reuploaded, please don't reject this one, just let somebody who wants to review it do it [16:15] seb128: I more meant that you might want to take up a difference in policy with the others. But again, perhaps we should talk in person. === _salem is now known as salem_ [16:16] SpamapS, there is no writen rule saying that a SRU has to be have a record bug for every changeset in the upload [16:17] SpamapS, or if there is one please point me to it [16:19] seb128: the wiki page implies they do; unless there's a microrelease exception [16:20] dobey, "imply", where? [16:20] https://wiki.ubuntu.com/StableReleaseUpdates#Fixing_several_bugs_in_one_upload [16:21] dobey, that upload is not a kitchen sink one, it has 2 fixes, one being a one liner for a segfault I've no testcase about [16:22] e.g those bugs that never get verified [16:23] seb128: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure .. The first requirement is that one records these fields in a bug report. [16:23] seb128: i'm not trying to argue that you're right or wrong. i'm just saying that my reading of that section (in combination with the main Procedure section above it, and the microrelease section below it) suggests that a bug needs to exist for each fix, and each fix needs to close those bugs in the changelog. [16:24] SpamapS, well, I've those fields, I just included a one liner upstream fix because I though it would improve things and wouldn't be a big deal [16:24] *shrug* [16:24] seb128: that is the last I'll respond about it. as I said, I'd prefer that we discuss in person, or that you approach somebody else on the SRU team about this. [16:25] SpamapS, fair enough [16:25] SpamapS, thanks [16:25] well in any case I've reuploaded, I don't intend to register a new bug and try to find a testcase for that a non reproducible segfault [16:26] so if somebody wants to accept those fixes great, otherwise it will stay broken for users and I will have lost my time on the SRU [16:28] seb128: well, you don't necessarily need to find a test case for extremely hard to reproduce bugs. if the code does the right thing to fix cases like that, it should be fairly obvious what the code is doing, and a simple "This is nigh impossible to force to happen, but the code is correct and obviously fixes this crash." for the [TestCase] in a bug. [16:28] seb128: from the IRC conversation, it seems to me like the issue is more the lack of the bug, than the testcase itself, no? :) === dendrobates is now known as dendro-afk [16:30] dobey, I batched 2 fixes in one paperwork trail, most SRU reviewers are not that picky and let those in [16:31] when fixes are easy ones that can be tested,reviewed easily [16:31] but whatever [16:31] that is more discussion time that the topic is worth, I bring it at UDS with the SRU guys [16:33] well, i don't know if my opinion matters, but i generally agree with having a separate bug for separate fixes. it helps with tracking the changes, in case some regression happens later with the fix; and it provides better information to the users about what is actually getting fixed, when they upgrade and look at the changelog entries. [16:33] oh well :-/ === Quintasan_ is now known as Quintasan === salem_ is now known as _salem === _salem is now known as salem_ === Ursinha-afk is now known as Ursinha [16:52] * xnox is confused why sbuild pyside gives me sbuild-build-depends-pyside-dummy : Depends: libphonon-dev but it is not going to be installed === salem_ is now known as _salem === _salem is now known as salem_ [17:04] xnox: sounds like uninstallable or un-co-installable build deps [17:04] slangasek: I wish it would either tell me, or filter out and use the other alternative build-dep =) [17:06] xnox: well, "it" is apt and apt doesn't give very good diagnostics in this case unless you crank the debugging up :) [17:07] something tells me that building 4.7really4.6 versions strings with libqt4-dev (>= 4:4.7.0) is not going to go down that well. [17:07] meh... off to play volleyball =) [17:13] slangasek: well at least pbuilder-dist is smarter - phonon-backend-null : Conflicts: phonon-backend which is a virtual package. The following actions will resolve these dependencies: and goes off to install phonon instead of phonon-backend-null [17:14] sbuild used to be smarter too, until it switched to using apt as its build-dep resolver :/ [17:14] barry, doko: was there any change in python3.3 that could cause it to think that file name is ""? [17:14] xnox: you might need --resolve-alternatives [17:14] (maybe for some objects that are not really files but python3.2 thought them were) [17:15] I can't find anything related in the release notes [17:16] micahg: thanks, I'll try that..... while sbuild is nice I find pbuilder more out-of-the-box friendly. E.g. my customisation file for sbuild is longer than the one I have for pbuilder-dist. [17:16] arguably pbuilder-dist is a config wrapper..... === ejat- is now known as ejat === gruebert is now known as grueblur === salem_ is now known as _salem === _salem is now known as salem_ [17:32] doko: I've spent three hours on that issue, and I give up, at least for today :( [17:33]