[00:00] <xnox> sassyn: but since 10.04 is still a support releases, you can ask a launchpad ppa to build them for you. So invoke backportpackage with a ppa argument for each and every missing dependency in 10.04
[00:00] <xnox> sassyn: and in the end the package you are after would be backported into 10.04 via that ppa.
[00:01] <xnox> sassyn: alternative is to modify the package you are after, to have less dependencies or not rely on version/features that are not available to make backporting easier.
[00:02] <sassyn> what do u mean by that  So invoke backportpackage with a ppa argument"
[00:02] <sassyn> u really helpful xnox
[00:02] <sassyn> thank u
[00:03] <xnox> sassyn: read $ man backportpackage, especially the three examples in the "EXAMPLES" section on the bottom, the third case is yours.
[00:04] <xnox> sassyn: appart you'd be fetching things just by package name and source location as done in the second example.
[00:07] <sassyn> xnox,
[00:07] <sassyn> still reading
[00:07] <xnox> sassyn: i need to go, experiment with backportpackage options, and if you get stuck again ask about on #Ubuntu-motu or #ubuntu-packaging.
[00:08] <sassyn> xnox,
[00:08] <sassyn> thank u sir!
[00:08] <sassyn> have a nice weekend
[05:16] <pitti> Good morning
[05:16] <pitti> shadeslayer: does linux-firmware-nonfree's Modaliases: field contain your device?
[07:18] <diwic> pitti, good morning, would you mind debcommit -r + upload lp:~ubuntu-audio-dev/alsa-tools/ubuntu and lp:~ubuntu-audio-dev/alsa-lib/ubuntu ?
[07:33] <pitti> diwic: can do
[07:34] <diwic> pitti, thanks :-)
[07:34] <pitti> alsa-lib uploaded
[07:35] <pitti> diwic: alsa-tools uploaded, too
[07:37]  * diwic gives pitti a big bowl of Spätzle as thank you :-)
[07:37] <pitti> haha
[08:00] <jagadeshanh> is the problem with the WiFi resolved?
[08:22] <tvoss> pitti, good morning :)
[08:22] <pitti> hey tvoss, wie gehts?
[08:22] <tvoss> pitti, hey, gut soweit :) und bei Dir?
[08:23] <pitti> tvoss: prima, danke
[09:08] <sassyn> hi all
[09:08] <sassyn> backportpackage a package failed due to unmet dependencies
[09:09] <sassyn> Running a 12.04 machine
[09:09] <sassyn> and trying to  backportpackage -b -s maverick -d precise -w . ulogd2_2.0.3-1ubuntu1.dsc
[09:34] <Sweet5hark> Moin!
[09:35] <Sweet5hark> Hi seb128, can you please review and upload http://people.canonical.com/~bjoern/trusty/libetonyek_0.0.3-0ubuntu2_source.changes ?
[09:36] <seb128> Sweetshark, sure
[09:36] <Sweet5hark> alrighty, Ill get a Coca-Cola for me. And a can for Will.
[09:37] <seb128> Riddell, ^ wants to have a look? that's a kubuntu package it seems, Sweet5hark fixed the depends
[09:46] <Riddell> seb128: Sweet5hark: looking
[09:47] <Riddell> Sweet5hark: yep, good, why's it getting a MIR?
[09:49] <Sweet5hark> Riddell, seb128: LibreOffice is in main, so I can either use libetonyek from main or make LibreOffice bring its own internal copy (its a hard dep). I prefer the first here.
[09:50] <Riddell> good good
[09:51] <seb128> Riddell, can you sponsor it if you +1? ;-)
[09:51] <seb128> thanks
[09:53] <Riddell> oh sure
[09:54] <Riddell> Sweet5hark: uploaded
[09:54] <Sweet5hark> Riddell: thanks!
[09:55] <Sweet5hark> Riddell: what uses kubuntu this for btw? calligra?
[09:57] <Laney> Riddell: (sorry for the ping flood) did you see the kubuntu image build failure? I guess you want to merge / sync the new synaptiks
[09:57] <seb128> Riddell, thanks
[10:02] <sassyn> Hi,
[10:02] <sassyn> Thanks for this.
[10:02] <sassyn> I followed this, but didn't manage to make it happen.
[10:02] <sassyn> The problem is that the pkg I need is coming from version 14.04 and i run 12.04
[10:02] <sassyn> So I dget the foo.dsc and try to build it using pbuilder, but the foo.dsc needs some other pkgs version which are no exits in the verion 12.04,
[10:02] <sassyn> so it failed.
[10:02] <sassyn> I started to download each required pkg (bar.dsc, zoo.dsc, etc...) that foo was depend on, but then got to a endless loop, since bar.dsc also wanted some pkg that where missing in the 12.04.
[10:02] <sassyn> So I play a little with the control file of the foo pkg, and got to a point where I had only 4 pkg that need to come from version 14.04 to version 12.04.
[10:02] <sassyn> I manage to build them, and also create a local repo, so the base image of pbuilder will be aware of them.
[10:02] <sassyn> Then try to build the foo.dsc and failed again.
[10:03] <sassyn> What am I'm doing wrong?
[10:03] <sassyn> It's being a week already without any sleep - and I just can't figure it out.
[10:03] <sassyn> Help will be mot welcome!
[10:03] <sassyn> Thank
[10:03] <sassyn> Sassy
[10:03] <sassyn> oppsss
[10:03] <sassyn> sorry about that :-(
[10:03] <sassyn> Group,
[10:03] <sassyn> I can't manage to backport my pkg
[10:04] <sassyn> need some help here. kind of lost - 1 week without any sleep - and I still can't get this pbuilder, cowbuilder, cowdancer and backport
[10:04] <sassyn> if someone can help it will be great!
[10:25] <Riddell> Sweet5hark: yes calligra uses it
[10:26] <Riddell> Laney: let's poke shadeslayer about that one :)
[10:26] <Laney> okay
[10:28] <Sweet5hark> Riddell: So my spidersenses were right there ... ;)
[10:36] <sassyn> Anyone?
[10:40] <pitti> sassyn: it would help if you'd mention what exactly fails when you build those (pastebin the build log or so)
[10:41] <sassyn> pitti,
[10:41] <sassyn> sure
[10:41] <pitti> sassyn: but in general you can't just lower dependencies, they are usually bumped for a reason
[10:41] <sassyn> pitti, but I think I get it somehow wrong and wanted to ask someone about the all process and not specific problem I have
[10:42] <pitti> sassyn: if you run into many dependencies that your package doesn't have in 12.04, you usually have to backport those as well, there are no easy shortcuts in general
[10:42] <pitti> it's not unlikely that your package fails to build if you lower a build dep and build it against an old library in 12.04, etc.
[10:42] <sassyn> pitti, I saw some thing call PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi"
[10:43] <sassyn> doesn't this should know to grub all dep?
[10:43] <sassyn> if so, I just don't understand how backport is working.
[10:44] <sassyn> pitti, what I did in the beining is that I install ubuntu 12.04 got the foo pkg and started to build it. then it ask for some deps that were missing, so I download them as well.
[10:45] <pitti> you already mentioned that part
[10:45] <pitti> but without details of what actually goes wrong (paste a build log), nobody can help you
[10:47] <sassyn> so in more general way, if pkg X of version 14.04 depend on Pkg Y from version 14.04, and I want to backport pkg X to version 12.04, what is the best way of doing so?
[10:47] <pitti> as you said, backport y first
[10:48] <sassyn> and what if y require Z from version 14.04?
[10:48] <pitti> wash, rinse, repeat
[10:48] <pitti> but if you require more than, say 5 packages, it's probably a lost cause
[10:48] <cjwatson> or sometimes figure out why that dependency is present and if it can be loosened; there's no general answer to this, it requires understanding and thought and sometimes creativity
[10:48] <pitti> you end up backporting half the release, and you should rather just use that release then (perhaps in a chroot)
[10:49] <sassyn> pitti understood
[10:50] <pitti> as cjwatson says, without build logs or even package names that's all we can say
[10:50] <sassyn> the pkg is ulogd2
[10:50] <sassyn> from 13.10
[10:50] <sassyn> which I manage to install on 10.04
[10:51] <Sweet5hark> pitti: "but if you require more than, say 5 packages, it's probably a lost cause" -- except if you are ricotz and heroically backport LibreOffice ...
[10:51] <pitti> heh, yes
[10:52] <sassyn> just need to download 3 orig debs from version 13.10 (which were installed by dpkg -i *) and then build 5 dep pakcages which in all of them i had to change the compact to use version 7 as I wanted to keep debhelp
[10:54] <sassyn> I'm lost :-(
[10:55] <sassyn> I was sure ppa will do this auto
[10:56] <cjwatson> PPAs only work at the level of individual source packages; they won't automatically figure out that they need to build additional things to satisfy your build-dependencies (although of course they will install any build-dependencies that are already available), and they won't automatically make any necessary modifications to your source package
[10:57] <cjwatson> they're a good way to avoid having to maintain the build infrastructure yourself
[10:57] <cjwatson> but they aren't artificially intelligent
[10:57] <sassyn> cjwatson, please can u tell me how
[10:58] <sassyn> i think i will drink some postion
[10:58] <sassyn> cause I totlay lost here
[10:58] <sassyn> I don't want to go manually for each verion
[10:58] <sassyn> there is no magic way?
[10:58] <cjwatson> backporting from 13.10 to 10.04 is bound to be very difficult; if nothing else the addition of multiarch between 10.04 and 12.04 meant a large number of changes to a large number of library packages
[10:58] <cjwatson> there is no magic way
[10:59] <cjwatson> if you find yourself needing to undo multiarch changes to a package, you can try reversing the steps in https://wiki.debian.org/Multiarch/Implementation
[10:59] <cjwatson> but if you're not already familiar with packaging it isn't going to be straightforward
[10:59] <cjwatson> if I were you I would certainly be considering whether it would be easier to upgrade to 12.04
[11:00] <sassyn> so backport will only work for a pkg from a new version only if the meet the depnedecies chain
[11:01] <cjwatson> right, that's inevitable
[11:01] <cjwatson> either you satisfy the dependencies or figure out how to weaken them
[11:01] <sassyn> or that I can backport each one of them
[11:01] <cjwatson> I'm including that in "satisfy"
[11:02] <cjwatson> which build-dependencies of ulogd2 aren't satisfied in lucid already?
[11:02] <sassyn> debhelper for example
[11:02] <cjwatson> well, debhelper (>= 9)
[11:02] <sassyn> manually change this to 7
[11:02] <sassyn> did work
[11:03] <sassyn> but I needed to have some extra pkg as well
[11:04] <cjwatson> you can probably get away with 7 without too much trouble, yes.  what are the other packages involved?
[11:05] <cjwatson> (7> in this specific case, I mean, since there are no library packages here)
[11:06] <sassyn>  DIST=precise ARCH=i386 pbuilder  build ulogd2_2.0.3-1ubuntu1.dsc
[11:06] <sassyn>  running this
[11:06] <sassyn> give me
[11:06] <sassyn> dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
[11:08] <sassyn> what does it mean?
[11:08] <cjwatson> looks to me like the genuine missing build-deps here are dh-autoreconf, libnfnetlink-dev (lucid has 1.0.0-1 but you need >= 1.0.1), libmnl-dev, libnetfilter-acct-dev, libnetfilter-conntrack-dev (lucid has 0.0.101-1 but you need >= 1.0.2), libdbi-dev, and dh-systemd
[11:09] <cjwatson> oh, you said precise, not lucid
[11:09] <sassyn> my mistake
[11:09] <cjwatson> why is debhelper (>= 9) a problem then?  precise has debhelper 9.20120115ubuntu3
[11:09] <sassyn> i meat precise
[11:09] <cjwatson> and in that case all my comments about multiarch above are irrelevant
[11:10] <cjwatson> so you're just missing libnfnetlink-dev (>= 1.0.1), libnetfilter-acct-dev, libnetfilter-conntrack-dev (>= 1.0.2), and dh-systemd
[11:11] <cjwatson> dh-systemd is easy - just drop that from Build-Depends and change "dh $@ --with autoreconf,systemd" in debian/rules to "dh $@ --with autoreconf"
[11:11] <sassyn> OK
[11:12] <sassyn> and them what? I will be still missing the libnfnetlink-dev (>= 1.0.1), libnetfilter-acct-dev, libnetfilter-conntrack-dev (>= 1.0.2)
[11:12] <sassyn> so then I will need to make the same for libnfnetlink-dev etc...
[11:12] <cjwatson> The build-essential:native thing above is spurious.  Either pbuilder is entirely broken for building on precise, or it's just giving you unhelpful output
[11:12] <sassyn> once I will have them all
[11:12] <cjwatson> I don't use pbuilder (I much prefer sbuild), so I can't help with that
[11:13] <cjwatson> Right, you'll need to backport all of libnfnetlink, libnetfilter-acct, and libnetfilter-conntrack; those build-deps seem to be real
[11:13] <cjwatson> libnfnetlink should be trivial
[11:14] <cjwatson> Indeed so should libnetfilter-acct and libnetfilter-conntrack; all their build-deps are already satisfied
[11:14] <sassyn> so once I do that, I should link my  build machine to the local repo which have libnfnetlink-dev etc.. build
[11:14] <cjwatson> Right
[11:15] <sassyn> so then go and try to build ulogd2
[11:15] <cjwatson> Or just upload these to a PPA if you're having trouble with pbuilder
[11:15] <sassyn> PPA is also new to me
[11:15] <sassyn> never used it
[11:15] <sassyn> will it be easy?
[11:16] <cjwatson> It's pretty straightforward
[11:16] <cjwatson> Start by creating a PPA for this at https://launchpad.net/~
[11:16] <sassyn> so I just upload my pkg to ppa, say the libnfnetlink-dev and the ppa will "know" to link to my ppa local repo auto?
[11:17] <sassyn> then go head and do the same for all the rest?
[11:17] <sassyn> until ending with ulog2?
[11:17] <cjwatson> Then you can do the first step with "backportpackage -u ppa:YOURLAUNCHPADUSERNAME/NAME-OF-PPA -s saucy -d precise libnfnetlink"
[11:17] <cjwatson> I don't know what you mean by linking to your ppa local repo
[11:17] <cjwatson> The PPA will build against the Ubuntu primary archive for the series in question (precise in this case) plus itself
[11:18] <cjwatson> (Unless configured otherwise, which is possible, but you shouldn't need to here)
[11:18] <sassyn> HOOO ok
[11:18] <sassyn> so I just need to do it in the right order
[11:18] <sassyn> running libnfnetlink before ulogd2
[11:19] <cjwatson> Right, and you'll need to construct a manual source upload for ulogd2 itself because you'll need to remove the dh-systemd build-dep
[11:19] <cjwatson> https://help.launchpad.net/Packaging/PPA
[11:19] <cjwatson> It's certainly possible to do all this locally too, it's just more effort
[11:20] <sassyn> cjwatson, u are great ! thank u !
[11:21] <sassyn> cjwatson, one more thing, if the libnfnetlink will require to have some pkg as well which only exitis in  saucy
[11:22] <sassyn> and I faillet's call it pkg M
[11:22] <sassyn> and build package M is a problem cause I will get to endless loop of other dep
[11:22] <sassyn> the way I overcome this was just download the *.deb file and install it on my local machine via dpkf -i m.deb
[11:23] <sassyn> how can I over come this in ppa?
[11:27] <cjwatson> sassyn: well, I already checked and that isn't the case for any of these
[11:27] <cjwatson> sassyn: you can't; you have to figure out how to build it
[11:28] <cjwatson> sassyn: it wouldn't actually be an endless loop anyway.  just requires creativity to figure out where to simplify things
[11:30] <sassyn> cjwatson, here what I did create a based image for precise using pbuilder. download the  init-system-helpers_1.7 pkg and build it using pbuilder . this one works. now I enable a local repo so the base image will have the  init-system-helpers_1.7 pkg using apt-get. now if I will run the build for ulog2 this is what I'm getting dh clean --with autoreconf,systemd
[11:30] <sassyn> dh: unable to load addon systemd: Can't locate Debian/Debhelper/Sequence/systemd.pm
[11:30] <cjwatson> 11:11 <cjwatson> dh-systemd is easy - just drop that from Build-Depends and change "dh $@ --with autoreconf,systemd" in debian/rules to "dh $@ --with autoreconf"
[11:31] <cjwatson> You were mistaken in attempting to resolve this by building init-system-helpers
[11:31] <sassyn> understand this, but why the base image didn't install this pkg which is avlibaile
[11:31] <cjwatson> Maybe it did but your backport was broken in some way
[11:32] <cjwatson> I don't think it's necessarily interesting to debug that since it isn't the right approach for backporting to precise anyway, IMO
[11:33] <sassyn> so what will be the right way?
[11:35] <pitti> sassyn: cjwatson told you twice now, see message from 5 mins ago
[11:43] <tseliot> pitti: is there documentation (or are there examples) on how to make sure that apport collects a set of files when filing a bug report against a specific package?
[11:44] <pitti> tseliot: both :) /usr/share/doc/apport/package-hooks.txt.gz is the documentation, and there are plenty of existing hooks in /usr/share/apport/package-hooks/ which do that
[11:44] <tseliot> pitti: great, thanks!
[11:47] <tvoss> davmor2, hey there
[12:07] <davmor2> tvoss|lunch: hello
[12:48] <pitti> tvoss|lunch: thanks, fixed the typo
[13:20] <tvoss|lunch> pitti, approved https://code.launchpad.net/~pitti/platform-api/crash-without-hw/+merge/204838
[13:30] <pitti> tvoss|lunch: cheers!
[13:30] <pitti> didrocks, sil2100 ^ what's the method du jour to land that now? still add to the spreadsheet?
[13:31] <sil2100> pitti: hah, yes, but a different one
[13:31] <sil2100> pitti: there's that CITrain spreadsheet where you should add landings - but I think you'll be trained on that next week ;)
[13:31] <pitti> sil2100: there's a fix for qtubuntu-sensors on top of that, but I guess I'll ask for that separately as in that branch I'd like to bump the dep to platform-api to the one I want to land now
[13:32] <sil2100> pitti: for now just poke sergiusens, he can fill in landings for that
[13:32] <pitti> sil2100: ok; would you mind adding https://code.launchpad.net/~pitti/platform-api/crash-without-hw/+merge/204838 there? it's a self-contained bug fix, no other dependencies
[13:32] <pitti> sil2100: thanks
[13:32] <pitti> sergiusens: can you please add https://code.launchpad.net/~pitti/platform-api/crash-without-hw/+merge/204838 there? it's a self-contained bug fix, no other dependencies
[13:33] <sergiusens> pitti, ack
[13:33] <pitti> sergiusens: "there" -> to the landing sheet
[13:33] <pitti> sergiusens: thanks
[13:33] <pitti> sergiusens: shoudl I top-approve that MP, or will you?
[13:34] <sergiusens> pitti, either is fine; you can do it now if you want; it won't get merged until it's in the archive
[13:34] <pitti> sergiusens: ack; done so that it falls off the review queue
[13:36] <pitti> sergiusens: and FTR, I tested it on mako and x86
[13:39] <sergiusens> pitti, sounds good
[13:54] <pete-woods> Trevinho: I'm really struggling to replicate this HUD bug
[13:55] <pete-woods> I've tried sublimetext 2 and 3
[13:55] <pete-woods> and opened .pl files in-case that perl action was significnt
[13:55] <pete-woods> Trevinho: are there plug-ins for the program? or some options you can turn on that enable more menus?
[14:06] <tvoss> sil2100, hey there
[14:18] <mpt> bdmurray, ev: Does this look good to you? https://launchpadlibrarian.net/165304593/Series%20colors.png
[14:32] <NikTh> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1277502
[14:32] <NikTh> Is this bug accurate ? And why something like this could be happened ?
[14:33] <Trevinho> pete-woods: oh, sorry missed your mentions...
[14:33] <pete-woods> Trevinho: no worrie
[14:33] <pete-woods> s
[14:33] <Trevinho> pete-woods: no sure, I'm just using sublime-text2 with some plugins...
[14:33] <Trevinho> but no one should be much relevant afaik
[14:33] <pete-woods> Trevinho: I'm desperate, though!
[14:34] <Trevinho> pete-woods: have you seen my bt? Is helpful in someway or do you need dbus monitoring stuffo or what?
[14:34] <pete-woods> Trevinho: it's helpful, but I really need to see what causes it
[14:35] <pete-woods> Trevinho: what's weird is that the stack would be stuck there, I mean, on that line it's just accessing a Qt property (i.e. get a QVariant)
[14:35] <pete-woods> there shouldn't be anything that could block
[14:35] <Trevinho> pete-woods: might be that it iterates over bad designed list of children/parents?
[14:35] <rbasak> NikTh: I don't think the reporter of that bug understands Ubuntu development process. AFAICS, there is no bug. See http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and https://wiki.ubuntu.com/ProposedMigration.
[14:36] <pete-woods> Trevinho: it has to be something along those lines
[14:36] <pete-woods> but still, why would it stop on the get variant call?
[14:36] <davmor2> tvoss: Hey dude so I managed to find the debs for that merge, I currently have 8 apps open on mako, all the apps are drawing correctly on dash and are all switching nicely and there is little slow down on the phone.  I'll open a few more and see if I can kill it
[14:37] <pete-woods> Trevinho: like here: http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.14.04/view/head:/libqtgmenu/internal/QtGMenuModel.cpp#L428
[14:37] <pete-woods> could there be something massive in the variant someone?
[14:37] <Trevinho> pete-woods: mh, I didn't check the actual code much (yet), I only saw it was iterating over actions... So I thought it might not handle the loop as it should
[14:38] <davmor2> tvoss: drawing the thumbnails is slow is that only thing I've noticed so far
[14:38] <pete-woods> *somehow
[14:40] <tvoss> davmor2, thanks for looking into it
[14:41] <davmor2> ogra_: how many apps could you install on mako before it started to die?
[14:41] <ogra_> install ?
[14:41] <davmor2> ogra_: sorry run rather than install
[14:41] <ogra_> i never managed to hit the edge
[14:41] <ogra_> davmor2, 6-7
[14:42] <davmor2> ogra_, tvoss: I'm getting close to 20 and the system is still pretty snappy although it is slowing slightly
[14:42] <ogra_> yay
[14:42] <ogra_> so that part imroved
[14:42] <ogra_> davmor2, could you rm /SWAP.swp, reboot and try again ?
[14:44] <Trevinho> pete-woods: no idea... Mh... The only thing might happen is that basically a children is actually also a parent of a child... and so we get an infinite loop
[14:44] <pete-woods> Trevinho: yes, that is possible I think, and should be accounted for, but surely that would lead to a huge stack?
[14:44] <pete-woods> given we're using recursion
[14:46] <Trevinho> yeah, that's true
[14:47] <NikTh> rbasak: Thanks for clarifying this.
[14:52] <mdeslaur> is there a retracer running for trusty bugs?
[14:52] <mdeslaur> looks like it's not being run
[14:53] <mdeslaur> bdmurray: any idea who I would ping about the trusty retracer?
[15:03] <davmor2> ogra_, tvoss: right with 21 apps open including webapps and the camera, 3 apps in the dash layout look blank but they open fine and can be switched to with no issues. memory wise on the dash I'm at 1070 of 1871 swp is 0 I will however now rm /SWAP.swp and try that too
[15:03] <tvoss> davmor2, thanks, can you take a sample of the shells memory usage?
[15:03] <doko> Sweet5hark, we now require symbols files for main inclusion
[15:05] <davmor2> tvoss: sorry do you mean with all that apps closed as a comparison?  If so I'll remove swap and reboot and it will be nice and clean :)
[15:06] <tvoss> davmor2, nope, right now when the previews go blank
[15:07] <davmor2> ogra_: rm cannot remove "/SWAP.swp"  no such file
[15:08] <davmor2> tvoss: so under htop unity8 is showing at 0.7% cpu and 22.7% mem
[15:09] <davmor2> tvoss: there is however several listings of unity8
[15:09] <tvoss> davmor2, those are threads, try to switch to tree view in htop
[15:11] <davmor2> tvoss: yeap all good so the figures stand :)  0.7 and 22.7
[15:11] <tvoss> davmor2, ack and thx
[15:14] <bdmurray> mpt: looks good to me, if you submit an mp I'll merge it later today
[15:14] <bdmurray> mdeslaur: for the launchpad one pitti or seb128
[15:14] <davmor2> tvoss: interestingly it seems to be the position rather than the apps that is blank 3 row 1 column and 4 row 1&2 column  all the rest appear correct but if I click on one of the blank app it goes to row 1 column1 and is visible and the one that is push to 3:1 is no blank
[15:15] <mdeslaur> bdmurray: thanks!
[15:15] <mdeslaur> seb128: any idea why the trusty retracer isn't running?
[15:15] <bdmurray> mpt: ah, I see your mp now.  so I'll merge that and the milestones one
[15:16] <seb128> mdeslaur, let me check
[15:17] <ogra_> davmor2, hmm, try /userdata/SWAP.*
[15:17] <davmor2> tvoss: http://ubuntuone.com/7my6xiriTiIEQBPxNw9O6D
[15:18] <davmor2> tvoss: it's only ever those 3 that are empty
[15:21] <davmor2> ogra_: rm: cannot remove '/userdata/SWAP.img': Operation not permitted
[15:21] <ogra_> davmor2, hmm, you might need to swapoff
[15:22] <davmor2> ogra_: that did it
[15:23] <tvoss> pitti, hey there
[15:23] <pitti> hello tvoss
[15:24] <mpt> thanks bdmurray
[15:25] <davmor2> ogra_: right htop now says swap 0/0MB  and now you want me to open apps galore again yes?
[15:26] <ogra_> yeah
[15:26] <ogra_> lets see how far you get
[15:26] <davmor2> ogra_: on it
[15:31] <davmor2> ogra_: I'm going to run out of installed apps
[15:31] <ogra_> lol
[15:31] <ogra_> how many do you have open
[15:31] <davmor2> ogra_: let me finisgh the installed apps and I'll tell you
[15:34] <davmor2> ogra_: 30 open apps, htop says 1181/1871MB on the memory line
[15:34] <ogra_> oh, well, that means it would get tricky to open some mem consuming stuff indie an app i guess
[15:35] <ogra_> *inside
[15:35] <pitti> mdeslaur: should be running just fine
[15:35] <pitti> seb128: ^
[15:35] <ogra_> try playing some music now and see if the apps still persist if you flick through them
[15:35] <davmor2> ogra_: and other than the draw on the thumbnails the phone is still pretty snappy :)
[15:35] <ogra_> (this looks like quite a hardcode stresstest :) )
[15:37] <davmor2> ogra_: just taken a bunch of photos and the memory usage has gone down, switch to dropping letters and it's lower still
[15:37] <ogra_> great
[15:37] <ogra_> well, Mir must have killed one or more apps that are bakgrounded
[15:37] <seb128> pitti, what in the backlog?
[15:38] <ogra_> you should see one that takes a bit longer to show up when you flick through
[15:38] <davmor2> ogra_: I'm assuming the extra is just holding memory for the images on that dash as it redraws each time I leave and app
[15:38] <sarnold> pitti: see e.g. https://bugs.launchpad.net/ubuntu/+source/vidalia/+bug/1276921 or https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1277197
[15:38] <davmor2> tvoss: ^
[15:38] <seb128> pitti, oh, trusty retracers
[15:38] <seb128> pitti, did you restart them?
[15:38] <seb128> or are they running?
[15:38] <pitti> seb128: no, they didn't crash in the first place
[15:38] <seb128> k
[15:38] <seb128> mdeslaur, do you have a bug number example?
[15:38] <seb128> oh what sarnold just said I guess
[15:39] <pitti> these two aren't in the logs
[15:39] <ogra_> davmor2, no, unity/Mir are supposed to keep the apps there but in SIGSTOP state ... if the memory pressure gets to high it starts killing them (but will start them afresh if you flick to a killed app)
[15:39] <seb128> I don't have access to those
[15:39] <davmor2> ogra_: with dropping letters open I'm down to 1083/1871MB
[15:39] <mdeslaur> seb128: yeah, hold on there are a couple of public ones
[15:39] <mdeslaur> seb128: 1275679
[15:40] <ogra_> davmor2, you should actually see one or more apps take a bit longer to show the UI (because they need to start from scratch)
[15:40] <davmor2> ogra_: seems to be working then :)
[15:40] <pitti> ERROR: connecting to Launchpad failed: unclosed token: line 20413, column 14
[15:40] <ogra_> what is important is that they still start fine ... and that the thumbnails stay around (and that the labels are correct fr the matching thumbnails)
[15:40] <pitti> mdeslaur, seb128 ^ ah, that's it
[15:41] <pitti> launchpadlib or LP itself going nuts
[15:41] <mdeslaur> pitti: whoops :)
[15:41] <ogra_> davmor2, if thats given i think we can call this test successfull
[15:41] <ogra_> :)
[15:41]  * pitti deletes the lplib cache
[15:42] <pitti> 87G.launchpadlib/api.launchpad.net/cache/
[15:42] <pitti> ouch! I guess launchpadlib doesn't have any cleanup code
[15:42] <mdeslaur> ouch!
[15:43] <davmor2> ogra_: so the blank ones are the shutdown apps by the look of it.  And they take an extra second to open back up when you swipe through the apps from the right
[15:43] <ogra_> yeah
[15:43] <ogra_> that should be fixed if click gets faster
[15:43] <cjwatson> when
[15:44] <cjwatson> :-)
[15:44] <ogra_> :)
[15:44] <ogra_> davmor2, in any case thats an awesome result !!!!
[15:44] <ogra_> and way better than what i saw last time when trying the same
[15:44] <cjwatson> but I have an n-way hydra madness customer bug to fix before I get back to that, and you probably want me to make some progress on the livefs/LP bug too
[15:44] <cjwatson> s/bug too/support too/
[15:44] <davmor2> cjwatson: and his leprechaun pot of optimism ;)
[15:45] <cjwatson> (when did you last see a six-foot-tall leprechaun?)
[15:45] <davmor2> tvoss: did you want me to comment on the merge?
[15:46] <davmor2> cjwatson: I didn't say you were, I said you had a leprechaun pot of optimism.  Gold didn't sound right for this instance :)
[15:47] <davmor2> cjwatson: also last Saint Patricks day all over the Country :D
[15:52] <cjwatson> davmor2: *shudder*
[15:54] <rharper> hallyn: it's been a few weeks, but I finally have an update to test-qemu.py that passes all 22 tests on: precise, quantal, raring, saucy and trusty,   there is a decent amount of churn in the script since a lot of failures were false positives with the test framework (ssh timeouts into the guest, guest image corruption, etc.)
[15:54] <rharper> hallyn: lp:~raharper/qa-regression-testing/scripts-test-qemu-fixups-v2
[15:56] <rharper> in some cases we still see random failure in the nic test, or one of the hotplug tests; but running them manually, or isolated, it passes just fine.  This is related to the harness, IMO, tcg on older releases likely has some issues that newer qemus have resolved, I've not seen any variance in the trusty qemu for these tests over the past month of hacking on this script
[15:59] <pitti> seb128, mdeslaur: it's catching up now
[15:59] <mdeslaur> thanks pitti!
[15:59] <sarnold> thanks pitti
[16:01] <davmor2> cjwatson: shhhh it might ruin the illusion but I think they might of been beer drinking 6ft leprechauns :)
[16:02] <tvoss> davmor2, your manual testing feedback would be helpful
[16:03] <davmor2> tvoss: no worries
[16:09] <seb128> pitti, thanks
[16:10] <davmor2> tvoss: Done
[16:10] <tvoss> davidcalle, thanks
[16:41] <infinity> jodh: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1277594
[16:42] <jodh> infinity: thanks
[16:43] <infinity> jodh: I imagine, other than the "document the new option" bit, it's a 2-line patch or so. :)
[16:43] <infinity> Well, and the bikeshedding over what to call the new option.  Maybe just "--sessions"?
[16:44] <infinity> As that's the logical inverse of --no-sessions
[16:44] <jodh> infinity: except that we also have --session just to be confusing :)
[16:44] <infinity> jodh: Hah.
[16:45] <infinity> jodh: I do question the choice to not prefix all of those options with --upstart or --init, too.  Extra confusing to me to sort out why bits of my kernel cmdline aren't for my kernel or initrd.
[16:45] <infinity> jodh: But way too late to go back and bikeshed that one. :P
[16:46] <xnox> infinity: jodh: is that about chroot sessions? i thought the plan to rip that out post trusty.
[16:47] <xnox> infinity: jodh: flipping the default the other way around also sounds reasonable to me.
[16:47] <infinity> xnox: I don't care if the code is ripped out, I just want the default changed.  The errors thrown are remarkably surprising to people who don't know what's going on (and annoying to people who do).
[16:48] <xnox> infinity: so a flag to do inverse naturally should be --no-sessions=false
[16:48] <infinity> *choke*
[16:48] <xnox> ;-) and the default is --no-sessions[=true]
[16:48] <infinity> --maybe-sessions=surpriseme
[16:50] <infinity> Oh dear, it's annual fire alarm testing day at my apartment building.  I might not be sane by EOD.
[17:14] <Laney> is Conflicts/Replaces enough to make update-manager happy to remove a package?
[17:15] <cjwatson> Laney: yes
[17:15] <Laney> merci
[17:39] <sassyn> xnox, hi
[17:56] <cjwatson> doko: do you think you could look at a ruby1.9.1 merge?  you're til; looks like it's needed to stop ruby-defaults breaking the world in -proposed
[17:56] <cjwatson> (well, the rubyish world)
[17:57] <doko> cjwatson, ok, not today anymore. will look at it tomorrow
[17:57]  * cjwatson nods
[17:57] <cjwatson> thanks
[18:00]  * infinity blinks at gnome-settings-daemon producing a _all.deb on i386 and _arch.deb on all the others.
[18:01] <infinity> xnox: What did you DO?
[18:02] <infinity> Oh, maybe it's the queue that's confused.
[18:02] <infinity> Very, very confused. :P
[18:03] <infinity> Or it's me.
[18:03] <infinity> Nevermind.
[18:07] <xnox> infinity: i had a sad day with gnome-settings-daemon, getting trolled by germans and french from desktop team did not help with concentration levels.
[18:07] <xnox> infinity: it should be _fine_ now.
[18:07] <xnox> infinity: i got the upstart jobs right, just nothing else.
[18:08] <infinity> xnox: Yeah, it's fine. I was confused by two different versions in the NEW queue.  My poor brain thought it was all the same version and was super confused. :P
[18:26] <sassyn> cjwatson,
[18:26] <sassyn> hi again
[18:27] <sassyn> at the end I manage to make it work
[18:27] <sassyn> with pbuilder
[18:27] <sassyn> the only thing I still don't understand is the dep issue.
[18:31] <sassyn> I will ask again, if I want to build a package name foo that exitst in ubuntu 14.04. So I have build a base image of 10.04 using pbuilder or ppa, and start the build process. The build map the base image, and check for deps.
[18:32] <sassyn> if all deps are OK, pkg build just fine. If however some dep can't be found (let's called it pkg bar), as it include only in version 14.04 - I need to download it as well, and build it under the base image.
[18:33] <sassyn> if bar also requires other dep I do the same until the end of the loop.
[18:33] <sassyn> I might need to build the entire system, which will be easyier to upgrade to 14.04, but let say once I download bar I'm OK.
[18:34] <sassyn> so bar was build, and I put it in a local repo, where the base image of 10.04 is sync to , and now starting to build the foo pkg. and foo now was created succesffuly
[18:34] <sassyn> I needed to play a little with the control and compat file since I'm using debhelp 7 and not 9 .
[18:35] <sassyn> If I try to update debhelp, I ended up with bascily upgrading a lot of pkg. So i just use 7 under the contol file to make it easier.
[18:35] <sassyn> and walla, I have the pkgs up in place.
[18:36] <sassyn> my question if this process it the way to go, or if there is onther magic way which be simpler.
[18:36] <sassyn> I was thinking that the dep process can be auto without me need to get involve
[18:36] <sassyn> at least that I was thinkg the backport command is doing
[18:37] <sassyn> so I will be thankfull if someone can drop me a comment here
[18:37] <sassyn> thank u
[18:39] <tarpman> sassyn: AFAICT you're doing it right, backportpackage only automates no-change backports, packaging changes (e.g. debhelper compat, dependency versions) have to be done manually
[18:39] <tarpman> sassyn: although FWIW I have seen a couple of PPAs where dh 9 was backported to lucid... can't remember where
[18:42] <hallyn> jibel: hi, I'm trying out https://wiki.ubuntu.com/QATeam/UpgradeTestingSetup on trusty, but bin/auto-upgrade-tester is python3, and python3 doesn't seem to have a distro_info package
[19:01] <bdmurray> pitti: why does apport retrace sometimes fail with "E: Ignore unavailable version '0.9.8.0-1ubuntu5' of package 'network-manager-applet'"?  The version of the package does exist its just in the release pocket and not -updates.
[19:03] <bdmurray> pitti: I mention -updates because that is enabled in the retracer sources.list file
[19:18] <sassyn> tarpman, thank u
[19:22] <Chipaca> hey all. Is there an easy way to tell dh to skip installing a file? the build builds it, but i don't want to ship it in the binary package
[19:25] <Chipaca> wait. why am i specifying --fail-missing
[19:25]  * Chipaca deskfaces
[20:07] <Noskcaj> Can someone please test build openimageio on ppc from debian? If it builds we can sync
[20:07] <psusi> so dpkg says no package owns /etc/fstab... so where does it come from?
[20:11] <xnox> psusi: installer generates it.
[20:11] <xnox> psusi: it's a config file, not a conffile.
[20:12] <psusi> weird...
[20:13] <xnox> psusi: /lib/init/fstab is owned by mountall and defines default things.
[20:13] <xnox> psusi: and i majority of cases one doesn't need an fstab at all.
[20:15] <psusi> xnox: sure, but one is provided and has some comments in it.. I'm looking at an old bug report that the comments are wrong and need updated... so I was wondering where the heck the file actually comes from
[20:15] <tedg> xnox, So it's appearing that if an Upstart job's execution is short enough it doesn't ever emit a "started" event.  Is that expected?
[20:26] <tedg> Looks like it never hits "running" — starting → security → pre-start → spawned → post-start → stopping → killed → post-stop → waiting
[20:32] <infinity> Noskcaj: I'll give it a shot.
[20:33] <infinity> Noskcaj: Also, that new cogl upstream you pointed me at looks like it was generated with a broken libtool.  Would be nice to hunt down where that came from and make sure that distro isn't still shipping such breakage.
[20:36] <Noskcaj> infinity, thanks.
[20:57] <infinity> Noskcaj: Unsurprisingly, the new openimageio still has the same issue.  I'll re-merge.
[20:57] <Noskcaj> ok, thanks
[22:37] <xnox> tedg: do you have a reproducible test case we can add to the test-suite?
[22:37] <tedg> xnox, Working on it.  It seems to be whether the post-start job takes longer than the main job.
[22:38] <tedg> Trying to verify that.
[22:38] <xnox> tedg: spawned -> stopping is plausible, but then post-start shouldn't be reached. Not so long ago, we did change some state transitions around there.
[22:39] <tedg> xnox, Here's what I'm getting, no running.  starting → security → pre-start → spawned → post-start → stopping → killed → post-stop → waiting
[22:39] <xnox> tedg: oh and i don't think we emit started, if the goal is changed to stopping mid-way.
[22:39] <xnox> (or e.g. stop on condition gets satisfied)
[22:40] <tedg> Hmm, that's what I'm seeing.  Do you think that's on purpose or a bug?
[22:41] <tedg> Really it did start, and run, it seems like started should have been emitted.
[22:41] <xnox> tedg: i need to see a test-case and/or code logs where you see above.
[22:41] <xnox> tedg: you are experiencing it, so pass on the know-how ;-)
[22:42] <xnox> (preferably in a bug report, just finished watching Sochi)
[22:42] <tedg> Yeah, okay.  I think I've got enough for a bug report now.
[22:42] <tedg> Ah, don't tell me.  We're not allowed to know here yet until Prime Time.
[22:42] <tedg> I'm curious if they could, perhaps, have fireworks.
[22:42] <tedg> :-)
[22:43] <xnox> tedg: i didn't get to see all of it, but it is indeed marvelous.
[22:46] <tedg> xnox, Okay, logged bug 1277737
[22:46] <xnox> tedg: why manual?
[22:46] <tedg> Oh, I usually do that for test jobs... just in case :-)
[22:47] <tedg> Works the same without.
[22:48] <xnox> tedg: that's normal.
[22:49] <xnox> tedg: if you really wish for started event to be emitted, it should be declared as a "task"
[22:49] <xnox> tedg: since main process died, before post-start was complete. And "started" is only emitted if post-start is complete and the main process is still alive.
[22:50] <tedg> xnox, Adding a "task" has the same behavior
[22:50] <tedg> I guess perhaps I should be using "spawned"
[22:50] <xnox> tedg: yeah, that's odd. Probably  a bug in a state transition.
[22:51] <tedg> I don't really care about the pre-start script
[22:51] <xnox> tedg: you shouldn't be using spawned... as that's racy =/
[22:52] <tedg> xnox, racy for what?  I just want to know when there's a PID.
[22:52] <xnox> tedg: the whole job is superflicious.
[22:53] <xnox> tedg: it should be just a single script "script sleep 5; sleep 10; end script"
[22:53] <xnox> tedg: do you have a real example where you are doing this? there is a lot of things that one can cruft, which make no sense.
[22:53] <tedg> Sure, it's a demo.
[22:53] <xnox> tedg: what's the real-world usecase ?
[22:54] <tedg> The case I'm seeing it is in the security confinement tests.
[22:54] <tedg> They test to ensure that the started applications are confined.  But they do so rather quicly.
[22:54] <xnox> tedg: i agree it's a bug, but if it's not a realistic configuration / bad job file we at times don't support this.
[22:54] <tedg> So they're failing.
[22:54] <xnox> tedg: can you point me to them?
[22:55] <tedg> xnox, https://wiki.ubuntu.com/Touch/Testing#Running_Security_tests
[22:55] <xnox> tedg: it sounds like racy test-suites. You should be leaving the main process for long enough to inspect it =)
[22:55] <tedg> It inspects the output as the task writes a file.
[22:55] <tedg> The problem is that the application launching code is waiting until the task is started.
[22:55] <xnox> tedg: one shouldn't do that, as that can be cached and not flushed....
[22:56] <xnox> tedg: one should watch for _both_ started and killed. Cause a buggy app can crash on startup, and thus started will not be emitted if it fails to spawn.
[22:56] <tedg> You're welcome to patch the test suite, but I want to solve this race so my code can land first :-)
[22:56] <tedg> We are watching started and killed.
[22:56] <tedg> The problem is that it's stopping without error.
[22:57] <tedg> So we're not flagging that.
[22:57] <xnox> tedg: your code land first => well let me invoke bus factor =)...........  I'm way past my EOW =))))) i'm up for trolling on irc, but i'm not up for writting code ;-)
[22:58] <tedg> Heh
[22:58] <xnox> tedg: i got over-trolled by desktop team today in the office, i want to pay it forward ;-)
[22:58] <tedg> xnox, Teach you to go into the office ;-)
[23:00] <tedg> Okay, need to do dinner.  I'll have to fix this later.
[23:01] <tedg> xnox, Thanks for the pointers!