=== _salem is now known as salem_
[00:33] <mdeslaur> bluesabre: someone from the SRU team needs to push the packages to -proposed. I'm not in the SRU team, so it's out of my hands.
[00:54] <hallyn> xnox: thanks!
[01:02] <hamiltont> I'm having trouble specifying vga=XXX as a kernel param. None of video modes match tables I've found
[01:03] <hamiltont> See http://imgur.com/LmYoe6o for example
[01:03] <hamiltont> (for the table of video modes I'm seeing output)
[01:03] <hamiltont> Also I entered vga=774, and the kernel seems to think I've entered video mode number 306
[01:04] <tarpman> hamiltont: 0x306, probably
[01:04] <tarpman> (no idea about the rest of your question, sorry)
[01:05] <hamiltont> No worries. Not sure I understand your reply. The modes are specified in hex, and I should try vga=0x306?
[01:05] <tarpman> "the kernel seems to think I've entered video mode number 306" -- hex 306 corresponds to the decimal 774 you entered
[01:05] <hamiltont> ah awesome
[01:06] <hamiltont> That shoudl let me specify any of the values listed in the table, which is really all I need to get it working
[01:06] <hamiltont> just curious why it doesn't correspond to any tables I can find, but I don't need to know
[01:06] <hamiltont> thanks
[01:35] <hamiltont> Does anyone know if it's possible to access a root shell during debian-installer? The shells on alt-F2 and alt-F3 do no appear to allow root
[01:36] <hamiltont> They are both busybox-based
[01:36] <hamiltont> and I can't run scripts owned by root
[01:36] <sarnold> you can't? o_O what error do you get?
[01:36] <hamiltont> permission denies
[01:36] <hamiltont> ed*
[01:37] <hamiltont> script I'm looking at is marked +x, and owned by root:root
[01:37] <hamiltont> I'm trying to run by doing ./script.sh
[01:37] <sarnold> what interpreter is it trying to use? does that interpreter exist? do all the libraries needed for that interpreter exist?
[01:37] <hamiltont> Using "sh script.sh" reports no permission error, but does not seem to run the script either
[01:38] <hamiltont> trying to use /bin/sh
[01:38] <hamiltont> I'd guess I'd see an error about libraries if they didn't exist
[01:38] <sarnold> I think last time I saw missing libraries needed for an interpreter, "permission denied" _was_ the error :)
[01:39] <hamiltont> Hmmm, interesting
[01:39] <sarnold> course that was back in the mists of time
[01:39] <hamiltont> perhaps that's a busybox failing, I tried to run this on another machine under bash and it prompted reported library problems
[01:40] <hamiltont> but I do seem to be root...just created a new file and it's also owned by root:root
[01:40] <hamiltont> so you're probably correct...the error is misleading me
[01:40] <sarnold> it's a long shot.. any chance you have strace available? strace is worth its weight in gold when debugging problems..
[01:41] <hamiltont> No luck :-/ It does have "set -x", so that's something, but the error is the same with that turned on
[01:41] <sarnold> how about ldd /bin/sh  ?
[01:42] <hamiltont> no luck on ldd either, just tried :-p
[01:42] <hamiltont> busybox can be a pita!
[02:01] <RAOF> bluesabre: Those SRUs are now testable in trusty-proposed, or will be once the buildds catch up.
[02:02] <bluesabre> oh, thanks a lot RAOF!
=== salem_ is now known as _salem
[03:23] <hamiltont> Does anyone have a sample of bash for detecting debug/verbose/etc from /proc/cmdline?
=== Ursinha is now known as Ursinha-afk
=== iulian is now known as Guest59033
[06:36] <pitti> Good morning
[07:05] <tvoss> doko_, good morning
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== Ursinha-afk is now known as Ursinha
[07:14] <dholbach> good morning
[07:15] <pitti> dpm: \o/
[07:15] <pitti> ./es/LC_MESSAGES/dialer-app.po
[07:15] <dpm> awesome :)
[07:16] <pitti> dpm: so the export worked fine; I'll build fresh packs then
[07:16] <dpm> pitti, excellent
[07:17] <infinity> pitti: Dude, email me some of those strawberries.  They look fantastic.
[07:17] <pitti> infinity: hehe -- that's a quality you can only get when plucking yourself :) (and eating a ton right on the field)
[07:18] <infinity> pitti: So very jealous and hungry now. :P
[07:19] <pitti> infinity: I'd love to keep some and bring them to the next sprint, but they might not be as enjoyable as today any more :/
[07:21] <pitti> haha! https://plus.google.com/u/0/+YonatanZunger/posts/EAZcFMeCRrG
[07:21] <pitti> unicode FTW
[07:21] <pitti> man, all these times when I was looking for a "man in business suit levitating" glyph and didn't find one..
[07:30] <xnox> hallyn: i'm west coast USA today =)
[07:31] <xnox> hallyn: please fix the symbols file though.
[07:49] <OdyX> tkamppeter: you could sync gutenprint 5.2.10-2
[08:08] <brendand> anyone know where to get ahold of jonathan lange or rob collins? this bug https://bugs.launchpad.net/testtools/+bug/1331358 in testtools is impacting on phone test results
[08:08] <ubottu> Ubuntu bug 1331358 in testtools "skip decorated tests still have setUp and tearDown run around them" [Undecided,New]
[08:09] <brendand> i could try and fix it myself of course
[08:21] <pitti> brendand: lifeless is rob collins
[08:23] <brendand> lifeless, hello?
[08:25] <pitti> brendand: might not be the best time for him, he's in Australia
[08:25] <RAOF> NZ, actually, which makes it a worse time :)
[08:27] <brendand> pitti, yeah i knew that. but he's marked active, and you never know - it's only 8:30pm
=== doko_ is now known as doko
[08:28] <doko> tvoss: ?
[08:39]  * ogra_ sighs ... the new inline comments feature in LP is sending annoyingly big emails in MP mails ... 
[08:40] <ogra_> would be nice if it wouldnt always attach the full patch for a one line comment thats somewhere in the middle
[08:41] <infinity> ogra_: It's a work in progress, attempting to be more intelligent about context is in the plans.
[08:41] <ogra_> cool
[08:41] <ogra_> then i'm willing to live with the annoyance for a while
[08:53] <pitti> dpm: Skipping domain dialer-app with too low priority 0
[08:53] <pitti> dpm: can you please fix?
[08:54] <dpm> pitti, argh, yes
[08:55] <pitti> dpm: also, there's a lot of programs with prio 0 which are wrong: http://paste.ubuntu.com/7662665/
[08:55] <pitti> dpm: perhaps for now I should treat priority 0 as "unset" and include them?
[08:56] <dpm> pitti, if I do this quickly, this priority change will be in the next .json files export. I've fixed dialer already
[08:56] <dpm> I'Ve got a few minutes, bbiab
[08:56] <pitti> dpm: sorry, de-duped: http://paste.ubuntu.com/7662669/
[08:58] <dpm> pitti, ok, thanks. I see that none of these affect the touch langpacks, so I've just fixed dialer for now. It should be in the next json export in the next few minutes. The other ones might take me a bit, but I can fix them all today
[08:58] <pitti> dpm: me too, need to disappear for ~ 2 h
[08:59] <pitti> dpm: thanks muchly
[08:59] <dpm> well, thank you for the list :)
[08:59] <Saviq> Mirv, https://code.launchpad.net/~saviq/ubuntu-ui-toolkit/new-qt-dep-names/+merge/223522
[09:01] <tkamppeter> OdyX, does your Gutenprint package contain all the recent Ubuntu changes, especially "debian/rules: Touch the *.ppd-updater files in override_dh_fixperms, as
[09:01] <tkamppeter>     in override_dh_install-arch the change does not stay." from 5.2.10~pre2-0ubuntu2?
[09:02] <OdyX> tkamppeter: kinda. It's installed by "install" directly instead of a .install file AFAIK. Also see the preinst for that case.
[09:04] <tkamppeter> OdyX, so I can sync without regression?
[09:11] <OdyX> tkamppeter: I think you can. :)
[09:11] <OdyX> tkamppeter: also, what is blocking cups 1.7.3-3 ?
=== lisca is now known as lubko
=== vrruiz_ is now known as rvr
=== Guest59033 is now known as iulian
[09:44] <rbasak> infinity: any progress on the juju-core power ftbfs please? I created bug 1329295 to track this. Mind if I assign this one to you?
[09:44] <ubottu> bug 1329295 in juju-core (Ubuntu) "juju-core 1.18.4-0ubuntu1 FTBFS on powerpc in utopic-proposed" [High,Triaged] https://launchpad.net/bugs/1329295
[09:51] <infinity> rbasak: I might a little, yeah.  Given I know exactly nothing about Go. :P
[09:51] <infinity> rbasak: But I will play with reproducing a bit more.
[09:51] <infinity> rbasak: Or, rather, reproducing the failure to fail on the porter, which is what's really odd.
[09:56] <rbasak> infinity: yeah, without reproduction on the porter I have no chance to even begin to look at it :-/
[10:05] <bdrung_work> cjwatson, i saw that you committed to the debian sbiuld git repo. can you have a look at the patches attached to Debian bug #714883?
[10:05] <ubottu> Debian bug 714883 in sbuild "sbuild: Support --add-repository to add an apt source for just one build" [Wishlist,Open] http://bugs.debian.org/714883
[10:06] <tkamppeter> OdyX, gutenprint I have synced now, thanks for your package. CUPS 1.7.3-3 got auto-synced, but probably only very recently, so that it does not appear in the updates of Utopic yet.
[10:17] <Chipaca> ogra_: low-priority ping, about ppu, when you've got 5
[10:18] <ogra_> sure
[10:18] <Chipaca> ogra_: is that an "I have 5 right now"?
[10:18] <ogra_> yeah
[10:19] <Chipaca> ogra_: so, I need sponsors for my PPU application, and AIUI you've reviewed some of my packaging of ubuntu-push. If that is correct, could you add yourself to https://wiki.ubuntu.com/Chipaca/PPU and lie^Wsay nice things about me?
[10:20] <ogra_> sure, no prob, when is your meeting ?
[10:20] <Chipaca> ogra_: I haven't asked for one yet
[10:20] <Chipaca> ogra_: AIUI I need to get a couple of sponsors, *then* ask
[10:20] <Chipaca> of course, i might be wrong -- i'm rather dense when it comes to this particular kind of bureaucracy
[10:21]  * Chipaca can neither confirm nor deny being dense about anything else at all
[10:21] <ogra_> heh, i'll add something, no worries
[10:21] <Chipaca> ogra_: thanks!
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
=== _salem is now known as salem_
=== rickspencer3_ is now known as rickspencer3
[12:58] <kgunn> doko: cjwatson hey guys....i hope its us doing something wrong, but we don't think so...
[12:58] <kgunn> https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1331435
[12:58] <ubottu> Ubuntu bug 1331435 in gcc-4.9 (Ubuntu) "Build problem: error: ‘size_t’ does not name a type" [Undecided,New]
[12:59] <kgunn> would one of you wanna work with camako on our team to help figure it out ?
[12:59] <kgunn> we've ground to a halt, its effecting our ci builds on our devel branch too
[13:00] <doko> kgunn, which version?
[13:01] <kgunn> doko: i'm sorry...which version of what ?
[13:02] <kgunn> doko: lemme grab a build log
[13:02] <doko> yes, build log would help
[13:06] <kgunn> https://launchpadlibrarian.net/177856545/buildlog_ubuntu-utopic-armhf.mir_0.3.0%2B14.10.20140618-0ubuntu1_FAILEDTOBUILD.txt.gz
[13:07] <kgunn> doko: sorry about that...thot it was in the bug, i added it there....link as well ^
[13:07] <doko> kgunn, is <cstddef> or <stddef.h> included?
[13:14] <camako> doko: (taking over from kgunn, who has a meeting) This is not something that failed until today. Haven't made any changes. Nevertheless adding those headers anyways, does not help.
[13:16] <camako> doko, we had other weird problems of this sort due to 4.8 to 4.9 changeover
[13:16] <doko> camako, afaics from the build log, your are still using 4.8, aren't you?
[13:16] <kgunn> camako: he knows :)
[13:17] <kgunn> doko: that log is from build silo 16....so it'd be whatever is in utopic
[13:17] <doko> camako, where can I get the source for this package?
[13:17] <kgunn> doko: lp:~mir-team/mir/0.3
[13:17] <camako> We had CI guys mess with this silo and switch it to 4.9
[13:19] <doko> xnox, ^^^ are the android headers mucking around with standard types?
[13:19] <asac> ricmm: rsalveti: ^^ you might know too
[13:20] <ogra_> right, thats an rsalveti question
[13:20] <sil2100> I acutally wanted to check that, but my armhf chroot takes ages to build mir
[13:21] <Saviq> sil2100, can I help with that?
[13:21] <camako> sil2000, cross_compile reproes the issue
[13:22] <camako> sil2100, you can use the cross-compile-chroot.sh in lp:~mir-team/mir/0.3 to repro it under a min
[13:26] <sil2100> camako: cross-building for the win then
[13:26] <sil2100> My chroot should just die...
[13:29] <doko> camako, so this is built using 4.8 if no other dependency ppa's are used
[13:31] <camako> doko, you 're probably right... I got word from robru that it was pointed to 4.9 though...
[13:31] <camako> it == silo
[13:33] <camako> sil2100, if it's your first time, it'll take a bit longer though... See "cross_compile" section in http://unity.ubuntu.com/mir/building_source_for_android.html
=== dholbach_ is now known as dholbach
[13:35] <dholbach> pitti, how can I find out more why "ubuntu-bug bla.crash" does not file a bug for me? :)
[13:36] <pitti> dholbach: because we haven't turned LP bug submission back on
[13:36] <dholbach> aha!
[13:36] <pitti> dholbach: sorry, bogus
[13:36] <pitti> dholbach: that's only for crashes, not bugs
[13:36] <pitti> dholbach: any stderr?
[13:36] <pitti> dholbach: ok, engaging brain: it's ubuntu-bug, but a crash :)
[13:37] <pitti> dholbach: you can comment out the problem_types line in /etc/apport/crashdb.conf
[13:37] <kgunn> doko: camako on the 4.9 vs 4.8 thing
[13:37] <dholbach> pitti, no, nothing on stderr
[13:37] <kgunn> i learned from slangasek y'day that the 4.9 lib was what is being used...but that the libstdc++-dev was 4.8
[13:37] <pitti> seb128: WDYT, time to enable apport for LP on utopic?
[13:38] <kgunn> so the logs show the build against 4.8....but in reality the lib is 4.9
[13:38] <kgunn> doko: i assume you knew that tho ?
[13:38] <doko> kgunn, yes, the runtime library, but that wouldn't explain any issue with a header file
[13:38] <kgunn> ...this was based on the _original_ idea that ABI hadn't broken
[13:38] <dholbach> pitti, thanks!
[13:39] <dholbach> pitti, I already thought I was doing it wrong ;-)
[13:39] <seb128> pitti, +1
[13:41] <pitti> dholbach, seb128: ^ uploaded
[13:41] <pitti> dholbach: thanks for the reminder :)
[13:41] <seb128> pitti, danke
[13:41] <dholbach> excellent!
[13:43] <Saviq> ricmm, https://code.launchpad.net/~saviq/unity-mir/new-papi-dep-name/+merge/223560
[13:45] <Saviq> ricmm, for the future: transitional packages need to be Arch: any and Multi-Arch: foreign
[13:45] <Saviq> ricmm, otherwise cross-building breaks
[13:46] <ricmm> sorry, updating that build-dep must've escaped me... somehow
[13:46] <ricmm> Saviq: landeded it
[13:49] <Saviq> ricmm, tx
[13:50] <rsalveti> morning
[13:52] <ricmm> Saviq: will you silo that yourself?
[13:52] <Saviq> ricmm, yeah
[13:52] <Saviq> ricmm, unless you have somewhere for it to hitch a ride?
[13:52] <ricmm> I dont, sorry
[13:53] <Saviq> ricmm, like silo 15?
[13:53] <ricmm> thats not landing yet
[13:53] <Saviq> ok, then whenever
[13:55] <rsalveti> kgunn: is that build failure only happening on armhf?
[13:55] <rsalveti> I did rebuild mir yesterday, but only armhf failed but due a different issue
[13:55] <kgunn> rsalveti: i believe, camako ? ^
[13:55] <camako> rsalveti, kgunn, yes
[13:55] <rsalveti> I don't get why armhf only though
[13:56] <rsalveti> as we're building the android backend on x86 as well
[13:56] <rsalveti> /usr/include/c++/4.8/mutex:779: undefined reference to `std::__get_once_mutex()'
[13:56] <rsalveti> this is the issue I had yesterday
[13:56] <rsalveti> just armhf as well
[13:57] <kgunn> rsalveti: that was fixed as part of https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1331242
[13:57] <ubottu> Ubuntu bug 1331242 in gcc-4.9 (Ubuntu) "libstdc++6: missing symbols std::__once_functor, std::__get_once_mutex(), `std::__set_once_functor_lock_ptr(std::unique_lock<std::mutex>*)" [Critical,Fix released]
[13:57] <camako> yea this is a different issue
[13:57] <kgunn> rsalveti: so once that was cleared, we saw this new issue
[13:58] <rsalveti> weird, wonder why my build didn't use latest gcc, but anyway
[13:58] <rbasak> ScottK: is a clamav merge on your radar? I see that you only uploaded to Debian yesterday, so no rush - just checking as I'm going through the whole list that ubuntu-server is subscribed to.
[14:00] <dholbach> seb128, do you know which package to install to make qt4 apps look less "funny" on utopic? :)
[14:01] <seb128> dholbach, I don't, sorry, maybe ScottK or Riddell or Mirv know?
[14:01] <Riddell> I recommend kubuntu-desktop
[14:02] <dholbach> right...
[14:02] <Riddell> although qt4 should magically detect it's running under gnome and use the gtk theme I think
[14:02] <Mirv> :)
[14:02] <Mirv> dholbach: what's funny about them?
[14:03] <Mirv> dholbach: kubuntu-desktop would surely work fine, but other than that the only thing that comes to my mind is checking appmenu-qt is installed which gives you global menu bar menus
[14:04] <doko> rsalveti, kgunn, ricmm, camako: blame android-headers please for that case, updated the bug report
[14:04] <dholbach> Mirv, looks like some theming engine is missing or something: http://people.canonical.com/~dholbach/tmp/screenshot.png
[14:04] <dholbach> Mirv, it looks like an ancient gtk theme
[14:04] <rsalveti> yeah, this is not a toolchain issue, still not sure why only happens on armhf though
[14:04] <rsalveti> probably on x86 the proper headers get included in the include chain
[14:05] <tvoss> rsalveti, or a missing define somewhere?
[14:05] <rsalveti> kgunn: camako: see that the error only happens when building the test
[14:05] <rsalveti> tvoss: size_t
[14:05] <rsalveti> missing a include
[14:05] <rsalveti> /usr/include/android/system/graphics.h:269:5: error: 'size_t' does not name a type
[14:06] <camako> rsalveti, so have the android headers changed in the last day or two? This wasn't a problem before..
[14:07] <rsalveti> camako: changed that yesterday, requested by kdub, to include some new entries added in android 4.4
[14:08] <camako> rsalveti, ok android headers changed, things got moved around, Mir fails, and probably needs additional headers now... gotcha
[14:08] <rsalveti> camako: one quick way to fix that is to include the missing header in the test case
[14:08] <rsalveti> itself
[14:08] <tvoss> rsalveti, yup, just tried that
[14:09] <rsalveti> tvoss: did it work?
[14:09] <tvoss> rsalveti, yup, seems so :) but the test case compile works now
[14:09] <rsalveti> tvoss: great, kgunn camako then please do the same
[14:10] <camako> rasalveti, tvoss, will do thx
[14:10] <rsalveti> tvoss: what did you include, stddef.h?
[14:11] <rsalveti> can probably change the header itself as well
[14:11] <Mirv> dholbach: hmm, my Spotify looks good at least
[14:12] <dholbach> you're right - for me it was skype and musique looking funny
[14:15] <doko> rsalveti, yes, stddef is needed in graphics.h
[14:17] <rbasak> stokachu: fancy merging keepalived again, please?
[14:17] <rsalveti> doko: yeah, saw the bug, just uploaded the fix
[14:17] <rsalveti> thanks
[14:19] <rsalveti> camako: kgunn: also fixed android-headers, once that lands in release you can try rebuilding mir
[14:19] <camako> rsalveti, sounds good
[14:20] <tvoss> rsalveti, stddef.h should do it, trying cstdlib in the test-case only now
[14:20] <tvoss> rsalveti, just for cross-checking
[14:21] <rsalveti> sure
[14:39] <seb128> is there an easy way to get the upstart env from a running user session in a vt?
[14:40] <seb128> like I logged in unity8 and I want to start/stop jobs from a vt
[14:40] <seb128> I can get the /proc/`pidof unity8`/environ UPSTART_.... definition and export it manually, that works but I was wondering if there was some less-manual way to do that
[14:41] <cjwatson> That's what I was about to suggest :)
[14:41] <cjwatson> It's basically just the same as attaching to a dbus session somewhere else, which to the best of my knowledge there's never been a non-manual tool for
[14:41] <seb128> k
[14:42] <seb128> so stupid command line question ... ;-)
[14:42] <seb128> if I "strings /proc/`pidof unity8`/environ | grep UPSTART" ... how can I redirect that to an export command?
[14:42] <cjwatson> export `...`
[14:43] <seb128> I know how to do it by putting in a file and editing the file to do an export, but i'm sure there is simpler way :p
[14:43] <seb128> oh, that easy?
[14:43] <seb128> cjwatson, thanks ;-)
[14:43] <stgraber> seb128: there's also /run/user/<uid>/upstart/sessions/<pid>.session
[14:43] <seb128> I was trying to "| export" with some use of xargs even, without luck
[14:43] <seb128> stgraber, thanks
[14:43] <cjwatson> can't use xargs because that would put it in a subshell which immediately exits
[14:44] <stgraber> though note that if you already have the init process pid anyway, you can just as well build the socket path yourself ;)
[14:46] <seb128> stgraber, well, same trick needed for dbus and other things
[14:46] <seb128> cjwatson, stgraber: thanks
[14:47] <cjwatson> also if you're doing it manually rather than using the file in /run/, "export `grep -z ^UPSTART_SESSION= /proc/PID/environ`" is easier than using strings
[14:47] <cjwatson> (grep -z leaves a trailing \0, but the shell ignores that so whatever)
[14:48] <seb128> good to know as well, thanks ;-)
[15:02] <hallyn> xnox: giving it a shot, this bit is black magic to me.  should i then bump the version?  (you've pushed the first it looks like?)
[15:05] <hallyn> really i wonder why it has that at all.  i didn't put it there...
[15:38] <hallyn> xnox: so should i be running dpkg-gensymbols against all the old versions to get the full historical list?
[15:41] <infinity> hallyn: If you want versioned deps to be as precise as possible, that would be the way to go.
[15:41] <infinity> hallyn: Otherwise, you'll get everything depending on your latest version, as you'll claim all the symbols appeared there.
[15:42] <hallyn> infinity: it's not some huge faux-pas to have version 2.4 change the .symbols contents for earlier packages?
[15:42] <hallyn> (doesn't break package builders or somesuch)
[15:42] <hallyn> ok, will do, thx
[15:42] <infinity> hallyn: Nah.  If you're generating a correct .symbols now, what you had before doesn't really matter.
[15:43] <infinity> hallyn: The basic idea is that if a package uses symfoo but not symbar, and symfoo appeared in upstream v1.2, but symbar appeared in v1.5, you want packages to depend on >= 1.2
[15:43] <infinity> hallyn: If you introduce a symbols file that claims everything appeared in 1.5, the deps are annoyingly a bit wrong (though it's not world-ending).
[15:44] <infinity> This is so much easier with libraries that version symbols sanely (like glibc), since you can just generate on the fly.  Sadly, very few do.
[15:45] <hallyn> (lessee if i can do something that can be described 'sane'.  looks simple enough...)
=== wendar_ is now known as wendar
=== darkbasic_ is now known as darkbasic
=== timrc is now known as timrc-afk
[17:21] <shadeslayer> bdmurray: how do I group together the same backtraces?
[17:21] <shadeslayer> bdmurray: in errors.ubuntu.com
[17:21] <shadeslayer> https://errors.ubuntu.com/problem/1a794f4f0b1fa61aa9916353ae643de6085125fc and https://errors.ubuntu.com/problem/2bb11f5013b5638956cbb06a6f822d811fde60a4 are the same
[17:23] <bdmurray> shadeslayer: there isn't a way at this point in time
[17:23] <shadeslayer> oh
=== timrc-afk is now known as timrc
[19:03] <mdeslaur> xnox: so, in the apparmor postinst script, I was doing invoke-rc.d apparmor reload, now that I'm adding an upstart job, I need to do something like "start apparmor ACTION=reload", but what if the user is running systemd? Is there a way for me to detect what init system is currently running?
[19:03] <mdeslaur> xnox: I can't just use invoke-rc.d, because I need more than 'start'
[19:09] <jdstrand> mdeslaur: slangasek mentioned that we may not want use the upstart job in that way, though I wasn't entirely clear why. I mentioned we could move the logic of the job out to a script and then have the job call the script and the postinst call the script
[19:09] <jdstrand> I can't recommend that we should do that, just mentioning it for background
[19:10] <mdeslaur> jdstrand: hrm interesting
[19:11] <slangasek> jdstrand, mdeslaur: the point there was that if anything referenced apparmor in its own 'start' condition (which we had discussed at one point), this would deadlock the upgrade
[19:11] <slangasek> given the current proposal, that's not an issue
[19:12] <slangasek> but as for passing different options to the upstart job... hmm
[19:12] <slangasek> this can probably be autodetected in the job, by checking UPSTART_EVENTS ?
[19:12] <slangasek> (and then you can just use invoke-rc.d)
[19:13] <mdeslaur> slangasek: I want to detect which init system is running in a postinst
[19:13] <slangasek> why's that?
[19:13] <slangasek> that's somewhat contrary of the general design of invoke-rc.d and friends
[19:13] <mdeslaur> of course, I'm not sure if adding custom ACTION commands is something that will be easy to port to systemd anyway, so perhaps it would be best to have a separate helper
[19:13] <slangasek> ... of?  contrary beside
[19:14] <mdeslaur> slangasek: the postinst needs to make apparmor invalidate the cache and rebuild policies, so it can't just be a 'start' command
[19:14] <mdeslaur> slangasek: so I'm not sure it fits well with invoke-rc.d
[19:14] <slangasek> mdeslaur: I'm not sure why it can't be
[19:15] <slangasek> that's what I'm saying, using $UPSTART_EVENTS you can detect the difference between "started at boot" vs "started from postinst"
[19:15] <slangasek> and have different behavior accordingly
[19:15] <slangasek> now, how you do the equivalent on systemd, I don't have an answer for offhand
[19:18] <mdeslaur> slangasek: hrm, where is $UPSTART_EVENTS documented with regards to being run in a postinst?
[19:18] <slangasek> mdeslaur: init(5), in the case of a manual start from a postinst it will be empty
[19:20] <mdeslaur> slangasek: oh! I understand now, thanks
=== roadmr is now known as roadmr_afk
[19:28] <lifeless> brendand: pitti: oh hai.
[19:28] <brendand> lifeless, hi!
[19:29] <brendand> lifeless, i filed a bug in testtools
[19:29] <brendand> lifeless, i'm glad to look at it myself if needed, but maybe you have an immediate answer
[19:29] <lifeless> the skip decorator decorates the method, setup and teardown are run by the framework, which means that that isn't a bug, its how the design works
[19:30] <lifeless> but I see the docs you quote
[19:30] <lifeless> so, will have to go and look at the python implementation
[19:30] <brendand> lifeless, yes - it does change the expected behaviour from the point of view of someone familiar with unittest
[19:32] <lifeless> oh man thats so ugly
[19:32] <lifeless> so sure, please do implement this for testtools
[19:32] <brendand> lifeless, any pointers?
[19:33] <brendand> lifeless, if i don't have to start from step 0, that would be appreciated
[19:33] <lifeless> you'll need to read the cpython implementation in Lib/unittest/case.py and then in testtools there is testtools/runtest.py where we pulled that logic sideways - you'll need to do the analogous thing there
[19:38] <lifeless> brendand: if you get stuck, gimme a shout
[19:39] <brendand> lifeless, that's definitely enough info, thanks
[19:42] <brendand> lifeless, so will __unittest_skip__ be present - i assume so?
[19:42] <lifeless> brendand: you know, I have no idea :)
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
=== timrc is now known as timrc-afk
[20:29] <doko> freetype and fontconfig -dev packages not multiarch? bad ...
[20:33] <slangasek> doko: see the longstanding bug report on the Debian BTS for freetype - freetype-config is part of the upstream build interface, and no one has yet given me a ready-to-apply patch for it
[20:34] <slangasek> I'll happily apply a fix if someone gives it to me, but so far the only people who care about multiarch coinstallability of freetype-dev are people building their own wine, and we have packages for that :)
[20:36] <doko> slangasek, isn't that just a sed removing the -L ?
[20:37] <slangasek> doko: bug log has details, I really can't remember right now :)
[20:37] <doko> pfff
[20:37] <doko> two ctte members as uploaders ...
[20:37] <slangasek> anyway, I don't need someone to tell me how to fix it, I need someone who cares to actually provide a patch, or else it'll remain a low priority for me
[20:38] <slangasek> doko: Keith has never, ever uploaded the package and I need to remove him from the Uploaders field
=== roadmr_afk is now known as roadmr
=== salem_ is now known as _salem
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
=== timrc-afk is now known as timrc
[23:01] <cjwatson> Riddell: looks like a bunch of KDE is stuck behind nepomuk-core - seems like just a missing "abi1" in rules?
[23:02] <cjwatson> (ignore if you already noticed)