=== imbrando1 is now known as imbrandon [00:49] barry, cjwatson: how is the update-manager build supposed to work with python3-distutils-extra + debhelper? Attempting a simple build fails if python is present at all, because debhelper picks /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm for the buildsystem which invokes python, not python3 [00:50] and this doesn't seem to be anything that's changed recently in any of the related packages... [00:53] oh, I see; the package has overrides that bypass this for dh_auto_{build,install} but not _clean, heh [00:53] * slangasek passes -nc :P [00:55] hmm, still fails, because it calls dh_auto_install rather than completely bypassing it [00:55] stgraber: ^^ looks like you did much of the python3 changes initially? any thoughts here on what I'm missing? [00:57] perhaps I'll just switch to pybuild [00:57] slangasek: hmm, I last touched it during the python3 sprint but it's an mvo package, so you need to make sure to run the script that's in the branch (can't remember the name, sorry) and then use bzr bd to trigger the build [00:57] I don't remember having to do anything else back then [00:57] well, this branch no longer has a pre-build script [00:58] ah, ok, I guess that's a good thing ;) [00:58] that went away back in June when mterry split the branches [00:58] so I think I can just condense debian/rules down to "dh $@ --with=python3 --buildsystem=pybuild" now... but I really have no idea why this stopped working [01:00] slangasek: i haven't tried building it in a while, but i hated that pre-build script. :/ +1 for --buildsystem=pybuild, and i have no idea why it's stopped working recently either [01:01] Me neither; I thought I was fairly careful to get all the overrides right [01:02] well, launchpad was ok with your overrides at the time you uploaded :) [01:02] but it definitely fails for me now === _salem is now known as salem_ [01:05] slangasek: local sbuild from trunk branch is happy [01:05] hmmm [01:05] furthermore, building with pybuild gives a failure because it can't find debian/tmp/usr/share/locale... but I don't see anything that installs that [01:06] slangasek: you're seeing buildd failures? [01:07] barry: no, local failures; not a pristine sbuild, I'm trying to bzr bd in a chroot [01:07] (so python is installed, since bzr needs python) [01:07] slangasek: i'm not sure i'd call my local raring chroot "pristine" ;) [01:07] but it's *fairly* sparse === Ursinha is now known as Ursinha-afk [01:10] right, so if I build in an env with no /usr/bin/python, it /happens/ to build successfully [01:11] slangasek: wow. and indeed, my chroot does not have /u/b/py === doko_ is now known as doko === wedgwood_away is now known as wedgwood === salem_ is now known as _salem [04:49] Good morning === wedgwood is now known as wedgwood_away === work_alkisg is now known as alkisg [06:47] good morning [06:49] Good morning [07:11] I'm trying to solve a bug in LTSP that might even result in data loss... could someone point me on how to write a cleanup handler for an X application (called LDM) that runs even if Xorg crashes (in which case I think Xorg kills all its childs) ? [07:12] It doesn't look like an atexit() handler would do, would I need a TERM signal handler instead? [08:00] cjwatson: re unified experience - that was my impression too. I'm just curious re the underlying tech that would achieve that. === amitk is now known as amitk-afk === smb` is now known as smb === henrix_ is now known as henrix [09:38] * Laney prods SpamapS with https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1074606/comments/19 [09:38] Ubuntu bug 1074606 in gparted (Ubuntu Quantal) "gparted identifying incorrect raid arrays" [High,In progress] [09:39] It's not an accident - this is new-ish behaviour; it's correct to upload with just the bare release as the target === amitk_ is now known as amitk [10:36] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion 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: pitti [10:39] diwic: Good catch. at one point I remember thinking that all used vlc, but I didn't really make the connection. [10:41] TheMuso, I'm uploading a fix for those two (1129990 and 1127872) within an hour [10:41] Ok great. [10:41] Thanks. [10:41] TheMuso, but while troubleshooting I discovered that autospawn seems to have stopped working, can you confirm that? [10:42] TheMuso, I also discovered that PA does not work at all on guest accounts due to just filed bug 1131139 [10:42] bug 1131139 in lightdm (Ubuntu) "Guest cannot create /run/user// subdirectory" [Undecided,New] https://launchpad.net/bugs/1131139 [10:42] diwic: Afaik autospawning works fine, as thats how pulse is brought up, at lesat I think so... [10:43] But I'll try and manually confirm in a bit on a text console when I'm logged out. [10:44] TheMuso, just execute "pulseaudio -k", then try to use pulse and see if it autostarts [10:45] Ok. [10:45] Yes. [10:45] It does. [10:46] But I am using the completely new pulse config here, I have nothing to do with pulse in my home dir. [10:46] TheMuso, ok, good. Then I probably screwed up something here. [10:47] I/c [10:49] ok, 0ubuntu3 uploaded [10:50] seb128: WDYT about bug 1130956? [10:50] bug 1130956 in gnome-system-monitor (Ubuntu) "Update gnome-system-monitor to 3.7.90" [Wishlist,New] https://launchpad.net/bugs/1130956 [10:51] seb128: specifically, moving leaf packages to 3.8 if they work with our 3.6 base [10:51] I/c [10:52] pitti, I'm fine updating as long as the people doing the update keep up with the bugs due to the unstable version they upload [10:52] pitti, g-s-m is fine, I would like to avoid e.g nautilus until 3.8 stable [10:52] seb128: yeah, absolutely (that bug mentions this also) [10:53] pitti, wfm then ;-) [10:57] seb128: ok, thanks; it's API/ABI freeze now and all that, so 3.8 should work as well [10:58] cool [11:21] seb128, pitti, hi :) [11:21] ricotz, hey [11:21] oh , 3.8 apps in raring [11:24] seb128, btw, gtk 2.24.16 is probably a candidate for raring? [11:25] ricotz, yeah, it's in the desktop team ppa, I was planning to land that with attente's unity menu work [11:25] ah, i see [11:25] good [11:26] hye ricotz, wie gehts? [11:28] pitti, hey, danke gut! [11:28] und dir? [11:29] pitti, i was tempted to ask if you could give those build a little bump https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+builds [11:29] pitti, btw is the /media vs /run/media patch in udisk2 still wanted? [11:32] ricotz: yes, slangasek was rather adamant on keeping /media/ [11:32] ricotz: it could soon be superseded by a better solution, though; some days ago there was some discussion on the ML about this topic, but I don't think that landed already [11:33] ricotz: oh, you packaged current udisks? that was on my TODO list in a week or two, I'll look at your pacakges then [11:35] dholbach: are you already sponsoring https://code.launchpad.net/~logan/ubuntu/raring/cpptest/1.1.2-0ubuntu1/+merge/149667 (as you committed recently), or want me to? [11:35] pitti, it is there for some time, it was already needed for an ealier gnome-dist-util version [11:37] pitti, due some refactoring a huge part of the media-patch gone obsolete (i could be wrong here though) [11:38] ricotz: I guess it's not that important for the gnome 3 ppa [11:39] pitti, it working fine afaics, the actual run/media>media change is still present and working [11:40] ricotz: ah, I guess David may have refactored that because he wanted to support a new udev property UDISKS_USE_MEDIA or so [11:40] ricotz: that's what I meant with "going to become much eaiser" [11:41] pitti, alright === alkisg is now known as work_alkisg [11:52] pitti, I sponsored it already [11:52] dholbach: ah, you didn't push the merge then, I guess; I'll mark it as merged [11:53] thanks pitti === dholbach_ is now known as dholbach === _salem is now known as salem_ [12:38] hey, I have a patch for pastebinit to work in python3 venv, the patch fixes the shebang line from "/usr/bin/env python" to "/usr/bin/python". I made the patch to current raring package using quilt, how can I contribute that and get it applied to raring [12:40] I also added a debian/changelog entry and tested the package [12:44] zyga: from looking at changelogs i would talk to stgraber for pointers [12:45] https://launchpad.net/ubuntu/+source/pastebinit/+changelog [12:45] stgraber: ping [12:45] I made a debdiff [12:46] stgraber: I'm not exactly sure what to do next, the debdiff is here http://paste.ubuntu.com/1698728/ [12:53] zyga: the official answer is most likely to read and follow https://wiki.ubuntu.com/SponsorshipProcess [12:56] asac: sorry, having read that page I don't know what to do, should I start with the lp:ubuntu/... package and re-do the change so that I can submit a merge request? [12:58] The traditional process involves: [12:58] 1. File an Ubuntu bug in Launchpad [12:58] 2. Attach your work (note: debdiff is one option there) [12:58] 3. Subscribe ubuntu-sponsors [13:00] from that point on the process should automatically unfold through discussion in bug. if nothing happens for a while, a gentle ping of last uploader asking for help is appropriate [13:01] asac: ah, thanks [13:03] zyga: thats copied out of the wiki page btw [13:17] zyga: and that's best way to do such stuff [13:17] zyga: not everyone tracks irc whole day [13:34] zyga, looks like pitti is the patch pilot today; if you get stuck, or when you think you're ready for review, you can (should) ping him [13:35] (see topic) [13:36] zyga: sure, I can upload that [13:36] zyga: but please forward this upstream, too [13:39] pitti: this is not an upstream bug [13:39] pitti: this is just the packaging, normally debhelper patches that but here it's not detecting this as a python package [13:40] pitti: I'll open a merge request after the meeting now [13:41] pitti: I suspect there's a ton of identical issues in other packages [13:42] hrw, bryceh: yeah, thanks, I was looking for input on how to contribute that [13:43] right, in general packaged python scripts should use /usr/bin/python..., not env [13:43] right [13:43] Hello. Can somebody try to tell me what was wrong in https://launchpadlibrarian.net/131963515/buildlog_ubuntu-raring-i386.calligra_1%3A2.6.1-0ubuntu5_FAILEDTOBUILD.txt.gz ? [13:43] zyga: no MP necessary, the patch is fine [13:44] zyga: I'm worried about adding the patch, not the form in which to sponsor it [13:44] Only one make[1]: *** [all] Error doesn't help... [13:44] zyga: it's this kind of annoying patches which we have to carry forever unless we agree with upstream what the shebang should be like [13:44] and it's not really a blocker for running with py3, you can just run python3 pastebinit, after all [13:44] pitti: but the shebang _is_ right upstream, it's a bug in debhelper not fixing all scripts this way [13:45] pitti: it's not a problem with python3, only with virtualenv -p python3 [13:45] zyga: if debhelper changes the hashbang to use env, how does the patch help then? [13:45] pitti: where it breaks because python == python3 [13:45] eh? [13:45] python == python3 is really wrong [13:45] pitti: it does for python packages, it does not look at all scripts to check [13:45] smartboyhw, /usr/include/qt4/QtWebKit/qwebpage.h:1:55: fatal error: ../../../../Source/WebKit/qt/Api/qwebpage.h: No such file or directory [13:45] that's what Arch is doing, and it's just plain broken [13:45] pitti: that's virtualenv [13:46] zyga: we better fix that then IMHO [13:46] pitti: virtualenv -p python3 /tmp/omg && . /tmp/omg/bin/activate [13:46] python != python3 [13:46] pitti: that's specified upstream behavior, python3 does that too [13:46] no, it's not [13:46] pitti: the real problem is in packaging I'm afraid [13:46] unfortunately the PEP does not explicitly forbid it [13:46] but the only ones guaranteed are "python2" and "python3" [13:47] if something calls "python" and gets python3, we cannot blame that something [13:48] pitti: still, it's broken in terms of our own policy [13:48] pitti: I'm glad to work on dh to actually fix that on arbitrary executable scripts [13:50] pitti: that would make this patch obsolete [13:50] pitti: note that many python developers use virtualenv (especially non-system developers) and this breaks a very popular program in practice [13:50] or fixing virtualenv [13:51] pitti: on the upside python3 is not really common yet [13:51] pitti: I can check if that's a vaiable fix but I suspect that'd be a patch for virtualenv that we carry and a difference from all other systems, I'm not sure we want that either [13:51] pitti: though I agree that virtualenv behavior is annoying [13:51] pitti: I'll ask virtualenv upstream [13:51] no, that's certainly something to fix in virtualenv upstream [13:53] pitti: would you be happy with dh automatically patching all 'env python' to 'python' scripts? [13:53] but even if we have to patch it there, it's IMHO better to patch in one place than in lots of packages [13:54] zyga: if that's the right thing to do, not 100% sure; barry, ScottK, any opinion about changing #!/usr/bin/env python hashbangs automatically? [13:55] (me talks to virtualenv commiter he knows) [13:56] pitti: It kind of depends. For "normal" python packages that makes sense. For things developers use, they may want to override that somehow. I think barry is the best person to ask. [13:57] I guess the root of all evil is http://www.python.org/dev/peps/pep-0394/ [13:57] "python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions" [13:57] that's quite frankly just plain stupid [13:57] pitti: note [13:57] as some distros like arch, and maybe the virtualenv authors will refer to that [13:57] pitti: that's python3.3 behavior [13:58] as that essentially invalidates "python" to be anything meaningful [13:58] pitti: run pyvenv-3.3 [13:58] pitti: well, in a way it's sensible outside of unix+packages world [13:58] so in theory everything needs to say "python2" or "python3" now [13:58] pitti: you install "that python" and "python.exe" is "that python" [13:58] unless you carefully port your py2 programs to work on both py2 and py3 [13:58] pitti: but it's already larger than virtualenv as python3.3 with standardized virtualenvs is what we have in the future [13:58] but it breaks pretty much every non-ported python2 program out there [13:59] pitti: note that shebang was not something that was in python scope until python3.3 [13:59] pitti: not python2 or python3, but system packages must use an absolute path for the interpreter [13:59] zyga: yeah, that PEP is quite recent, 2011 [13:59] yes [13:59] pitti: note that it also fixes shebangs on windows [13:59] zyga: no, that's not the problem; "/usr/bin/env python" should still get you python 2.x [14:00] (it might not be policy compliant for other reasons, that's my question to barry) [14:00] pitti: in theory yes but look that all windows releases have 'python.exe' [14:00] pitti: so no version-encoded executabales [14:00] well, same problem [14:00] pitti: 3.3 fixes that a bit [14:01] pitti: with a new program that interpretes shebangs for python [14:01] pitti: to work for 2.* - 3.* [14:01] zyga: it looks at the source code and tries to figure out whether it's for py2 or 3? [14:01] pitti: sadly it's something we've been doing but that's not "the python way", so the solution might be painful [14:01] pitti: no, it reads the shebang [14:01] pitti: and the shebang is special [14:01] pitti: let me show you the spec [14:01] but that's the one that they just invalidated as a reliable source of information [14:02] http://www.python.org/dev/peps/pep-0397/ [14:02] the root cause is that py3 breaks compat with py2 in many ways, i. e. it is really a new language [14:02] so you can't call it like the old one [14:02] pitti: scroll down to "Shebang line parsing" [14:02] pitti: that's true [14:02] pitti: I think we really need barry to tell us his opinion [14:03] zyga: well, that shebang line parsing is ceratinly helpful [14:03] pitti: at this time, we'd have to patch virtualenv and python3.3+ to fix this [14:03] but it seems orthogonal to determining for which python version a program is [14:03] pitti: actually [14:03] pitti: could we do something as crazy as binfmt support to use 3.3 launcher on all python files? [14:03] wouldn't that even aggravate the problem? [14:04] pitti: it does support python2 versions [14:04] we can't run any py2 program through py3 [14:04] pitti: that launcher just re-exes the right version of pytohn [14:04] how does it determine the right version? [14:04] if the hashbang says "python", then you really could just guess [14:04] pitti: according to the spec [14:04] (in the world of PEP-394) [14:04] pitti: I don't know off the top of my head [14:05] in the actual world, python has meant 2.x for years [14:05] (which again is why PEP-394 is broken) [14:06] pitti: yeah but we need to deal with 'bug that became a feature' unless we can fix it upstream somehow [14:07] pitti: it says that /usr/bin/python2 automatically locates python2.* installation [14:07] pitti: it's pretty long, I'm in a meeting, let me read that in the background [14:07] pitti: ping me if barry sends a word [14:09] zyga: yes, no problem with "python2" and "python3" [14:23] pitti: think any more about having clusters able to use the same port? :) [14:24] Snow-Man: not recently [14:24] it's frustrating to not be able to use the cluster tools. :/ [14:26] pitti,zyga: IIRC I already switched to /usr/bin/python3 in current upstream trunk [14:27] Apparently, python is somewhat broken in Raring [14:27] os.sync() is broken [14:28] indeed [14:28] Can anyone review https://code.launchpad.net/~jderose/ubuntu/raring/python3.3/fix-1131183/+merge/149838 [14:29] Jason has submitted a fix [14:29] pitti,zyga: next release of pastebinit will be python3 only with /usr/bin/python3 as shebang. I don't really have an ETA though as I'm not spending much time on it usually [14:29] stgraber: cool, thanks [14:30] vibhav: thanks [14:30] pitti: thank Jason DeRose :) === francisco is now known as Guest99270 [14:44] dholbach: so docutils support for named links has landed! ... and I'm going to backport it to raring [14:45] mitya57, great [14:45] (though it's a bit ugly `like this `_) [14:45] ah, and I also wanted to do a sphinx sru [14:45] mitya57, ubuntu-packaging-guide ftbfs right now - did you see the build log? [14:45] dholbach: I've fixed it yesterday [14:46] h no [14:46] great [14:46] :) [14:47] I think we should upload 1.3.1 before the feature freeze [14:47] (after I finish the python 3 port) :-) === wedgwood_away is now known as wedgwood [15:13] pitti, can you check that your sponsoring for #1131183 works on the buildds? [15:14] doko: sure; I built it locally and confirmed that both os.sync and fsync work [15:14] pitti, local builds were not the issue [15:14] I'll do it again with the packages from the buildds [15:15] thanks === Ursinha-afk is now known as Ursinha [15:23] what was the link for the udd branch import status/log/whatever? [15:24] package-import.u.c [15:30] ah, thanks Laney [15:30] oh [15:30] why is it so backed up? [15:31] there's 845 outstanding jobs :-/ [15:31] one of which i am doing a new release of [15:40] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion 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: [15:47] doko: amd64 has built, the buildd binaries are fine [16:05] slangasek: howdy!! Just wanted to let you know I have uploaded python-django (ubuntu1.6) and python-tx-tftp as part of the MAAS SRU! === zz_jackyalcine is now known as jackyalcine [17:02] jamesh: hiya! I was wondering if you had a chance to look at https://code.launchpad.net/~kirkland/upstart/no-scold/+merge/148816 yet? [17:03] slangasek: howdy! I was wondering if you had a chance to look at https://code.launchpad.net/~kirkland/pam/sbin-update-motd/+merge/148559 yet? [17:03] kirkland: You probably meant jodh, not jamesh. [17:04] infinity: ah! thanks! [17:04] infinity: does he generally hang out here? [17:04] kirkland: Generally, though he seems to adhere rather strictly to a concept of work hours. :) [17:05] infinity: lucky dog [17:05] infinity: thanks, I'll try to grab him earlier tomorrow [17:05] slangasek: Did you and Colin come up with anything when unwinding the update-manager partial last night? [17:05] infinity: perhaps I'm catching slangasek on the right side of the sun, though :-) [17:06] slangasek: I mean, it's correct that u-m doesn't generally want to remove packages, do we need to be doing mid-cycle quirking to allow specific bits like this to happen? [17:07] The problem with quirking is that we only know the quirk is needed post facto, so we'd need to upgrade update-manager to apply the quick [17:07] *quirk [17:07] (Besides, it sounds like a lot of messing around rather than honouring the metadata) [17:07] cjwatson: Oh, fair point. [17:07] I was starting to attempt to write a test case for this [17:08] cjwatson: Well, be default, it's meant to be as conservative as "apt-get upgrade", as in, it'll add packages, but never remove. [17:08] s/be/by/ [17:08] cjwatson: I'm not sure how far we can relax that before we accidentally let it remove half of -desktop on a bad resolver run. === mitya57_ is now known as mitya57 [17:09] I think mvo's idea of "permit removal as long as there's a direct c/p/r" would be ok ... [17:09] cjwatson: Probably, yeah. Any fallout from that will be obvious packaging bugs that should be fixed anyway. [17:10] at least that way if there were a chain of packages involved then (worst case) you could work around it by c/p/ring them all [17:10] cjwatson: Though, if such fanciness is being attempted, that almost belongs in the apt resolver itself, so upgrade (and other libapt consumers) can get a similar behaviour. [17:11] I dunno, I sort of like the strict behaviour of upgrade - it's at least simpl [17:11] e [17:11] It is that. [17:11] And this is something that's being explicitly forbidden by u-m [17:12] It does depcache.upgrade(True) and checks depcache.del_count by hand [17:12] Well, yes, I realise u-m is a bit different under the hood. But even if it was just forking "apt-get upgrade", the result would be the same in this case. [17:12] So it doesn't seem particularly wrong to relax it in u-m too [17:12] It would, but I don't agree that it's a good model for it to be emulating apt-get upgrade [17:12] Because I think apt-get upgrade is generally wrong [17:12] Heh. [17:12] Which goes back to "maybe upgrade should be less wrong". [17:13] For instance if you're in the habit of using apt-get upgrade all the time then you'll lose out on new Recommends [17:13] But making it less wrong while still unlikely to break computers is hard. [17:13] Which is not how the system is meant to work [17:13] (And, more to the point, you have no way to notice that you're losing out on new Recommends) [17:13] That said, if we're worried about breaking computers, u-m is where we need to be most worried. So if we get the logic right there, surely having all apt consumers do the same thing is fine. [17:14] Honestly, any apt consumer that's driving depcache in an upgrade-like way rather than a dist-upgrade-like way is already wrong [17:14] The right fix is to have them drive it in a dist-upgrade-like way [17:14] And then to check delete counts and guess if it's okay? [17:14] And forget about upgrade as hard as possible [17:14] Or whitelist particular packages [17:14] Where "guess" means "duplicate the same PCR checking"? [17:14] (And TBH crazy delete counts are much less of a problem nowadays) [17:15] Well, as you point out, whitelisting only works after the fact, which is chicken and eggy. [17:15] No, I mean whitelist important things like -desktop [17:15] Oh, right. [17:15] Which is pretty much the dist-upgrader approach. [17:15] Allow violence, repair. [17:16] I just don't think that starting with apt-get upgrade is the right way to get a safe and correct upgrade path, so I'm not really so interested in fixing it [17:16] Starting with dist-upgrade or similar makes a lot more sense to me [17:16] Yeah, that's fair. I haven't actually *run* apt-get upgrade in years (a decade, maybe?) for reasons stated. [17:17] Then again, I don't run update-manager for similar reasons, so perhaps this highlights your view well. [17:21] Right now, u-m is half-way in between. It allows installing new packages but refuses to remove. === henrix is now known as henrix_ [17:22] (AFAIK anyway.) === henrix_ is now known as henrix [17:49] mlankhorst: I'm confused by bug #1130974, I cannot reproduce this build failure here [17:50] bug 1130974 in xserver-xorg-video-nouveau (Ubuntu Precise) "mesa_8.0.4-0ubuntu0.3 fails to build on 12.04.2" [Undecided,Fix committed] https://launchpad.net/bugs/1130974 [17:50] slangasek: needs libdrm >= 2.4.34 to fail [17:50] so if you don't have updates pocket enabled, it will just work [17:51] mlankhorst: hmm.... ok, I do have -updates enabled but apparently didn't apt-get update [17:51] :-) [17:57] * mlankhorst has enough sru's to verify now! [17:59] roaksoax: hi - how is the new python-django upload different from the previous one? I still had an action item from the last TB meeting to re-review the previous upload [17:59] kirkland: haven't looked at it yet, sorry... it's in the queue though [17:59] slangasek: no worries, thanks [17:59] infinity, cjwatson: so is there a consensus that we should go ahead with having u-m handle the c/p/r specially? [18:00] slangasek: the new upload drops the GenericIpAddressField [18:00] slangasek: which is now implemented in MAAS [18:00] roaksoax: ok. if that's your preference, I'll review that one instead - I guess it should be a quicker review [18:01] slangasek: indeed!! :) [18:02] slangasek: I think that's what I picked up. I started working on it but have been a bit derailed into trying to make u-m's test suite actually pass for me reliably so that I have a solid base to work on [18:02] ok :) [18:03] slangasek: That seems less scary than just letting it tear things out willy-nilly, yes. [18:03] (I have some kind of test isolation bug that's breaking my brain at the moment) [18:03] me, I'm still stuck trying to get it to build reliably without adding a Build-Conflicts with python [18:03] Side note: Our UI needs more opportunity to use present users with options involving the word "willy-nilly". [18:03] pybuild is nearly there, but for some reason the install_data target isn't installing the .mo files [18:03] Not to mention SERIOUSLY CAN WE STOP HAVING NETWORK-DEPENDENT TEST SUITES [18:03] s/use // [18:04] slangasek: mterry posted a dh9 branch - don't suppose that makes a difference? [18:04] for update-manager? yeah, it prevents the shebang from being stripped down to python2 by dh_pysupport [18:05] oh, is that what's been happening? [18:05] yeah, that might be a quicker fix [18:05] cjwatson, the test suite is unreliable for you? [18:06] cjwatson, hmm, I see the pep8 test fails... and the port-listening test, which I agree is a pain [18:06] mterry: yeah, got a failure in test_update_list which is order-of-tests-dependent [18:06] mterry: I fixed the pep8 tests, update [18:06] no port-listening failure here [18:07] cjwatson, probably because you have installed an ssh server locally [18:07] heh, but of course I have a local openssh server [18:07] cjwatson, if port 22 isn't open, it fails [18:07] stupid test [18:07] cjwatson, which is a stupid test :) [18:07] Might have a go at that later [18:08] Trying to narrow down the one I'm actually seeing first === kentb is now known as kentb-afk [18:11] For me this fails reliably in test_update_list.GroupingTestCase.test_app if I have previously run test_cache.TestCache and test_meta_release_core.TestMetaReleaseCore in the same nosetests3 run, but not if I've run only one of those or neither. [18:13] And if you remove test_meta_release_core.TestMetaReleaseCore.testnewdist then test_meta_release_core.TestMetaReleaseCore.test_url_downloadable falls over in a heap. Hateful thing. [18:17] Which I think is actually a genuine failure masked somehow ... [18:26] hi guys - now where ubuntu-phone is flooded ... do you know of a channel for ubuntu phone core app devs? === yofel_ is now known as yofel [18:27] cjwatson: ok, the dh9 still doesn't make a difference... that only avoids dh_pysupport mangling the files post-install, it doesn't prevent the build system from invoking setup.py wrong === Quintasan_ is now known as Quintasan [18:30] larsgk: #ubuntu-arm =) [18:30] xnox: cool - thanks === deryck is now known as deryck[lunch] [19:03] sbeattie: bug 982619 could use a test case [19:03] bug 982619 in apparmor (Ubuntu Precise) "aa-logprof wrongly transforms PUx to UPx" [High,In progress] https://launchpad.net/bugs/982619 [19:03] bdmurray: thanks [19:04] sbeattie: oh and bug 1091642 [19:04] bug 1091642 in apparmor (Ubuntu Precise) "apparmor parser fails due to matchflags not being reset" [Undecided,Triaged] https://launchpad.net/bugs/1091642 [19:04] sbeattie: let me know when they do and I'll rereview / approve [19:05] the latter has a testcase incorporated in the source as part of the patch [19:06] but yeah, I can tease that out and include it in the bug description. === AbsintheSyringe2 is now known as AbsintheSyringe === kentb-afk is now known as kentb [19:24] shadeslayer: think you could get someone to verify the transmission package you have in quantal-proposed? I'm waiting on it to prepare a transmission security update... [19:33] transmission from proposed still works fine, let me quickly install qt to see if the bug is fixed [19:34] ok how do I use the magnet link? [19:34] (and what is a magnet link?) [19:34] pasting it in chromium just gets to me to a google index ._. === henrix is now known as henrix_ [19:39] jtaylor: paste it into your torrent client. on rtorrent, backspace ... [19:39] sarnold: in the bug testcase "* Try to open same magnet link using chromium," [19:39] jtaylor: ah :D [19:41] it works from firefox though, is that enough? === dpm is now known as dpm-afk === deryck[lunch] is now known as deryck [20:04] Can I upload proposed SRU's with just "precise" in the changelog file or do I still have to manually change that to precise-proposed? [20:10] * jtaylor always adds -proposed [20:10] I think the automatic proposed is just raring, but I could be wrong [20:12] YokoZar: just "precise" will work fine [20:12] jtaylor: the rewrite works for all series [20:12] nice [20:12] YokoZar: yes, you can. [20:14] https://wiki.ubuntu.com/StableReleaseUpdates should be updated then [20:14] it still says upload to -proposed [20:18] * ScottK always writes -proposed in debian/changelog. [20:18] (for SRUs) [20:18] jtaylor: It's automatic everywhere. === baba is now known as unix [20:49] hallyn, maybe I need to upgrade to raring because I'm not finding armhf lxc containers in quantal even remotely stable... even when I get a container that's bootable and capable of being logged into, I get hangs :( [20:49] armhf-on-x86, to be more specific [20:51] timrc: like i say there will still be issues on raring, but i can actually do real work in an armhf container in raring [20:51] just dont' run java [20:51] it segfaults - i need to check actually whether physical arm host maybe does the same thing [20:52] hallyn, keyboard is still responsive in the lxc console (I can ctrl-z, for example) [20:53] hallyn, anywho, I'll give it a whirl in raring :) === salem_ is now known as _salem [21:08] jtaylor: interesting, from what I tested firefox didn't handle magnet links but chromium did :P [22:15] could not find lxc in 12.10 for ppc [22:16] E: Unable to locate package lxc [22:17] https://launchpad.net/ubuntu/quantal/powerpc/lxc does show it [22:22]