=== hloeung is now known as Guest79884
=== Guest79884 is now known as hloeung
[01:41] <xnox> rhl: get it into debian, that's easiest to do via a team (e.g. java team, python team, etc)
[01:41] <xnox> rhl: and it would get automatically synced into ubuntu.
[01:42] <xnox> rhl: what's the software / package name?
[01:42] <rhl> its a library for "applied and computational topology" and i'm submitting it to fedora with the name 'ctlib' since 'ctl' is taken
[01:42] <rhl> ctl.appliedtopology.org will be the website, and git.appliedtopology.org holds the source
[01:42] <rhl> ctl.appliedtopology.org/r/ has the release
[01:43] <rhl> and git.appliedtopology.org has another repo there called 'package_managers' which holds my fedora spec and tentative OS/X spec
[01:43] <rhl> my friend will give me his ubuntu thing tommorow
[01:45] <rhl> xnox: interested in packaging for me?
[01:49] <xnox> rhl: i'm not, but Debian Science Team and/or Debian Med Team might be interested.
=== jamesh_ is now known as jamesh
[04:25] <infinity> xnox: Erm, why did you do that kmod upload?
[04:25] <infinity> xnox: I dropped that delta intentionally.
[04:25] <infinity> xnox: Was there a bug caused by that that you didn't reference?
[04:27] <infinity> xnox: Oh, I see.  So, that should be guarded by an if, not removed entirely, IMO.
[05:02] <Logan_> infinity: having a nice conversation? ;P
[05:29] <infinity> Logan_: The best ones are with myself.
[05:30] <TheMuso> I'd agree with that. :)
[05:30] <TheMuso> s/I'd/I/
[05:37] <Unit193> pitti: Not sure it's of interest, but got plymouth with systemd.  Shamelessly stolen from OpenSUSE.
[06:01] <pitti> shadeslayer: interesting; I don't have a modem so can't easily reproduce; mind filing as a bug with tag "systemd-boot"?
[06:01] <pitti> Unit193: oh! absolutely
[06:02] <pitti> Good morning
[06:02] <Unit193> Howdy.
=== rww is now known as heartbleed
=== heartbleed is now known as rww
[06:08] <Unit193> pitti: modemmanager has caused some issue for me until I purged it, only has an upstart job.
[06:10] <pitti> Unit193: right, see shadeslayer's ping
[06:10] <Unit193> I got him in another channel, yeah.
[06:10] <pitti> shadeslayer | [20:46:44] pitti: abr 27 20:44:45 solembum dbus-daemon[686]: dbus[686]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemMan
[06:15] <pitti> infinity: FYI, I think http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/revision/347 is "the" fix
[06:37] <alkisg> I want to file a bug report to make ibus recommented by ubuntu-desktop, not depended on it. Is there any reason not to? It does cause keyboard layout problems and it's not required by upstream gnome, e.g. in fedora it can be removed with no downsides at all...
[06:39] <rww> alkisg: it's only a recommend already...
[06:40] <alkisg> rww: I can't purge it without removing ubuntu-desktop, let me check the dependency chain...
[06:40] <alkisg> unity-control-center
[06:41] <alkisg> It both depends and recommends ibus
[06:41] <alkisg> And ubuntu-desktop depends on unity-control-center
[06:42] <rww> https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1294482
[06:42] <ubottu> Launchpad bug 1294482 in unity-control-center (Ubuntu) "ibus should be recommends only and not in depends" [Low,Triaged]
[06:42] <alkisg> Thank you rww :)
[06:43] <alkisg> I guess I'll have to make a dummy package in a ppa in order to bypass it, since I don't see it getting SRU'ed...
[06:44] <alkisg> Or at least, fix im-config so that it doesn't launch ibus by default like im-switch did in 12.04
[06:44] <alkisg> I.e. in 12.04 ibus wasn't running, in 14.04 it is, without reason
[06:46] <Unit193> alkisg: If the ubuntu-desktop metapackage is like the lubuntu and xubuntu ones, there's no reason you shouldn't just let it go.
[06:46] <dholbach> good morning
[06:47] <alkisg> Unit193: these packages get removed when purging ibus: ubuntu-desktop* unity-control-center* unity-control-center-signon* webaccounts-extension-common* xul-ext-webaccounts*
[06:47] <alkisg> ...I'd prefer it if I didn't have to check which of those are needed by schools and which aren't...
[06:48] <alkisg> Good morning
[06:48]  * alkisg will spend another day trying to pinpoint what part of ubuntu (probably unity-settings-daemon) breaks keyboard layout switching, while it works fine in fedora 20, and would welcome any help he could get...
[06:49] <alkisg> The first part towards fixing keyboard layouts, is for xkb options like "grp:alt_shift_toggle" to be respected, fedora respects while ubuntu discards it
[06:50] <darkxst> alkisg, gnome/unity-settings-daemon depend on ibus
[06:50] <alkisg> darkxst: they shouldn't, upstream gnome doesn't depend on it
[06:51] <alkisg> It recommends it, but doesn't depend on it, e.g. `yum erase ibus` on fedora works fine
[06:51] <alkisg> But OK I can `chmod -x ibus-daemon`, so let's say that part was solved, the keyboard layout issue in Ubuntu is more serious...
[06:52] <alkisg> Unity-settings-daemon somehow manages to omit the xkb layout options in Ubuntu, while gnome-settings-daemon in Fedora respects them and everything works fine there
[06:52] <darkxst> alkisg, fedora is *not* upstream
[06:52] <alkisg> I know, I talked with upstream gnome about it
[06:53] <darkxst> alkisg, the ibus daemon would be optional, but the libraries are not
[06:53] <alkisg> Right
[06:53] <alkisg> It can depend on libibus, no problem there
[06:54] <alkisg> Let's say the ibus issue is solved, we can track it in bug #1294482. The next and more serious problem is the xkb options...
[06:54] <ubottu> bug 1294482 in unity-control-center (Ubuntu) "ibus should be recommends only and not in depends" [Low,Triaged] https://launchpad.net/bugs/1294482
[06:55] <alkisg> When running full screen applications like tuxpaint, which grab keyboard input, we can't switch languages
[06:55] <alkisg> So we can't type greek in tuxpaint, so apps like those are now useless in 14.04. They do work fine in other distributions.
[06:56] <alkisg> The problem is that unity-settings-daemon doesn't get the layout switch shortcut because of the keyboard grab. The solution is the grp:alt_shift_toggle xkb option, which was the default until 14.04
[06:56] <alkisg> Now, some part of unity-settings-daemon blocks the use of xkb options... that's what I'm trying to pinpoint
[06:59] <alkisg> I.e. if I launch `xinit` and run `setxkbmap -query`, I get: "options:    grp:alt_shift_toggle,grp_led:scroll",
[06:59] <alkisg> but if I log in to Unity, I get: "options:    grp_led:scroll". And the problem is that something, probably unity-settings-daemon, strips "grp:alt_shift_toggle"
[07:00] <alkisg> Even if I use setxkbmap to set it again, unity-settings-daemon removes it a few seconds later when I switch layouts
[07:05] <darkxst> alkisg, oh I see, I am not familar with that code, speak with attente]
[07:05] <alkisg> Thank you darkxst, will do
=== davidcalle_ is now known as davidcalle
[08:27] <ekarlso-> doesn't ubuntu include firmware in kernel ?
[08:28] <ekarlso-> I installed kernel 3.14.1 from kernel-mainline and bnx2 isn't working due to firmware missing :(
[08:31] <infinity> ekarlso-: linux-firmware
[08:32] <ekarlso-> infinity: well I see the firmware is in /lib/firmware/3.14.x but the module doesn't seem to find it ?
[08:38] <ekarlso-> any clues ?
[08:59] <pitti> doko_: the libpython3.4-testsuite install failure in utopic-propsed that the autopkgtest shows reproduces in a simple utopic-proposed schroot, so that looks real
=== doko_ is now known as doko
[09:02] <doko> pitti, known, needs a sync
[09:02] <pitti> doko: ah, splendid
[09:38] <xnox> infinity: well update-initramfs was exploading on my machine, and in jenkins making all ADT runs not happy at all.
[09:39] <xnox> infinity: if you do want that hunk in, it needs a guard indeed.
=== alkisg is now known as work_alkisg
[10:06] <doko> xnox, boost1.55 has the gccxml recommendation again. intended?
[10:06] <xnox> doko: no, fixed in debian svn will refix in ubuntu as well. infinity pinged me about it as well by now =)
[10:07] <doko> apw, linux-exynos5 wants you to write some shiny MIRs ... http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[10:08] <xnox> doko: is it linux-exynos5 or actual d-i components that need fixing though?
[10:09] <cjwatson> Probably linux-exynos5
[10:09] <cjwatson> This sort of thing is usually missing Provides
[10:09] <cjwatson> But I walked apw through the process of hunting those down at the core sprint so hopefully he is now an expert O:-)
[10:09] <doko> ahh, ok
[10:11] <apw> cjwatson, erm, oh you did :)
[10:12] <apw> hateful thing
[10:13] <cjwatson> Let me know if you need help
[10:13] <xnox> apw: "i'm an expert, i can do anything." http://youtu.be/BKorP55Aqvg
[10:14] <apw> cjwatson, will do
[10:18]  * doko stops building ruby-tcltk, lets us demote tcltk 8.5
[10:34] <darkxst> 'seeded-in-ubuntu' is pretty hosed right now ;(
[10:34] <ogra_> yay, germinate doesnt have any recommends anymore in touch ... finally
[10:34] <ogra_> xnox, thanks so much for the help earlier
[10:35] <darkxst> on my trusty laptop it only shows 'supports' results
[10:36] <darkxst> and same on utopic
[10:37] <xnox> ogra_: cool, i'll do the same commit to trusty seed then!
[10:37] <ogra_> yeah
[10:37] <Laney> darkxst: I guess because there aren't U images yet
[10:38] <darkxst> Laney, its doing on trusty as well though?
[10:38] <darkxst> or is it just not that smart ;)
[10:38] <Laney> don't think so
[10:39] <cjwatson> It always uses the latest series, doesn't it?
=== MacSlow is now known as MacSlow|lunch
[10:39] <cjwatson> I mean, it doesn't take a series option
[10:39] <cjwatson> Anyway, there should hopefully be images today
[10:40] <darkxst> cjohnston, ok
[10:41] <darkxst> cjwatson even
[10:43] <Laney> Just checked the code, that's what it seems to do
=== gusnan_ is now known as gusnan
[10:45]  * darkxst has 3 weeks without internet and comes back to series switchover chaos! yay!
[10:46] <Laney> Not sure I'd classify that problem under 'chaos' personally
[10:47] <pitti> Laney: well, ask britney :)
[10:48] <pitti> the poor thing is running for hours, snakefruit is full of sweat
[10:48] <Laney> I mean the problem that seeded-in-ubuntu isn't accurate atm
[10:48] <pitti> ah
[10:51] <darkxst> well getting internet was 'chaos' atleast
[10:52] <darkxst> and I was away the last 10 days just to add too that
[10:53] <cjwatson> pitti: It was having trouble yesterday, but we applied some blocks to fix that; it seems happy enough at the moment
[10:53] <cjwatson> well, s/fix/work around/, whatever
[10:53] <pitti> cjwatson: oh, great (it was really meant to be a joke -- with the autosync it's a tough calculation)
[10:54]  * darkxst nearly pee'd on a snake while I was camping, is that what makes snakefruit?
[10:55] <cjwatson> Thanks for that
[10:58] <cjwatson> doko: If you happen to be looking at MIRish stuff, looks like the git -> source-highlight build-dep will need some fairly quick attention - uninstallable git on !i386 in -proposed has some fallout
[11:01] <doko> cjwatson, ok
[11:01] <doko> jamespage, maven time again!
[11:01] <doko> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[11:05]  * jamespage jumps for joy
[11:05] <xnox> \o\ \o/ /o/
[11:13] <davmor2> doko: congratulations on the scrolliest page I've seen in a while :)
[11:15] <pitti> graph theory at its best!
[11:33] <geser> one could try it adding the svgpan.js library to it makes it easier to use (http://www.cyberz.org/blog/2009/12/08/svgpan-a-javascript-svg-panzoomdrag-library/)
[11:54] <mdeslaur> xnox: are you still hitting bug 1271591? it's driving me insane :P
[11:54] <ubottu> bug 1271591 in gnome-keyring (Ubuntu Trusty) "upstart job race prevents gnome-keyring from being ssh agent" [High,Triaged] https://launchpad.net/bugs/1271591
[11:55] <xnox> mdeslaur: yes, it's driving me insane as well. Let me assign it to myself and get that done soon.
[11:55] <mdeslaur> cool
[11:56]  * mdeslaur hugs xnox
[11:56] <seb128> xnox, mdeslaur: thanks
[11:56] <seb128> $drink offer to whoever fixes it
=== MacSlow|lunch is now known as MacSlow
[12:25] <cjwatson> plars: Does anything special need to be set up to make the image testing trigger to cdimage (the pending->current thing) work for utopic?
[12:25] <cjwatson> Aside from telling cdimage that it should expect that trigger for utopic
[12:30] <ogra_> cjwatson, given atht pending->current copying happens by me doing it with mark-current manually i dount that
[12:30] <ogra_> *doubt
[12:30] <cjwatson> ogra_: Not for Ubuntu Desktop it doesn't.
[12:30] <cjwatson> Or server.
[12:30] <ogra_> oh, sorry
[12:30] <ogra_> to much touch in my brain :)
[12:30] <cjwatson> ogra_: Also, I just noticed that cdimage was auto-copying for touch on i386, which wasn't totally helpful
[12:30] <cjwatson> I've fixed that for future builds
[12:31] <ogra_> auto-copying ? to current ?
[12:31] <cjwatson> Yup
[12:31] <ogra_> ouch
[12:31] <ogra_> i wonder why we never noticed
[12:32] <cjwatson> ogra_: Anyway, I think you're all set up for utopic touch builds whenever you're ready
[12:33] <ogra_> whee !
[12:33] <ogra_> let me try one then :)
[12:33] <ogra_> running
[12:36] <pitti> ogra_: have your helmet on?
[12:36] <ogra_> always :)
[12:37]  * pitti ^5s ogra
[12:37] <ogra_> hard hat :)
[12:38] <xnox> cjwatson: ogra_: aren't i386 builds automatically copied, because there is no testing of those yet and we just need the latest all the time at the moment?
[12:39] <cjwatson> I think you're ascribing intent that doesn't exist
[12:39] <ogra_> xnox, no idea why they were atomatically copied, they definitely shouldnt go out of sync with the rest of the world
[12:39] <cjwatson> They're automatically copied because nobody ever thought to add i386 to the relevant line in production/current-triggers
[12:39] <ogra_> right
[12:39] <xnox> cjwatson: hm, ok.
[12:39] <ogra_> the intend is surely definitely to not have them do that
[12:40] <ogra_> -surely
[12:40] <cjwatson> And I happened to notice while setting up utopic
=== _salem is now known as salem_
[12:48] <apw> cjwatson, after a long delay, i have been through all of the udebs Provide: names referenced by the listed missmatches (for linux-exynos5) and they seem to all be there :/  and it also has a matching package-list to master, so i would expect it to be right
[12:49] <ogra_> why do we have an exynox5 flavour ? i thought that was armmp/generic capable
[12:49] <cjwatson> Huh, OK, I'll try to have a look later today
[12:49] <apw> ogra_, because they ahve a huge heap of patches and only came along very close to release
[12:50] <ogra_> ah, sad
[12:50] <apw> ogra_, we may be able to get rid of it in U if we are lucky
[12:50] <ogra_> ++
[12:50] <apw> cjwatson, i downloaded the built .udebs and they looked right too, but hmmm
[12:51] <cjwatson> You usually investigate this by looking through the Packages file
[12:51] <cjwatson> No need to download the udebs then, since all their metadata is already in Packages
[12:51] <apw> oh heh, that would ahve been more sensible
[12:52]  * apw is confused how this is broken in utopic and wasn't in trusty given we have the same version
[12:52] <apw> or did someone add images for this in U
[12:55] <cjwatson> It was broken in trusty
[12:55] <cjwatson> We just ignored those component mismatches
[12:56] <apw> well that is something at lease
[13:04] <xnox> it's a universe kernel that provides packages, that can be pulled in by d-i components from main. Is it just that "exynos5" sorts ahead of "generic" and hence exynos5 (universe) are preferred instead of generic (main) modules on armhf?
[13:15] <psusi> what is the current status of wubi?  was it only removed from the installation medium or totally unsupported now?
[13:15] <xnox> psusi: it has never been removed from installation medium.
[13:16] <xnox> psusi: it provides the ui popup "this is ubuntu image, click reboot now to experience the matrix." on windows machines
[13:16] <plars> cjwatson: should already be set up, this ran this morning on desktop: mark-current -p ubuntu -s utopic -t desktop -a amd64 20140428.1: success
[13:17] <plars> and it doesn't look like we've had a server run yet
[13:17] <psusi> xnox: then that's not wubi ;)
[13:17] <plars> but when we do, it's set to trigger after a good run of the default job
[13:17] <mdeslaur> is there a special tag for precise->trusty upgrade bugs?
[13:17] <mdeslaur> (ie: bug 1313712)
[13:17] <plars> same as it was last cycle... if you'd like, we can revisit where that trigger should happen
[13:17] <xnox> psusi: if you move the wubi.exe binary from the cd to desktop, and launch it - it offers to do wubi installation.
[13:17] <ubottu> bug 1313712 in libselinux (Ubuntu) "Trusty's libselinux1 is causes issues with Precise's upstart during dist-upgrade" [Undecided,New] https://launchpad.net/bugs/1313712
[13:17] <plars> but it's at least in the same state as trusty
[13:17] <psusi> oh that's weird
[13:18] <psusi> hrm... ok, then there seems to be some confustion resulting from the discussion last year on -devel about removing it
[13:18] <psusi> at least amoung askubuntu, the belief is that wubi is no longer supported, so don't use it
[13:19] <psusi> it sounds like you are saying that is not the case
[13:19] <xnox> mdeslaur: upstart in precise did not have support for stateful re-execution and it did not have libselinux enabled, thus to get upstart linked against libselinux one needs to boot trusty's upstart&selinux.....
[13:19] <cjwatson> plars: OK, cool
[13:19] <xnox> mdeslaur: that bug sounds incomplete, or it's a saucy->trusty upgrade bug?
[13:19] <cjwatson> plars: No revisiting needed, just checking
[13:20] <mdeslaur> xnox: I don't know, I didn't look at it, I just wanted to make sure I tagged it properly
=== ken__ is now known as kenvandine
[13:21] <cjwatson> plars: Should get a server run in a bit
[13:21] <ogra_> cjwatson, the cdimage part of touch passed successfully ...
[13:21] <plars> good
=== sz0 is now known as sz0`
[13:22]  * ogra_ waits for system-image now 
=== sz0` is now known as sz0
[13:22] <ogra_> so many moving parts nowadays :(
[13:22] <plars> looks like we should see a touch image soon I guess
[13:22] <ogra_> 20min or so
[13:22] <plars> ogra_++ :)
=== sz0 is now known as sz0`
[13:23] <plars> ogra_: we made sure things were in place before the weekend just in case so we should be all set, but I'll keep an eye out for it
=== Ursinha-afk is now known as Ursinha
[13:23] <ogra_> plars, right, same goes for system-image importing ... but its all untested
=== sz0` is now known as sz0
=== sz0 is now known as sz0`
=== sz0` is now known as sz0
=== sz0 is now known as sz0`
=== sz0` is now known as sz0
[13:27] <apw> cjwatson, oh i might know what this is, so don't start without checking
[14:05] <seb128> xnox, do you plan to SRU that gnome-keyring fix as well? ;-)
[14:06] <xnox> seb128: yes, once utopic people try it out =)
[14:06] <Laney> do you really mean 'starting xsession-init'?
[14:06] <seb128> xnox, k
[14:06] <Laney> that sounds quite broad
[14:06] <xnox> seb128: you are on utopic?
[14:07] <seb128> xnox, no, and I don't think I plan to update before LTS .1
[14:07] <seb128> the LTS still needs some work/polish
[14:07] <xnox> Laney: yes i did, see ssh-agent. gnome-keyring is like a pam module no? thus it's all in the environment already before even upstart starts....
[14:07] <xnox> Laney: that task just queries the variables  and exports them to the upstart and the $world
[14:12] <pitti> ogra_: oh, congrats! (1st phone image)
[14:12] <ogra_> :D
[14:13] <xnox> ogra_: ahead of desktop images et.al? =)
[14:13] <ogra_> yeah
[14:13] <ogra_> thanks to cjwatson's awesome preparation work
[14:14] <cjwatson> xnox: The first desktop image came out a few hours ago
[14:14] <cjwatson> I used it as the initial test
[14:15] <cjwatson> ogra_: Do you want your cron job on?
[14:15] <cjwatson> I've enabled the rest
[14:15] <ogra_> cjwatson, yes please
[14:16] <xnox> *darn* =))))
[14:16] <cjwatson> ogra_: OK, done
[14:16] <ogra_> thanks
[14:16] <Laney> xnox: I see, well anyway at the bare minimum the gnome-keyring command is wrong
[14:17] <Laney> itym gnome-keyring-daemon
[14:17] <Laney> (-s)
[14:17] <xnox> Laney: correct.
[14:18]  * xnox ponders where/how it's working here.
[14:19] <xnox> fixing
[14:20] <Laney> merci
[14:24] <xnox> Laney: hm, that's racy i now got keyring secrets, but no gnome-keyring gpg-agent/ssh-agent
[14:37] <Laney> xnox: Hrm, where does that come from?
[14:47] <bdmurray> cjwatson: could you have a look at bug 1312928?
[14:47] <ubottu> bug 1312928 in openssh (Ubuntu) "SSH-Agent not working in KDE/X-Session if user's login shell is a tcsh" [Medium,New] https://launchpad.net/bugs/1312928
[14:50] <Logan_> xnox: is this delta still needed? https://launchpad.net/ubuntu/+source/guayadeque/0.3.5~ds0-4ubuntu1
[14:50] <Logan_> I don't really understand what you wrote in the changelog :P
[14:51] <Logan_> oh, are you saying that integration with the sound indicator is already built in, so we don't need its own indicator?
[14:55] <cjwatson> bdmurray: ok
[14:55] <cjwatson> bdmurray: committed to Debian; will queue up when I'm next doing SRU prep (probably later this week)
[14:56] <bdmurray> cjwatson: okay, thanks
[15:01] <smoser> anyone able to tell me what Luser error i'm making
[15:01] <smoser>  https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1313550
[15:01] <ubottu> Launchpad bug 1313550 in maas (Ubuntu) "ping does not work as a normal user on trusty tarball cloud images." [High,Confirmed]
[15:02] <smoser> i *thought* it was just forgetting/missing '--xattrs' to tar
[15:03] <cjwatson> smoser: check out the changes I made in response to bug 1302192
[15:03] <ubottu> bug 1302192 in ubiquity (Ubuntu Trusty) "capabilities not preserved on installation" [Critical,Fix released] https://launchpad.net/bugs/1302192
[15:04] <cjwatson> smoser: does curtin use busybox tar?
[15:05] <xnox> Logan_: correct, just exporting mpi interface is enough. Test-build debian version, see if it still appears in sound menu and doesn't create a stand-alone indicator.
[15:05] <smoser> it uses `which tar`, which in maas's case will be gnu tar.
[15:05] <smoser> and in my example was gnu tar.
[15:05] <smoser> am i just simply doing somethign wrong there? it doesn't look like '--xattr' works.
[15:05] <cjwatson> ok, the changes I made didn't rely on any particular tar behaviour since busybox tar doesn't have xattrs support
[15:05] <cjwatson> so you could just do likewise
[15:05] <xnox> Logan_: also i thought libindicator was deprecated and not needed in ubuntu any more (i.e. we try to remove it from the archive)
[15:06] <cjwatson> tar might need to be given an --xattrs-include which includes the security namespace
[15:06] <xnox> Logan_: also, why are you looking at my merges? =)
=== Ursinha is now known as Ursinha-afk
[15:07] <cjwatson> perhaps
[15:09] <cjwatson> smoser: see also https://bugzilla.redhat.com/show_bug.cgi?id=771927
[15:09] <ubottu> bugzilla.redhat.com bug 771927 in tar "RFE: tar should support file capabilities" [Medium,New]
[15:09] <smoser> cjwatson, it seems '--xattrs-include=*' works.
[15:09]  * cjwatson nods
[15:10] <cjwatson> the overhead of doing getfattr | setfattr as I did in live-installer was negligible so I was happy enough with that
[15:10] <cjwatson> but --xattrs-include='*' looks right
[15:12] <smoser> cjwatson, is --xattrs a proper superset of --acls ?
[15:13] <cjwatson> pass
[15:14] <cjwatson> I *think* ACLs are implemented using Linux xattrs, but I hardly ever need to go anywhere near ACLs
[15:15] <cjwatson> attr(5) mentions system.posix_acl_access
[15:15] <cjwatson> It's probably not guaranteed
[15:19] <Logan_> xnox: I'm just a curious person ;P
=== roadmr is now known as roadmr_afk
=== Ursinha-afk is now known as Ursinha
[16:06] <pitti> I'm trying to untangle the uninstallability of qml bits in utopic-proposed
[16:06] <pitti> does anyone know what's going on there?
[16:07] <pitti> it makes chromium-browser, ubuntu-sdk, qtcreator etc. uninstallable, and blocks migration of systemd
[16:07] <Laney> pitti: I think Mirv was looking at it
[16:07]  * xnox ponders if it's related to blocked pending transitions at all.
[16:08] <pitti> apt-get install qtdeclarative5-controls-plugin
[16:08] <pitti> that works in utopic
[16:08] <pitti> but in -proposed I get "qtdeclarative5-controls-plugin : Depends: qml-module-qtquick-controls but it is not going to be installed"
[16:09] <Laney> There were some package renames inherited from Debian which we need to add transitionals for
[16:09] <Laney> is what I understood
[16:09] <pitti> the fun thing is that there's no such package
[16:09] <pitti> not even a virtual one
[16:09] <pitti> oh, perhaps that's already the root of the problem
[16:09] <pitti> I was walking down the dependency chain
[16:09] <xnox> pitti: i think you can ask for chromium-browser and qtcreator-plugin-ubuntu ADT tests to be waived, as long as they don't regress in "utopic" without "utopic-proposed"
[16:09] <pitti> xnox: I ran them in utopic and they are fine
[16:09] <xnox> pitti: same way we force past a few other tests like this.
[16:10] <xnox> pitti: and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtgraphicaleffects-opensource-src seems to be the culprit, no?
[16:10] <xnox> qml-module-qtgraphicaleffects/i386 unsatisfiable Depends: qml-module-qtquick2
[16:11] <pitti> xnox: right, that's the one I see as well
[16:11] <pitti> Laney: would you consider setting a temporary ignore for chromium-browser and qtcreator-plugin-ubuntu failures?
[16:11] <Laney> sec
[16:11] <pitti> or do we want to block everything until this gets fixed?
[16:12] <xnox> well, i wish for more sagari's to be added to buildds ;-)
[16:12] <Laney> I know Mirv uploaded stuff for this through the ci train earlier
[16:12] <cjwatson> xnox: infinity was going to work on that pretty soon I think
[16:13] <xnox> cjwatson: \o/
[16:15] <Laney> pitti: I'd like to wait until the new qtdeclarative-opensource-src shows up to see what the lay of the land is then, if you don't mind
[16:15] <pitti> Laney: sure, that sounds fine
[16:15] <pitti> I was mostly interested in figuring out the root cause, but seems it's underway
[16:15] <pitti> thanks Mirv!
[16:16] <Laney> it's mid migrating, should be along to a britney near you quite soon
[16:23] <doko> pitti, please join -release on a regular basis for issues and questions about the autopkg tests
[16:27] <bdmurray> mpt: Hi. If we use the same colors for failed as for by 12.04 standards what would we use for failed 12.04 retraces?
[16:28] <shadeslayer> could someone point me to a discussion on changing the IO scheduler for Ubuntu to deadline?
[16:40] <Laney> pitti: huzzah, the autopkgtests succeeded
[16:50] <Mirv> pitti: you're welcome. some Qt modules were autosynced from Debian that depended on changes that needed manual syncing. it took some time because I was landing four accumulated patches as well at the same time and needed a full test run.
[16:50] <zyga> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/utopic-adt-plainbox/ARCH=i386,label=adt/lastBuild/console
[16:50] <zyga> so why does the solver wants to remove the package being tested rather than install it?
[16:50] <Mirv> there's more work to be done at least in qtmultimedia but it looked like qtdeclarative should be enough to unblock things from proposed, and other renames can be done at leisure
[16:51] <zyga> http://ci.debian.net/#package/plainbox the same package works in unstable
[16:53] <apw> cjwatson, ok, i have double checked both exynos5 and generic and cannot account for this missmatch; i have tried to cobble together a data set to debug against, but just could not get it to produce the same results so i am stymeed
[17:06] <Riddell> bdmurray: ping
[17:08] <bdmurray> Riddell: hi
[17:08] <Riddell> bdmurray: could you join us in #kubuntu-devel for a minute?
[17:09] <bdmurray> I guess
[17:15] <Riddell> ev: how does a person get access to errors.ubuntu.com ?
=== roadmr_afk is now known as roadmr
[17:20] <pitti> Laney: yay! "Valid candidate"
[17:20]  * pitti hugs Mirv
[17:20] <pitti> doko: ack
[17:23] <Elv1313> ev: ping, Hello, I filled the error access form for the sflphone-kde package (I am the maintainer / main dev), the guys on #kubuntu-devel said I could ping you to have the request approved
[17:31] <Elv1313> is there a magic way to convert the "raw" backtraces to add debug symbols?
[17:58] <juliank> pitti: I cannot connect to www.piware.de, what's happening?
[18:02] <juliank> Yay, it's back!
[18:15] <dobey> pitti: around?
[18:15]  * dobey guesses not after looking at the time
[18:37] <ev> Elv1313: you should be all set
[18:37] <ev> just added you
[19:00] <Elv1313> thanks
[19:01] <Elv1313> ev: "This problem failed to retrace. This is often caused by debug symbols no longer being available for the package version and library version dependencies installed at the time of the crash. Its instances represent one portion of a larger problem. No stacktrace will be available for this set." anything to do about this?
[19:02] <ev> Elv1313: alas, there's not much we can do about those until we get ddebs in the librarian.
[19:03] <Elv1313> ev: do you know any scripts that can take this backtrace and apply the symbols locally?
[19:12] <Elv1313> is it possible to download the raw ".crash" for those crashes?
[19:22] <zyga> I need help
[19:22] <zyga> I need to cross compile a qt5 plugin
[19:22] <zyga> is that doable now?
[19:24] <Elv1313> yes, doable, but cross compiling ain't easy
[19:26] <zyga> I'm all ears (or link eyes)
[19:26] <zyga> I know how to cross compile stuff, just not how debian does it
[19:28] <Elv1313> I was about to redirect you to google, but now, that's a relevant sub-question. I guess you can replace the CC/CXX env vars, but I never tried "real" cross compiling. If you want to compile a 32bit package on a 64bit system, this is trivial, take a look at thte "debbootstrap" command
[19:29] <zyga> I want to build a bunch of qt5 code for armhf
[19:29] <zyga> do I need a chroot or is this really going to work with just cross libs
[19:29] <zyga> wookey: maybe you can help me out (just once I promise)
[19:30] <Elv1313> never tried that one. I have one of these http://www.aliexpress.com/item/Quad-core-RK3188-MK809-III-Google-TV-Box-Android-2GB-RAM-8GB-ROM-1-8GHz-Max/907227860.html and it is more than fast enough to be used as build-bot
[19:46] <apw> cjwatson, just trying to do an initramfs-tools update but it would necessitate a console-setup update which is vastly behind, it has been suggested you might have done the last and know why it is back
[19:54] <doko> apw, xnox: could one of you have a look at the libguestfs dep-wait?
[19:57] <apw> doko, can do
[20:01] <infinity> pitti: TB meeting?  You're the chair. :P
[20:02] <infinity> doko: Eww, a build depending on a kernel image?  That's vile.
[20:03] <apw> infinity, yeah i know ... they are making an appliance image
[20:03] <apw> i guess its trying to be debian-installer
[20:13] <cjwatson> apw: oh it's just hard and has a track record of somewhat invasive rearrangements so it was too scary to update last cycle; hopefully I'll manage it earlyish this cycle
[20:28] <ScottK> mterry: I took care of subscribing the relevant team to electric-fence bugs, but I'm not sure fixing the issues you bring up is worth deviating from Debian over?
[20:29] <mterry> ScottK, I just commented.  I filed a bug for tracking and approved the MIR
[20:29] <ScottK> mterry: Cool.  Thanks.
[20:34] <jfi> tedg, Hello, the 'guide' parameter of app_indicator_set_label is supposed to work on trusty/unity? Is it correct that its goal is to do automaticaly some padding of the label to avoid change of the indicator area width? I hardly see how it can work as indicator does not appear to use a fixed font. Anyway to change the font family?
[20:35] <tedg> jfi, No way to change the font, and sure it doesn't work perfectly. More for things like number where you can generally assume "100" would be the widest value.
[20:36] <tedg> jfi, You can, if you want generate the strings to see what the widths are, but that's probably more work than you're interested in.
[20:36] <jfi> tedg, well, my concern is that if I set the guide to 'WWWWWWWWWW' and put a label '0' it does not do any padding
[20:37] <tedg> jfi, Hmm, it should. Perhaps that changed. Trevinho would you know?
[20:38] <jfi> tedg, ok, if it 'should' work, I will try to find the bug in my code (but I doubt to be honest) and open a BR with a short sample
[20:39] <tedg> jfi, I'm just not sure, we didn't touch the indicator side in Trusty, but the Unity side had a lot of work for HiDPI. They may have changed things.
[20:51] <doko> ScottK, Riddell: please could you have a look at the qtruby and korundum ftbfs?
[20:51] <ScottK> Sure.
[21:19] <apw> doko, also looking at supermin (as a dep of libguestfs)
=== salem_ is now known as _salem
[22:02] <wookey> zyga don't think I've ever cross-built QT5, so don;t know if it will work
[22:07] <wookey> it's not on http://people.canonical.com/~cjwatson/cross/armhf/trusty
[22:07] <wookey> the QT4 there looks like it did a good chunk of build before falling over due to trying to build native test but not having native fountconfig present.
[22:07] <sithlord48> hello xnox : . i have a bug report question. if you install libboost-dev the following libboost-filesystem-dev and libboost-program-options-dev are not installed . i have not sure if this is a bug or not. should a report be made? i was told in #kubuntu-devel to ask you here
[22:08] <infinity> wookey: qt5 fails due to not selecting a cross-compiler.
[22:08] <infinity> wookey: http://people.canonical.com/~cjwatson/cross/armhf/trusty/qtbase-opensource-src_5.2.1+dfsg-1ubuntu13_armhf-20140410-0048
[22:09] <infinity> wookey: Quite possibly just needs --host and --build thrown at configure or something equally simple.
[22:50] <xnox> sithlord48: that's not a bug. typicallly you should depend on just the -dev packages that you need (e.g. boost-dev filesystem-dev etc)
[22:50] <Trevinho> jfi: yeah, much code there changed... Do yo have a test-case handy?
[22:50] <xnox> sithlord48: all of boost is not in main, just part of it.
[22:50] <sithlord48> xnox : im installing libogre-dev and my ogre build requires those
[22:51] <sithlord48> libogre-dev requires libboost-1.54-dev
[22:51] <xnox> sithlord48: there is libboost-all-dev but that's _very_ large and has everything, it's in universe only (it has parallel, mpi, graph etc)
[22:51] <xnox> sithlord48: ogre does not require everything from boost.
[22:52] <sithlord48> xnox:  not ogre just the target im building.  this i why i was unsure if it was a pacakging bug or not. i can simply add them to my control file to fix it for me.
[22:53] <xnox> sithlord48: yeah do that. Possibly libogre-dev should declare a few more dependencies by default. e.g. when compiling against libogre-dev one will probably need libboost1.54-dev, libboost-atomic1.54-dev, libboost-date-time1.54-dev, libboost-thread1.54-dev,
[22:54] <xnox> sithlord48: libogre-dev already declares dependencies on boost & thread, not sure if the other two need adding. i'll check that.
[22:54] <sithlord48> xnox:  it seams to pull most all of them. i only had to add the two i've mentioned other wise it wouldn't link the exe
=== sz0_ is now known as sz0`
=== sz0` is now known as sz0_