[04:23] <pitti> Good morning
[04:32] <hades08> im trying to allow this :  apparmor="DENIED" operation="open" profile="lxd_lxc_0.19-1" name="/dev/ppp" pid=5162 comm="lxc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 what anyone could help me ?
=== ming is now known as Guest52262
[05:17] <jjohansen> hades08: you would need to add
[05:17] <jjohansen>   /dev/ppp r,
[05:17] <jjohansen> to the lxd_lxc_0.19-1 profile
[05:22] <hades08> to common.conf ??
[05:22] <hades08> or the usr.bin file in apparmor.d ?
[05:24] <hades08> none seems to work , i get the apparmor denied when trying to do : "lxc file push /dev/ppp mycontainer/dev/"
[05:24] <jjohansen> hades08: possibly or one of the files it includes, it seems I don't have one to look at atm
[05:24] <hades08> my /dev/ppp is in 666 mode too
[05:25] <jjohansen> hades08: okay, I will need a few minutes to install something to look at
[05:25] <hades08> oh ! thx :)
[05:36] <hades08> jjohansen: are you trying it ?
[05:36] <jjohansen> hades08: my system is updating so I can install the package
[05:37] <hades08> i ve also tried this : https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1474047 for you to know, not working neither
[05:37] <ubottu> Launchpad bug 1474047 in lxc (Ubuntu) "pppoe fails inside container" [Undecided,Invalid]
[05:37] <hades08> ^^
[05:38] <hades08>  mknod /dev/ppp c 108 0 from the container doesnt work
[05:39] <hades08> lxc.mount.entry = /dev/ppp dev/ppp none bind,optional,create=file do work but the /dev/ppp has 600 chmod and chown is nobody:nogroup and not working
[05:39] <hades08> in the container
[05:42] <hades08> i get a /dev/ppp in the container using that method but its not working then. ppp kernel modules i have loaded are: "pppoe" and "pppox"
[05:47] <hades08> i have added : "/dev/ppp rw," in /etc/apparmor.d/usr.bin.ubuntu-core-launcher and also "lxc.cgroup.devices.allow = c 108:0 rwm" in /apps/lxd/0.19-1/bin/x86_64/lxc/config/common.conf
[06:01] <hades08> jjohansen: any idea ?
[06:36] <dholbach> good morning
[06:39] <sladen> morning dholbach
[06:41] <dholbach> hi sladen
[07:40] <ricotz> dholbach, good morning, would you mind taking a look at https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1505146
[07:40] <ubottu> Launchpad bug 1505146 in plank (Ubuntu) "Sync plank 0.10.1-1 (universe) from Debian unstable (main)" [Undecided,New]
[07:41] <dholbach> yep, in a bit - need to finish something else first
[07:41] <ricotz> dholbach, thanks!
[07:56] <dupondje_> seems like there are major issues with the wpa_supplicant version in Wily and WPA2 Enterprise :(
[09:08] <Odd_Bloke> diwic: o/ We were talking at LinuxCon about problems I was having with my sound (namely that, on each boot, I have to set the channels for my card in alsamixer before pulseaudio will recognise them); where should I file a bug for this?
[09:20] <diwic> Odd_Bloke, so it was about 2ch / 6ch mode, right?
[09:20] <Odd_Bloke> diwic: Yep.
[09:21] <diwic> Odd_Bloke, for a start, how about running "ubuntu-bug audio" and point me to the resulting bug?
[09:29] <Odd_Bloke> diwic: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1505584 (Thanks!)
[09:29] <ubottu> Launchpad bug 1505584 in alsa-driver (Ubuntu) "[Realtek ALC887-VD] Playback only through 2 channels by default" [Undecided,New]
[09:33] <diwic> Odd_Bloke, so you have added "model=3stack-6ch-dig" ?
[09:35] <Odd_Bloke> diwic: Hmm, I must have done that at some point when trying to fix it.
[09:36] <Odd_Bloke> diwic: Let me remove that to see what difference it makes; will I have to reboot for it to be picked up?
[09:37] <diwic> Odd_Bloke, yes, reboot necessary
[09:37] <diwic> Odd_Bloke, but anyhow, you have only three jacks in the rear, which are normally used for mic in + line in + line out?
[09:38] <diwic> Odd_Bloke, i e, not front + read + clfe
[09:38] <diwic> by default
[09:39] <Odd_Bloke> diwic: Yep, only three jacks; that assignment sounds likely (though I've never needed/wanted anything other than output).
[09:40] <diwic> Odd_Bloke, not sure how well that works, with PulseAudio and all. I suggest you retask your jacks a little harder with hda-jack-retask instead
[09:40] <diwic> Odd_Bloke, I'd say it's not officially supported at least
[09:48] <cousteau> who do I have to bug for https://bugs.launchpad.net/trusty-backports/+bug/1368094 to be taken care of?
[09:48] <ubottu> Launchpad bug 1368094 in trusty-backports "Please backport openjdk-8 8u40~b04-2 (universe) from utopic" [Undecided,In progress]
[09:52] <rbasak> cousteau: only one of these people: https://launchpad.net/~ubuntu-backporters/+members
[09:52] <rbasak> cousteau: looks like there's a mailing list - ubuntu-backports@lists.ubuntu.com
[09:52] <cousteau> do they have a channel I can make noise on?
[09:52] <rbasak> I'm not aware of an IRC channel specifically for backporters. #ubuntu-devel might be a reasonble fallback but I'm not sure all backporters read that channel
[09:53] <rbasak> openjdk sounds like a pretty major piece of backporting work to meth though!
[09:53] <cousteau> well, I already commented on the bug report, I see no point on commenting on the mailing list too
[09:53] <cousteau> I assumed they'd be here too
=== marcusto_ is now known as marcustomlinson
[09:54] <cousteau> well, I'd say it's important to do; as I commented in the bug some third party software may use Java 8 (which is the currently supported Java version) so it won't work on Ubuntu LTS unless you install a PPA
[09:56] <cousteau> the same will happen when Java (and OpenJDK) 9 is released (Sept 2016).  Whoever's "in charge" will have one year until Java 8 is EOL'd (Sept 2017 approx).
[09:59] <rbasak> Sorry, I didn't mean to imply that it's not useful or valuable, and I appreciate you driving it.
[10:00] <rbasak> I'm just saying that it sounds like a considerable piece so getting review and upload may be difficult if that review is a considerable amount of work compared to your average backport.
[10:00] <cousteau> oh... yeah, I didn't understand that :)
[10:00] <cousteau> I get that doing that is a huge amount of work
[10:01] <cousteau> that's why I commented that OpenJDK 9 should be started to be backported ASAP; to have as much time as possible for this task to be completed
[10:02] <cousteau> it's also a higher priority than the average backport, I think
[10:04] <cousteau> (...well, for now there's the PPA workaround, so it's not a life or death matter, but I think this should be done anyway)
[10:09] <Odd_Bloke> diwic: hdajackretask seems to have done the trick; thanks!
[11:27] <sil2100> barry: hey! In-between stuff I'm looking into https://bugs.launchpad.net/ubuntu/+source/python-glance-store/+bug/1505632 if you don't mind
[11:27] <ubottu> Launchpad bug 1505632 in python-glance-store (Ubuntu) "FTBFS due to failing unit tests" [Undecided,In progress]
=== _salem is now known as salem_
[12:29] <gonzzor> Hi, is it possible to use the same debian/{control,rules} files if I want the package to work with upstart in older Ubuntu and systemd in never ubuntu?
[12:30] <gonzzor> The configure script requires an option to enable upstart script generation and does a pkg-config call for systemd..
[12:30] <cjwatson> You could make it work with both init systems in both old and new releases.
[12:30] <cjwatson> Which has been quite standard for some time ...
[12:31] <gonzzor> So I would install both a .service and a .conf, or?
[12:31] <cjwatson> Yeah
[12:31] <cjwatson> And see dh_installinit(1) for maintainer script logic
[12:34] <gonzzor> Ah, I see. How about Build-Depends for systemd on systems that doesn't have it?
[12:34] <cjwatson> You can safely build-depend on dh-systemd back to trusty
[12:34] <gonzzor> Good, trusty is the oldest I need to support..
[12:35] <cjwatson> Rather than build-depending on systemd itself, though, you should pass --with-systemdsystemunitdir=/lib/systemd/system to configure
[12:35] <gonzzor> So users of 15.10 would still get the upstart script but it won't be used unless they are actually running upstart instead of systemd..
[12:35] <cjwatson> (Assuming the package supports such a flag, but it's fairly standard and you could add it if it doesn't)
[12:35] <cjwatson> Right
[12:36] <gonzzor> Yes, it does support that flag, and by default calls pkg-config to ask for path if none is given.. Thanks to systemd developers for providing the autoconf snippet :)
[12:40] <gonzzor> cjwatson: Thanks for the help :)
[12:40] <cjwatson> np
[12:51] <cjwatson> gonzzor: If you need an example, binfmt-support is a reasonably simple package of mine that supports several init systems.
=== fginther` is now known as fginther
[13:28] <Odd_Bloke> cjwatson: wgrant: smoser: utlemming_sprint: I'm trying to test new UEFI images (currently for amd64, but soon ppc64el and arm64); what's the best way to confirm that an image is bootable?
[13:33] <cjwatson> Odd_Bloke: A minimal test would be to install ovmf and do something like   qemu-system-x86_64 -enable-kvm -bios /usr/share/qemu/OVMF.fd -m 1024 -cdrom trusty-server-amd64.iso
[13:33] <cjwatson> Odd_Bloke: UEFI isn't a thing on ppc64el as far as I know, and I don't know exactly what firmware image you'd need on arm64.
[13:33] <wgrant> arm64 needs wily's qemu-efi
[13:34] <wgrant> it boots the cloud images fine, just might need overriding to virtio on the qemu commandline
[13:35] <wgrant> any qemu-efi older than current wily will either hang or not autoboot a cloud image
[13:36] <wgrant> for booting ppc64el xloud images, the default firmware (SLOF) works fine
[13:36] <wgrant> (but ppc64el is not UEFI)
[13:44] <barry> sil2100: cool
=== balloons is now known as Guest77290
[13:53] <Odd_Bloke> cjwatson: wgrant: Cool, thanks.
[13:53] <mterry> jdstrand, so in bug 1267393, a bunch of new components got added.  Is the timeframe for that 15.10 or 16.04?  Are you / the security team going to look at the golang packages there?  I can do the non-go ones, like dh-golang if it helps
[13:53] <ubottu> bug 1267393 in juju-core (Ubuntu) "[MIR] juju-core, juju-mongodb, gccgo, golang" [High,Confirmed] https://launchpad.net/bugs/1267393
[13:54] <Odd_Bloke> Yeah, don't know why I thought EFI was a thing on ppc64el.
[14:04] <pitti> slangasek, mvo: I just tried the proposed apt pinning in bug 1503150; I thought it worked for me a few days ago, but not right now
[14:04] <ubottu> bug 1503150 in autopkgtest (Ubuntu) "Minimize installed packages from -proposed" [Wishlist,In progress] https://launchpad.net/bugs/1503150
[14:04] <pitti> am I doing anything wrong there?
[14:13] <mvo> pitti: what kind of error do you get? or what behavior?
[14:13] <pitti> mvo: the unmet dependencies, what I just wrote in comment #5
[14:16] <mvo> pitti: aha, sorry for the noise then, I have a look in the bug (in a bit)
[14:17] <pitti> mvo: thanks; the idea was that with pin prio 100 it would take required deps from -proposed, but take everything that can be resolved in -release from that
[14:23] <pitti> slangasek, mvo: did another followup (doesn't solve the problem, but explains what worked before)
[14:26] <tdaitx> doko, I'm not sure if you saw this yesterday: debdiff for squid 3.8.14 is @ https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1502178
[14:26] <ubottu> Launchpad bug 1502178 in squid3 (Ubuntu) "update squid from 3.3.8 to 3.3.14" [Undecided,New]
[14:27] <tdaitx> err... s/3.8.14/3.3.14/ =)
[14:27] <doko> tdaitx, I can't decide this, you have to ask somebody from the ubuntu-release team ... e.g. Laney, slangasek, bdmurray, infinity, ...
[14:48] <jdstrand> mterry: there is only one that I thinks actually needs a security review-- golang-go.crypto
[14:49] <jdstrand> the others just need to follow the Debian go packaging
[14:50] <tdaitx> Laney, slangasek, bdmurray, infinity: I appreciate if any of you could take a look at LP: #1502178 when you have the time =)
[14:50] <ubottu> Launchpad bug 1502178 in squid3 (Ubuntu) "update squid from 3.3.8 to 3.3.14" [Undecided,New] https://launchpad.net/bugs/1502178
[14:54] <bev> A question about packaging...I see a few packages which declare that they break every other version of itself, e.g. libstdc++6=4.9.2.10ubuntu13 says Breaks: libstdc++6 (!= 4.9.2-10ubuntu13). What's the reason for doing this, can't there only be one version of the package be installed at the same time anyways?
[14:56] <mterry> jdstrand, noted, thanks.  Are they trying to get these in for wily?
[14:56] <jdstrand> mterry: yes
[14:56] <mterry> jdstrand, humph ok
[14:56] <jdstrand> lxd too
[14:59] <cjwatson> bev: Where are you seeing that?  Not in the raw package metadata, I think.
[14:59] <cjwatson> But maybe in some frontend?
[15:02] <bev> cjwatson: It was in the output of 'aptitude show libstdc++6'. Your are right, if I download the .deb it's not in the control file
[15:03] <cjwatson> bev: Right.  That's for Multi-Arch: same packages; it's possible to have those installed for more than one architecture at the same time
[15:03] <cjwatson> bev: apt generates that Breaks field automatically in such cases to ensure that you have the same version installed across all architectures
[15:03] <bev> Ah, I see. Thanks!
[15:04] <cjwatson> (Also an implicit Replaces: ${self}:other (<< ${binary:Version}) )
[15:04] <cjwatson> bev: More detail is at https://wiki.ubuntu.com/MultiarchSpec
[15:24] <tsdgeos> seb128: you may as well SRU the whole poppler and not that individual fix :D
[15:25] <seb128> tsdgeos, would perhaps do if poppler was not breaking abi compatibility between every version ;-)
[15:25] <tsdgeos> but we don't :)
[15:25] <seb128> you do on core
[15:25] <seb128> which things shouldn't use
[15:25] <tsdgeos> it's the people using the wrong libs ;)
[15:25] <seb128> but do....
[15:25] <tsdgeos> complain to them :D
[15:25] <tsdgeos> i'm just wondering why this fix is more important than the other N we've done
[15:28] <seb128> tsdgeos, it might not be, but it has a reproducable test case and users who care about it/are probably going to verify the sru
[15:29] <tsdgeos> honestly that definition apply to 99% of the bugs we fix
[15:29] <tsdgeos> we seldom fix bugs without reproduceable tests cases
[15:29] <seb128> we should maybe SRU more poppler fixes
[15:29] <tsdgeos> but ok, it's just someone complained loudly i guess :D
[15:29] <seb128> it's just a manpower issue
[15:29] <seb128> you would argue that fixing nothing is better than fixing some issues?
[15:30] <seb128> I do agree that fixing all issues would be best
[15:30] <tsdgeos> no i was just wondering why *this* one
[15:30] <seb128> we just don't have somebody active enough on the poppler package to do that
[15:30] <seb128> just because I saw some user comment asking about it
[15:30] <seb128> and the description states it's hitting people trying to open boarding pass documents
[15:31] <tsdgeos> at some point if we're serious about the document viewer on the phone i'd say we should make it so we track poppler more closely
[15:32] <tsdgeos> also on the phone libreoffice and latex would be minor problems
[15:32] <tsdgeos> or maybe not :D
[15:32] <seb128> right
[15:32] <seb128> except that the document viewer is going to use libreoffice
[15:33] <seb128> but yeah, I'm going to try to be better at backporting poppler updates/fixes in the next lts
[15:34] <tsdgeos> not blaming you btw
[15:34] <tsdgeos> i understand this is a manpower issue
[15:34] <tsdgeos> but seriously nowadays all the API changes are so corner case that a rebuild should just get us good with the new packages
[15:35] <tsdgeos> not sure a rebuild is acceptable from the point of view of the policy makers
[15:38] <seb128> probably not easily in SRUs
[15:40] <stgraber> infinity, pitti, kees, slangasek: I won't be able to make the TB meeting due to having to be at an in-person meeting, sorry.
[15:43] <pitti> stgraber: ack; should be a near-zero agenda anyway
[15:44] <seb128> bdmurray, hey, do you know why https://errors.ubuntu.com/problem/ebd96647ac9cf4ab66948f10e1daa1815c85075c states that it doesn't have g-d-u ddebs when they are on http://ddebs.ubuntu.com/pool/main/g/gnome-disk-utility/
[15:44] <infinity> stgraber: Slacker. :)
[15:45] <bdmurray> seb128: looking
[15:45] <seb128> bdmurray, thanks
[15:46] <seb128> infinity, hey, do you plan to get the current tzdata uploaded for !wily?
[15:46] <bdmurray> seb128: they aren't on ddebs - the amd64 version of 3.16.2-0ubuntu1 is missing
[15:46] <seb128> oh, right
[15:47] <infinity> seb128: I planned to do that a week ago.  Argh.  I brained incorrectly and it slipped off the stack.  Will do now.
[15:47] <seb128> infinity, thanks
[15:47] <seb128> bdmurray, thanks, going to do a no change g-d-u upload then
[15:47] <bdmurray> having said that apport was recently changed to check launchpad for ddebs in this case
[15:53] <pitti> infinity, kees, slangasek: TB meeting reminder in 7 mins
[15:54] <bdmurray> mvo: Could you have a look at bug 1505337? It has to do with the auto_flag changes to aptdaemon / update-manager.
[15:54] <ubottu> bug 1505337 in update-manager (Ubuntu) "update-manager crashed with aptdaemon.errors.AptDaemonError in commit(): org.debian.apt: kinit#auto isn't a valid package name" [Medium,New] https://launchpad.net/bugs/1505337
[15:58] <infinity> pitti: Ahh, crap, I'm chairing I guess, since stgraber bowed out.  I have to remind myself how to use the bot every time.
[16:00] <mvo> bdmurray: I have a look, my guess is that u-m may miss a strict version dependency on aptdaemon or that aptdeamon was running, u-m and aptdaemon got updated but the running aptdaemon was not replaced so u-m tried to drive it with the new flags but the old one was still active that did not understood it
[16:02] <bdmurray> mvo: the version dependency was added so I'd agree with second idea.
[16:02] <bdmurray> mvo: is there anyway to prove that?
[16:03] <mvo> bdmurray: reproducing by intalling a non-proposed system, running u-m, update close u-m and quickly open u-m again, aptdaemon has a timeout of some minutes of inactivity iirc of inactivity
[16:04] <mvo> bdmurray: tricky to fix if the theory is true
[16:04]  * mvo needs to think about it
[16:08] <bdmurray> mvo: Does aptdaemon.txt in the bug contain the process id of aptdaemon?
[16:11] <bdmurray> mvo: Yes, it does and it didn't change between installing u-m and aptdaemon and the failure.
=== g4mby is now known as PaulW2U
[17:57] <dobey> anyone know how to make gccgo-4.9 work on vivid?
=== pat__ is now known as pmcgowan
[18:12] <mustafam> Hi,
[18:12] <mustafam> I think this bug is important, it prevents any user with only DSL/PPPoE from connecting, and we approach release:
[18:12] <mustafam> [21:04] <mustafam> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1446689
[18:12] <ubottu> Launchpad bug 1446689 in network-manager (Ubuntu) "network-manager configured to use /usr/sbin/pppoe but does not recommend pppoe" [Undecided,Confirmed]
[18:13] <mustafam> Its solution is a matter of build flag
[18:13] <mustafam> Or adding a dependency for pppoe
[18:24] <rbasak> cyphermox: ^
=== coreycb` is now known as coreycb
=== JanC_ is now known as JanC
=== salem_ is now known as _salem
[21:58] <chiluk> infinity are you around?  would you like to discuss bug 1432871 real quick?  I see you pinged caribou in the backlog while I was on vaca..
[21:58] <ubottu> bug 1432871 in coreutils (Ubuntu Wily) "`df` shows bind mounts instead of real mounts." [Low,In progress] https://launchpad.net/bugs/1432871
[22:05] <chiluk> I guess I'll try tomorrow...
[22:40] <seb128> bdmurray, your software-properties upload seems buggy and the bug you fixed was already handled by the previous upload from today I think
[22:43] <seb128> bdmurray, well "buggy", it shouldn't create issue but you special case one error, the reports have different variants, like some user use "ppa:/user/name" but some have "ppa::user/name"
[22:44] <seb128> bdmurray, also please do merge propose your changes against lp:software-properties so they can get reviewed
[23:02] <bdmurray> seb128: I tested it and the error I was trying to address didn't seem fixed.
[23:03] <seb128> bdmurray, weird, in any case there is no reason to bypass merge proposal and reviews
[23:06] <seb128> (the exception should be handled by the previous commit as well, unsure why it didn't work for you)
[23:07] <bdmurray> seb128: the previous commit will raise an exception, but does it tell you what the proper format is? My thought was a lot of people seem to be making this mistake so the leading forward slash must be in some documentation somewhere and its easy to fix.
[23:10] <seb128> bdmurray, looking to the reported errors the leading slash is not the only typo, some users have an extra ":" for example, so handling one case only seems a bit random
[23:13] <bdmurray> seb128: I would have ignored it but there are about 1800 instances of the leading slash. I guess you could find somebody to reject it if you don't like it.
[23:15] <seb128> bdmurray, I'm going to try it tomorrow, but the previous upload should handle that error as well as other cases of typos and display an error saying that the format is wrong rather than triggering apport
[23:15] <seb128> unsure why it's not working for you
[23:16] <seb128> bdmurray, but please next time go through merge proposal and reviews rather than commiting directly to trunk like that
[23:16] <bdmurray> seb128: I've tested it again and the ubuntu12 works for me but I think it could be much more helpful. "ERROR: 'ppa:/gottcode/gcppa' is not a valid ppa format" doesn't help.
[23:17] <bdmurray> seb128: Is software-properties special somehow?
[23:17] <seb128> bdmurray, well, what happens in your version if add "ppa::gottcode/gcppa'?
[23:17] <seb128> bdmurray, it's an upstream project maintained in launchpad, like apport, update-manager, software-center, etc
[23:18] <seb128> we usually go through code review for those
[23:18] <seb128> or what do you mean?
[23:21] <bdmurray> I mean I've been commiting directly to update-manager and ubuntu-release-upgrader for years now, and didn't realize I should be using merge proposals and reviews.
[23:21] <seb128> hum, k, I usually mp fixes and try to nag mvo or somebody for review
[23:21] <seb128> oh well, no big deal
[23:22] <seb128> your change is fine, I just think it's incomplete but I guess we can fix the other cases with another upload
[23:26] <seb128> night