[06:55] <pitti> Good morning
[07:02] <pitti> cyphermox_: acpi-support> it's still used for some corner cases AFAIK, mostly for events which don't produce a proper evdev event yet
[07:02] <pitti> cyphermox_: or at least not at the time of the last review; the proper thing is to fix the kernel drivers to generate evdev events, of course, but that needs the affected hw for verifying
[07:03] <pitti> darkxst: tests with their own dbus interface> not enough context, I'm afraid; where do you see that? tests can set up their own fake services of course
[07:04] <darkxst> pitti, the tracker tests, require the Tracker dbus interface to be running
[07:04] <pitti> mapreri: ah, the arm64 fix is upstream? I don't know how harmful a missing semicolon is (should be tested under GNOME, KDE, XFCE), supposedly not important
[07:05] <pitti> darkxst: ah, autopkgtest or build time checks?
[07:05] <darkxst> build time, maybe they would be better as autopkgtests, but they are not setup as installed-tests currently
[07:06] <pitti> darkxst: so the upstream tests require a running tracker? that sounds just broken
[07:06] <pitti> darkxst: they ought to start tracker from the build tree and test that, preferrably on a private dbus instance
[07:08] <darkxst> pitti, yup right now they are testing the installed tracker (which is non-existent when building in a chroot)
[07:08] <darkxst> I will file an upstream bug
[07:08] <pitti> darkxst: ah, ok
[07:09] <pitti> darkxst: then this indeed can't even run during package build time, and should be run as autopkgtest
[07:09] <pitti> darkxst: the autopkgtest can then do something like dbus-launch make check-installed (or however it's called)
[07:10] <darkxst> pitti, so dump the tests/ code into a -tests package?
[07:11] <pitti> darkxst: no, please don't; if they are built (i. e. not in python or shell, but compiled), add a "Restrictions: build-needed"
[07:12] <pitti> darkxst: oh, I suppose it might follow the GNOME direction of providing installed tests
[07:12] <pitti> darkxst: like glib's; but preferrably they should still also be able to run against the build tree, so that developers can easily run them as well
[07:12] <darkxst> pitti, unit-tests are all compiled (I think), functional tests are mostly python (although these seem to end up installed when enabled)
[07:13] <pitti> darkxst: I think creating more binary packages for tests is clutter
[07:18] <darkxst> pitti, but isnt that what glib/gjs etc do?
[07:21] <pitti> darkxst: glib does, and probably a few more packages; building glib just takes a while, so it's more justified there
[07:25] <darkxst> pitti, right, just didrocks suggested we should really get the unit-tests running if we want to MIR tracker
[08:26] <mapreri> pitti: yes, I sent the patch to upstream myself. The validator report the messing semicolon as an Error.... I can try under XFCE and unity (I use i3) later today.
[10:15] <loa> xnox, hi, can you look at my bug report?
[10:16] <xnox> loa: yes, but not right now. Will investigate later today.
[10:16] <loa> xnox, it was my first atempt in bug reporting i don't know how clear i done it.
[10:16] <loa> xnox, ok.
[10:23] <darkxst> pitti, can you take a look at bug 1283551
[10:23] <darkxst> really wanted to SRU that back into trusty, but having to rebuild all typelibs seems like a pain there ;(
[10:24] <darkxst> we do get about 3000 crashes a week from that bug though ;(
[10:39] <pitti> darkxst: err, why do we have to rebuild *all* typelibs?
[10:39] <pitti> darkxst: I haven't digged into that crash in detail, but that seems like a small corner case
[10:40] <pitti> the ownership of the instance parameters is pretty much always "none" for methods and "full" for constructors, and that's what pygi/gjs/etc. should assume if it's not otherwise specified
[10:40] <pitti> so this should only need a rebuild of a typelib which has an API that behaves differently?
[10:41] <pitti> darkxst: I assume the rebuild is necessary to get the ownership annotation of the instance parameter into the typelib?
[10:45] <darkxst> pitti, its hard to tell which api need the transfer ownership
[10:45] <pitti> darkxst: but it should be obvious for the particular crash you wanted to fix?
[10:46] <darkxst> pitti, unfortunately not possible to get a gjs backtrace, from coredumps ;(
[10:47] <darkxst> would need gdb replay foo for that
[10:51] <darkxst> i.e. there is no way to tell which module cause the crash :(
[11:43] <pitti> infinity, slangasek: now that we have enough space on germanium, do you actually still see any reason to also split ddebs by component? they could just all go into "main" on ddebs, which eliminates the entire problem of having binaries in main+universe, binNEW, change-overrides, etc.
[11:45] <tseliot> cking, pitti: I hadn't noticed that kengyu said he'd work on this alternative approach to solve the Unity corruption problem on S3: https://lists.ubuntu.com/archives/fwts-devel/2014-July/004987.html
[11:45] <tseliot> cking, pitti: so I worked on the same issue adding support for sysfs and logind to fwts. Would my work still be useful? Or shall I throw it away?
[11:46] <pitti> erk, acpi-fakekey??
[11:46] <pitti> that doesn't even work on most machines, it's a really nasty hack from the distant past
[11:47] <pitti> tseliot: how is that related to suspend issues?
[11:47] <tseliot> pitti: https://bugs.launchpad.net/fwts/+bug/1339588
[11:47] <pitti> tseliot: perhaps you gave me the wrong fwts-devel URL?
[11:48] <pitti> tseliot: I'm familiar with the pm-utils/quirks/etc. parts we've discussed recently, but adding a copy of acpi-fakekey to fwts seems both unrelated and undesirable
[11:51] <tseliot> pitti: I haven't talked to kengyu yet (he seems to be offline atm) but I think the point of the patch is to trigger S3 using the function key so that logind is notified (?). That's the link from the private bug report
[11:51] <tseliot> pitti: let me subscribe you to the private report
[11:52] <pitti> tseliot: is that supposed to test the Fn key functionality or suspend? because these shouldn't be mixed
[11:53] <tseliot> pitti: I'm not sure. Hopefully #1332411 (which you can access now) will give you some insight
[11:53] <tseliot> also cking might know more about it
[11:56] <cking> tseliot, i'm not entirely sure what the desired solution was; I just commented on the fact that adding an executable to fwts was undesired
[11:56] <tseliot> oh, ok
[11:57] <cking> tseliot, can you respond to keng-yu's patch and explain what you are doing to resolve this issue if it is related?
[11:57] <tseliot> cking: sure
[11:58] <cking> thanks
[12:00] <pitti> cking, tseliot: followed up
[12:01] <tseliot> thanks
[12:48] <cyphermox_> pitti: I understand, but I'm not sure exactly what hardware is affected.
[12:48] <pitti> cyphermox_: that's the very problem :)
[12:49] <cyphermox_> pitti: I'll double check, but I may have at least some of the supposedly affected hardware in my possession; I use a thinkpad, and I have a toshiba at home, possibly also an asus netbook
[12:49] <cyphermox_> my thinkpad certainly doesn't require the acpi-support stuff
[12:49] <cyphermox_> (or at least not the radio toggle button)
[12:49] <pitti> cyphermox_: yes, neither does mine; a few years ago slangasek had one which required acpi-support for the wifi toggle AFAIR
[12:50] <cyphermox_> my main concern is pretty much just ripping out as much as the wifi toggle code as we can, in preparation for starting to use urfkill on desktop too
[12:51] <pitti> cyphermox_: yes, I'd gladly get rid of acpi-support
[12:51] <cyphermox_> ;)
[13:10] <LocutusOfBorg1> can anybody please sponsor gambas3 for me?
[13:10] <LocutusOfBorg1> I'm the last uploader
[13:10] <LocutusOfBorg1> (if we exclude a rebuild)
[13:11] <LocutusOfBorg1> http://paste.debian.net/109663/
[13:33] <shadeslayer> mvo_: ping
[13:34] <mvo_> shadeslayer: pong
[13:35] <shadeslayer> mvo_: what's the status of appstream in ubuntu? alternatively, whom should I talk to about it?
[13:36] <mvo_> shadeslayer: beside support for downloading the new data via apt AFAIK there is noone working on the integration, but if someone steps up and starts that effort, that would certainly be supported
[13:37] <mvo_> shadeslayer: maybe worth doing a calll for volunteers in a blog post or something like that?
[13:38] <shadeslayer> mvo_: ok, what needs to be done in Ubuntu specifically? because I know that the package manager in Kubuntu is pushing for it
[13:38] <shadeslayer> so muon will get appstream support in the next release
[13:38] <mvo_> shadeslayer: hm, metadata extraction on the serverside would be needed, but that is probably pretty straightforward as this is already availalbe, but in a slightly different format
[13:39] <shadeslayer> mvo_: https://lists.ubuntu.com/archives/kubuntu-devel/2014-July/008540.html
[13:41] <mvo_> shadeslayer: yeah, it will just be that the extraction needs to move to a different format it seems
[13:42] <shadeslayer> roger
[14:01] <stokachu> @pilot out
[14:38] <hallyn> apw: stgraber: what is the cleanest way to compare current kernel versions to an expected one from a script?  Is there a helper for that, or should i just parse uname -r myself?
[14:40] <Laney> bdmurray: are you going to be around for DMB later?
[14:41] <bdmurray> Laney: yes
[14:41] <Laney> okay, cheers
[14:41] <Laney> I'm trying to work out if I can be away. :)
[14:43] <apw> hallyn, nothing i know of, the tools use uname -r
[14:44] <stgraber> hallyn: I usually parse /proc/sys/kernel/osrelease
[14:51] <hallyn> ok, thx, awk it is :)
[15:07] <hallyn> slangasek: ok, so for ITP for cgmanager, assuming my last upload will be promoted for utopic, what's the right thing to do with the packaging for debian?  Do I start with a clean empty changelog, or do I keep the utopic changelog and add an entry for 0.27-1 ?
[15:08]  * hallyn goes back to testing in jessie in either case
[15:40] <slangasek> pitti: I don't have any opinion on ddebs.u.c splitting by component, except that from what I saw of the code, I'm concerned that this doesn't really make solving the problem any easier, it just moves it around a bit
[15:42] <slangasek> cyphermox_: the last laptop I know used the acpi-support wifi toggle was the T60; I don't remember if my X201 did.  I can say that at the time, the "toggling" behavior being provided by !acpi-support was suboptimal, the behavior I wanted (which acpi-support gave me) was to rotate through the antenna on/off positions rather than being a soft version of the hardware kill switch
[15:43] <slangasek> hallyn: keeping the history and adding an entry for 0.27-1 is fine
[15:43] <cyphermox_> slangasek: thanks
[15:44] <hallyn> cool, thanks
[15:44] <cyphermox_> slangasek: sound like it's not the right time to remove it then, and it probably will interact badly with urfkill for that behavior
[15:45] <slangasek> yeah, maybe
[16:02] <hallyn> hello SRU team, just a note that bug 1321365 has been verified for trusty;  could it be promoted to trusty-updates?  (i've got two new bugs to look at SRUing :( )
[16:06] <cjwatson> hallyn: done
[16:14] <hallyn> cjwatson: thanks!
[16:30] <infinity> pitti: The only problem with not splitting by component is that ddebs depend on real debs, so installing a ddeb from main probably shouldn't depend on a deb in universe and confuse people.  That said, the sort of users who use ddebs probably don't care.
[16:47] <hallyn> slangasek: working with http://people.canonical.com/~serge/cgmanager-0.27.1/cgmanager_0.27-1.dsc
[16:55] <hallyn> hm, no, there' sa problem in that
[16:58] <hallyn> stgraber: d'oh, i think i need to add a --pidfile option to cgmanager :(
[17:01] <hallyn> pitti: hi, would you ahve time today or (more likely) tomorrow to vet the systemd-shim update to work with cgmanager?
[17:09] <doko> pitti, can you give back https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-cantor/lastBuild/? ?
[17:13] <cjwatson> doko: I can.  Done (in d-jenkins, so you won't see it on jenkins.qa for a bit).
[17:14] <cjwatson> pitti: ^-
[17:15] <hallyn> stgraber: no, guess not - i'm just having weird libnih behavior.  oh well.  i may have to bug jodh :)
[17:57] <rpadovani> Saviq, xnox o/ I have a question about sbuild. It's the first time I use it and I want to create an armhf host of utopic. I use as shell zsh, and I have problem with sbuild -A -d utopic --host armhf package*.dsc
[17:57] <rpadovani> it says zsh: no matches found: package*.dsc
[17:57] <rpadovani> So I tried sbuild -A -d utopic --host armhf package\*.dsc
[17:57] <rpadovani> E: Invalid source package*.dsc
[17:58] <rpadovani> And a lot of other combinations with quotes, double quotes and backslash. Do you know if there is a way to work with zsh? Thanks :-)
[17:58] <sarnold> rpadovani: note that "package*.dsc" is just a placeholder for the actual dsc file from your package..
[18:00] <rpadovani> sarnold, mhhh I'm not sure to understand. If I want to create a click package for Ubuntu touch using a chroot and I don't want to use QtCreator, what's the way? I think I have to use sbuild, isn't it?
[18:01] <sarnold> rpadovani: sorry, no idea there :) i'm just saying that "package*.dsc" might mean "org.rpadovani.something-123.456.dsc"  or something similar :)
[18:02] <sarnold> rpadovani: run "find . -name '*dsc'" and see if you find a .dsc sitting around nicely waiting to be built :)
[18:02] <rpadovani> sarnold, ok, thanks for your information :-) I need to understand what is the package I supposed to build
[18:06] <xnox> rpadovani: sbuild is used to (a) create / manager chroots of varius debian-like releases (b) to build debian binary packages (.deb) from debian source package formats (most commonly .dsc)
[18:06] <xnox> rpadovani: clicks are neither.
[18:06] <xnox> rpadovani: maybe you want $ click chroot --help ? which uses sbuild behind the scenes, but enables to create/crosscompile native sdk clicks for i386, amd64 and armhf.
[18:07] <xnox> rpadovani: most of our "clicks" use CMake build system to compile stuff and use helper snippets and templates for the click manifest / config keys.
[18:08] <shadeslayer> could someone share some insight on https://launchpad.net/ubuntu/+source/kdbusaddons/5.0.0-0ubuntu1
[18:08] <rpadovani> xnox, aha! Thanks for the suggestion about click chroot! I'll check :-)
[18:08] <shadeslayer> the build works fine on amd64 on my local machine as well
[18:09] <hallyn> slangasek: ok, updated http://people.canonical.com/~serge/cgmanager-0.27.1/cgmanager_0.27-1.dsc , this works nicely under experimental.  Now trying under systemd just to see...
[18:11] <bdmurray> slangasek: why might Contents-armhf.gz be out of date here? http://ports.ubuntu.com/ubuntu-ports/dists/utopic/
[18:12] <bdmurray> slangasek: I'm guessing its out of date because of the liburcu1 / liburcu2 change on 7/10
[18:13] <slangasek> bdmurray: how out-of-date is out of date?  The file on pepo hasn't been updated since July 3
[18:13] <slangasek> I don't recall how frequently these are meant to be updated, though I'm reasonably sure it's not daily
[18:13] <xnox> bdmurray: well, because the creation of that file is racy and often fails on publication. Currently it has been loosing that race since 3rd of July.
[18:13] <slangasek> aha
[18:13] <xnox> slangasek: cjwatson was offering for me to poke lp to fix that =)
[18:13] <bdmurray> well that presents a problem for the apport retracers
[18:14] <slangasek> xnox: it would seem to be a very good idea if you did so
[18:14] <xnox> bdmurray: i386/amd64 ain't no better =) http://archive.ubuntu.com/ubuntu/dists/devel/
[18:14] <bdmurray> xnox: yeah, I saw that too :-(
[18:15] <xnox> slangasek: before or after i get rid of cts pinging me about plymouth 0.9.x =) ? something to do with piles of golden bricks being shipped.
[18:16] <xnox> slangasek: i haven't started poking those jobs yet, but it should be easy enough to schedule them to not nuke the in-flight contents that's getting generated.
[18:17] <slangasek> xnox: before
[18:19] <xnox> slangasek: =)))) i like you.
[18:21] <bdmurray> xnox: I'd appreciate an update with whatever happens
[18:22] <xnox> bdmurray: i should file tracking bug, if there isn't one yet.
[18:23] <bdmurray> xnox: that'd be helpful ;-)
[19:00] <bluesabre0> o/
[19:29] <cjwatson> xnox: Let me know if you need help.
[19:30] <cjwatson> xnox: See also https://bugs.launchpad.net/launchpad/+bug/1013583, in case that's useful
[19:38] <xnox> cjwatson: well there is a nice branch from mvo attached to that one =) i may review it on the side as my efforts of getting into apt / reading C++ better.
[19:39] <cjwatson> xnox: That may already be on production; not sure.  Still a matter of rejigging LP to use it.
[19:39] <xnox> ack.
[19:44] <psusi> cjwatson: I noticed the new parted package is in the NEW queue.. I though that was just for packages that were actually new?
[19:45] <xnox> psusi: new, is new in a sense of new binary packages, always.
[19:45] <xnox> psusi: e.g. libparnedN+1 is probably new.
[19:46] <xnox> psusi: libparted2* in this case are new, among others.
[20:05] <xnox> barry: do you have time to review https://code.launchpad.net/~xnox/launchpadlib/py3-new/+merge/225691 ? If not, I was planning on merging it and starting a PPA with porting effors of various key projects.
[20:05] <xnox> e.g. ubuntu-archive-tools and ubuntu-dev-tools
[20:05] <xnox> and like lptools.
[20:05] <xnox> cause i think a few more issues will be uncovered by porting those.
[20:06] <barry> xnox: i did review it, but maybe i should have also set the status to approved? ;)
[20:06] <barry> xnox: and yay!
[20:06] <xnox> barry: ah, I see.
[20:06] <xnox> barry: hm, let me "uncover the inline diff comments"
[20:06] <barry> xnox: i used the inline comment system
[20:06]  * xnox fails
[20:06] <barry> yeah
[20:07] <xnox> barry: i'm not sure what's wrong with these inline comments, somehow e.g. in github they are in yourface obvious.
[20:07] <barry> xnox: i see them when i visit the page, but maybe that's because i wrote them?
[20:07] <barry> e.g. lineno 466
[20:08] <xnox> i need to click "show inline diff comments" on the comment and then they appear.
[20:11] <stgraber> cjwatson, slangasek: e-mail to ubuntu-devel-announcement for one of you to moderate, thanks!
[20:27] <cjwatson> psusi: Right, as xnox says.  Quite normal and expected.
[20:28] <cjwatson> stgraber: done
[20:28] <cjwatson> psusi: Near the end fo the road now though. :-)
[20:28] <cjwatson> *of
[20:29] <stgraber> cjwatson: thanks
[21:39] <xnox> barry: awesome stuff. merged.
[21:43] <barry> xnox: \o/
[21:45] <xnox> barry: how about more awesome reviews of dubious re-casts of strings to strings multiple times? =) https://code.launchpad.net/~xnox/lazr.restfulclient/fixes/+merge/224945
[21:46]  * barry looks
[21:47] <xnox> barry: please don't cry =)
[21:50] <xnox> barry: i think importing HttpLib2Error as SSLHandshakeError is the peak highlight.
[21:50] <barry> xnox: yeah, i was just wondering about that one - trying to see if there are any docs on that change
[21:59] <barry> xnox: commented
[22:25] <xnox> barry: replied. but will fix up tomorrow. Time to Zzzzzz =)
[22:33] <TJ-> xnox: do you have a few minutes to discuss your mdadm bootdegraded patch for bug #1279741 ?
[23:04] <xnox> TJ-: not now, i'm in the UTC+1 timezone. Can you send me an email instead?
[23:04] <slangasek> cjwatson: 1ab7964e9fa4b495f263a036159f28140da7237b on console-setup makes me want to scream
[23:05] <TJ-> xnox: I'll open a bug report, but I was just trying to get a sense of the reasoning, since it appears to have broken booting from RAID1 degraded mirrors for several users I've supported.
[23:06] <cjwatson> slangasek: Thanks Anton
[23:06] <cjwatson> "hi, I briefly found internet in Bulgaria and here's everything I did for the last month"
[23:06] <slangasek> :/
[23:07] <slangasek> I think he meant to say high-proof reading
[23:08] <cjwatson> That was very much his MO on partman for some time
[23:14] <saiarcot895> Hi all, do are packages in ppa:openjdk-r/ppa slated to go into the main repos?
[23:16] <slangasek> bonus points for random mixing of 'elif' and 'else if' <sigh>
[23:23] <hallyn> desrt: (on the off chance that you are checking irc, but hopefully you are not :)  finally figured out one needed change to your cgm.1 systemd branch - the JobRemoved signal needs the scope name in the 3d arg and "done" in 4th.  With that, all seems good.  (Only other change I'm doing is making systemd force itself into / cgroup at startup)
[23:32] <jarreed0>  So I have an idea for the Ubuntu Touch OS. It is something I use everyday on my android. It is a tilt control setting were if my phone tilts enough to be placed in my pocket or if my android is set face down the screen will lock. If I would like this specifically and other tilt controlls, like turning auto-tilt on and off, to be implemented into the Ubuntu Touch OS how would I go about making a setting page on the status b
[23:32] <jarreed0>  lled "Tilt Controls" were I can implement these controls and other ones. Also by doing so will it have to be an app for some one to install or who would I contact to get it intergrated into the system so its built into everyones Ubuntu Touch phone. I posted this idea on the xda forums. I was told that it was an interesting idea and to try posting this here and on #ubuntu-touch
[23:34] <hallyn> desrt: updates are in github.com/hallyn/systemd-shim #cgm.2
[23:35] <hallyn> will ping pitti about it in the morning
[23:37] <xnox> cjwatson: slangasek: what's that about? =) bulgarian patches =)
[23:38] <cjwatson> xnox: console-setup
[23:39] <cjwatson> the Debian developer in question at least used to live in Bulgaria with very occasional internet access, and showed up once a month or so with a patch dump and then went away again
[23:39] <cjwatson> but that was a while ago :)
[23:39] <slangasek> yes, the justification for a garbage-dump git commit in 2013 is less clear
[23:40] <xnox> cjwatson: sounds legit =)
[23:41]  * xnox giggles at DDs arguing about matching multiple hashes and how that somehow protects the archive "better"