[02:19] <cjwatson> cyphermox: can certainly try a test package if you point me at it
[04:42] <Mirv> Unit193: hellos
[05:00] <pitti> Good morning
[05:10] <pitti> doko__, cjwatson: so perl isn't held by autopkgtest failures now, just by uninstallability
[05:17] <YokoZar> cjwatson: Would a sync of new libcdio (for multiarch compatibilty) be appropriate?  (Debian includes new upstream version as well)
[05:17] <YokoZar> https://bugs.launchpad.net/ubuntu/+source/libcdio/+bug/1151565
[07:02] <dholbach> good morning
[07:20] <jibel> pitti, I've 2 machines running utopic that hang on shutdown or reboot. One hangs on unmountfs, the other I don't know. DO you know how to debug that?
[07:36] <pitti> jibel: did you already try without "splash quiet"?
[07:36] <kdeuser56> pitti: have you got my mail about apport?
[07:36] <jibel> pitti, yes, and it stops at unmounting file systems ...
[07:36] <pitti> kdeuser56: yes, Harald already answered it
[07:36] <jibel> pitti, and stays here forever
[07:36] <kdeuser56> pitti: what does he mean by faking the dr.konqui accept file?
[07:37] <kdeuser56> pitti: how would I make that automatic at every crash?
[07:37] <pitti> kdeuser56: not sure -- I don't know drkonqui or Kubuntu's current crash handling at all, I'm afraid
[07:37] <jibel> (not really forever but I waited like 10min before hard rebooting the machines)
[07:37] <kdeuser56> pitti: yeah, but why is there not way to always invoke apport?
[07:38] <pitti> jibel: hmm; can you still switch VTs at that time? maybe there's some error on VT8 or so
[07:38] <kdeuser56> pitti: does apport simply not detect the crash when drkonqi is invoked?
[07:38] <pitti> kdeuser56: as apachelogger wrote, it was designed like that
[07:38] <jibel> pitti, it happens on every shutdown/reboot. I can switch VTs but there is no error
[07:38] <kdeuser56> pitti: apport or dr.konqi?
[07:38] <pitti> kdeuser56: yes, if KDE programs themselves intercept the SIGSEGV, then it doesn't go to the kernel and thus apport
[07:39] <pitti> jibel: hmm, I'm afraid I have no idea at that point :/ perhaps jodh has some trick up his sleeve to make upstart more verbose on the console
[07:39] <kdeuser56> pitti: oh, that means dr konqi would need to be patched if I wanted that behavior ...
[07:40] <jibel> pitti, okay, thanks. I'll ask when he is online.
[07:41] <pitti> kdeuser56: I suppose it's too late in drkonqui; the signal needs to be re-raised after invoking the KDE crash handler and deciding that you also want apport (or a proper core dump)
[07:41] <apachelogger> class KCrash in kde4libs is the thing that needed patching
[07:43] <kdeuser56> apachelogger: oh damn, since I think I can't patch that myself, can I workaround that issue with a shell script being invoked?
[07:44] <kdeuser56> apachelogger: could you explain me how you meant the dr.konqui.accept trick?
[07:44] <apachelogger> http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kdelibs/view/head:/debian/patches/kubuntu_raise_after_drkonqi.patch
[07:44] <apachelogger> our KCrash will raise the signal to the kernel iff a drkonqi-accept file is present
[07:44] <apachelogger> +    sprintf(filePath, "/var/crash/%s.%d.drkonqi-accept", buf, uid);
[07:45] <apachelogger> buf being the url of the binary that crashed with / exchanged for _ and uid is, well, the user id
[07:45] <apachelogger> so what you could do is write a wrapper script around drkonqi that always creates this file
[07:46] <kdeuser56> apachelogger: ah damn, now I see another problem: I have my custom patched version of apport, where I changed the file format to include a date
[07:46] <pitti> I hope just the date, not the time
[07:47] <kdeuser56> pitti: I included hours, thats restrictive enough for me
[07:47] <apachelogger> in the file name?
[07:48] <kdeuser56> apachelogger: yeah, otherwise apport would overwrite existing crash reports of the same application
[07:48] <pitti> only if you already saw the previous one
[07:49] <kdeuser56> pitti: what do you mean by "saw"?
[07:49] <kdeuser56> retraced?
[07:49] <pitti> well, if you got an apport window which told you about the crash and let you decide whether to report it
[07:49] <pitti> it won't overwrite "unseen" crashes, just increase the "CrashCounter" to avoid flooding with repetitive crashes
[07:50] <pitti> to limit to 3 crashes per executable and day
[07:50] <kdeuser56> pitti: ah okay, thats too often the case for me, so I prefer my time patch
[07:50] <kdeuser56> (that I get the windows, or a cron scripts autoretraces stuff for me)
[07:51] <kdeuser56> pitti: why does apport-retrace never modify the original file? why do I have to print to stdout or to another file?
[07:52] <pitti> kdeuser56: you can tell it to update the original file;  in fact, that's the default
[07:52] <pitti> -s → stdout, -o → other file, -g → gdb session; none of those: update original file
[07:52] <kdeuser56> pitti: i am afraid it never does for me .... it always tells me to use either s, o or g
[07:53] <pitti> hm, that could be fallout from a bug fix last week
[07:53] <pitti> but it at least had worked before
[07:53] <kdeuser56> pitti: when was before?
[07:53] <pitti> like, until two weeks (or so) ago
[07:54] <pitti> anyway, bug report appreciated
[07:54] <kdeuser56> pitti: are you sure? I can't confirm that
[07:54] <pitti> should be simple to fix
[07:55] <kdeuser56> pitti: okay I will investigate and when I am sure it does not work, I'll report a bug, but I am already pretty sure
[07:55] <kdeuser56> apachelogger: does the diff you linked also apply to the frameworks version?
[07:57] <kdeuser56> apachelogger: deleting lines 26-30 and 36-38 should do what I want, right?
[08:00] <apachelogger> kdeuser56: it's not ported to frameworks but generally yes
[08:01] <kdeuser56> apachelogger: does the yes also apply to the line deleting in the diff?
[08:02] <kdeuser56> apachelogger: I mean sure the class name "possiblyRaiseForApport" would not make sense any more then for me, but that should not hurt
[08:02] <apachelogger> dunno
[08:02] <apachelogger> you really could just replace possiblyRaise with raise(sig)
[08:03] <kdeuser56> apachelogger: you mean in KCrash::setCrashHandler?
[08:03] <kdeuser56> apachelogger: what does the "KCrash::setCrashHandler(0);" do then?
[08:04] <apachelogger> prevents it from looking in on itself
[08:04] <kdeuser56> apachelogger: so it makes sense to set it before raise(sig), right?
[08:05] <apachelogger> yeah
[08:06] <kdeuser56> apachelogger: so what I am expected to get then is both, dr. konqui and apport, right?
[08:07] <kdeuser56> pitti, apachelogger: thanks for your great help, I'll try it!
[08:13]  * Mirv hugs pitti for pygobject (virt-manager)
[08:14] <pitti> Mirv: heh, no worries :)
[08:14] <pitti> I broke it, I fix it
[08:15] <pitti> Mirv: ah, you use virt-manager?
[08:16] <Mirv> pitti: yes nowadays. I felt so outdated on ordinary manually qemu + vnc, that I finally installed it and also started using SPICE. now the lxc folks tell me I'm still totally outdated :(
[08:17] <pitti> Mirv: ah, I always just use qemu from the command line; I didn't quite like all the extra overhead and daemons of virt-manager; but I suppose it's quite a bit easier to use?
[08:18] <pitti> Mirv: (FAOD, not saying that virt-manager is bad, I just don't know many people who use it)
[08:18] <Mirv> pitti: well the same I wasn't sure what benefit setting it up would be, but now running VM:s on remote machine works pretty nice anyhow
[08:18] <pitti> Mirv: yeah, I guess it's quite a bit better for someone like a server hoster where you have permanent VMs and need to manage them
[08:18] <Mirv> I think I just saw xnox using it a long time ago or something, and it seemed cool
[08:19] <pitti> I only have temporary ones or boot images for testing
[08:20] <Mirv> right. I've permanent 14.04 LTS and Debian VM:s on another machine.
[08:20] <Mirv> QXL/Spice don't make Mesa+LLVM Unity 7 fast, though, but it's usable
[08:21] <pitti> Mirv: ah, and now you want to move most of them to LXC containers? :-)
[08:21] <Mirv> pitti: probably I should do that, yes :)
[08:22] <pitti> Mirv: depends on what you want to do; for the most part, containers are faster and nicer, but you can't test different kernels or do low-level stuff (graphics etc.) with them
[08:24] <Mirv> yes, I'd probably want to be able to pass the GPU to the VM eventually too, since I eg. test Qt and others which are nicer with accelerated 3D
[08:25] <Mirv> not sure thouh which year that's coming to qemu/gallium3d, but probably eventually
[08:25] <pitti> Mirv: testing newer Qt is easier with schroot or LXC
[08:25] <pitti> Mirv: as they use the same kernel/hardware as the host; testing fixed kernel drives also doesn't make much sense in QEMU; so it sounds like indeed you want containers or schroots
[08:29] <apachelogger> (if you manage to setup networking for LXC that is :P)
[08:39] <pitti> apachelogger: err -- there's exactly zero work involved in that
[08:44] <apachelogger> pitti: that's improvement then. I tried to replace our neon build infrastructure schroots with LXC in feburary and networking was not working at all ;)
[08:46] <pitti> odd, that has worked for ages
[08:55] <mlankhorst> doko__: odd, I do not get the LLVM failure here..
[08:55] <mlankhorst> maybe it's cpu specific code triggering?
[08:55] <doko> mlankhorst, welcome to debugging jits generating code for different processors :-P
[08:56] <mlankhorst> hah
[08:56] <mlankhorst> can I 'downgrade' the code generation?
[08:59] <Mirv> pitti: as a baby step I installed lxc on that remote machine and I can now connect to that too via virt-manager.
[09:02] <pitti> Mirv: hah, cool!
[09:02] <mlankhorst> oh colored dmesg.. my eyes..
[09:05] <mlankhorst> ok my crap system can reproduce that error:-)
[09:22] <Mirv> any core-dev around to ack CI Train debian/ changes? this time libaccounts-glib/qt + online accounts. the three links containing the diffs are at https://ci-train.ubuntu.com/job/ubuntu-landing-015-2-publish/ - two are just version bump changes.
[09:23] <Mirv> and even the libaccounts-glib just adds one file to be installed
[09:24] <pitti> Mirv: LGTM, ack
[09:24] <Mirv> this is the official "thank pitti" day
[11:29] <mlankhorst> doko: found a testcase
[11:29] <mlankhorst> piglit with DISPLAY=:0 LIBGL_ALWAYS_SOFTWARE=1 bin/ext_transform_feedback-change-size  range-shrink
[11:55] <mlankhorst> hm, works with more recent mesa..
[11:57] <mlankhorst> I'll do a full test to be sure..
[12:30] <mlankhorst> ok ubuntu-ui-toolkit doesn't seem to fail either..
[12:59] <mlankhorst> doko: well if I file a FFe for mesa 10.3 I should be able to enable llvm, pending the remaining piglit tests
[13:07] <cjwatson> YokoZar: I don't know, haven't investigated.  If you want to take responsibility for it don't let me stop you :)  (My Ubuntu change can certainly be synced over now)
[13:08] <cjwatson> doko: thanks for working on the perl transition; FYI I'm working on libguestfs, it's requiring me to fix up gfs2-utils first
[13:09] <doko> cjwatson, ahh, I have a libguestfs package
[13:09] <doko> dropped the libguestfs-gfs2 b-d
[13:09] <cjwatson> doko: shouldn't be necessary
[13:09] <cjwatson> I almost have gfs2-utils fixed ...
[13:10] <doko> cjwatson, what do you propose about the unreadable kernel images?
[13:10] <cjwatson> doko: that isn't what's blocking it, is it?
[13:11] <doko> cjwatson, fails later trying to run the tests. disabled for now.
[13:11] <cjwatson> roaksoax: so Fedora gfs2-utils has dropped the init script entirely, which is broken at the moment because it requires cman in order to start.  Do you think I could just drop that init script from Ubuntu too and rely on mounting being done in other ways?
[13:13] <roaksoax> cjwatson: +1
[13:13] <cjwatson> doko: there appears to be a SKIP_TEST_SYSLINUX_PL environment variable available, at least
[13:13] <cjwatson> hm, maybe it's not that test
[13:14] <doko> cjwatson, http://people.canonical.com/~doko/tmp/libguestfs.debdiff
[13:14] <doko> still with the gfs2 disabled
[13:14] <roaksoax> cjwatson: if they have dropped it, then it would be good for us to do it. Although, are we looking to merge a new version from Debian? Has Fedora dropped it in the same version we have?
[13:15] <cjwatson> build-depending on grub2?!
[13:15] <cjwatson> roaksoax: there's no new version from Debian to mereg
[13:15] <cjwatson> *merge
[13:15] <doko> that was already in Debian
[13:16] <cjwatson> still evil :)  should probably be grub-something-bin
[13:16] <roaksoax> cjwatson: ok. Yeah we should definitely not need cman as a dependency for the initi script, so I think it is safe to drop it
[13:16] <cjwatson> build-depending on grub2 installs something that will own the system's boot sector
[13:17] <cjwatson> doko: so if I fix gfs2-utils can you try restoring libguestfs-gfs2?
[13:17] <doko> sure
[13:17] <doko> cjwatson, but I'm afk again, so I'll leave the packages on p.c.c
[13:20] <cjwatson> roaksoax: I guess the alternative is dropping cman and gfs_controld from Required-{Start,Stop} in the init script rather than dropping the whole thing, but I don't know enough about gfs2
[13:21] <roaksoax> cjwatson: I'll investigate and take care of it. Thanks for point it out!
[13:21] <cjwatson> roaksoax: Cool, thanks.  Could you start with http://paste.ubuntu.com/8140684/ ?
[13:21] <mlankhorst> doko: I can't reproduce the crasher with llvm 3.5 and mesa 10.3-rc1, I will try to upload mesa 10.3 before flipping the switch..
[13:21] <doko> \o/
[13:21] <roaksoax> cjwatson: will do! thank you!
[13:27] <mlankhorst> I've ran over half the mesa tests now, and tried the ubuntu-ui-toolkit tests on it
[13:27] <mlankhorst> both had failures before
[13:48] <doko> cjwatson, how is your ocaml foo? http://launchpadlibrarian.net/183130799/supermin_5.1.9-1ubuntu1_5.1.9-1ubuntu2.diff.gz  this might require a proper fix in src/kernel.ml
[14:47] <kdeuser56> pitti: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1361242
[15:13] <pitti> kdeuser56: thanks
[15:59] <kdeuser56> is noninteractive boot option still recommended for preseeding?
[16:18] <hallyn> doko: hi - slof is failing to build in utopic-proposed.  When I build it in a trusty container (using older gcc-defaults-powerpc-cross) it builds fine.  that package (gcc-defaults-powerpc-cross) is a bit of an enigma :)
[16:20] <doko> hallyn, -> porter-powerpc.canonical.com preprocessed source, and how it is called. the build log may please your eyes, but it doesn't help anybody else
[16:22] <hallyn> not sure how to parse that.  where on porter-powerpc.canonical.com is it?  I was thinking i'd try building 4.9.2 of gcc-defaults-powerpc-cross
[16:22] <hallyn> on porter-powerpc.canonical.com am i supposed to use schroot?  (no dchroot htere)
[16:23] <hallyn> hm, 4.9.2 was mentioned in email ubt don't see it avail
[16:33] <shadeslayer> anyone know how the autologin setup happens in ubiquity?
[16:34] <hallyn> doko: hm, I see that porter-powerpc.c.c:/home/doko/gcc/log shows segvs as well
[16:35] <hallyn> guess that's 100% unrelated
[16:40] <lullis> Hey guys... I have a quick question regarding how to register new indicators to be displayed on the panel from either unity-greeter or gtk-greeter.
[16:41] <lullis> I see that the conf files from the greeters have an entry to list which indicators to be active, but how do I add a new one? I was trying to find for .desktop files, but nothing showed up.
[17:05] <hallyn> doko: shnickities porter-powerpc.canonical.com has the exact same behavior - utopic fails, trusty builds
[17:05] <hallyn> maybe it's a core gcc bug
[18:01] <marvin-hh> Why doesn't AppArmor work after installation for Firefox? Alternatively, why is /bin/kmod executed by firefox?
[18:04] <sarnold> marvin-hh: on-demand loading of a network protocol is most likely; did you compile your kernel with ipv6 support as a module?
[18:04] <marvin-hh> sarnold: I am using -generic.
[18:05] <sarnold> marvin-hh: hunh. can you paste your DENIED line?
[18:06] <gatox> hi, i'm having issues to be able to cross-build ubuntu-system-settings for arm.. could anyone help me?? this is what is happening: http://paste.ubuntu.com/8140373/
[18:07] <Laney> gatox: it's busted since we added the qt dbus mock thing
[18:07] <marvin-hh> sarnold: http://paste.kde.org/pxpqrbpse/kogntk
[18:07] <seb128> Laney, :-(
[18:07] <gatox> Laney, ahhhhh.... any other way to do it?? i'm not being able to build it on the phone because installing only de u-s-s dependencies i run out of space
[18:08] <marvin-hh> sarnold: why would on demand loading of modules in -generic be any reason at all for apparmor complaining?
[18:08] <marvin-hh> sarnold: I mean: this is not something which should ever have ended up in a release.
[18:08] <Laney> gatox: porter machine or a PPA which builds arm
[18:08] <sarnold> marvin-hh: there's a reason why the firefox profile isn't turned on by default :)
[18:09] <Laney> btw AFAICS it comes down to this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755874 which is something I want to work on
[18:09] <sarnold> marvin-hh: maybe firefox is trying to load some kernel modules for ati-based glx or gle or similar? could be you're the first to use our firefox profile with an ATI video card
[18:09] <marvin-hh> sarnold: in that case, I would like to disable the profile.
[18:10] <sarnold> marvin-hh: aa-disable /usr/bin/firefox  ought to do it
[18:10] <marvin-hh> sarnold: after an upgrade it was on.
[18:10] <marvin-hh> sarnold: Profile for /usr/lib/firefox/firefox.sh not found, skipping
[18:11] <marvin-hh> sarnold: in short, that didn't work.
[18:11] <sarnold> marvin-hh: hrm, try aa-disable /etc/apparmor.d/usr.bin.firefox   ?
[18:11] <sarnold> (I can't recall if it happily takes paths right to profiles or not..)
[18:12] <marvin-hh> sarnold: that seems to have worked.
[18:12] <sarnold> marvin-hh: nice
[18:12] <marvin-hh> sarnold: I don't understand how it was ever enabled otherwise.
[18:13] <sarnold> marvin-hh: me neither.
[18:13] <marvin-hh> sarnold: are you sure that upgrading from 12.04 to 14.04.1 cannot magically enable it?
[18:13] <sarnold> marvin-hh: it really should take some effort to turn on firefox..
[18:14] <marvin-hh> sarnold: it's not important now. Perhaps I turned it on a long time ago and am I only getting the messages in my face now.
[18:14] <sarnold> marvin-hh: could be that newer X drivers supported features that older releases didn't.. (I'm still guessing it was ATI drivers, though the evidence is pretty circumstantial)
[18:15] <sarnold> marvin-hh: if you want to investigate some time, try lsmod before running firefox, run firefox, visit whatever website kicked this off, then re-check loaded modules
[18:15] <sarnold> see what's new
[18:22] <cjwatson> doko: really pretty minimal, I'm afraid
[18:26] <doko> cjwatson, ?
[18:27] <cjwatson> doko: you asked how my ocaml knowledge was
[18:27] <cjwatson> I don't have much :)
[18:27] <cjwatson> ML classes from 15 years ago at university
[18:27] <doko> hallyn, sure, I'll look at it next week. won't get to it before without command line parameters and preprocessed source
[18:28] <doko> cjwatson, ahh, the supermin thing. yep, they do some string matching in src/kernel.ml, but I don't understand it :-/
[18:44] <Janusz> Hello. I don't want to code today, but need a good lecture to be better in Linux developing. What could You recommend?
[18:45] <marvin-hh> Janusz: there is no point in learning details about Linux unless you are optimizing something specially for Linux (which is still a bad idea, unless you are working for a >10B USD company).
[18:46] <marvin-hh> Janusz: and in that particular case, you wouldn't be asking this.
[18:46] <marvin-hh> Janusz: just learn the fundamentals.
[18:46] <Janusz> marvin-hh: Like?
[18:47] <marvin-hh> Janusz: like the top 5 of books on algorithms on Amazon.
[18:47] <marvin-hh> Janusz: don't waste your time on 'agile' methods.
[18:47] <marvin-hh> Janusz:
[18:47] <marvin-hh> Janusz: you can better also not waste your time with Ubuntu.
[18:48] <marvin-hh> Janusz: Ubuntu only tolerates newbies.
[18:48] <marvin-hh> Janusz: Ubuntu's only goal is to make you dependent on their corporate support once you start using it for anything important.
[18:48] <marvin-hh> Janusz: Ubuntu is not designed to last.
[18:49] <Janusz> Thank You.
[19:12] <Kangarooo> how to subscribe to wiki pages? i just want to know is there some place where i can remoe my subscritions? Somehow im subscribed to every wiki page and i want it to stop
[19:52] <rww> Kangarooo: log in to wiki.ubuntu.com, then go to https://wiki.ubuntu.com/Home?action=userprefs&sub=notification
[19:53] <Kangarooo> rww: there everything is empty
[19:53] <Kangarooo> rww: but still i get the emails
[20:04] <rww> Kangarooo: the "subscribed wiki pages" box is empty?
[20:04] <Kangarooo> rww: yes
[20:04] <rww> Do you have any other wiki accounts somehow? (multiple email addresses forwarding over, etc.)?
[20:05] <Kangarooo> rww: nope
[20:06] <rww> and they're notifications for wiki.ubuntu.com and not help.ubuntu.com/community ?
[20:07]  * rww just remembered that both of those exist...
[20:18] <Kangarooo> rww: theres empty but was ticked some checkboxes on. i removed them.
[20:25] <Kangarooo> emails still comming
[20:33] <hallyn> doko: ok, thanks, i don't think there is a rush, but i can point you to exact commands and source in a bit  - thx
[20:44] <Kangarooo> rww: https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/1361361
[20:48] <roaksoax> cjwatson: http://paste.ubuntu.com/8143984/
[20:48] <roaksoax> cjwatson: seems that it is safe to remove the init script
[20:49] <cjwatson> roaksoax: Cool, please do.  Do we need a debian/gfs2-utils.maintscript or something to do rm_conffile?
[20:49] <cjwatson> (Not sure how that interacts with the other init script stuff, e.g. if you need to imitate /usr/share/debhelper/autoscripts/postrm-init
[20:49] <cjwatson> )
[20:50] <roaksoax> cjwatson: I'll look into that!
[21:00] <roaksoax> cjwatson: and yeah I do not think we need postrm-init logic, as there really no daemon that we are running. The init script was just looking at /etc/fstab to mount/unmount
[21:00] <roaksoax> cjwatson: but I don't think it would hurt adding it
[21:01] <cjwatson> ok, whatever's easiest then
[21:01] <cjwatson> I don't really know gfs2 at all :)
[21:51] <roaksoax> cjwatson: ok.. this does it... http://paste.ubuntu.com/8144463/ I'll upload
[22:16] <cjwatson> roaksoax: rock, thanks
[22:42] <JasonBourne> Hello