=== imbrando1 is now known as imbrandon
slangasekbarry, 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 python300:49
slangasekand this doesn't seem to be anything that's changed recently in any of the related packages...00:50
slangasekoh, I see; the package has overrides that bypass this for dh_auto_{build,install} but not _clean, heh00:53
* slangasek passes -nc :P00:53
slangasekhmm, still fails, because it calls dh_auto_install rather than completely bypassing it00:55
slangasekstgraber: ^^ looks like you did much of the python3 changes initially?  any thoughts here on what I'm missing?00:55
slangasekperhaps I'll just switch to pybuild00:57
stgraberslangasek: 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 build00:57
stgraberI don't remember having to do anything else back then00:57
slangasekwell, this branch no longer has a pre-build script00:57
stgraberah, ok, I guess that's a good thing ;)00:58
slangasekthat went away back in June when mterry split the branches00:58
slangasekso 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 working00:58
barryslangasek: 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 either01:00
cjwatsonMe neither; I thought I was fairly careful to get all the overrides right01:01
slangasekwell, launchpad was ok with your overrides at the time you uploaded :)01:02
slangasekbut it definitely fails for me now01:02
=== _salem is now known as salem_
barryslangasek: local sbuild from trunk branch is happy01:05
slangasekfurthermore, building with pybuild gives a failure because it can't find debian/tmp/usr/share/locale... but I don't see anything that installs that01:05
barryslangasek: you're seeing buildd failures?01:06
slangasekbarry: no, local failures; not a pristine sbuild, I'm trying to bzr bd in a chroot01:07
slangasek(so python is installed, since bzr needs python)01:07
barryslangasek: i'm not sure i'd call my local raring chroot "pristine" ;)01:07
barrybut it's *fairly* sparse01:07
=== Ursinha is now known as Ursinha-afk
slangasekright, so if I build in an env with no /usr/bin/python, it /happens/ to build successfully01:10
barryslangasek: wow.  and indeed, my chroot does not have /u/b/py01:11
=== doko_ is now known as doko
=== wedgwood_away is now known as wedgwood
=== salem_ is now known as _salem
pittiGood morning04:49
=== wedgwood is now known as wedgwood_away
=== work_alkisg is now known as alkisg
dholbachgood morning06:47
alkisgGood morning06:49
alkisgI'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:11
alkisgIt doesn't look like an atexit() handler would do, would I need a TERM signal handler instead?07:12
kieppie1cjwatson: re unified experience - that was my impression too. I'm just curious re the underlying tech that would achieve that.08:00
=== amitk is now known as amitk-afk
=== smb` is now known as smb
=== henrix_ is now known as henrix
* Laney prods SpamapS with https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1074606/comments/1909:38
ubottuUbuntu bug 1074606 in gparted (Ubuntu Quantal) "gparted identifying incorrect raid arrays" [High,In progress]09:38
LaneyIt's not an accident - this is new-ish behaviour; it's correct to upload with just the bare release as the target09:39
=== amitk_ is now known as amitk
pitti@pilot in10:36
=== 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
TheMusodiwic: Good catch. at one point I remember thinking that all used vlc, but I didn't really make the connection.10:39
diwicTheMuso, I'm uploading a fix for those two (1129990 and 1127872) within an hour10:41
TheMusoOk great.10:41
diwicTheMuso, but while troubleshooting I discovered that autospawn seems to have stopped working, can you confirm that?10:41
diwicTheMuso, I also discovered that PA does not work at all on guest accounts due to just filed bug 113113910:42
ubottubug 1131139 in lightdm (Ubuntu) "Guest cannot create /run/user/<name>/ subdirectory" [Undecided,New] https://launchpad.net/bugs/113113910:42
TheMusodiwic: Afaik autospawning works fine, as thats how pulse is brought up, at lesat I think so...10:42
TheMusoBut I'll try and manually confirm in a bit on a text console when I'm logged out.10:43
diwicTheMuso, just execute "pulseaudio -k", then try to use pulse and see if it autostarts10:44
TheMusoIt does.10:45
TheMusoBut I am using the completely new pulse config here, I have nothing to do with pulse in my home dir.10:46
diwicTheMuso, ok, good. Then I probably screwed up something here.10:46
diwicok, 0ubuntu3 uploaded10:49
pittiseb128: WDYT about bug 1130956?10:50
ubottubug 1130956 in gnome-system-monitor (Ubuntu) "Update gnome-system-monitor to 3.7.90" [Wishlist,New] https://launchpad.net/bugs/113095610:50
pittiseb128: specifically, moving leaf packages to 3.8 if they work with our 3.6 base10:51
seb128pitti, I'm fine updating as long as the people doing the update keep up with the bugs due to the unstable version they upload10:52
seb128pitti, g-s-m is fine, I would like to avoid e.g nautilus until 3.8 stable10:52
pittiseb128: yeah, absolutely (that bug mentions this also)10:52
seb128pitti, wfm then ;-)10:53
pittiseb128: ok, thanks; it's API/ABI freeze now and all that, so 3.8 should work as well10:57
ricotzseb128, pitti, hi :)11:21
seb128ricotz, hey11:21
ricotzoh , 3.8 apps in raring11:21
ricotzseb128, btw, gtk 2.24.16 is probably a candidate for raring?11:24
seb128ricotz, yeah, it's in the desktop team ppa, I was planning to land that with attente's unity menu work11:25
ricotzah, i see11:25
pittihye ricotz, wie gehts?11:26
ricotzpitti, hey, danke gut!11:28
ricotzund dir?11:28
ricotzpitti, i was tempted to ask if you could give those build a little bump https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+builds11:29
ricotzpitti, btw is the /media vs /run/media patch in udisk2 still wanted?11:29
pittiricotz: yes, slangasek was rather adamant on keeping /media/11:32
pittiricotz: 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 already11:32
pittiricotz: oh, you packaged current udisks? that was on my TODO list in a week or two, I'll look at your pacakges then11:33
pittidholbach: 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
ricotzpitti, it is there for some time, it was already needed for an ealier gnome-dist-util version11:35
ricotzpitti, due some refactoring a huge part of the media-patch gone obsolete (i could be wrong here though)11:37
pittiricotz: I guess it's not that important for the gnome 3 ppa11:38
ricotzpitti, it working fine afaics, the actual run/media>media change is still present and working11:39
pittiricotz: ah, I guess David may have refactored that because he wanted to support a new udev property UDISKS_USE_MEDIA or so11:40
pittiricotz: that's what I meant with "going to become much eaiser"11:40
ricotzpitti, alright11:41
=== alkisg is now known as work_alkisg
dholbachpitti, I sponsored it already11:52
pittidholbach: ah, you didn't push the merge then, I guess; I'll mark it as merged11:52
dholbachthanks pitti11:53
=== dholbach_ is now known as dholbach
=== _salem is now known as salem_
zygahey, 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 raring12:38
zygaI also added a debian/changelog entry and tested the package12:40
asaczyga: from looking at changelogs i would talk to stgraber for pointers12:44
zygastgraber: ping12:45
zygaI made a debdiff12:45
zygastgraber: I'm not exactly sure what to do next, the debdiff is here http://paste.ubuntu.com/1698728/12:46
asaczyga: the official answer is most likely to read and follow https://wiki.ubuntu.com/SponsorshipProcess12:53
zygaasac: 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:56
asacThe traditional process involves:12:58
asac 1. File an Ubuntu bug in Launchpad12:58
asac 2. Attach your work  (note: debdiff is one option there)12:58
asac 3. Subscribe ubuntu-sponsors12:58
asacfrom 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 appropriate13:00
zygaasac: ah, thanks13:01
asaczyga: thats copied out of the wiki page btw13:03
hrwzyga: and that's best way to do such stuff13:17
hrwzyga: not everyone tracks irc whole day13:17
brycehzyga, 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 him13:34
bryceh(see topic)13:35
pittizyga: sure, I can upload that13:36
pittizyga: but please forward this upstream, too13:36
zygapitti: this is not an upstream bug13:39
zygapitti: this is just the packaging, normally debhelper patches that but here it's not detecting this as a python package13:39
zygapitti: I'll open a merge request after the meeting now13:40
zygapitti: I suspect there's a ton of identical issues in other packages13:41
zygahrw, bryceh: yeah, thanks, I was looking for input on how to contribute that13:42
pittiright, in general packaged python scripts should use /usr/bin/python..., not env13:43
smartboyhwHello. 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
pittizyga: no MP necessary, the patch is fine13:43
pittizyga: I'm worried about adding the patch, not the form in which to sponsor it13:44
smartboyhwOnly one make[1]: *** [all] Error doesn't help...13:44
pittizyga: it's this kind of annoying patches which we have to carry forever unless we agree with upstream what the shebang should be like13:44
pittiand it's not really a blocker for running with py3, you can just run python3 pastebinit, after all13:44
zygapitti: but the shebang _is_ right upstream, it's a bug in debhelper not fixing all scripts this way13:44
zygapitti: it's not a problem with python3, only with virtualenv -p python313:45
pittizyga: if debhelper changes the hashbang to use env, how does the patch help then?13:45
zygapitti: where it breaks because python == python313:45
pittipython == python3 is really wrong13:45
zygapitti: it does for python packages, it does not look at all scripts to check13:45
brycehsmartboyhw, /usr/include/qt4/QtWebKit/qwebpage.h:1:55: fatal error: ../../../../Source/WebKit/qt/Api/qwebpage.h: No such file or directory13:45
pittithat's what Arch is doing, and it's just plain broken13:45
zygapitti: that's virtualenv13:45
pittizyga: we better fix that then IMHO13:46
zygapitti: virtualenv -p python3 /tmp/omg &&  . /tmp/omg/bin/activate13:46
pittipython != python313:46
zygapitti: that's specified upstream behavior, python3 does that too13:46
pittino, it's not13:46
zygapitti: the real problem is in packaging I'm afraid13:46
pittiunfortunately the PEP does not explicitly forbid it13:46
pittibut the only ones guaranteed are "python2" and "python3"13:46
pittiif something calls "python" and gets python3, we cannot blame that something13:47
zygapitti: still, it's broken in terms of our own policy13:48
zygapitti: I'm glad to work on dh to actually fix that on arbitrary executable scripts13:48
zygapitti: that would make this patch obsolete13:50
zygapitti: note that many python developers use virtualenv (especially non-system developers) and this breaks a very popular program in practice13:50
pittior fixing virtualenv13:50
zygapitti: on the upside python3 is not really common yet13:51
zygapitti: 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 either13:51
zygapitti: though I agree that virtualenv behavior is annoying13:51
zygapitti: I'll ask virtualenv upstream13:51
pittino, that's certainly something to fix in virtualenv upstream13:51
zygapitti: would you be happy with dh automatically patching all 'env python' to 'python' scripts?13:53
pittibut even if we have to patch it there, it's IMHO better to patch in one place than in lots of packages13:53
pittizyga: if that's the right thing to do, not 100% sure; barry, ScottK, any opinion about changing #!/usr/bin/env python hashbangs automatically?13:54
zyga(me talks to virtualenv commiter he knows)13:55
ScottKpitti: 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:56
pittiI guess the root of all evil is http://www.python.org/dev/peps/pep-0394/13:57
pitti"python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions"13:57
pittithat's quite frankly just plain stupid13:57
zygapitti: note13:57
pittias some distros like arch, and maybe the virtualenv authors will refer to that13:57
zygapitti: that's python3.3 behavior13:57
pittias that essentially invalidates "python" to be anything meaningful13:58
zygapitti: run pyvenv-3.313:58
zygapitti: well, in a way it's sensible outside of unix+packages world13:58
pittiso in theory everything needs to say "python2" or "python3" now13:58
zygapitti: you install "that python" and "python.exe" is "that python"13:58
pittiunless you carefully port your py2 programs to work on both py2 and py313:58
zygapitti: but it's already larger than virtualenv as python3.3 with standardized virtualenvs is what we have in the future13:58
pittibut it breaks pretty much every non-ported python2 program out there13:58
zygapitti: note that shebang was not something that was in python scope until python3.313:59
zygapitti: not python2 or python3, but system packages must use an absolute path for the interpreter13:59
pittizyga: yeah, that PEP is quite recent, 201113:59
zygapitti: note that it also fixes shebangs on windows13:59
pittizyga: no, that's not the problem; "/usr/bin/env python" should still get you python 2.x13:59
pitti(it might not be policy compliant for other reasons, that's my question to barry)14:00
zygapitti: in theory yes but look that all windows releases have 'python.exe'14:00
zygapitti: so no version-encoded executabales14:00
pittiwell, same problem14:00
zygapitti: 3.3 fixes that a bit14:00
zygapitti: with a new program that interpretes shebangs for python14:01
zygapitti: to work for 2.* - 3.*14:01
pittizyga: it looks at the source code and tries to figure out whether it's for py2 or 3?14:01
zygapitti: sadly it's something we've been doing but that's not "the python way", so the solution might be painful14:01
zygapitti: no, it reads the shebang14:01
zygapitti: and the shebang is special14:01
zygapitti: let me show you the spec14:01
pittibut that's the one that they just invalidated as a reliable source of information14:01
pittithe root cause is that py3 breaks compat with py2 in many ways, i. e. it is really a new language14:02
pittiso you can't call it like the old one14:02
zygapitti: scroll down to "Shebang line parsing"14:02
zygapitti: that's true14:02
zygapitti: I think we really need barry to tell us his opinion14:02
pittizyga: well, that shebang line parsing is ceratinly helpful14:03
zygapitti: at this time, we'd have to patch virtualenv and python3.3+ to fix this14:03
pittibut it seems orthogonal to determining for which python version a program is14:03
zygapitti: actually14:03
zygapitti: could we do something as crazy as binfmt support to use 3.3 launcher on all python files?14:03
pittiwouldn't that even aggravate the problem?14:03
zygapitti: it does support python2 versions14:04
pittiwe can't run any py2 program through py314:04
zygapitti: that launcher just re-exes the right version of pytohn14:04
pittihow does it determine the right version?14:04
pittiif the hashbang says "python", then you really could just guess14:04
zygapitti: according to the spec14:04
pitti(in the world of PEP-394)14:04
zygapitti: I don't know off the top of my head14:04
pittiin the actual world, python has meant 2.x for years14:05
pitti(which again is why PEP-394 is broken)14:05
zygapitti: yeah but we need to deal with 'bug that became a feature' unless we can fix it upstream somehow14:06
zygapitti: it says that /usr/bin/python2 automatically locates python2.* installation14:07
zygapitti: it's pretty long, I'm in a meeting, let me read that in the background14:07
zygapitti: ping me if barry sends a word14:07
pittizyga: yes, no problem with "python2" and "python3"14:09
Snow-Manpitti: think any more about having clusters able to use the same port? :)14:23
pittiSnow-Man: not recently14:24
Snow-Manit's frustrating to not be able to use the cluster tools. :/14:24
stgraberpitti,zyga: IIRC I already switched to /usr/bin/python3 in current upstream trunk14:26
vibhavApparently, python is somewhat broken in Raring14:27
vibhavos.sync() is broken14:27
vibhavCan anyone review https://code.launchpad.net/~jderose/ubuntu/raring/python3.3/fix-1131183/+merge/14983814:28
vibhavJason has submitted a fix14:29
stgraberpitti,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 usually14:29
zygastgraber: cool, thanks14:29
pittivibhav: thanks14:30
vibhavpitti: thank Jason DeRose :)14:30
=== francisco is now known as Guest99270
mitya57dholbach: so docutils support for named links has landed! ... and I'm going to backport it to raring14:44
dholbachmitya57, great14:45
mitya57(though it's a bit ugly `like this <ref_>`_)14:45
mitya57ah, and I also wanted to do a sphinx sru14:45
dholbachmitya57, ubuntu-packaging-guide ftbfs right now - did you see the build log?14:45
mitya57dholbach: I've fixed it yesterday14:45
dholbachh no14:46
mitya57I think we should upload 1.3.1 before the feature freeze14:47
mitya57(after I finish the python 3 port) :-)14:47
=== wedgwood_away is now known as wedgwood
dokopitti, can you check that your sponsoring for #1131183 works on the buildds?15:13
pittidoko: sure; I built it locally and confirmed that both os.sync and fsync work15:14
dokopitti, local builds were not the issue15:14
pittiI'll do it again with the packages from the buildds15:14
=== Ursinha-afk is now known as Ursinha
dobeywhat was the link for the udd branch import status/log/whatever?15:23
dobeyah, thanks Laney15:30
dobeywhy is it so backed up?15:30
dobeythere's 845 outstanding jobs :-/15:31
dobeyone of which i am doing a new release of15:31
pitti@pilot out15:40
=== 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:
pittidoko: amd64 has built, the buildd binaries are fine15:47
roaksoaxslangasek: howdy!! Just wanted to let you know I have uploaded python-django (ubuntu1.6) and python-tx-tftp as part of the MAAS SRU!16:05
=== zz_jackyalcine is now known as jackyalcine
kirklandjamesh: hiya!  I was wondering if you had a chance to look at https://code.launchpad.net/~kirkland/upstart/no-scold/+merge/148816 yet?17:02
kirklandslangasek: 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
infinitykirkland: You probably meant jodh, not jamesh.17:03
kirklandinfinity: ah!  thanks!17:04
kirklandinfinity: does he generally hang out here?17:04
infinitykirkland: Generally, though he seems to adhere rather strictly to a concept of work hours. :)17:04
kirklandinfinity: lucky dog17:05
kirklandinfinity: thanks, I'll try to grab him earlier tomorrow17:05
infinityslangasek: Did you and Colin come up with anything when unwinding the update-manager partial last night?17:05
kirklandinfinity: perhaps I'm catching slangasek on the right side of the sun, though :-)17:05
infinityslangasek: 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:06
cjwatsonThe 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 quick17:07
cjwatson(Besides, it sounds like a lot of messing around rather than honouring the metadata)17:07
infinitycjwatson: Oh, fair point.17:07
cjwatsonI was starting to attempt to write a test case for this17:07
infinitycjwatson: 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
infinitycjwatson: I'm not sure how far we can relax that before we accidentally let it remove half of -desktop on a bad resolver run.17:08
=== mitya57_ is now known as mitya57
cjwatsonI think mvo's idea of "permit removal as long as there's a direct c/p/r" would be ok ...17:09
infinitycjwatson: Probably, yeah.  Any fallout from that will be obvious packaging bugs that should be fixed anyway.17:09
cjwatsonat least that way if there were a chain of packages involved then (worst case) you could work around it by c/p/ring them all17:10
infinitycjwatson: 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:10
cjwatsonI dunno, I sort of like the strict behaviour of upgrade - it's at least simpl17:11
infinityIt is that.17:11
cjwatsonAnd this is something that's being explicitly forbidden by u-m17:11
cjwatsonIt does depcache.upgrade(True) and checks depcache.del_count by hand17:12
infinityWell, 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
cjwatsonSo it doesn't seem particularly wrong to relax it in u-m too17:12
cjwatsonIt would, but I don't agree that it's a good model for it to be emulating apt-get upgrade17:12
cjwatsonBecause I think apt-get upgrade is generally wrong17:12
infinityWhich goes back to "maybe upgrade should be less wrong".17:12
cjwatsonFor instance if you're in the habit of using apt-get upgrade all the time then you'll lose out on new Recommends17:13
infinityBut making it less wrong while still unlikely to break computers is hard.17:13
cjwatsonWhich is not how the system is meant to work17:13
cjwatson(And, more to the point, you have no way to notice that you're losing out on new Recommends)17:13
infinityThat 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:13
cjwatsonHonestly, any apt consumer that's driving depcache in an upgrade-like way rather than a dist-upgrade-like way is already wrong17:14
cjwatsonThe right fix is to have them drive it in a dist-upgrade-like way17:14
infinityAnd then to check delete counts and guess if it's okay?17:14
cjwatsonAnd forget about upgrade as hard as possible17:14
cjwatsonOr whitelist particular packages17:14
infinityWhere "guess" means "duplicate the same PCR checking"?17:14
cjwatson(And TBH crazy delete counts are much less of a problem nowadays)17:14
infinityWell, as you point out, whitelisting only works after the fact, which is chicken and eggy.17:15
cjwatsonNo, I mean whitelist important things like -desktop17:15
infinityOh, right.17:15
infinityWhich is pretty much the dist-upgrader approach.17:15
infinityAllow violence, repair.17:15
cjwatsonI 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 it17:16
cjwatsonStarting with dist-upgrade or similar makes a lot more sense to me17:16
infinityYeah, that's fair.  I haven't actually *run* apt-get upgrade in years (a decade, maybe?) for reasons stated.17:16
infinityThen again, I don't run update-manager for similar reasons, so perhaps this highlights your view well.17:17
cjwatsonRight now, u-m is half-way in between.  It allows installing new packages but refuses to remove.17:21
=== henrix is now known as henrix_
cjwatson(AFAIK anyway.)17:22
=== henrix_ is now known as henrix
slangasekmlankhorst: I'm confused by bug #1130974, I cannot reproduce this build failure here17:49
ubottubug 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/113097417:50
mlankhorstslangasek: needs libdrm >= 2.4.34 to fail17:50
mlankhorstso if you don't have updates pocket enabled, it will just work17:50
slangasekmlankhorst: hmm.... ok, I do have -updates enabled but apparently didn't apt-get update17:51
* mlankhorst has enough sru's to verify now!17:57
slangasekroaksoax: 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 upload17:59
slangasekkirkland: haven't looked at it yet, sorry... it's in the queue though17:59
kirklandslangasek: no worries, thanks17:59
slangasekinfinity, cjwatson: so is there a consensus that we should go ahead with having u-m handle the c/p/r specially?17:59
roaksoaxslangasek: the new upload drops the GenericIpAddressField18:00
roaksoaxslangasek: which is now implemented in MAAS18:00
slangasekroaksoax: ok.  if that's your preference, I'll review that one instead - I guess it should be a quicker review18:00
roaksoaxslangasek: indeed!! :)18:01
cjwatsonslangasek: 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 on18:02
slangasekok :)18:02
infinityslangasek: That seems less scary than just letting it tear things out willy-nilly, yes.18:03
cjwatson(I have some kind of test isolation bug that's breaking my brain at the moment)18:03
slangasekme, I'm still stuck trying to get it to build reliably without adding a Build-Conflicts with python18:03
infinitySide note: Our UI needs more opportunity to use present users with options involving the word "willy-nilly".18:03
slangasekpybuild is nearly there, but for some reason the install_data target isn't installing the .mo files18:03
infinitys/use //18:03
cjwatsonslangasek: mterry posted a dh9 branch - don't suppose that makes a difference?18:04
mterryfor update-manager?  yeah, it prevents the shebang from being stripped down to python2 by dh_pysupport18:04
slangasekoh, is that what's been happening?18:05
slangasekyeah, that might be a quicker fix18:05
mterrycjwatson, the test suite is unreliable for you?18:05
mterrycjwatson, hmm, I see the pep8 test fails...  and the port-listening test, which I agree is a pain18:06
cjwatsonmterry: yeah, got a failure in test_update_list which is order-of-tests-dependent18:06
cjwatsonmterry: I fixed the pep8 tests, update18:06
cjwatsonno port-listening failure here18:06
mterrycjwatson, probably because you have installed an ssh server locally18:07
cjwatsonheh, but of course I have a local openssh server18:07
mterrycjwatson, if port 22 isn't open, it fails18:07
cjwatsonstupid test18:07
mterrycjwatson, which is a stupid test  :)18:07
cjwatsonMight have a go at that later18:07
cjwatsonTrying to narrow down the one I'm actually seeing first18:08
=== kentb is now known as kentb-afk
cjwatsonFor 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:11
cjwatsonAnd 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:13
cjwatsonWhich I think is actually a genuine failure masked somehow ...18:17
larsgkhi guys - now where ubuntu-phone is flooded ... do you know of a channel for ubuntu phone core app devs?18:26
=== yofel_ is now known as yofel
slangasekcjwatson: 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 wrong18:27
=== Quintasan_ is now known as Quintasan
xnoxlarsgk: #ubuntu-arm =)18:30
larsgkxnox: cool - thanks18:30
=== deryck is now known as deryck[lunch]
bdmurraysbeattie: bug 982619 could use a test case19:03
ubottubug 982619 in apparmor (Ubuntu Precise) "aa-logprof wrongly transforms PUx to UPx" [High,In progress] https://launchpad.net/bugs/98261919:03
sbeattiebdmurray: thanks19:03
bdmurraysbeattie: oh and bug 109164219:04
ubottubug 1091642 in apparmor (Ubuntu Precise) "apparmor parser fails due to matchflags not being reset" [Undecided,Triaged] https://launchpad.net/bugs/109164219:04
bdmurraysbeattie: let me know when they do and I'll rereview / approve19:04
sbeattiethe latter has a testcase incorporated in the source as part of the patch19:05
sbeattiebut yeah, I can tease that out and include it in the bug description.19:06
=== AbsintheSyringe2 is now known as AbsintheSyringe
=== kentb-afk is now known as kentb
mdeslaurshadeslayer: 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:24
jtaylortransmission from proposed still works fine, let me quickly install qt to see if the bug is fixed19:33
jtaylorok how do I use the magnet link?19:34
jtaylor(and what is a magnet link?)19:34
jtaylorpasting it in chromium just gets to me to a google index ._.19:34
=== henrix is now known as henrix_
sarnoldjtaylor: paste it into your torrent client. on rtorrent, backspace <paste>...19:39
jtaylorsarnold: in the bug testcase "* Try to open same magnet link using chromium,"19:39
sarnoldjtaylor: ah :D19:39
jtaylorit works from firefox though, is that enough?19:41
=== dpm is now known as dpm-afk
=== deryck[lunch] is now known as deryck
YokoZarCan 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:04
* jtaylor always adds -proposed20:10
jtaylorI think the automatic proposed is just raring, but I could be wrong20:10
stgraberYokoZar: just "precise" will work fine20:12
stgraberjtaylor: the rewrite works for all series20:12
xnoxYokoZar: yes, you can.20:12
jtaylorhttps://wiki.ubuntu.com/StableReleaseUpdates should be updated then20:14
jtaylorit still says upload to -proposed20:14
* ScottK always writes -proposed in debian/changelog. 20:18
ScottK(for SRUs)20:18
ScottKjtaylor: It's automatic everywhere.20:18
=== baba is now known as unix
timrchallyn, 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
timrcarmhf-on-x86, to be more specific20:49
hallyntimrc: like i say there will still be issues on raring, but i can actually do real work in an armhf container in raring20:51
hallynjust dont' run java20:51
hallynit segfaults - i need to check actually whether physical arm host maybe does the same thing20:51
timrchallyn, keyboard is still responsive in the lxc console (I can ctrl-z, for example)20:52
timrchallyn, anywho, I'll give it a whirl in raring :)20:53
=== salem_ is now known as _salem
shadeslayerjtaylor: interesting, from what I tested firefox didn't handle magnet links but chromium did :P21:08
xxiaocould not find lxc in 12.10 for ppc22:15
xxiaoE: Unable to locate package lxc22:16
xxiaohttps://launchpad.net/ubuntu/quantal/powerpc/lxc does show it22:17
stgraberxxiao: do you have universe enabled in /etc/apt/sources.list?22:22
xxiaostgraber: thanks. was comparing it to x86 12.04, indeed universal is not enabled22:29
xxiaostgraber: i built the rootfs from ubuntu-core, it has universal disabled by default22:29
stgraberyeah, that was my guess when you said you couldn't find lxc in 12.1022:29
xxiaonow it's ok, thanks!22:30
lefterisI'm interested in getting an SRU for LP bug #1081307 but debfx there says there's already a pending SRU which although I cannot find22:54
ubottuLaunchpad bug 1081307 in virtualbox (Ubuntu Quantal) "I'm upgrading the 12.04.1 to quantal 3.5 kernel - virtualbox-dkms 4.1.12-dfsg-2ubuntu0.2: virtualbox kernel module failed to build" [Undecided,Confirmed] https://launchpad.net/bugs/108130722:54
lefteriscould someone tell me if I need to prepare a debdiff, or just need to wait?22:55
jtaylordebfx: ^22:56
jtaylorI can't find it either, its also not in the queue, maybe it was rejected?22:56
lefteriscan i prepare a debdiff for https://launchpad.net/bugs/1081307 or just need to wait?23:12
ubottuUbuntu bug 1081307 in virtualbox (Ubuntu Quantal) "I'm upgrading the 12.04.1 to quantal 3.5 kernel - virtualbox-dkms 4.1.12-dfsg-2ubuntu0.2: virtualbox kernel module failed to build" [Undecided,Confirmed]23:12
ScottKlefteris: You can prepare a debdiff without waiting.23:16
lefterisScottK: ok, thanks23:18
GuidoPallemansis there any way to save settings for an app in qml?23:18
slangasekbarry, doko, pitti: so I'm looking for some advice on an interaction between python3-distutils-extras and pybuild.  build_i18n works by extending data_files with the list of generated .mo files to install; this works fine if build_i18n is called from the same process as install, but when they're called from separate processes, the info doesn't get passed anywhere... and pybuild seems to be clever enough that it doesn't call build_i18n a 23:22
slangasek... in the 'install' target.23:22
slangaseknot sure which bit to consider this a bug in23:22
sarnoldslangasek: you were cut off at "it doesn't call build_i18n a"23:22
* doko never touched distutils-extra23:23
slangaseksarnold: orly?  should have wrapped to a second irc message23:23
barryslangasek: interesting.  do you have a branch to show this?  total wag would make me think that it's p-d-e that should work better in that case23:23
* slangasek has splitlong.pl enabled23:23
slangasekdoko: that doesn't prohibit you from having opinions :)23:24
sarnoldslangasek: it didn't seem to flow into the second message well, ".. call build_i18n a in the 'install' target"23:24
* barry has futz with p-d-e a few times23:24
slangasekbarry: sure, let me twiddle my update-manager branch into something pushable23:24
slangaseksarnold: heh, then apparently splitlong and freenode disagree about how long is long :P  "second time"23:24
ScottKslangasek: It did wrap into a second message fine here.23:25
barryslangasek: could you port splitlong to elisp so i can use it in erc? :)23:26
slangasekbarry: I'm sure someone has implemented it for erc before... :)23:26
sarnoldslangasek: heh :)23:27
slangasekbarry: lp:~vorlon/update-manager/pybuild23:28
slangasekbarry: in principle, do you think the right answer is for build_i18n to stash its state somewhere and have a separate install_i18n target that picks it back up, or for pybuild to call setup.py in a way that build_i18n gets run again?23:31
=== kentb is now known as kentb-out
barryslangasek: my gut feeling is that `pythons setup.py <command>` should be stateless and pybuild should adjust for that23:31
barryslangasek: well, otoh install does install everything from the build directory, so build; build_i18n; install should work23:33
slangasekwhat I really don't understand is why /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm invokes setup.py install in such a way that build_i18n is run again, but pybuild does not23:35
barryslangasek: maybe ping piotr over in debian-python?23:40
barryprobably just a bug in pybuild is my guess23:42
barryslangasek: is this the symptom of the problem:23:47
barrycp: cannot stat './debian/tmp/usr/share/locale': No such file or directory23:47
barrydh_install: cp -a ./debian/tmp/usr/share/locale debian/update-manager-core//usr/share/ returned exit code 123:47
barry 23:47
slangasekbarry: yes23:51
slangasekis meant to be installed by the debian/rules install target; isn't23:51
barryslangasek: one thing that's interesting is that it looks like pybuild build s into .pybuild/pythonX.Y_3.3/build/ but the mo directory is left in build/23:54
barryslangasek: wag, maybe pybuild isn't passing --install-layout to build_i18n?23:55
slangasekbarry: it's evidently not passing --install-layout to any of the setup.py invocations23:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!