[00:07] <xnox> cjwatson: is there any way to run memtest on an uefi based machine?
[00:07] <xnox> or should i force it booting with bios? (not sure if it can)
[00:11] <psusi> xnox, there was a multiboot build of memtest iirc... maybe grub-efi can load a multiboot image?
[00:13] <cjwatson> memtest upstream isn't willing to build both bios and uefi support into the same version, afaict
[00:13] <cjwatson> so I think the answer is no
[00:14] <cjwatson> multiboot might let you start the binary, but I don't think it makes it work :-)
[00:18] <psusi> is there a uefi build of memtest then?
[00:21] <cjwatson> I don't think so :(
[00:21] <cjwatson> not one I've seen anyway, been a while since I cared to look
[00:30] <xnox> cjwatson: http://www.memtest86.com/download.htm appears to claim uefi support. I'll try that one out.
[00:30] <cjwatson> ok ...
[00:42] <xnox> cjwatson: blimey, it has bling and 3d mouse pointer and everything.
[00:42] <xnox> cjwatson: it's an efi executable by the looks of things.
[00:47] <xnox> =(((( errors are popping up....
[03:47] <hallyn> slangasek: hi, regarding the move of OVMF.fd.  Does that require a Replaces: ?
[03:47] <hallyn> Or is it ok bc it's from the same source pkg?
[03:56] <hallyn> no i guess it'll need it.  that's for tomorrow i think
[04:02] <hallyn> slangasek: d'oh, nm - I was looking at the wrong version.  I see you did it.  sorry.
[04:14] <slangasek> hallyn: it does require replaces: - but see mjt's request to put the symlink in the ovmf package
[05:38] <pitti> Good morning
[06:01] <RAOF> pitti: Good morning!
[06:06] <ion> that
[07:11] <Unit193> mvo: Hello.
[07:11] <mvo> hey Unit193 - uhhh, I still have a upload that needs to be done, right?
[07:12] <mvo> (sorry!)
[07:12] <Unit193> mvo: Just needed to make sure a desktop file was fit for the package, yep: https://bugs.launchpad.net/bugs/1060543
[07:15] <Unit193> (Anywho, shower now)
[07:28] <pitti> infinity, slangasek: FYI, I changed the ppc64el tests to run with apt clone; so no aufs/overlayfs any more
[07:29] <Mirv> zyga: you should find bug #1282257 fixed now with 12.04 + SDK PPA
[08:07] <darkxst> xnox, bug 1284496: any idea what is causing that "half" gear, its surely not GNOME
[08:24] <dholbach> good morning
[08:29] <ion> that
[08:32] <zyga> Mirv: thank you
[10:27] <pitti> doko: I fixed python3.4's autopkgtest to also work in containers (i. e. on ppc64el): http://paste.ubuntu.com/6993709/
[10:27] <pitti> doko: do you want me to upload that, or do you just want to stage it in the Debian VCS?
[10:28] <pitti> doko: same problems/fix on 2.7 and 3.3, I can prepare and test debdiffs if you want
[10:36] <doko> pitti, would like to fix it in debian. will take your patch, and stgraber is scared by python anyway ...
[10:37] <pitti> doko: stgraber? :-)
[10:38] <pitti> doko: oh, I'm not planning to ask for a freeze exception for this; it's irrelevant for beta-1, I'm just walking through the ppc64el failures
[10:38] <doko> he has a cold ;p
[10:39] <pitti> doko: I'll prepare/test corresponding patches for 2.7 and 3.3 and hand them to you then, ok?
[10:40] <doko> pitti, yes, that would be nice. can you change this for the two other tests as well?
[10:40] <pitti> doko: sorry, which two other tests?
[10:41] <doko> ahh, only in 2.7 and 3.3
[10:41] <pitti> doko: in 3.4 there's just testsuite and testsuite-dbg
[10:41] <doko> yep, should be added there. using this to catch progressions
[10:42] <doko> applied for 3.4 locally
[10:43] <pitti> doko: ah, I see the "failing-tests" in 3.3; yes, will apply to those as well of course
[10:44] <pitti> doko: these aren't in 3.4, so I didn't know what you mean at first
[10:55] <doko> pitti, now added in 3.4
[10:56] <pitti> doko: thanks; I confirmed that it still works in qemu, too
[11:04] <pitti> doko: btw, would you mind fixing Vcs-* for python3.4? the ones at http://packages.qa.debian.org/p/python3.4.html don't work any more
[11:05] <doko> ohh, not yet created
[11:25] <pitti> doko: http://people.canonical.com/~pitti/tmp/python2.7.lxc-autopkgtest.debdiff and http://people.canonical.com/~pitti/tmp/python3.3.lxc-autopkgtest.debdiff
[11:32] <MacSlow> mhall119, hey there... do we have a developer-doc publishing process? I'm asking because I want know where to put my developer-docs for UbuntuTouch notifications.
[11:32] <MacSlow> mhall119, or can I just use the wiki as usual
[11:34] <doko> pitti, thanks, applied
[11:57] <xnox> pitti: so i did a mechanical port of ofono-scripts from python2 to python3. https://code.launchpad.net/~xnox/ubuntu/trusty/ofono/python3/+merge/208117 and it seems to mostly work.
[11:57] <xnox> pitti: can you test it a bit more? i don't quite know how to drive them and/or what the expected results should be.
[12:00] <pitti> xnox: oh, I'm currently at porting them
[12:00] <pitti> xnox: yes, the mechanical import is overzealous
[12:01] <pitti> I want to keep them bilingual to submit them to upstream
[12:01] <pitti> (I assigned the bug to me earlier)
[12:01] <pitti> xnox: yes, I'll test them
[12:05] <pitti> xnox: did you send anything upstream already? AFAICS there is only the ML, no bug tracker
[12:06] <pitti> xnox: I'll send my formatted patches, just want to refer to your post if you did already
[12:06] <xnox> pitti: nah, i didn't send it through.
[12:06] <xnox> pitti: i was not convinced about keeping them bilingual.
[12:07] <pitti> might be more palatable for upstream though, and not hard to do
[12:07] <xnox> pitti: looking at the port however, adding "from __future__ import print_function" below all shebangs should be sufficient to keep them bilingual.
[12:08] <pitti> I didn't do that, I just converted the few examples of print "foo", e to print("foo %s" % e)
[12:08] <pitti> (in the except: clauses); everywhere else it was already ok
[12:08] <xnox> pitti: also a few scripts used pygobject, so i've ported that go gi
[12:08] <xnox> pitti: i see =) fair enough.
[12:08] <pitti> *nod*
[12:09] <xnox> pitti: i think in like apparmor, i kept compat from 2.3 - 3.2 by using sys.stdout.write("%s\n" % foo)
[12:09] <xnox> but that was pain =)
[12:09] <pitti> xnox: yeah, I usually do that to replace print >> sys.stderr, "..."
[12:10] <pitti> i. e. sys.stderr.write("...\n")
[12:10] <xnox> yeap.
[12:20] <OdyX> tkamppeter: I've uploaded cups-filters 1.0.46-1 and cups 1.7.1-6 to unstable. They both have code to migrate the LOAD_LP_MODULES handling to cups-filters where they belong and there's quite a bunch of work for the systemd socket activation + exit-on-idle (which I took from you, but renamed according to upstream feedback). I'm interested in merging reasonable patches for the upstart support in Debian (although I have hard time seeing who would r
[12:37] <pitti> xnox: it seems  lp:~phablet-team/ofono/ubuntu is the official branch?
[12:38] <xnox> pitti: i dunno =) but looks like it might be.
[12:41] <pitti> rsalveti: ok, now I'm confused :)
[12:41] <xnox> pitti: i'd ask sergiusens =)
[12:41] <pitti> so confused that I'm even pinging the wrong person
[12:42] <pitti> sergiusens: so now I'm confused; I did the py3 port against git://git.kernel.org/pub/scm/network/ofono/ofono.git
[12:42] <pitti> sergiusens: and I'm about to port it to lp:~phablet-team/ofono/ubuntu
[12:42] <sergiusens> pitti, we moved to git to share with jolla
[12:42] <pitti> sergiusens: (older version, packaging changes, and I want to sneak in a fix for making it possible to purge ofono-phonesim-autostart)
[12:43] <pitti> sergiusens: so what is that github branch?
[12:43] <sergiusens> pitti, and have something that syncs in to our bzr branch
[12:43] <tkamppeter> OdyX, great. For Upstart the main problem is bug 1276713, I hope, xnox can help here.
[12:43] <sergiusens> pitti, that github branch is the ofono/ril spinoff (awe is trying to keep the code sane to propose an upstream merge sometime)
[12:44] <pitti> sergiusens: but apparently our packaging branch isn't based off that rilmodem github branch? at least our packaging branch doesn't have test/rilmodem/
[12:45] <OdyX> tkamppeter: ideally, prepare these patches in a master-ubuntu branch that has the current master branch merged; I'd review and include them
[12:46] <pitti> sergiusens: so you need the tests ported (and extended to cover test/rilmodem/) against that github branch, plus backporting the test to our bzr packaging branch?
[12:47] <sergiusens> pitti, one sec, looking for the documentation for this (it's a big sync mess)
[12:47] <OdyX> tkamppeter: I've also done the same patch replacement than you did for -5ubuntu3
[12:55] <sergiusens> pitti, lp:~phablet-team/ofono/rilmodem that's where the github repo is imported to
[12:55] <sergiusens> I'm plus 1 for an ofono-ril source package; but you need to take that to rsalveti ;)
[12:59] <pitti> sergiusens: ok, so I'll port the bits to the github branch and do a pull request; then, how does this get into the packaging branch?
[12:59] <sergiusens> pitti, and this is the https://code.launchpad.net/~phablet-team/ofono/ubuntu
[13:00] <sergiusens> packaging
[13:01] <sergiusens> pitti, this may be a bit outdated, but goes over the flow https://docs.google.com/a/canonical.com/document/d/1Sigl_2iJyNc7VDC3HMVylSEDRLGoKncVAMNAhkicqW8/edit#heading=h.myx0y9f6p5ah
[13:03] <pitti> sergiusens: ok, thanks; I'll look a that after lunch
[13:06] <sergiusens> pitti, in any case; if you make the pull request on github, awe and rsalveti will make it land into the archives
[13:19] <cjwatson> Hm.  Is there really no way to throw an exception from a finally block in Vala?
[13:19] <cjwatson> That's less than helpful when your finally block consists of things that might fail ...
[13:26]  * cjwatson redesigns a bit
[13:43] <tkd> hm, i'm trying to track down the source of a SIGABRT in ldconfig (saucy), but the binary is stripped and the libc6-dbg package no longer ships the symbols for /sbin/ldconfig.real. is this intentional?
[13:54] <mhall119> MacSlow|lunch: API docs?
[14:20] <MacSlow> mhall119, yes... API/guideline docs
[14:26] <kgunn> doko: ping
[14:38] <mhall119> MacSlow: you can publish them using the JSON API if can get them in the right format
[14:38] <mhall119> MacSlow: are they qdoc?
[14:38] <MacSlow> mhall119, ehm... nope
[14:39] <MacSlow> mhall119, what's a good example of how that should look like... and can it deal with images... as pure text would be  a bit "dry" :)
[14:40] <mhall119> MacSlow: no image support yet, I need to learn ceph or whatever we use internally
[14:43] <MacSlow> mhall119, old / NotifyOSD docs are https://wiki.ubuntu.com/NotifyOSD and I kind of assume knowledge of that and mainly point out differences, provide examples... it's not written like plain API doc as that would be just replicating libnotify's doc.
[14:43] <MacSlow> mhall119, but I can see how far I can get with that JSON API stuff
[14:46] <MacSlow> mhall119, another "issue" is the fact that we don't have QML-bindings for notifications yet. So it doesn't blend well with the regular SDK-doc
[14:47] <mhall119> MacSlow: ah, ok, those aren't really "API Docs" the way I think of them
[14:48] <mhall119> MacSlow: really the only think we'd want in the API docs website is QML bindings API docs
[14:48] <MacSlow> mhall119, so would a dedicated wiki-page be sufficient then?
[14:48] <mhall119> yeah, I think so
[14:48] <mhall119> this doesn't look like is for app developer consumption for the most part
[14:49] <MacSlow> mhall119, ok... at least I know where to go once we have QML-bindings
[14:49] <mhall119> yup
[14:49] <mhall119> and we would very much like to get those QML bindings :)
[14:49] <MacSlow> mhall119, notifications are meant to be used by 3rd-party developers
[14:49] <MacSlow> :)
[14:50] <pitti> sergiusens: ok, sent https://github.com/rilmodem/ofono/pull/56
[14:50] <mhall119> MacSlow: right, but 3rd party developers don't care about the spacing inside the bubble or how they are stacked on screen
[14:51] <MacSlow> mhall119, still they want to be able to trigger notifications... so they need some guidance/examples to copy&paste from :)
[15:05] <sergiusens> pitti, fwiw I'm ok with py3 only
[15:06] <sergiusens> pitti, out of curiosity, you don't need to import print_function anymore for py2?
[15:06] <pitti> sergiusens: in py2 it's just a statement which prints a tuple with a single element :)
[15:06] <sergiusens> ah
[15:07] <pitti> or rather, just a parenthesized expression, not a tuple
[15:07] <pitti> sergiusens: which is why print(a, b) doesn't work (looks odd) in py2, and thus I avoided that syntax
[15:07] <pitti> sergiusens: and replaced it with "foo %s" % exception
[15:07] <sergiusens> ok, that works for me
[15:15] <cjwatson> I still prefer using print_function anyway
[15:15] <cjwatson> Since I have nothing that cares about pre-2.6 any more
[15:15] <cjwatson> (And, honestly, I'd be quite surprised if anyone else here *really* did)
[15:16] <doko> pitti: gobject-introspection should run autreconf
[15:16] <cjwatson> Well, aside from launchpad-buildd.  Hopefully that'll be fixed soon...ish
[15:16] <doko> checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no
[15:17] <pitti> doko: yes, sorry; that's done in -3, I thought it already imported -3 but LP didn't yet
[15:18] <pitti> doko: I'll sync -3 once it's imported, until then it'll get stuck in -proposed
[15:18] <kgunn> doko: i understand you might be a good person to talk to about this bug https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1284653
[15:19] <kgunn> just shew me away if its something you're already working on...
[15:38] <slangasek> pitti: apt-clone> ok, cool.  Are the failed ppc64el tests going to be re-run?
[15:38] <slangasek> doko: can you please take a look at the valgrind bug kgunn mentions above?
[15:39] <doko> slangasek, sure, might be tomorrow
[15:39] <kgunn> doko: appreciate it....our ci is blocked until then...thanks
[15:40] <slangasek> doko: if this is blocking CI, we need to get it addressed today.  Do you know if this should be fixable with a valgrind rebuild?  (seems unlikely to me)
[15:40] <doko> ave to look
[15:47] <pitti> slangasek: I re-ran a lot of them already, but if I missed some I'm happy to retry more
[15:47] <pitti> slangasek: I didn't really see any which failed specifically for overlayfs
[15:47] <pitti> slangasek: I retried upstart, eglibc, and some usual  suspects
[15:51] <slangasek> pitti: ok, so the latest runs of https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/job/trusty-adt-coreutils-ppc64el/ were done with the new setup?
[15:51] <pitti> slangasek: right
[15:51] <slangasek> ok, thanks
[15:51] <pitti> slangasek: as I said, the failures are independent of the overlay
[15:52] <pitti> slangasek: we'll probably just drop these two tests, if they don't work in LXC; this is already just a subset of the upstream tests anyway
[15:52] <pitti> slangasek: I fixed some 5 other tests yesterday and today, but I can't do that single-handedly
[16:01] <pitti> slangasek: FYI, I fixed the python{2.7,3.3,3.4} issues, doko committed the patch to Debian; so the next upload should fix those
[16:01] <slangasek> pitti: spiff
[16:01] <pitti> slangasek: also, there's quite a lot of failures which are due to nonexisting packages, such as valgrind or odbc
[16:01] <pitti> I guess these already count as "real" problems
[16:02] <bdmurray> mpt: your addition of the milestones adds empty space in the graph for the future milestones, is that intended?
[16:02] <pitti> slangasek: I haven't yet walked through all of the failures, just perhaps 1/4; most failures are indeed due to missing dependencies, not really ppc specific (aside from the uninstallabilities)
[16:02] <pitti> slangasek: so generally this is looking mostly good
[16:02] <slangasek> pitti: valgrind would need porting, and tests should probably do something sensible on architectures where it doesn't exist
[16:03] <pitti> slangasek: ah, ok
[16:03] <slangasek> pitti: what's the odbc problem?
[16:03] <slangasek> unixodbc is certainly available
[16:03] <pitti> e. g. http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest%20ppc64el/job/trusty-adt-psqlodbc-ppc64el/4/console
[16:03] <pitti> E: Package 'odbc-postgresql' has no installation candidate
[16:04] <pitti> https://launchpadlibrarian.net/167155126/buildlog_ubuntu-trusty-ppc64el.psqlodbc_1%3A09.02.0100-2ubuntu1_FAILEDTOBUILD.txt.gz
[16:04] <pitti> test failures
[16:04] <pitti> psqlodbcw.so' : file not found
[16:04] <pitti> or rather, some build failure
[16:04] <slangasek> pitti: ah, well, the problem is trying to run the autopkgtest for a package which has itself not been built for the arch :)
[16:05] <pitti> right
[16:06] <cjwatson> .so file not found> /me guesses out-of-date libtool macros without even looking at the log :)
[16:06] <pitti> cjwatson: *nod*
[16:07] <cjwatson> Grr, https://bugzilla.gnome.org/show_bug.cgi?id=558620 is annoying
[16:20] <doko> slangasek, valgrind uploaded, untested. afk now until the late evening
[16:28] <slangasek> doko: ok, thanks
[16:28] <pitti> YokoZar: is there any progress with getting 1.6 out of -proposed? AFAIK that required some hinting in britney?
[16:32] <pitti> slangasek: e. g. the exim4 one is easy, just missing dependency; exactly the same problem in http://ci.debian.net/data/unstable-amd64/packages/e/exim4/2014-02-22.log
[16:32]  * pitti goes to fix and file a bug to Debian
[16:32] <seb128> hum, why is britney (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#empathy) saying
[16:32] <seb128> out of date on ppc64el: empathy, empathy-dbg, mcp-account-manager-goa, nautilus-sendto-empathy (from 3.8.6-0ubuntu4)
[16:32] <seb128> where
[16:32] <seb128> https://launchpad.net/ubuntu/+source/empathy/3.8.6-0ubuntu4
[16:33] <seb128> https://launchpad.net/ubuntu/+source/empathy/3.8.6-0ubuntu5
[16:33] <seb128> it's depwait on ppc64el on both versions
[16:33] <pitti> so out-of-date sounds quite right?
[16:34] <cjwatson> britney's still looking at the bootstrap archive for its "before" state
[16:34] <cjwatson> I mean, the pre-rebuild archive
[16:34] <seb128> so it needs an overwrite?
[16:35] <xnox> cjwatson: shouldn't that be reverted now...
[16:35] <cjwatson> No, it means it used to build before we rebuilt the world and now doesn't
[16:35] <seb128> pitti, well, the error suggests it think it's a regression and is blocking it due to that
[16:35] <cjwatson> So this is actually one of the things it *should* be catching IMO
[16:36] <seb128> cjwatson, it briefly built when we changed the arch lists from a limited set to "all", but that created uninstallable binaries (depending in qtdeclarative)
[16:36] <xnox> cjwatson: i think it's a false positive, as the chain of dependencies gained a depwait on qml.
[16:36] <cjwatson> Oh, mind you, gnome-control-center-signon ... yeah
[16:36] <seb128> cjwatson, we reverted to the old archs list
[16:36] <seb128> but we might have binaries leftover to delete then?
[16:36] <cjwatson> No
[16:36]  * seb128 wants qt5.2
[16:37] <cjwatson> Anyway, infinity said he was going to look through the list of differences ASAP and check whether anything needed to be saved to avoid rebootstrapping
[16:37] <cjwatson> Because it's not just proposed-migration, the chroots are still pointed at the pre-rebuild archive for build-deps AIUI
[16:37] <cjwatson> So I'd prefer to let him finish tha
[16:37] <cjwatson> t
[16:37] <seb128> ok
[16:37] <seb128> empathy is blocked by beta freeze anyway
[16:37] <seb128> so no hurry
[16:38] <seb128> cjwatson, thanks
[16:38] <doko> 5.2 is an odyssey
[16:38] <cjwatson> Does anyone actually have a current list of what's blocking 5.2?
[16:38] <Laney> thought I saw something go by in my release mailbox
[16:38] <seb128> Mirv send status updates on the phone list
[16:39] <Laney> https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1278329
[16:39] <mitya57> cjwatson: two bold items in http://pad.ubuntu.com/qt52-dependencies
[16:39] <seb128> ah, the bug Laney pointed has a the update from yesterday
[16:40] <seb128> "multimedia on Ubuntu Touch"
[16:40] <seb128> we need to get rsalveti & co look at that :p
[16:40] <Laney> it's not really precise
[16:41] <seb128> https://bugs.launchpad.net/ubuntu/+source/qtmultimedia-opensource-src-touch/+bug/1271192
[16:42] <seb128> but that doesn't have lot of details either
[16:42] <seb128> out of "need to be ported to qt 5.2"
[16:43] <doko> what worries me more is that we have absolutely no status what else besides the phone will break
[16:43] <sergiusens> pitti, didrocks hey, if wanted debug syms for https://launchpad.net/ubuntu/+source/qtubuntu-camera how would I get them (if created at all)
[16:44] <seb128> doko, not a lot out of the phone is using qt5
[16:45] <seb128> sergiusens, http://ddebs.ubuntu.com/pool/universe/q/qtubuntu-camera/
[16:45] <seb128> sergiusens, seems like they are in the normal ddebs archive?
[16:46] <sergiusens> seb128, thanks
[16:46] <seb128> sergiusens, yw!
[16:46] <pitti> sergiusens: they are in ... what seb128 said
[16:51] <pitti> doko: ah, LP imported it, fixed in https://launchpad.net/ubuntu/+source/gobject-introspection/1.39.90-3
[16:57] <pitti> slangasek: https://jenkins.qa.ubuntu.com/job/trusty-adt-bluez-ppc64el/6/console is an interesting failure, that smells like an actual problem
[17:06] <xnox> doko: there only are like 5 things outside of ubuntu phone that use qt5.
[17:06] <xnox> in the archive...
[17:06] <Laney> currently
[17:15] <xnox> Laney: doko: but they are also known to work, since debian is on 5.2 for a long time.
[17:17] <Laney> does Debian have a KDE which uses Qt 5?
[17:17] <Laney> & that's in exp only isn't it?
[17:18] <xnox> Laney: nobody has it, and neither will we. Framework5 is aimed to be released after 14.04 is released, and kubuntu is planning to provide a backport/ppa to be able to run framework on top of 14.04 base.
[17:20] <xnox> Laney: thus if either of the two turns out to be incompatible, framework5 has time to fix it in devel, and qt5.2 will need srus. but that's a given. It is known that Framework5 will ideally want 5.2, thus having 5.2 by default is desired by all parties involved in trusty.
[17:21] <Riddell> 5.2++
[17:21] <Laney> I'm not denying that it is a desirable state to aim for. The point is that it's quite late and all of the testing so far has been phone focused.
[17:22] <Riddell> from the KDE side we need 5.2, 5.0 doesn't work with our stuff
[17:22] <xnox> Laney: correct, there is no other testing we can do to be honest, as there just aren't anything out there that uses qt5 yet. I mean, you can try running pokerth, but that thing is like always borked =))))
[17:23] <xnox> Riddell: did you try running it against the canonical-edgers ppa with 5.2 ?
[17:23] <xnox> (or at least rebuild against it)
[17:23] <xnox> the whichever Neon builds out there?
[17:23] <Riddell> xnox: yes, it only builds if using that ppa
[17:23] <xnox> Riddell: perfect! ship it! =)
[17:31] <zteam> Hi guys!
[17:31] <zteam> I just wanna ask a simple question
[17:34] <zteam> I have a quite annoying bug in Ubuntu 13 (I assume) with Lightdm which I'm unable to resolve would it make sense to file a bug-report on that  considering 14.04 is just a around the corner, or would that just waste the developers time?
[17:37] <ogra> zteam, is it fixed in 14.04 ?
[17:40] <xnox> zteam: you should just ask / describe your bug straight off the bat. there is little benefit discussing "what ifs" =)
[17:43] <zteam> ogra,  I have no idea, and I don't have powerful enough hardware to test in a Virtualbox either :-)
[17:44] <ogra> zteam, well then you should file it in any case to make sure it can get fixed in 14.04 (if it is still present there)
[17:44] <xnox> zteam: there are like ~300 people here running 14.04.... and we are yet to hear what the bug is =)
[17:44] <ogra> and that :)
[17:46] <zteam> xnox, sure my problem is that my Ubuntu 13.10 installation sometimes forgets to start up LightDM, and instead just give me a black screen it, so I have to go to a terminal and run "sudo service lightdm restart" to get LightDM to run
[17:46] <xnox> zteam: are you using Ubuntu / Unity, or e.g. Lubuntu, Xubuntu, Mint, etc?
[17:47] <zteam> xnox,  I have been asking about this in the Ubuutu channel and people have examined my logfiles, but no one have been  able to give me a working solution
[17:48] <zteam> xnox, I'm using Unity, but I also have XBMC installed (and selectable from LightDM)
[17:48] <xnox> zteam: please file a bug using: ubuntu-bug unity-greeter
[17:49] <xnox> zteam: that should attach everything that's necessory.
[17:50] <zteam> xnox, Okey, I should add that this happens quite rarely, last time it happend was about one week.
[17:54] <zteam> xnox, will that tool collect the .old logfiles as well?
[17:56] <xnox> zteam: it should collect all that's useful.
[18:35] <c_korn> hello, if a website uses gzip for delivering the content, how can I debian/watch to do this properly? e.g. wget "http://byuu.org/" -O- -q | zcat
[19:03] <roaksoax> cjwatson: howdy! I think you can help me with this. Is there a way to preseed a value from a package we are installing to one of its dependencies"?
[19:04] <roaksoax> cjwatson: for example, i want to install: sudo apt-get install X, but X depends on Y, and I want to preseed the value of Y so it does not show a particular debconf note
[19:04] <cjwatson> roaksoax: No, use some method other than preseeding
[19:04] <roaksoax> cjwatson: what method would that be?
[19:04] <cjwatson> No idea, depends on the package
[19:05] <cjwatson> If X depends on Y then there's no guarantee whatsoever that any of X's code would run before Y is installed
[19:05] <cjwatson> Much less before Y's preconfiguration happens, which could be arbitrarily early
[19:06] <roaksoax> cjwatson: Right. makes sense.
[19:06] <cjwatson> (dpkg-preconfigure doesn't sort packages in any kind of dependency order, and doesn't really have the information needed to do so anyway)
[19:11] <cjwatson> pitti: Do you have any recommendations for doing some kind of equivalent of unittest.mock in Vala unit tests?
[19:11] <cjwatson> Google is not helping
[19:11] <roaksoax> cjwatson: thanks!
[19:13] <cjwatson> roaksoax: (your problem may be insoluble, or at least may require significant reworking of how Y does things)
[19:14] <cjwatson> I'm not aware of people being particularly successful at this in the past - it's generally been a mess when people have tried IIRC
[19:20] <roaksoax> cjwatson: so, what if I change the priority of such debconf note to medium. Would it still be shown in the installer but not on an apt-get install?
[19:52] <Saviq> any idea why I can't launch empathy recently, which is complaining about non-existent libwayland-egl.so.1?
[19:55] <Saviq> had to symlink libwayland-egl.so
[20:13] <Noskcaj> Can someone look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/ekiga/ftbfs/+merge/208221 ? It should fix the i386 and ppc64el build failures
[20:37] <zteam_> So I created a bug report about my LightDM issue, would apprcieate very much if someone can have a look at it :-) https://bugs.launchpad.net/ubuntu/+bug/1284826
[20:44] <Noskcaj> zteam_, I've changed it so it actually affects lightdm
[20:54] <hallyn> just curious, does anyone do anything with workman (https://gitorious.org/workman/pages/Home) ?
[20:55] <hallyn> hm, maybe workman is obsoleted by systemd
[20:56] <hallyn> oh, yes it was - https://www.redhat.com/archives/workman-devel/2013-July/msg00007.html
[20:56] <zteam_> Noskcaj, thanks, I personally have no idea, whetever, LightDM or unity-greeter is the root of my problem :-)
[20:59] <Noskcaj> zteam_, Next time you file a bug, use "ubuntu-bug PACKAGE". But it's good you attached the logs.
[21:00] <zteam_> Noskcaj, belive me I trieed too...
[21:00] <Noskcaj> ok
[21:00] <zteam_> Noskcaj, sudo ubuntu-bug unity-greeter
[21:00] <zteam_> [sudo] password for zteam:
[21:01] <zteam_> (process:8032): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
[21:01] <Noskcaj> oh
[21:02] <zteam_> yep, that's what I felt too, a crasing bug-report tool :P
[21:05] <infinity> zteam_: Why would you run it as root?
[21:06] <zteam_> infinity, becuase I assumed the reeson it crashed the first time was it didn't had permission to read some logfiles
[21:09] <zteam_> infinity, the first time I ran it I just I did ran ubuntu-bug unity-greeter, but then it didn't worked I thought, it was uable to reach some logfiles
[21:10] <zteam_> infinity, :-)
[21:14] <Noskcaj> Could someone please do some work on the sponsoring queue? It's getting fairly full, mostly with bugfixes
[21:57] <cjwatson> roaksoax: the installer uses the same debconf priority as the regular system (high), so no
[23:20] <slangasek> pitti: https://jenkins.qa.ubuntu.com/job/trusty-adt-bluez-ppc64el/6/console > does module loading work in the test env, and do you have linux-image-extra installed (or better, the linux-image-generic metapackage)?  I reproduced a failure here, but only because bluetooth.ko was missing
[23:50] <infinity> pitti: Should I be seeing armhf and ppc64el configurations on https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-eglibc/
[23:50] <infinity> pitti: Or is that coming $later?
[23:51] <infinity> Oh, maybe that's just the britney-triggered ones?
[23:51] <infinity> Where do I find the non-britney runs?
[23:52] <infinity> pitti: Ahh, nevermind.  Going up one level, I found armhf and ppc64el in their own little worlds.
[23:57] <infinity> pitti: Okay, so the eglibc/armhf failure looks like armhf is still using overlayfs?
[23:57] <infinity> pitti: The ppc64el failure, though, is completely unexpected and weird...