=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
[02:19] <hallyn> pitti: oh, pls.  systemd-shim sets autoremove on login directories.  that breaks running the cgmangaer tests without moving yourself out of login directory :)  it'll definately be better to get StopSession+Abandon working from systemd-shim, and not set autoremove
[02:21]  * hallyn wonders whether desrt is back
=== diskzokej is now known as lubko
=== timrc is now known as timrc-afk
[04:17] <pitti> Good morning
[04:17] <pitti> hallyn: yes, I was talking to desrt yesterday
[04:17] <pitti> hallyn: what is "autoremove on login directories"?
[04:31] <pitti> hallyn: do you know about the status of reuploading cgmanager to Debian?
[04:35] <Unit193> It's on mentors, as of "today"
[04:35] <hallyn> pitti: systemd-shim sets RemoveOnEmpty, so that after all tasks in a cgroup and all child cgroups disappear, the cgroup dir is removed
[04:36] <hallyn> pitti: cgmangaer should be uploaded tomorrow i'm hoping
[04:38]  * hallyn out
[04:41] <pitti> hallyn: ah, thanks
[05:05] <pitti> sergiusens: do you plan to merge https://merges.ubuntu.com/t/telepathy-mission-control-5/, or want me (or someone else) to steal? (needed for upower transition)
[05:09] <sergiusens> pitti: I never knew I was supposed to; in any case I can't upload so feel free to do it (my stuff was apparmor related that jdstrand promoted)
[05:10] <pitti> sergiusens: right, you were the last uploader, so by default you are the merger
[05:10] <pitti> sergiusens: ack, thanks
[05:11] <sergiusens> pitti: am I supposed to get an email about this? I don't want to block people in the future :-)
[05:11] <pitti> sergiusens: no email; they are on https://merges.ubuntu.com/main.html
[05:11] <pitti> sergiusens: (and /universe.html, etc.)
[05:11] <sergiusens> gt it
[05:11] <sergiusens> thanks
[05:36] <pitti> xnox: FYI, http://anonscm.debian.org/cgit/collab-maint/pkg-util-linux.git
[05:36] <pitti> xnox: I just asked Andreas when he plans to land this
[07:05] <smb> infinity, Just saw the email about helping out with iso testing for the Trusty point release. Is there a way to see which ones are in progress right now and which untaken. Not that all start doing the same which is not helping much
[07:07] <jibel> smb, you can follow the progress and submit results on the iso tracker http://iso.qa.ubuntu.com/qatracker/milestones/318/builds
[07:08] <dholbach> good morning
[07:09] <jibel> smb, the download links are wrong for trusty, you must add 'trusty' in the url eg. http://cdimage.ubuntu.com/trusty/daily-live/20140722.2/trusty-desktop-amd64.iso
[07:09] <smb> jibel, Ah ok. Hm yeah seem to have changed even in the few minutes I did not refresh
[08:51] <xnox> pitti: i got emails it's in experimental.
[08:51] <pitti> xnox: yep, it was just duly celebrated in #debian-gnome :)
[08:51] <xnox> pitti: and as I pinged infinity, it's ftbfs on !amd64 =)
[08:51] <pitti> xnox: yes, known
[08:51] <pitti> (I think, ah mentioned something like that)
[08:51] <pitti> he's also preparing 2.25 and a fix for the remaining RC bug
[08:56] <xnox> pitti: anyway, i was testing usb-creator / udisks2 against it, and it seems fine. However, didn't fix my woes, so uploaded a patch adding to udisks dbus options "just-do-it" flag, which makes everything work =)
[09:00] <pitti> yeah, that's the "quick hack" part which we need to revert; it's not documented/upstream and just a workaround for the actual bug
[09:00] <pitti> e. g. supposedly if this happens the disk hasn't actually be cleaned properly
[09:02] <xnox> pitti: well, reading the code (a) i give a full block disk, e.g. /dev/sdb (b) ask to format (c) it waits for it to magically re-appears after wipefs -a (d) it doesn't, since we need to call Rescan to read partition tables by the OS, or lack of thereof.
[09:03] <xnox> thus, with the "plug" it goes to blindly create requested partions/partition-table/filesystem, which then validate afterwards.
[09:03] <xnox> pitti: maybe i'm failing to understand udisks2 expectations there, and how they are not satisfied at that point.
[09:27] <smb> jibel, Hrm, would you say a missing "update" option on the manual partitioning and re-use home test case is a bug or a feature. Its the same image used to install after all. What I get is only install alongside or erase...
[09:36] <jibel> xnox, what are the conditions in ubiquity to see the option 'reinstall ubuntu' in the partitioner ?
[09:36] <jibel> s/reinstall/upgrade/
[09:41] <smb> Meh, filed bug 1347521 in the mean-time
[09:41] <ubottu> bug 1347521 in ubiquity (Ubuntu) "No update/upgrade option when re-installing with same ISO" [Undecided,New] https://launchpad.net/bugs/1347521
[09:44] <xnox> smb: *sigh* upgrade would only be offered from 13.10 -> 14.04.1 daily
[09:44] <jibel> smb, the option 'upgrade' is only displayed if the installed version is older than the version you're installing otherwise you will see 'reinstall'
[09:45] <xnox> smb: but reinstall should be offered for in-place 14.04.1 dailies.
[09:45] <shadeslayer> ev: around?
[09:45] <ev> hi
[09:45] <smb> xnox, I did not see reinstall other than install alongside :/
[09:46] <xnox> smb: =(
[09:46] <xnox> smb: it is strange that you already mention that /home is on a separate partition.
[09:46] <shadeslayer> ev: any clue why https://errors.ubuntu.com/?user=kubuntu-bugs&period=month doesn't give me any info
[09:46] <xnox> smb: btrfs?
[09:47] <shadeslayer> ev:  and goes "An error occurred while trying to load the most common problems."
[09:47] <smb> xnox, No ext4. That is part of the test instructions
[09:47] <smb> (not the ext4 part but to have home seperate)
[09:47] <xnox> smb: ok.
[09:49] <ev> shadeslayer: it needs to be added to http://bazaar.launchpad.net/~daisy-pluckers/daisy/trunk/view/head:/tools/import_user_packages.py . Feel free to propose an MP which does that.
[09:49] <shadeslayer> ev: thx
[09:49] <shadeslayer> ev: this worked before though
[09:51] <xnox> smb: during .1 release testing we are ideally looking for bugs and things that regress verses a .0 baseline.
[09:51] <shadeslayer> ev: https://code.launchpad.net/~rohangarg/daisy/add-kubuntu-bugs/+merge/227879
[09:54] <smb> xnox, Yeah, and you can always choose to ignore certain bugs. But when I do follow test instructions I try to follow test instruction. And them say, if not expected behaviour, file bug. So I file bug. 3:) I don't mark them critical, though
[10:04] <xnox> smb: cool. and i hope that test cases do not guide one into impossible situations. E.g. install with lvm, and then do manual re-partitioning.
[10:04] <apw> xnox, you hope for the impossible
[10:05] <smb> xnox, They may not guide one, but I happened to just re-use a disk with lvm when running a test-case asking for that... :-P
[10:05] <xnox> smb: =))))))))))))))
[10:05] <xnox> lolz
[10:06] <xnox> good good.
[10:07] <ev> shadeslayer: merged. Should work on the next cron run (I think it's daily)
[10:07] <smb> xnox, You are not really expecting our users to not do the impossible ... ;) As I said, I won't mark those things as critical but keep opening bugs just to document things
[10:07] <shadeslayer> thanks! :)
[10:13] <xnox> psivaa: plars: are there ubiquity autopilot tests running for all flavours, with trusty daily images?
[10:14] <psivaa> xnox: i'm not sure about ubiquity AP tests. may be jibel knows?
[10:20] <jibel> xnox, no, it's only testing the dev release, I'll add them
[10:20] <xnox> jibel: yes please, that would help a lot for smoke testing and respins.
[10:21] <jibel> xnox, I fully agree since the fallback is me doing manual tests :)
[10:21] <xnox> jibel: the AP tests should be pulled from lp:~ubuntu-installer/ubiquity/trusty-proposed instead of lp:~ubuntu-installer/ubiquity/trunk. Whilst they didn't diverge yet, they may do so in the future.
[10:21] <xnox> jibel: well and kernel team are doing it at the moment as well =)
[10:22] <jibel> xnox, yeah, thanks kernel team
[10:25] <pitti> sil2100: bug 1346199 is sufficiently tested now, but just for safety I suppose we should keep that in -proposed until we get out of the traincon swamp for touch?
[10:25] <ubottu> bug 1346199 in systemd (Ubuntu) "Needs testing in -proposed: systemd 208" [High,In progress] https://launchpad.net/bugs/1346199
[10:27] <sil2100> pitti: hey, yeah I would first like us to move out all our 4.9 gcc-related transitions from -proposed
[10:28] <pitti> sil2100: ack
[10:28] <sil2100> Would be really grateful for that ;)
[10:28] <pitti> sil2100: it's not that urgent; systemd as pid 1 is totally broken ATM, but as we don't support that, getting the touch image back to green/promotable certainly trumps that
=== doko_ is now known as doko
[10:40] <Riddell> pitti: can you see any problem with bug 1347565 and what's a good test case?
[10:40] <ubottu> bug 1347565 in apport (Ubuntu Utopic) "apport recommends gdb" [Undecided,New] https://launchpad.net/bugs/1347565
[10:55] <smb> jibel, I am a bit confused about http://iso.qa.ubuntu.com/qatracker/testcases/1312/info. Specifically I seem to miss the "no network" part of it.
[11:02] <jibel> smb, the test case is wrong, step 5, 'is connected to the internet' must be greyed, the list of languages for trusty are en, es and zh. For other language there is a popup when the system is connected to a network.
[11:02] <jibel> balloons, ^ could you fix this test case
[11:02] <jibel> ?
[11:59] <apw> xnox, hey when i select "Something Else" the next installer screen is taller, this tallerness persists from then on, making all of the windows go off the bottom on my test box
[11:59] <xnox> apw: gtk+ enjoy it =)
[12:00]  * ogra_ hands apw a few horizontal lines with pixels
[12:00] <apw> ogra_, i need about 200 if you have them
[12:00] <ogra_> just glue tzhem on at the bottom
[12:00] <xnox> apw: you should be able to press super and drag the window up.
[12:00] <ogra_> sure, np ...
[12:00] <apw> xnox, oh yeah i can cause i know how, but ... its hard if you don't
[12:00] <xnox> =)
=== _salem is now known as salem_
[12:11] <apw> xnox, you might want to look at bug: #1347630 and reassign it as you see fit
[12:11] <ubottu> bug 1347630 in ubiquity (Ubuntu) ""You may want to read the release notes" link takes you to ubuntu home page" [Undecided,New] https://launchpad.net/bugs/1347630
=== ximion1 is now known as ximion-afk
[12:17] <pitti> hey Riddell
[12:17] <pitti> Riddell: looking
=== greyback is now known as greyback|lunch
[12:17] <jibel> apw, it's a redirect on server side. It'll have to be updated with the new version of the release.
[12:18] <apw> jibel, ok what shall i assign that bug to
[12:18] <apw> i assume there is a project for the website somewhere
[12:18] <pitti> Riddell: ah, I think that should be fine; AFAIK, the full gdb has support for decoding python and other languages, but we don't need those for crash processing
[12:19] <jibel> apw, ubuntu-website
[12:22] <pitti> Riddell: I added a test case to the bug
[12:22] <Riddell> thanks :)
[12:22] <pitti> Riddell: did you happen to commit this to bzr locally and just need to push, or should I grab the diff from LP?
[12:23] <Riddell> pitti: does it need updated in bzr, will UDD not do that magically?
[12:23] <pitti> Riddell: it's not using UDD; I want to be this a proper branch of trunk, which UDD can't do
[12:24] <pitti> (one of the main reasons why IMHO UDD is broken -- it falls down in the ideal case of having both upstream and packaging all in bzr..)
[12:24]  * Riddell looks
[12:24] <cjwatson> Yeah, UDD is most kindly described as "aspirational" I think
[12:25] <pitti> Riddell: anyway, I'll just push it
[12:25] <pitti> Riddell: erk, FTBFS due to twisted uninstallability in -proposed
[12:26] <Riddell> wibble
[12:26] <Riddell> trusty bzr is out of date anyway, tsk to bdmurray
[12:26] <pitti> Riddell: pushed utoic
[12:26] <pitti> Riddell: and utopic, too
[12:27] <pitti> Riddell: ah, I'll import 2.14.1-0ubuntu3.2 too
=== pete-woods1 is now known as pete-woods|away
=== MacSlow is now known as MacSlow|lunch
[12:36] <pitti> Riddell: trusty branch updated
[12:39] <Riddell> thanks pitti
[12:50] <pitti> cjwatson: ah, http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2014-January/013883.html is indeed a nice summary
[12:50] <cjwatson> It may not be worth your time trying to convert an existing package, but perhaps worth trying out on something new
[12:50] <pitti> cjwatson: so indeed conceptually not that much different from http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/README.source
[12:51] <pitti> cjwatson: but git-dpm dch looks quite nice, essentially implying the "export" step you need to do for -pq
[12:51] <cjwatson> Yeah, as I say I think it's basically an implementation (IMO nicer but YMMV) of the same idea
[12:51] <cjwatson> pitti: I find myself using commit --amend a lot with it
[12:51] <cjwatson> and git-dpm update-patches --amend
[12:52] <pitti> This is an enforced workflow change; you can't mix and match this
[12:52] <pitti>    with manual developer use of quilt in a particularly sane way, and
[12:52] <pitti>    you have to use git-dpm if you're touching patches in any way.
[12:52] <pitti> oh, that would be a rather big downside
[12:52] <pitti> I thought with -dpm the patch branch would also be transient, it's not then?
[12:52] <cjwatson> Well, you can, it's just that git-dpm will probably want to rewrite stuff later
[12:52] <pitti> ah
[12:53] <pitti> yeah, there's always some noise in patch headers
[12:53] <cjwatson> It's sort of transient; the tip of it is merged into master
[12:53] <cjwatson> You don't keep a ref around for it, but its history remains
[12:53] <cjwatson> I generally view this as a plus, but as I say YMMV
[12:54] <cjwatson> I'm actually not sure what git-dpm does if you just drop in a quilt patch it's never heard of.  Generally speaking once I have something in git-dpm I don't want to use quilt
[12:55] <cjwatson> It's git, I'm sure you have all the swiss army knives required to deal with it, just not sure how neat it is :)
[12:56] <pitti> heh, yes
[12:56] <xnox> cjwatson: how/where in launchpad can i get to image builds? which team/person/etc should I be looking for?
[12:56] <pitti> cjwatson: my main concern was mostly about other people touching the packaging/quilt series as well, and converting everyone to a new tool in lockstep seemed a bit difficult
[12:56] <cjwatson> xnox: They're all under ~ubuntu-cdimage, but the index is crap right now
[12:56] <pitti> much easier for (essentially) single-maintainer packages, of course
[12:56] <cjwatson> xnox: You can use the lp.livefses collection on the webservice
[12:57] <cjwatson> and then .web_link
[12:57] <xnox> cjwatson: ack. yeah, cuase https://launchpad.net/~ubuntu-cdimage doesn't show me any links to livefs builds et al.
[12:57] <cjwatson> xnox: basically they're of the form /~ubuntu-cdimage/+livefs/ubuntu/SERIES/NAME, e.g. .../utopic/ubuntu-desktop
[12:57] <cjwatson> Yeah, I've been meaning to write some kind of index but ENOTIME
[12:58] <xnox> jibel: ^
[12:58] <xnox> jibel: e.g. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/lubuntu
[12:58] <jibel> xnox, cjwatson ack, thanks
[12:58] <smb> xnox, I think bug 1347676 might be somewhat bad.
[12:58] <ubottu> bug 1347676 in ubiquity (Ubuntu) "Installer fails to find disk to install" [Undecided,New] https://launchpad.net/bugs/1347676
[12:58] <cjwatson> Whoops, sorry, my example was buggy :-)  .../utopic/ubuntu
[12:58] <xnox> well above lubuntu build url works =)
[12:58] <cjwatson> xnox: Also, there's a link to the build in each of the CD build logs (http://people.canonical.com/~ubuntu-archive/cd-build-logs/
[12:58] <cjwatson> )
[12:59] <cjwatson> So you can always track it down from there
[12:59] <cjwatson> e.g. top few lines of http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/trusty/daily-live-20140722.2.log
[13:02] <xnox> jibel: btrfs is seeded everywhere where it's needed. not sure what's going on. let me pull lubuntu iso.
[13:02] <jibel> xnox, from the logs you see that it's a recommends but recommends are not installed
[13:03] <jibel> xnox, https://launchpadlibrarian.net/180540741/buildlog_ubuntu_trusty_i386_lubuntu_UPLOADING.txt.gz
[13:04] <xnox> jibel: hm, right.
[13:05] <xnox> jibel: but in the equivalent utopic build, it's going to be installed.
[13:05] <xnox> hm.
[13:05] <jibel> xnox, and it's installed for ubuntu
[13:08] <xnox> jibel: ubuntu installs recommends, but lubuntu does not.
[13:09] <xnox> jibel: the seeds are the same
[13:09] <xnox> jibel: thus lubuntu trusty and utopic should both be the same, however lubuntu/utopic has btrfs-tools yet lubuntu/trusty does not.
=== MacSlow|lunch is now known as MacSlow
=== greyback|lunch is now known as greyback
[13:52] <bulletxt> hi, if I download from ubuntu packages the source of printer-driver-gutenprint , how can I build it with ubuntu specifics ? Like prefix and all the rest? Thanks a lot
[13:52] <cjwatson> debuild -B -uc -us
[13:53] <cjwatson> Sorry, -b not -B
[13:53] <bulletxt> in which folder? in the extracted  [gutenprint_5.2.10~pre2-0ubuntu2.debian.tar.gz] file ?
[13:53] <cjwatson> you should not extract that file manually
[13:53] <cjwatson> dpkg-source -x gutenprint_5.2.10~pre2-0ubuntu2.dsc
[13:54] <cjwatson> that will produce a gutenprint-5.2.10~pre2 directory; build in there
[13:54] <bulletxt> ok let me try
[13:54] <cjwatson> debuild will probably require you to install build-dependencies before it will proceed
[13:54] <cjwatson> (there are of course approaches for automating that, but they're overkill if you're just trying to build one thing)
=== pete-woods|away is now known as pete-woods
[13:55]  * cjwatson -> out
[13:56] <bulletxt> ok cjwatson I did dpkg-source -x gutenprint_5.2.10~pre2-0ubuntu2.dsc
[13:56] <bulletxt> it created a folder gutenprint-5.2.10~pre2
[13:56] <bulletxt> should I just get in there and do make; make install ?
[13:58] <roadmr> bulletxt: no, see what cjwatson said, was to debuild -b -uc -us
[13:59] <bulletxt> ok roadmr I got into the new created folder and did debuild -b -uc -us
[13:59] <bulletxt> but it gave some errors
[14:00] <roadmr> which errors? something about unmet build dependencies I imagine?
[14:00] <bulletxt> yea I'll paste the whole thing
[14:01] <bulletxt> roadmr: http://paste.ubuntu.com/7842095/
[14:01] <roadmr> bulletxt: ok! but to get you started faster, you need to install all the packages listed in "Unmet build dependencies"
[14:01] <roadmr> bulletxt: just apt-get install all those packages, then try again
[14:01] <bulletxt> yea but please give a look at the paste
[14:01] <bulletxt> I'm not sure that's the problem
[14:01] <bulletxt> mm
[14:01] <bulletxt> maybe yea
[14:02] <roadmr> bulletxt: give it a try :) you can't build without the deps :P
[14:02] <bulletxt> ok cool I installed debuild -b -uc -us
[14:02] <bulletxt> I mean, the missing dev packages
[14:02] <bulletxt> now its going ahead
[14:02] <bulletxt> :D
[14:03] <roadmr> bulletxt: cool! ok, so it'll spit out one or more .deb at the end
[14:03] <bulletxt> so, lets say I want to apply my personal patch to gutenprint, should I first apply the patch and then do  debuild -b -uc -us   ??
[14:03] <roadmr> bulletxt: correct, apply your patch on that directory where you're building. You'll notice it contains all of gutenprint source
[14:04] <bulletxt> yea, ok so first I apply my patch then i do the debuild command
[14:04] <roadmr> bulletxt: right
[14:05] <bulletxt> but, do I have to be root when doing debuild  ??
[14:05] <roadmr> bulletxt: no
[14:05] <bulletxt> ok
[14:05] <roadmr> bulletxt: debuild uses some tricks to avoid needing root while building
[14:05] <bulletxt> ok cool
[14:06] <bulletxt> its spitting out a lot of debs on my desktop, lol
[14:06] <roadmr> :D
[14:15] <bulletxt> roadmr: do you by chance know how to correctly apply a  patch.diff file into the source ?
[14:16] <roadmr> bulletxt: hm usually patch -p0 < patch.diff (do this while in the gutenprint directory)
[14:16] <bulletxt> a simple patch < file.diff should be enough I supose
[14:16] <bulletxt> ok
[14:21] <bulletxt> roadmr:  It returned this:  (Stripping trailing CRs from patch; use --binary to disable.) patching file src/main/print-olympus.c (Stripping trailing CRs from patch; use --binary to disable.) patching file src/xml/papers.xml
[14:22] <roadmr> bulletxt: patch would complain loudly if there was a problem, so it looks OK to me, just a warning
[14:22] <bulletxt> ok
[14:22] <bulletxt> then its time to redo the debuild and then install the debs :D  hopefully I won't destroy my system :)
[14:23] <roadmr> bulletxt: looks like your changes are relatively harmless, good luck!
[14:44] <arges> have you guys seen this apt error before, it seems to have been happening recently : http://pastebin.ubuntu.com/7842304/
[14:51] <xnox> arges: yes. ddebs are very racy at updating their dists/
[14:52] <xnox> arges: the reply is prodstack4 or shipping strong booze to germany somewhere where pitti is or something like that =)
[14:52] <arges> xnox: fun fun fun
[14:53] <pitti> I tried to do a first attempt of updating dists/ atomically, but it's 'orribly complicated
[14:58] <bulletxt> roadmr: great everything went fine. Thanks a lot (also cjwatson!)
[14:59] <jodh> xnox, hallyn: Just a reminder that https://code.launchpad.net/~jamesodhunt/ubuntu/utopic/cgmanager/enable-upstart-cgroup-support/+merge/227209 is still o/s. We really need this enabled such that if we hit problems, we have sufficient time to resolve before RTM :)
[15:00] <xnox> jodh: we are not landing it right now, not until gcc-4.9 is resolved on the phone and we promoted an image and/or some such.
[15:00] <roadmr> bulletxt: I just helped with some minor syntax. Glad it worked!
[15:00]  * xnox goes to check status of 4.9
[15:01] <jodh> xnox: ok - thanks for the update.
[15:02] <xnox> so on http://people.canonical.com/~platform/citrain_dashboard// silo 008 needs to publish and an image build done.
[15:02] <xnox> not sure if there is a bug number to be notified.
[15:04] <hallyn> jodh:  what is o/s ?
[15:04] <xnox> slangasek: is there a tracking bug for gcc-4.9 explicit somewhere? packages in silo 008 close no bugs....
[15:05] <xnox> hallyn: i've extrapolated from Oxford dictionary as "outstanding"
[15:06] <jodh> xnox: you win a prize! And you prize is... to handle my MP :)
[15:08] <hallyn> xnox: that was my guess, but i was wondering if there was a more technical term it coudl e short for :)
[15:09] <hallyn> jodh: so, when I bzr branch lp:upstart, what's the recommended way to bootstrap to a point where I can build?  I tried the usual sorts of steps but didn't get the right series of steps apparently
[15:10] <xnox> hallyn: apt-get build-dep upstart; autoreconf --force --install; ./configure; make -j12; make check -j12
[15:10] <xnox> hallyn: if that's not "usual sorts of steps" you did, please update the "usual sorts of steps" to above =)
[15:11] <xnox> hallyn: and let us know, if above does not work for any reason.
[15:11] <hallyn> xnox: ok, autoreconf.  i was doing 'aclocal;libtoolize;autoheader;autoconf;automake' type of steps
[15:12] <hallyn> thanks :)
[15:12] <xnox> hallyn: from that expanded list autopoint vs gettexize is the missing piece i think.
[15:13]  * hallyn looks up autopoint
[15:13]  * hallyn respectfully suggests to jodh that a 'bootstrap.sh' might be worthwhile :)
[15:13] <jodh> hallyn: http://upstart.ubuntu.com/cookbook/#setting-up-an-upstart-development-environment, http://upstart.ubuntu.com/cookbook/#unit-tests. I generally just 'autoreconf -fi && ./configure ...'
[15:14] <hallyn> or just a note in README
[15:16] <tkamppeter> Anyone with knowledge about SLP (Service Location Protocol) around?
[15:16] <xnox> hallyn: "autoreconf -fi" is the golden standard these days. to the point that most of "bootstrap" scripts like autogen.sh et.al. just call "autoreconf -fi" these days.
[15:16] <xnox> hallyn: why do you not use autoreconf?
[15:18] <hallyn> i dunno, cause i didn't know how it fit in with the other magic incantations
[15:18] <hallyn> certainly seems nicer
[15:20] <hallyn> i think i (without thinking about it) assumed autoreconf was a debbuilder thing.  i used it in package building, but not by hand
[15:23] <xnox> hallyn: it's the top-class command to rule them all part of autotools. it inteligently inspects and tries to run all the tools, as many times as needed, in the right order.
=== timrc-afk is now known as timrc
[15:24] <hallyn> xnox: unicorns
[15:40] <pitti> slangasek: ah, thanks for the updates wrt. armhf
[15:41] <pitti> slangasek: so this exercise of summarizing was useful, glad to hear that it's not quite as bad as I feared
[15:46] <hallyn> jodh: all right, i can finally reproduce the make check failure in lp:upstart :)  will aim to mp a fix later today
[15:47] <jodh> hallyn: thanks!
[16:40] <slangasek> xnox: the tracking bug was bug #1329089
[16:40] <ubottu> bug 1329089 in dbus-cpp (Ubuntu) "g++-4.9 binary incompatibilities with libraries built with g++-4.8" [Critical,In progress] https://launchpad.net/bugs/1329089
[16:53] <xnox> slangasek: ah ok. and none of the merge proposals mention this bug, because unicorns?! =) ok, gotcha.
[16:53]  * slangasek shrugs :)
[17:02] <xnox> at times i honestly believe setuptools is worse than autotools. Whilst both can drive one crazy, the latter at least generates piles of logs and error messages.
[17:03] <mlankhorst> we shoud all use the android build tools ;-)
=== Ursinha is now known as Ursinha-afk
[17:35] <hallyn> jodh: tbh the cgmanager tests in upstart don't seem u seful
[17:35] <hallyn> they seem like they woudl test libcgmangaer, not upstart
[17:37] <hallyn> so it's fine to do setup_cgroup_sandbox() before running tests, and skip the tests if setup_cgroup_sandbox fails.
[17:38] <hallyn> but right now it just tries setup-cgroup_sandbox and fails is that fails.  That's wrong.
[17:39] <hallyn> now the init/tests/test_cgroup.c looks good.
[17:40] <hallyn> though it doesn't test any actual cgroup actions i guess
=== Ursinha-afk is now known as Ursinha
[17:42] <hallyn> ok purely my fault for misunderstanding that file in january?  ok i think i know what to do :)  thx for listening :)
[17:43] <hallyn> there, that's better
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
[18:48] <jodh> hallyn: those tests are meta-tests so not actually for testing upstart, just the env its tests run in to ensure it is 'sane'. thanks for MP!
=== Ursinha is now known as Ursinha-afk
=== rickspencer3_ is now known as rickspencer3
=== Ursinha-afk is now known as Ursinha
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
=== salem_ is now known as _salem