=== salem_ is now known as _salem
[00:32] <hallyn> slangasek: i'm doing another fresh jessie install so i can test the proposed cgmanager (and systemd-shim and lxc whiel i'm at it).  what will be the next step in getting cgmanager into experimental?
[00:32] <slangasek> hallyn: none; why would I upload it to experimental instead of unstable? ;)
[00:41] <hallyn> slangasek: bc i originally tagged it with experimental? :)
[00:43] <slangasek> pssh :)
[00:46] <mbiebl_>  hallyn: please upload it directly to unstable
[00:48] <hallyn> slangasek: should i change the changelog msg then?
[00:48] <slangasek> hallyn: if you wish, though I figure it's fair game for me to adjust that during sponsorship
=== _salem is now known as salem_
[01:55] <hallyn> hm.  stgraber: do you think cgmanager in debian ought to mount name=systemd, or not?
[01:55] <hallyn> i guess it should
[01:56] <hallyn> (else lxc fails)
[01:56] <stgraber> hallyn: yeah, it probably should. Maybe make this conditional to logind's presence?
[01:57] <stgraber> hallyn: as in [ -e /lib/systemd/systemd-logind ] && args="$args -m name=systemd"
[01:58] <stgraber> hallyn: hmm, actually, I think we want to do it unconditionaly
[01:58] <hallyn> stgraber: mbiebl was talking about no longer having the logind start script mount the cgroups, so i think that could break
[01:58] <hallyn> better to just always mount it
[01:59] <stgraber> hallyn: because otherwise if you have a host without logind but a container with logind, things will fail due to lack of name=systemd
[02:00] <hallyn> good point
[02:13] <hallyn> all right lxc works fine in jessie with cgmanager;  one more rebuild of systemd-shim to test that bit
=== superm1_ is now known as superm1
[03:20] <hallyn> slangasek: had to update http://people.canonical.com/~serge/cgmanager-0.27.1/cgmanager_0.27-1.dsc anyway for one more one-line fix, so i changed release to unstable.  works here with lxc and systemd-shim, so i'm now stepping back from it.
=== hyperair is now known as Guest90316
=== maxb is now known as Guest41692
=== salem_ is now known as _salem
[04:06] <pitti> Good morning
[04:07] <pitti> infinity: ddeb deps> ah right; so I guess, time for a more intrusive rewrite then, and then I can avoid everything else which makes this thing so slow, and also avoid having to maintain the cronjobs every release
[04:08] <pitti> doko_: did you see that the new twisted seems to break quite a number of rdeps?
[04:08] <pitti> hallyn: I can have a look
[04:09] <pitti> hallyn: is there a github pull request or similar for that?
[04:13] <hallyn> pitti: hey!  no pull request yet;  waht would the pull request be to?  desrt's tree?  (he has a cgm.1 branch which i'm based off of)
[04:13] <hallyn> for now it's just in github.com/hallyn/systemd-shim #cgm.2
[04:14] <pitti> hallyn: ah, ok, can look there
[04:17] <hallyn> cool
[04:25] <pitti> hallyn: might take a bit though, I'm currently swamped in requests/todos
[04:43] <hallyn> pitti: understandable - going to bed now;  I can look for review/sponsor in #debian-systemd tomorrow if need be.  thanks in either case
=== Aki-Thinkpad is now known as snakes
=== snakes is now known as _snakes
=== _snakes is now known as D8
=== D8 is now known as _8D
=== _8D is now known as _8D[_]
=== Lutin_ is now known as Lutin
=== Guest41692 is now known as maxb
[08:06] <Saviq> seb128, hey, will you guys have time to review https://code.launchpad.net/~mterry/ubuntu-system-settings/locking-hash/+merge/224346 ?
[08:07] <seb128> Saviq, I wouldn't mind a review from the security team on that one, they had lot of good reviews comments and specific notes on the first review (see the bug report)
[08:07] <seb128> Saviq, I can have a look today but I want a security ack before approving it
[08:07] <Saviq> seb128, yeah sure
[08:07] <Saviq> seb128, we're working on it on that front as well
[08:08] <seb128> great
=== doko_ is now known as doko
[08:32] <doko> pitti, yep, not unusual
[09:27] <Tribaal> Hi all. I opened a branch against an ubuntu package and would appreciate it if someone could have a look at it (it's waiting for sponsorship - but I'd like to make sure I followed the process properly).
[09:28] <Tribaal> Here's the bug: https://bugs.launchpad.net/ubuntu/+source/ubumirror/+bug/1341523 A "just wait" answer would be good enough :)
[09:28] <ubottu> Ubuntu bug 1341523 in ubumirror (Ubuntu) "Update to upstream 0.4" [Undecided,In progress]
[09:34] <jamespage> cjwatson, around? bug 1341618 just got bought to my attention
[09:34] <ubottu> bug 1341618 in grub2 (Ubuntu) "grub 1.99-21ubuntu3.15 will not boot on some hardware" [Undecided,Confirmed] https://launchpad.net/bugs/1341618
[09:38] <cjwatson> jamespage: left a comment
[09:38] <jamespage> cjwatson, ta - i'll poke Spads again
[09:39] <sil2100> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
[09:41] <Spads> cjwatson: I've asked the APAC folks who had first-hand experience to elaborate.  thanks.
[10:25] <zyga> hey, I'm back from holidays and my sbuild/schroot setup is now broken (all utopic), I seem to get a message saying that my chroots are not owned by root (they are owned by sbuild)
[10:25] <zyga> googling didn't really help me much
[10:25] <zyga> the exact message is:
[10:25] <zyga> E: sid-amd64-sbuild-625b5676-4967-4132-b55e-cd4d95cb5fe5: Failed to lock chroot: /var/lib/sbuild/sid-amd64.tar.gz: File is not owned by user root
[10:37] <darkxst> pitti, running a autopkgtest with build-needed, doesn't pick up the build depends from the main package?
[10:37] <pitti> darkxst: it does
[10:38] <pitti> darkxst: well, for building
[10:38] <pitti> darkxst: not for the test
[10:39] <darkxst> pitti, I have to use --disable-unit-tests on the main build or it fails (unless I override that with ||true)
[10:40] <pitti> darkxst: that's not indended -- building the package should behave like on a buildd
[10:40] <darkxst> pitti, tracker tests won't run in buildd
[10:40] <pitti> darkxst: so tracker's debian/rules shoudl already use --disable-unit-tests during build?
[10:41] <pitti> darkxst: sorry, I'm afraid I still don't understand the question/problem
[10:41] <darkxst> pitti, yes it does, we want to run the unit-tests but they can't be run at build time
[10:41] <darkxst> since they need the tracker dbus interfaces
[10:41] <zyga> hmm
[10:42]  * zyga digs through schroot code to understand what is causing the problem
[10:42] <pitti> darkxst: yeah, sounds like these unit tests are rather broken :/ (they ought to start a private D-BUS instance with the locally built tracker)
[10:42] <darkxst> pitti, so right now I have a autopackage test with "make -c tests check"
[10:42] <pitti> darkxst: ah, wrapped in a dbus-launch or so?
[10:42] <darkxst> xvfb-run
[10:44] <Saviq> jodh, hey, on bug #1222705, do you have a phone with Ubuntu on it by any chance?
[10:44] <ubottu> bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [High,Confirmed] https://launchpad.net/bugs/1222705
[10:45] <jodh> Saviq: I don't have a phone (still waiting ... :)
[10:45] <Saviq> jodh, the most reproducible case is "restart unity8" on the phone for us, let me try and get you some logs
[10:45] <jodh> Saviq: thanks
[10:45] <Saviq> jodh, will try and reproduce on emulator, too
[10:50] <zyga> hmm
[10:50] <zyga> it seems that all chroot files need to be owned by root because of $reasons
[10:50] <zyga> ok, let's try
[10:51] <zyga> \o/
[10:51] <zyga> ok
[10:51] <zyga> that worked
[10:51]  * zyga looks at schroot changelog
[10:52] <darkxst> pitti, so the tests run in a fresh chroot?
[10:52] <pitti> darkxst: yes, with only the test dependencies installed
[10:53] <Saviq> jodh, https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1222705/comments/18
[10:53] <ubottu> Ubuntu bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [High,Confirmed]
[10:54] <jodh> Saviq: ta
[10:55] <darkxst> pitti, so would be better to --enable-unit-tests and ignore test failure on build, then just run the tests from autopkgtest?
[10:55] <darkxst> or add all the build-deps to the tests/control ?
[10:56] <pitti> darkxst: you can do that, or you find a way to just build the tests (make -C tests) and run them against the installed tracker
[10:56] <jodh> Saviq: could you also attach the /var/crash/_sbin_init.*.txt?
[10:56] <pitti> darkxst: you can add @builddeps@ to the test dependencies if you want to build stuff in your test script
[10:56] <Saviq> jodh, sure, let me get some symbols in it first
[10:57] <jodh> Saviq: thanks, if you could also trigger the crash with the Session Init running as 'init --user --debug', that would also be fantastic.
[10:58] <Saviq> jodh, hmm any idea how would I go about that with lightdm auto-starting the session?
[11:00] <jodh> Saviq: well you could just 'initctl log-priority debug' before starting the tests.
[11:00] <Saviq> jodh, oh yeah that'd work
[11:01] <jodh> Saviq: last time I checked, lightdm runs the script /usr/bin/ubuntu-touch-session which you could hack to add '--debug' if you'd prefer.
=== pete-woods is now known as pete-woods|lunch
[11:20] <Saviq> jodh, added two attachments to the bug, not sure if there's any more useful info
=== MacSlow is now known as MacSlow|lunch
[11:53] <uki> Is there anyway I can easily have gdb with python2 support on ubuntu 13/14 instead of python3?
[11:53] <uki> All my gdb scripts are broken as the newer gdb uses python3
[11:57] <darkxst> uki, you need to make your scripts python3 compatible
[11:58] <uki> darkxst: any easier way to downgrade?
[11:58] <darkxst> uki, only if you rebuild gdb against python2
[11:58] <darkxst> not possible with archive versions
[11:59] <uki> ah i see, thats sounds good. so id have to "apt-get source", uncompress the deb and rebuild?
[12:00] <uki> darkxst: ^^
[12:01] <darkxst> uki, I have never tried, its pretty easy to convert most scripts. but at the very least you would need to modify build-depends
[12:02] <uki> darkxst: im comfortable with python3, yes, but im using an entire lib written for use within gdb thats written in python2. conversion isn't really desirable at this point.
=== psivaa is now known as psivaa-off
[12:14] <darkxst> uki, try run the scripts through 2to3
=== _salem is now known as salem_
[12:18] <sil2100> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[12:18]  * sil2100 lunch
=== MacSlow|lunch is now known as MacSlow
[12:40] <darkxst> pitti, will xvfb-run pass through test errors? or do I need to trap them somehow?
[12:41] <pitti> darkxst: it passes through stdout/err and exit code, so no need for anything special
[12:41] <sil2100> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
[12:45] <darkxst> pitti, so this should be fine then? http://pastebin.com/ESPq5FNs
[12:45] <Saviq> jodh, just reproduced the same crash under i386 emulator, do you know the steps to get one?
[12:45] <pitti> darkxst: if that builds the unit tests and works, it looks fine
[12:45] <darkxst> pitti, runs fine locally with adt-run
[12:46] <pitti> darkxst: @builddeps@ because "make -C tests check" actually builds more stuff than what gets build with dpkg-buildpackage?
[12:46] <LocutusOfBorg1> xnox, did you read this? https://github.com/performous/performous/commit/79eff6c44b76f26366588e12a606a77bd6e97a83
[12:46] <LocutusOfBorg1> :)
[12:48] <darkxst> pitti, yes, as mentioned earlier main build has --disable-unit-tests
[12:48] <pitti> darkxst: right, but the test doesn't call ./configure again, that's why I wondered; so if that make call does it, then fine :)
[12:49] <pitti> darkxst: btw, if that works, the tests should also work during package build if you run them through xvfb-run in debian/rules override_dh_auto_test
[12:50] <Saviq> jodh, https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1222705/comments/24
[12:50] <ubottu> Ubuntu bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [High,Confirmed]
[12:50] <darkxst> pitti, no I tried that first, but they require the tracker dbus, which of course isn't installed (although I will file a bug upstream about fixing that)
[12:50] <jodh> Saviq: thanks, I'll ping you if I need anything else.
[12:50] <Saviq> jodh, cheers
[12:52] <darkxst> pitti, they also require a utf-8 locale and $HOME set, fwiw
[12:52] <pitti> darkxst: ah, ok; thanks!
[13:12] <smb> xnox, It is a rather minor issue but I thought to document it anyway. Now what again would be the package related to current desktop installer?
[13:15] <cjwatson> ubiquity
[13:16] <sil2100> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== Sweetsha1k is now known as Sweetshark
=== pete-woods|lunch is now known as pete-woods
[13:38] <smb> cjwatson, thanks
=== timrc-afk is now known as timrc
[14:17] <kgunn> ChrisTownsend: hey there, i'd normally pester stephen on this...
[14:17] <kgunn> but, we're getting darn close to landing qtcomp
[14:17] <kgunn> but we need one mp (1 line change)
[14:17] <kgunn> https://code.launchpad.net/~gerboland/unity8-desktop-session/qtcomp/+merge/225884
[14:18] <kgunn> reviewed
[14:18] <kgunn> would you mind ?
[14:18] <kgunn> there have been a few of us that have tested the silo against unity8-desktop
[14:18] <kgunn> https://wiki.ubuntu.com/Unity8/QtComp
[14:19] <kgunn> and it worked fine
[14:21] <ChrisTownsend> kgunn: Hey.  Sure, I can take a look.  Is the suggestion that Stephen made been done?
[14:22] <kgunn> ChrisTownsend: uh.... :P
[14:23] <ChrisTownsend> kgunn: Also, that MP is marked WiP, but I assume it's ready for review since you are asking me:)
[14:24] <kgunn> greyback: ^ yeah, can we flip the switch to review ?
[14:24] <greyback> kgunn: done. Unsure what checklist to enter though
[14:25] <ChrisTownsend> kgunn: And when you "tested in the silo", does that mean unity8-desktop-session is already in a silo and this just needs approved so it can be published?
[14:25] <kgunn> greyback: something sensible....like, no api break, been tested as part of https://wiki.ubuntu.com/Unity8/QtComp
[14:26] <kgunn> ChrisTownsend: yes, its a collection of MP's that all have to go at once...and its been under test by us & the community for over a week now
[14:26] <kgunn> and something we need for rtm
[14:26] <kgunn> hence my underwear being slightly wadded
[14:26] <ChrisTownsend> kgunn: Ok, makes sense.  I wasn't sure if a new silo, etc. needed to be set up.
[14:26] <ChrisTownsend> kgunn: lol, we'll get it in.
[14:28] <kgunn> ChrisTownsend: yeah, we're just in the process of collecting approvals....and will just flip the switch on that silo from testing to "attempt to land"
[14:29] <ChrisTownsend> greyback: kgunn:  So is bregma's comment about this also needing to be added to data/unity8-mir.conf legit.  You say it works already, so maybe that's not necessary, but I'm just wondering if it still needs to be there just to be safe.
[14:29] <greyback> ChrisTownsend: yep I just saw that. I'll do it to be safe
[14:30] <ChrisTownsend> greyback: Cool, thanks.
[14:33] <ChrisTownsend> greyback: Let me know when you have that pushed and I'll approve.
[14:34] <greyback> ChrisTownsend: just pushed
[14:34] <ChrisTownsend> greyback: Ok, thanks
[14:34] <greyback> thank you!
[14:35] <ChrisTownsend> kgunn: greyback: Approved
[14:35] <greyback> one down....
[14:35] <kgunn> woohoo
[14:36]  * ChrisTownsend Hopes kgunn's underwear is slightly less wadded.
[14:37] <kgunn> lol thanks ChrisTownsend
[14:38] <ChrisTownsend> kgunn: np!
=== Sweetsha1k is now known as Sweetshark
[14:58] <Riddell> mvo_: ping, are you able to help debug an apt issue with me?
[14:58] <mvo_> Riddell: maybe, what is the issue you see?
[14:59] <Riddell> mvo_: I'm making a new meta package
[14:59] <Riddell> for kubuntu-plasma5-meta
[14:59] <Riddell> it's in the kubuntu-ppa/next
[14:59] <Riddell> but when I apt-get install kubuntu-plasma5-desktop it doesn't want to install because powerdevil says it breaks on kde-workspace-data
[15:00] <Riddell> mvo_: how do I tell it it's fine to remove kde-workspace-data ?
[15:00] <Riddell> if I explicitly   apt-get install kubuntu-plasma5-desktop powerdevil  it's fine with removing kde-workspace-data and anything else that's needed
[15:00] <mvo_> Riddell: this is against utopic? give me a sec to see what the resolver tells me
[15:00] <Riddell> mvo_: yep
[15:01] <Riddell> mvo_:  sudo apt-add-repository ppa:kubuntu-ppa/next ; sudo apt-add-repository ppa:ci-train-ppa-service/landing-005
[15:02] <mvo_> Riddell: ok, give me a minute to setup a chroot
[15:02] <Riddell> mvo_: oh I have an ec2 if you give me your ssh key
[15:03] <Riddell> mvo_: ssh ubuntu@ec2-54-91-220-158.compute-1.amazonaws.com
[15:04] <hallyn> mbiebl: slangasek: pitti: so systemd-shim is nto useful in experimental as is anyway, so could we upload the patched version to experimental as soon as cgmanager goes into unstable, to make progress with systemd-208 after it gets some wider testing?
[15:05] <mvo_> Riddell: thanks, I will use that then
[15:06] <mvo_> Riddell: you have not added the ppa in the ec2 instance yet, is that correct?
[15:06] <mvo_> Riddell: unicorns eh :) ?
[15:07] <Riddell> mvo_: I have, in /etc/apt/sources.list.d/
[15:07] <mvo_> Riddell: aha, what is the binary package name I need to install to trigger the problem?
[15:07] <Riddell> mvo_: I've only installed kubuntu-desktop, the issue is with kubuntu-plasma5-desktop
[15:07] <mvo_> Riddell: thanks, that was the name I missed
[15:15] <mvo_> Riddell: so apt tries to keep it because installing it would causing removals of a package with a higher "score", but there is something more going on it seems. with the ppa and the landing silo I can not install kubuntu-desktop ( kubuntu-desktop : Depends: plasma-desktop but it is not going to be installed)
[15:16] <Riddell> mvo_: I don't think I've tried that, plasma 5 overlaps with the old stuff in various places so I'm not trying to support going back the way
[15:16] <mvo_> Riddell: which seems to come from a conflict of plasma-workspace against klipper
[15:16] <mvo_> Riddell: aha, ok
[15:17] <Riddell> mvo_: so maybe I should just keep the name of the meta package the same as kubuntu-desktop
[15:18] <mvo_> Riddell: the breaks in powerdevil says "Breaks: kde-workspace-data (<< 4:4.98.0)" - would that be a option? a updated kde-workspace-data ?
[15:18] <Riddell> mvo_: nah kde-workspace is going away in plasma5 land
[15:18] <mvo_> Riddell: that may well make sense, if kubuntu-desktop is going to vanish
[15:19] <mvo_> Riddell: ok, that is good to know, give me a sec then
[15:21] <mvo_> Riddell: if its going away then you may simply add a transitional package for those, I don't really know much about the way kde is packaged (or develooped :) so take my advice with a grain of salt. but if it is not co-installable, well :)
[15:23] <Riddell> mvo_: hmm yes that's another idea
[15:23] <mvo_> Riddell: a direct conflict/break in the kubuntu-plasma5-desktop would also work
[15:23] <Riddell> aah yes
[15:24] <Riddell> good, I'll play around, thanks mvo_
[15:24] <mvo_> Riddell: good luck and sorry that this is so complicated, I wonder/wondered if it would be worth  to add/support a "obsoletes" tag just like in rpm
[15:41] <sil2100> didrocks: so, I was wondering... since in cu2d whenever, let's say, the cu2d-apps-head-2.1build job has finished with success, jenkins automatically started the cu2d-apps-head-2.2check job
[15:41] <sil2100> didrocks: while I didn't see any triggers configured from the jenkins side
[15:41] <sil2100> didrocks: nor in the cu2d scripts being executed
[15:41] <didrocks> sil2100: there was master job IIRC
[15:42] <didrocks> let me check
[15:42] <sil2100> Ah
[15:42] <sil2100> !
[15:42] <didrocks> https://wiki.ubuntu.com/DailyRelease/StackPublish#Different_phases_of_one_stack
[15:42] <didrocks> this diagram can help
[15:43] <sil2100> didrocks: I see the job, hah, makes sense now
[15:43] <didrocks> so…
[15:43] <sil2100> Thanks!
[15:43] <didrocks> you have the master job
[15:43] <didrocks> which triggers the prepare jobs
[15:43] <didrocks> which was traking the prepare-project ones, one per project on that stack
[15:44] <didrocks> then, master was chaining (once prepare finishes successfully or only having warnings) to 2 jobs in parallel
[15:44] <didrocks> build and check
[15:44] <didrocks> both were chaining to the publish one
[15:44] <didrocks> this is a simplified case, there is the waitonstacks in reality, but not needed for that demonstration
[15:44] <didrocks> sil2100: does that make sense? ^
[15:47] <sil2100> didrocks: makes sense indeed, thanks :)
[15:47] <didrocks> yw ;)
=== lutostag_ is now known as lutostag
[16:37] <bdmurray> xnox: did you have a look at the issue regarding Contents.gz or did we win the race condition?
[17:00] <brendand> does anyone know how to use a binary from the build at build time?
[17:00] <brendand> i want to use a binary provided by the package i'm writing tests for, in the tests
[17:01] <cjwatson> mangle paths, or run the tests in question via autopkgtest
[17:17] <xnox> bdmurray: no, not yet. will look into it today.
[17:18] <xnox> LocutusOfBorg1: \o/
[17:19] <xnox> smb: so which bug did you file about ubiquity?
=== roadmr is now known as roadmr_afk
[18:01] <smb> xnox, bug 1342071
[18:01] <ubottu> bug 1342071 in ubiquity (Ubuntu) "Invisible installer dialog on VM iso installation" [Low,New] https://launchpad.net/bugs/1342071
[18:02] <smb> installer dialogue is a bot off as I mean the "eject media and press enter" back on the framebuffer
=== alexisb is now known as alexisb_lunch
[18:14] <xnox> smb: yeah. and i don't know how to make it more reliable.
=== rpadovani_ is now known as rpadovani
=== lubko is now known as zmok
[18:18] <smb> xnox, Hm, ok. Probably I should investigate a bit more into it. I was not sure it ever really was brought up and I get surprised every cycle when I play around with VM installations :-P
[18:19] <smb> At least as long as I do them manually and not through netinst
[18:20] <xnox> smb: i think we should be doing systemd style pivot into a shutdown initramfs that shows that text....
[18:20] <xnox> smb: at the moment however it's a jumbo between kernel, plymouth messages and that text.
[18:22] <smb> xnox, Yeah, this has been a pain in other senses as well (racing on the way up). Though I cannot help myself from being doubtful that systemd is less painful when taking over the world.
[18:33] <xnox> smb: i haven't yet planned how to do ubiquity with systemd.
[18:33] <xnox> smb: i believe we will have to conflict and/or replace targets. or something like that.
[18:36] <smb> xnox, Its not so much knowledge that makes me doubtful. Though I cannot decide myself whether I should call it pessimistic or realistic. >:)
=== roadmr_afk is now known as roadmr
=== timrc is now known as timrc-afk
[19:24] <brendand> is there any variable i can use in debian/rules to reference the directory like 'build-area/url-dispatcher-0.1+14.10.20140619/obj-x86_64-linux-gnu'
[19:24] <brendand> i.e. the directory where binaries are built into
[19:33]  * hallyn feels all accomplished now that he created a debian mentors account
[19:34] <hallyn> slangasek: dunno if it helps in anyway, but i pushed cgmanager to mentors.debian
[19:53] <xnox> hallyn: \o/
[19:53] <xnox> hallyn: let me review that =)
[19:53] <xnox> hallyn: well there are lintian errors already =)
[19:57] <hallyn> xnox: the bad-distribution-in-changes-file unstable error?
[19:57] <xnox> hallyn: nah, I'll comment on mentors, I see a few other issues.
[19:57] <hallyn> cool, thanks
=== timrc-afk is now known as timrc
[20:14] <hallyn> xnox: when responding to feedback with a new pkg, do i bump the version as i would in archive/ppa, or do i just delete and re-upload?
[20:14] <hallyn> (re-upload would be suboptimal as feedback-as-teaching is lost)
[20:17] <xnox> hallyn: well, with mentors.
[20:17] <xnox> hallyn: you would keep the version the same, but keep adding things in the changelog.
[20:17] <xnox> e.g. * Fixed foobar and bar in jars.
[20:18] <xnox> hallyn: and published a second comment about binaries.
[20:24] <hallyn> xnox: i did look for an ITP bug to close, but didnt' see one.  the, uh, other cgmanager upload didn't close one so i assumed that was an optional formality.  is it not?
[20:26] <xnox> hallyn: in Debian, the person who "Intends To Package" should open an "Intends To Package" bug against "WNNP" package. And close it on the first upload into debian.
[20:26] <xnox> hallyn: I don't see any prior uploads in Debian.
[20:26] <xnox> hallyn: there is no ITP bug equivalent in Ubuntu.
[20:27] <xnox> https://www.debian.org/devel/wnpp/
[20:27] <hallyn> xnox: right, there is a cgmanager (0.20 version) upload to ftp.debian somewhere.  that's the one i meant.
[20:27] <hallyn> ok, will open that bug then
[20:28] <xnox> hallyn: you may use $ report-bug or just construct email by hand. They are cc'ed to debian-devel by default, so you can see plenty of examples.
[20:29] <xnox> hallyn: i really don't see cgmanager 0.20 upload, that got accepted.
[20:30] <hallyn> it didn't get accepted
=== alexisb_lunch is now known as alexisb
[20:38] <hallyn> argh, i hate the symbols files :)
[21:07] <doko> xnox, please don't revert gobjc back, won't help, and won't help for gfortran either. tvoss did promise to be ready today, so we can point to 4.9 again
[21:10] <xnox> doko: why will it "won't help" ?
[21:11] <xnox> doko: and it's not a revert, per se. At the moment a non-matching library was getting installed for the default compiler... Not sure how fortran operates, but it seems to be buildable.
[21:12] <xnox> doko: unlike fortran, which is a binary in path, cc1obj is just an internal gcc private executable. one uses gcc to compile objc code.
[21:19] <doko> xnox, same as f951
[21:20] <xnox> doko: ok, so when you/slangasek reverted to 4.8, why was it not done for gobjc, gojbc++ and fortran as well? given that it left those in complete FTBFS state.
[21:20] <xnox> (in -proposed and -release)
[21:23] <doko> xnox, because fortran is an ABI transition which already was in progress
[21:23] <slangasek> xnox: because we were implementing an immediate short-term fix for a critical phone issue, leaving a few packages ftbfs in the short term is acceptable collateral damage in the general case
[21:23] <doko> and I didn't want to investigate if it is safe to revert gobjc
[21:23] <slangasek> xnox: and gcc-4.9 is supposed to be made the default again RSN
[21:23] <doko> if you did investigate, then sure, that might be safe
=== salem_ is now known as _salem
[22:21] <hallyn> xnox: looking at the dpkg-gensymbols output for libcgmanager0, it gives me symbol@Base...  with netcf it gives me symbol@NETCF_version.
[22:22] <hallyn> problem with my .pc file?
[22:27] <xnox> hallyn: not the .pc file -> that one just encode paths to your header files & which libraries to link/depend on.
[22:27] <xnox> hallyn: if you want to version your symbols, you'd need to use libtool symbol versioning facilities.
[22:28] <hallyn> xnox: and if i don't want to?
[22:29]  * hallyn looks to see what doing that might entail
[22:30] <xnox> hallyn: you are fine just as it is. if later you want to update a symbol you would be able to provide two versions of the same symbol and mark one of them the default.
[22:30] <xnox> hallyn: or like, just don't break you api/abi =)
[22:31] <hallyn> xnox: but then how do i generate a symbols file,
[22:31] <hallyn> i thought the "*@LIB_version package-version" was the whole point
[22:31] <xnox> hallyn: the debian/libcgamanger0.sybmols?
[22:32] <xnox> https://wiki.debian.org/UsingSymbolsFiles ?
[22:37] <xnox> hallyn: the point of debian/*.symbols file to list _all_ symbols and when they were introduced. Such that you can catch if they change or get removed, and also get correct dependencies depending on which apis are used.
[22:37] <hallyn> yeah that's where i'm looking.  that gives me a huge list, which you seemed not to want for netcf
[22:38] <hallyn> ok - i'll upload with the results of that- thanks
[22:38] <xnox> hallyn: right, so netcf is special. Upstream has versioned all of their symbols very tightly, hence debian/libnetcf1.symbols is ok to use wildcards to get all symbols covered.
[22:39] <xnox> hallyn: but that doesn't help to catch, if e.g. upstream make a mistake.
[22:40] <xnox> hallyn: e.g. I like dbus-cpp symbols files the best.
[22:40] <hallyn> netcf does that in src/netcf_public.syms?
[22:40] <hallyn> dbus-cpp symbols?
[22:41] <hallyn> the package?
[22:42] <hallyn> nope
[22:42] <xnox> hallyn: this symbols file for libcgmanager is correct one http://paste.ubuntu.com/7800703/
[22:43] <hallyn> xnox: ok, that's what i've got (except 0.27 :)
[22:43] <xnox> hallyn: in libnih, we do version symbols using a libtool versioning script e.g. https://github.com/keybuk/libnih/blob/master/nih/libnih.ver hence they are not @Base.
[22:43] <xnox> hallyn: so just stick that into debian/libcgmanager0.symbols and you are done.
[22:43] <hallyn> xnox: thanks.
[22:45] <hallyn> xnox: (still looking at dbus-cpp)
[22:45] <xnox> hallyn: that one is c++ hence symbols are different per-platform and 32/64/big/little.
[23:00] <mbiebl> cyphermox_: calestyo being pleasant as always (re that NM bug)
[23:00] <mbiebl> anyway, since we basically all agree, I'll try to cook up a patch and run it by you
[23:05] <cjwatson> brendand: "build-area/url-dispatcher-0.1+14.10.20140619" is almost certainly just your current directory; no need to put that together.  For the rest of it you want "obj-$(DEB_HOST_GNU_TYPE)".  You should normally put "DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)" near the top of debian/rules to make sure that variable is initialised.
[23:06] <cjwatson> brendand: But "obj-$(DEB_HOST_GNU_TYPE)" is something that your package's own build system controls - it's not set by anything central.  So if your package is buggy it's possible it's being set from something else, e.g. DEB_BUILD_GNU_TYPE.  You should really grep your package's source code to find out where that's set.
[23:06] <cjwatson> brendand: Or perhaps your package's build system.  For instance some cdbs classes set $(DEB_BUILDDIR) to that.
[23:07] <cjwatson> Or indeed some debhelper modes.
[23:30] <infinity> robert_ancell: 1:2.8.3-0ubuntu1build1 really?
[23:31] <infinity> robert_ancell: ITYM -0ubuntu2 ;)
[23:32] <robert_ancell> infinity, which package?
[23:32] <infinity> robert_ancell: That was calligra.  I noticed it cause I was looking at the FTBFS.
[23:33] <robert_ancell> Ah, I think I did that because I don't have access to lp:~kubuntu-packagers/kubuntu-packaging/calligra
[23:33] <robert_ancell> but I'm not sure it's valid :)
[23:33] <infinity> robert_ancell: For future reference, "dch -R" intelligently does the right thing (-NbuildN for unmodified Debian stuff, increments -NubuntuN for not)
[23:33] <robert_ancell> ta, didn't know that
[23:34] <infinity> robert_ancell: Oh, if it was intentional cause you expected them to throw it away, that sort of makes sense, ish. :)
[23:34] <robert_ancell> yeah.