[00:39] <xnox> sergiusens: did you see bug #1290492 ?
[00:39] <ubottu> bug 1290492 in Ubuntu Music App "Impossible to update translations" [High,In progress] https://launchpad.net/bugs/1290492
[00:46] <sergiusens> xnox, I haven't... and qmake :-/
[00:48] <xnox> =(
[00:49] <sergiusens> xnox, from what I've been seeing, the sdk hard codes a bunch of stuff all around
[01:17] <infinity> tvoss: Why does dbus-cpp force g++-4.7 (which doesn't exist on ppc64el)?
[01:27] <ScottK> cjwatson: Thanks for mentioning git-dpm the other day.  I think I finally found the tool that makes sense to me.
=== _salem is now known as salem_
[03:12] <sarnold> does anyone know off-hand what the deal is with minidlna? upstream renamed the package, I can't find if there is a new debian package, and our trusty minidlna package has been deleted but I can't find a readymedia package..
[03:13] <rww> "lp #1253071, FTBFS, RC buggy, removed from Debian testing, not ported to libav9" per https://launchpad.net/ubuntu/+source/minidlna/+publishinghistory
[03:13] <ubottu> Launchpad bug 1253071 in minidlna (Ubuntu) "FTBFS against libav9" [Undecided,Triaged] https://launchpad.net/bugs/1253071
=== salem_ is now known as _salem
[03:55] <sarnold> rww: thanks! :)
[05:26] <pitti> Good morning
[05:27] <pitti> SpamapS: well, the py version of juju is gone, isn't it? I suppose it could be reactivated (and I really wish it was..), but we certainly shouldn't support *two* versions
[05:30] <SpamapS> pitti: I should restate. It's unlikely I'll be running juju any time soon. :-P
[05:30] <pitti> SpamapS: ah :)
[05:34] <Unit193> Anyone got a link to the bash completion problem in files with spaces?
[05:35] <sarnold> Unit193: I've seen these two so far: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031  https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1290572
[05:35] <ubottu> Launchpad bug 1288031 in bash-completion (Ubuntu) "Tab expansion only auto-completes directory names" [High,Confirmed]
[05:35] <ubottu> Launchpad bug 1290572 in bash-completion (Ubuntu) "tab completion skips files when path begins with ~" [Undecided,New]
[05:40] <Unit193> "file Hogans\ Heroes/Hogans\ Heroes\ Season\ " and it stop there, it's not quite either because if there's more than one one file it'll complete up to the diff, then stop and won't pick back up.
[05:43] <sarnold> Unit193: is that the behaviour controlled by show-all-if-ambiguous ?
[05:43] <Unit193> Shouldn't be, defaults used to be fine.
[05:45] <sarnold> something seems pretty broken anyway
[05:46] <Unit193> Yeah, I'm holding off the other upgrade, tab complete is too important to me. :P
[05:46] <sarnold> the amount I've used my trusty vms so far I've only noticed that it doesn't work as I'm used to. heh.
[05:47] <sarnold> the last time I looked into doing anything with tab completion I got the simple cases done alright but the harder stuff was .. well, harder. I found my head going around in circles while trying to read the more complicated examples.
[05:47] <sarnold> I'm glad it's not me on the line to fix it :) "everyone downgrade to saucy's bash" wouldn't go over real well. :D
[05:48] <Unit193> Hah, that's what I did with some python package to fix gcalcli. :P
[06:53] <pitti> barry: yay, 3.4~rc3 looks much happier now, thanks!
=== plars_ is now known as plars
[07:30] <mitya57> pitti: hi, can you please check what happened to dh-python autopkgtest? update_excuses.html says it's "running" since yesterday, and there is no entry for ubuntu4 upload on public Jenkins.
[07:31] <pitti> hey mitya57; looking
[07:32] <pitti> mitya57: the run was started, but yay jenkins hiccup :( /me restarts
[07:32] <mitya57> Danke!
[07:38] <pitti> Finished: SUCCESS
[07:38] <pitti> mitya57: thanks!
[07:38] <pitti> trusty-adt-dh-python-ppc64el now works, too
[07:39] <mitya57> Nice :)
=== smb` is now known as smb
=== evfool_ is now known as evfool
[08:34] <Ademan> For security fixes, is there any hierarchy among LTS releases? (latest LTS gets patch, eventually gets backported to next latest LTS)
[08:38] <pitti> Ademan: usually all releases get fixed at the same time
[08:41] <Ademan> pitti: thanks
[09:17] <Saviq> mardy, hey, there seems to be an issue with signon-ui and google accounts with SSO, it asks me for the google password, which effectively doesn't exist with SSO... I had the account working before, but seems it got unauth-ed for some reason, and I can't reconnect now because of that, any ideas?
[09:55] <warren> Is anyone familiar with the /etc/init/*.conf files?  I'm trying to exec a command as a non-root user and define a command that runs to stop it.
[09:58] <RAOF> warren: You're probably looking for the upstart cookbook?
[09:58] <warren> I see it
[09:58] <warren> I see post-stop
[09:58] <warren> but that doesn't seem to be exactly what I want
[09:59] <RAOF> You want non-root users to be able to start/stop the service?
[09:59] <warren> no
[09:59] <warren> I want to exec /path/to/program as a certain non-root user
[09:59] <warren> and I want to "killall -u nonrootusername" on stop.
[10:00] <warren> someone suggested "exec sudo -u nonrootusername /path/to/program"
[10:00] <warren> I suppose that works.
[10:01] <RAOF> Ah, yeah. That'd be right.
[10:01] <warren> pre-start and post-stop appears that it would work for the killall
[10:01] <warren> but there's no command to define stop?
[10:01] <RAOF> No; stop is SIGTERM
[10:02] <warren> ok, then I want pre-start and post-stop
[10:02] <RAOF> (Or whatever you set kill signal to)
[10:03] <RAOF> You probably want pre-stop, then. Otherwise your thing will already have been sent SIGTERM.
[10:04] <warren> It's a thing that launches another thing that launches another thing ...
[10:04] <warren> i didn't write it, I'm just packaging it
[10:05] <RAOF> So it does its own process supervising? :)
[10:06] <warren> yeah, and killall -u is good enough ...
[10:08] <warren> RAOF: thanks
[10:15] <tsdgeos> what's wrong with bash? i get an error just by tabbing in an empty window :S
[10:16] <tsdgeos> do you guys get that?
[10:17] <tsdgeos> bash: words: bad array subscript
[10:17] <seb128> tsdgeos, bug 1289597
[10:17] <ubottu> bug 1289597 in bash-completion (Ubuntu) "bash: words: bad array subscript" [Undecided,Confirmed] https://launchpad.net/bugs/1289597
[10:17] <seb128> it has a sponsoring request as well
[10:19] <seb128> tsdgeos, you can nag ogra_ or RAOF about sponsoring I guess, they are supposed to be piloting
[10:19] <seb128> or janimo or rbasak
[10:19] <tsdgeos> i wonder if that fixes the other billions of regressions i have in tab handling
[10:19] <tsdgeos> probably not
[10:20] <tsdgeos> i am half productive since my tab broke
[10:20] <seb128> tsdgeos, I guess the other ones are https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031
[10:20] <ubottu> Launchpad bug 1288031 in bash-completion (Ubuntu) "Tab expansion only auto-completes directory names" [High,Confirmed]
[10:20] <tsdgeos> that one and also https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1290553
[10:20] <ubottu> Launchpad bug 1290553 in bash (Ubuntu) "tab completion regression in trusty in files that contain ? in name" [Undecided,New]
[10:22] <seb128> blame doko for uploading the new bash after ff without a ffe and then going on holidays letting stuff buggy
[10:22] <seb128> he's back next week though, I hope he's going to have a look then
[10:22] <tsdgeos> wonder if i should add bash-completion to https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1290553 too
[10:22] <ubottu> Launchpad bug 1290553 in bash (Ubuntu) "tab completion regression in trusty in files that contain ? in name" [Undecided,New]
[10:22]  * tsdgeos does
[10:23] <seb128> I'm pondering reverting the bash update meanwhile, since that's a new version that was uploaded without ffe approval and which introduced regressions
=== Ursinha is now known as Ursinha-afk
[10:36] <cjwatson> ScottK: yay
[10:57] <xnox> seb128: well i presume other people would notice as well. I see a thread on gnu.bash.bug which seems to believe it might be a bug in bash-completion.
[10:58] <seb128> xnox, "other people would notice as well"? you mean?
[10:59] <xnox> seb128: as in, it's a bug that i'm expecting to have a hotfix somewhere quick.
[10:59] <seb128> xnox, let's see, we have the issue for over a week though
[11:00] <seb128> xnox, it also doesn't change the fact that the new bash was uploaded without a ffe
[11:01] <cjwatson> There's https://code.launchpad.net/~j/bash-completion/bug1289597/+merge/210089 FWIW
[11:01] <xnox> seb128: i see a bug filed in launchpad 13h ago, and threads on upstream mailing list very recent, less than a week ago.
[11:02] <seb128> xnox, I've no doubt it's going to be fixed, I'm not sure what we are arguing about there?
[11:02] <seb128> cjwatson, yeah, I pointed that to tsdgeos earlier, we just need a patch pilot to do a shift and pick it up for sponsoring ;-)
[11:03] <xnox> seb128: "I'm pondering reverting the bash update meanwhile" i don't like reverts, especially when people are working to resolve things. Short term it might be quicker to revert, but in the long run it's a waste of resources to not just fix it properly without reuploading revert of the revert.
[11:04] <seb128> xnox, well, that was a feature update without a ffe
[11:04] <seb128> which is buggy as well
[11:05] <xnox> seb128: sure, but uploading reverts is not a solution to the problem - e.g. as to why ffe process was not respected.
[11:06] <seb128> xnox, just waving hands and saying it's ok to not respect the process is not a solution either
[11:06] <seb128> but let's not argue about it
[11:06] <seb128> doko is not even there :p
[11:07] <xnox> seb128: cjwatson: so executing "complete -r" makes the completion as per bug report work.
[11:07] <xnox> but i'm not sure what that does, and whether that's suppose to be called from bash postinst?!
[11:08] <cjwatson>       -r        remove a completion specification for each NAME, or, if no
[11:08] <cjwatson>         NAMEs are supplied, all completion specifications
[11:08] <xnox> cjwatson: right, so bash is not broken.
[11:08] <cjwatson> can't possibly be called from bash postinst, it's a shell builtin
[11:08] <cjwatson> I mean, can't usefully be called.  it won't magically affect other shells ...
[11:09] <cjwatson> I would expect that "complete -r" basically just makes the current shell act as if bash-completion weren't installed
[11:10] <seb128> xnox, btw, are you in the office today? ;-)
[11:10] <xnox> seb128: are you?
[11:10] <xnox> seb128: i was in, yesterday but not today. Do you need people in the office poked?
[11:10] <seb128> xnox, no, but mpt upgraded saucy to trusty and has a non booting machine, just plytmouth and nothing
[11:11] <seb128> xnox, I was trying to figure out who could help him
[11:11] <xnox> seb128: =((( he should have upgraded yesterday. cjwatson, jodh and I were in the office.
[11:11] <seb128> yeah :/
[11:11] <xnox> seb128: the office support is on holliday today...
[11:12] <seb128> he started the upgrade yesterday, but has an old laptop with a slow disk, upgrade takes ages
[11:14] <xnox> cjwatson: seb128: bash-completion appears to fix completion bugs for me. Let me test it more here.
=== AbsintheSyringe is now known as fooctrl
=== MacSlow is now known as MacSlow|lunch
[11:48] <tkamppeter> OdyX, hi
[11:50] <pitti> jamespage: is juju-local something which the server team supports and wants bug reports for?
[11:51] <pitti> jamespage: it falls over quite hard trying to bootstrap containers in current trusty, on bind-mounting the log directory AFAICS (and apparently also on LXC's cgroup warnings, although this could be a red herring)
[11:52] <pitti> jamespage: or is it deliberately in universe, and a community project?
[12:03] <jamespage> pitti, it is
[12:06] <rbasak> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: rbasak
[12:11] <rbasak> lp:ubuntu/precise/charm-tools appears to have some extra commits on top of the version of charm-helpers that is in precise. I didn't even know this was possible. What's the appropriate action here? Blow it away by uploading the SRU I want, instead? Will that somehow break UDD?
[12:17] <OdyX> tkamppeter: I fixed the permissions now, should be okay.
[12:30] <tkamppeter> OdyX, thanks, everything pushed.
[12:31] <OdyX> tkamppeter: yay, will upload shortly
=== _salem is now known as salem_
[12:38] <rbasak> jdstrand: please could you take a look at: https://code.launchpad.net/~sdeziel/ubuntu/precise/xl2tpd/fix-for-lp1244780/+merge/194247
[12:40] <rbasak> jdstrand: I'm unhappy to upload because 1) there are three patches, but the bug implies one and the changelog entry describes two; and 2) I'm unfamiliar with the package, and the test case isn't detailed enough for me to follow it. But for my latter objection, I appreciate that this is one of those interop things that needs an affected user to do the SRU verification anyway, and clearly Simon will be able to do it, so it's only a weak objection.
[12:40] <rbasak> jdstrand: I'd appreciate your opinion. If you think it's good, I can test and upload as-is.
[12:41] <rbasak> sdeziel: ^^
[12:47] <jdstrand> rbasak: I agree with your '1'. I think the changelog is too terse and it would be much easier for reviewers if the changelog described everything better
[12:47] <jdstrand> rbasak: as for '2'-- me too
[12:48] <jdstrand> rbasak: that said, excepting the changelog being too terse, the other issues I mentioned have all been addressed it seems
[12:49] <jdstrand> rbasak: tbh, I think that the changelog should be updated and dch -r ran before uploading since the sru team is going to have all the same questions we had when reviewing it
=== MacSlow|lunch is now known as MacSlow
[12:52] <rbasak> jdstrand: should I JFDI (fix the changelog and upload)? I'm never sure what to do in this kind of case - I don't want to modify Simon's entry yet still leave his signature.
[12:52] <rbasak> (OTOH, I don't want to use mine and take his credit away)
[12:52] <rbasak> And I don't want to have to make him go and fix it first, either.
[12:53] <jdstrand> rbasak: I've fixed changelog entries to make them more clear and adjusted timestamps in these situations. if you understand the patches, then sure, makes sense. just mention it in the MP
[12:54] <jdstrand> let me rephrase-- if you understand the patches well enough to make the changelog clear for the sru team, then sure
[12:54] <rbasak> jdstrand: OK. Thank you for your help!
[12:54] <jdstrand> np
[12:55] <jdstrand> (seems one of the comments in the MP makes it fairly clear)
[12:58] <jamespage> rbasak, technically that is possible (branch being used outside of packages) but its unusual
[12:59] <rbasak> jamespage: OK. I'm planning to just upload over the top, since I don't expect those other changes to land anyway (and there's nobody to drive that now)
[13:00] <rbasak> Laney: would you mind reviewing Gunnar's response at https://mentors.debian.net/package/mythes-sv please? I don't have a Debian hat, but it seems to me that the issues are the same for Ubuntu.
[13:00] <rbasak> I'm not sure about there being no licence in the source apart from in debian/copyright, even though I understand the notice can from an external source.
[13:00] <rbasak> And same for preferred form for modification, and the generated thing in the upstream source.
[13:29] <ogra_> cjwatson, urgh, susie just upgraded her laptop (14.04) and grub seems to be gone now
=== Ursinha-afk is now known as Ursinha
[13:29] <ogra_> i end up in win8
[13:31] <cjwatson> Check she doesn't have -proposed enabled
[13:31] <cjwatson> I haven't done a matching grub2-signed for the latest upload yet
[13:31] <cjwatson> Though it's also in unapproved for amd64, so probably not that
[13:31] <ogra_> i cant get into ubuntu at all
[13:31] <ogra_> i cant even intercept the boot anymore
[13:32] <ogra_> and i'm 100% she doesnt have proposed ... she only does auto updates, all other maintenance is done by me
[13:32] <cjwatson> I think realistically you'll have to figure out something locally with the aid of a rescue image or something before I have any chance at all of helping
[13:32] <ogra_> iirc xnox has the same device ....
[13:33]  * ogra_ cant even get into UEFI anymore ... 
[13:33] <ogra_> sigh !
[13:33] <ogra_> worst time for that to  happen
[13:34] <cjwatson> Sorry.  I don't think it's a systemic problem, though, it's not something I've heard other complaints about so far ...
[13:34] <cjwatson> And 2.02~beta2 has been in trusty for a while
[13:35] <ogra_> well, she only accepted the reboot u-m offered her after an auto update
[13:37] <cjwatson> Is the system strange in any other way?
[13:38] <cjwatson> I suppose it could be https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1272664
[13:38] <ubottu> Launchpad bug 1272664 in efibootmgr (Ubuntu) "Installing UEFI boot entry on Hyper-V gen 2 corrupts VM configuration, making the VM unuseable" [High,Confirmed]
[13:38] <infinity> ogra_: I assume you can boot a live image to investigate further?
[13:38] <cjwatson> But I can only guess wildly
=== jono is now known as Guest95937
[13:39] <Laney> rbasak: I'm on me hols now, so I won't be able to get to that until next week (sorry Gunnar)
[13:39] <Laney> rbasak: But yes, I think the issues are the same
[13:39] <ogra_> infinity, i could but need to do some errands before diving into UDS :P
[13:39] <Laney> debian/copyright can document the state even if it's not in the orig tarball
[13:39] <ogra_> cjwatson, infinity, so the BIOS was apparently re-set
[13:40] <Laney> rbasak: He pointed to another package - you could check if that has only the generated files or the inputs too
[13:40] <Laney> and it doesn't matter if you don't have Debian upload rights; you can still do a review which will be useful for the person who does come to upload it
[13:42]  * ogra_ finally got into the bios ... the EFI order was re-shuffled for whatever reason
=== bfiller_afk is now known as bfiller
=== Guest30460 is now known as NCommander
=== NCommander is now known as Guest83929
[14:03] <OdyX> tkamppeter: uploaded 1.0.47-1 now and prepared cups for oldstable and cups-filters for stable. AFAIK cups in lucid is affected through debian/local/filters/pdf-filters/pdftoopvp and cups-filters is affected in all Ubuntu releases.
=== MacSlow is now known as MacSlow|afk
[14:59] <rbasak> infinity: would you mind reviewing/uploading dannf's MP in https://code.launchpad.net/~dannf/ubuntu/trusty/flash-kernel/m400/+merge/208705 for flash-kernel please? ltgm, I also trust dannf anyway, and it's yellow in the queue.
[14:59] <rbasak> (I haven't tested it or anything)
[15:00] <rbasak> (I presume this is one of the ones that relatively few sponsors will be comfortable uploading)
[15:00] <dannf> rbasak: thx
[15:00]  * dannf meant to poke about that today
[15:01] <infinity> rbasak: Yeah, can look in a sec.
[15:02] <rbasak> Thanks!
[15:02] <Logan_> morning, all :)
[15:03] <jamespage> pitti, juju is still in MIR so its all in universe
[15:06] <rbasak> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[15:14] <infinity> tvoss: *poke*
=== MacSlow|afk is now known as MacSlow
=== salem_ is now known as _salem
[15:38] <jcastro> barry, FYI: https://bugs.launchpad.net/charms/+bug/1199052
[15:38] <ubottu> Launchpad bug 1199052 in Juju Charms Collection "New charm: mailman" [Undecided,Incomplete]
[15:41] <barry> jcastro: sweet
[16:01] <pitti> jamespage: ah, seems it's due to me not using /var/lib/lxc, so not affecting the default case; I filed it as bug 1290920 anyway
[16:01] <ubottu> bug 1290920 in juju (Ubuntu) "fails to start container with local provider with non-default LXC path" [Undecided,New] https://launchpad.net/bugs/1290920
[16:02] <jamespage> pitti, ack
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== bfiller is now known as bfiller_afk
=== AbsintheSyringe is now known as fooctrl
[17:25] <bdmurray> jibel: I was looking at bug 1286161 again and tried to restore the clone file and it failed badly
[17:25] <ubottu> bug 1286161 in ubuntu-release-upgrader (Ubuntu) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,New] https://launchpad.net/bugs/1286161
=== _salem is now known as salem_
[17:47] <ogra_> pitti, did anyone talk to you about the ofono-phonesim dbus issues we had while you were away (and the .crash files we get in the dailer-app tests due to that) ?
=== darkbasic_ is now known as darkbasic
[17:58] <pitti> ogra_: no, not so far
[17:58] <ogra_> oh
[17:59] <ogra_> pitti, since the switch to py3 we get tracebacks for many of the ofono scripts during testing
[17:59] <pitti> ogra_: ah, interesting; is there a bug for it?
[17:59] <ogra_> xnox worked around two of them but there is something more essential broken it seems so we stopped there
[17:59] <pitti> ogra_: UDS session now, TTYL
[17:59] <ogra_> pitti, same here :)
[18:00] <ogra_> just wanted to know if you had been pointed to it already, we can talk tomorrow :)
[18:01] <xnox> pitti: i did file a bug against apport.
[18:01] <xnox> pitti: after the double-hangout we can quickly chat about it =)
[18:03] <ogra_> xnox, tomorrow is enough too ... it will be late already after the double HO :)
[18:05] <mdeslaur> tkamppeter: do you have an example command line I can use to test pdftoopvp?
[18:09] <tkamppeter> mdeslaur, no, but I can ask Tim Waugh who has sent me the info about the vulnerabilities.
[18:11] <mdeslaur> tkamppeter: I just want to make sure it works, not necessarily test the exact security issue
[18:11] <mdeslaur> tkamppeter: I don't know what to specify as opvpDriver=
[18:13] <Wellark> hmm.. guys, how do I get this landed? https://code.launchpad.net/~kaijanmaki/connectivity-api/ci-testrun/+merge/202958
[18:13] <Wellark> the project is not in the archives yet
[18:14] <Wellark> I just need to get that MR to the trunk
[18:14] <Wellark> then after that I need the trunk to be included in universe
[18:14] <Wellark> this is unity8 dependencies so AFAIK there is a top level FFe in place
=== bfiller_afk is now known as bfiller
[18:48] <juliank> pitti: I'm a bit confused. You wrote in bug 1288171 that python-apt fails on some pyflakes tests. We run those tests during the build, and all builds were successful (and thus, pyflakes ran successfully on the build servers), so I wonder what's happening.
[18:48] <ubottu> bug 1288171 in python-apt (Ubuntu Trusty) "0.9.3 regression: Setting APT::Architecture now downloads wrong indexes" [High,Fix committed] https://launchpad.net/bugs/1288171
[18:55] <juliank> It's really strange that our tests run succesfully during the build on both Debian & Ubuntu, and the same tests fail in different ways when running from autopkgtests.
[19:01] <pitti> juliank: yeah, indeed; I have a closer look tomorrow morning
[19:01] <pitti> (UDS session ATM)
[19:02] <pitti> juliank: https://jenkins.qa.ubuntu.com/job/trusty-adt-python-apt/72/ARCH=amd64,label=adt/console
[19:02] <pitti> juliank: perhaps during build you don't run tests/old/ ?
[19:02] <pitti> juliank: and in debian http://ci.debian.net/#package/python-apt it's differently broken
[19:03] <juliank> pitti: They are not run, never. We run exactly the same tests during build and autopkgtest. The test tests/test_pyflakes.py fails, on autopkgtest, but not during the build.
[19:03] <juliank> But better get back to that UDS session then...
[19:03] <pitti> juliank: oh, but pyflakes might see tests/old/ and complain about those
[19:04] <juliank> pitti: Right, and we filter them out in our test_pyflakes.py script, and do not pass them to pyflakes.
[19:04] <pitti> juliank: ok, no off-hand idea without a closer look; I'll check tomorrow morning
[19:04] <juliank> OK, thanks.
=== bschaefer_ is now known as bschaefer
=== SpamapS_ is now known as SpamapS
[19:51] <molgrum> sorry if this is the wrong channel but it seems like a dev question, is radeon.dpm=1 planned to be enabled by default any time soon or is it too experimental yet?
[19:56] <pitti> xnox: to resume, you filed a bug against apport for the ofono python3 conversion?
[19:56] <pitti> xnox: oh, you mean bug 1287628?
[19:57] <ubottu> bug 1287628 in dialer-app (Ubuntu) "invoke_incoming_call() doesn't seem to work, result is not checked, yet test_incoming test passes (?!)" [Undecided,Confirmed] https://launchpad.net/bugs/1287628
[19:57] <pitti> xnox: I'll have a look at that tomorrow
[19:57] <pitti> ... or Thursday, given patch pilot/UDS/etc.
[19:58]  * pitti waves good night
[19:59] <xnox> pitti: that's a fix to tests in dialer-app, yes.
[19:59] <xnox> pitti: the "python3-apport not catching python2 crashes bug" is bug #1287659
[19:59] <ubottu> bug 1287659 in apport (Ubuntu) "python2 crash traceback was not caught, yet python3 one was" [Undecided,Confirmed] https://launchpad.net/bugs/1287659
=== TheMuso` is now known as TheMuso
=== Adri2000 is now known as Guest68283
=== ryanakca is now known as Guest51432
=== jono is now known as Guest57735
=== Trewas666 is now known as trewas
=== dkessel_ is now known as dkessel
=== StevenK_ is now known as StevenK
=== seb128_ is now known as seb128
[23:12] <xnox> upgraded from bad corsair vengeance memory to corsair beast. Didn't do benchmarks yet, but it appears to be faster and more stable \o/
[23:12]  * xnox is happy on my desktop again.