[00:00] <sbeattie> sarnold: I turned it off for my apt-mirror, but I also fallback point to archive.ubuntu.com via apt-cacher-ng, and so pull the Translations files (and thus package descriptions) from there.
[00:01] <sarnold> sbeattie: ahhhh. that works.
[00:01] <sbeattie> that is, in my laptop's sources.list, I do the fall back thing. That way I also get packages that my mirror has not managed to download yet.
[00:26] <tdaitx> bdmurray, what hook exactly causes apport to run for eg. LP: #1451656 and LP: #1448331 ? I'm wondering if there is a way to collect additional information from update-alternatives when those are triggered...
[00:26] <ubottu> Launchpad bug 1451656 in openjdk-7 (Ubuntu) "package openjdk-7-jdk:amd64 7u79-2.5.5-0ubuntu0.14.04.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,Incomplete] https://launchpad.net/bugs/1451656
[00:26] <ubottu> Launchpad bug 1448331 in openjdk-7 (Ubuntu) "package openjdk-7-jre-headless:amd64 7u79-2.5.5-0ubuntu0.14.04.2 failed to install/upgrade: sub-processo script post-installation instalado retornou estado de saída de erro 2" [Undecided,New] https://launchpad.net/bugs/1448331
[00:48] <mwhudson> how much space does an archive mirror take up? roughly?
[00:48] <mwhudson> mm i guess i'd want a sid mirror too really
[00:49] <lifeless> depends on the suites you're mirroring
[00:49] <lifeless> there's rough docs on the wiki for mirror operators IIRC
[00:52] <mwhudson> https://wiki.ubuntu.com/Mirrors says 777gb
=== _salem is now known as salem_
=== salem_ is now known as _salem
[04:29] <pitti> Good morning
[04:53] <pitti> utlemming: ah, are http://cloud-images.ubuntu.com/xenial/ being produced regularly now? nice!
[04:53] <pitti> utlemming: ppc64el images are still missing?
[05:08] <pitti> oops, I broke debhelper
[05:34] <pitti> *phew*, only iscsitarget and apport were affected, and these were both held back by tests
[07:17] <seb128> sru team, bdmurray, arges, is anything blocking the glib SRU to wily to be accepted? it's in the queue since 11-09 and fixes an important nautilus segfault issue, users start being annoyed and keep asking why it's taking so long to get reviewed
[07:18] <seb128> though it seems Laney did another upload with the same version
[07:18] <seb128> confusing :-/
[07:20] <dholbach> good morning
[07:20] <seb128> same with the libreoffice one, that was supposed to be a SRU landing around release time and it's sitting in the queue :-/
[07:20] <seb128> hey dholbach!
[07:21] <pitti> stgraber: with lxd, is there a way to relax the apparmor policies to allow mounting in the container? similar to what I do with lxc in https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/lxc-slave-admin/setup-adt-lxc.commands#n49
[07:21] <pitti> stgraber: some autopkgtests rely on that
[07:21] <dholbach> hey seb128
[07:21] <pitti> stgraber: or is that a question of capabilities and not apparmor, and thus difficult in an unpriv container in principle?
[07:27] <stgraber> pitti: unpriv containers can't mount block devices, that's a kernel restriction but the ones you have listed are virtual filesystems and so should be fine
[07:28] <stgraber> pitti: you can append things to the generated per-container apparmor profile by setting the raw.apparmor configuration key against the container or in a profile which applies to the container
[07:29] <stgraber> pitti: though in your case, if things do work inside an unprivileged container, I'd suggest you just set raw.lxc=lxc.aa_profile=unconfined to turn off apparmor entirely. For unprivileged containers, apparmor isn't actually needed for security, it's mostly an extra safety net in case the kernel itself goes bad, for an adt environment, relying only on the kernel seems reasonable to me and will require less messing with apparmor configs.
[07:29] <pitti> stgraber: ah, bind mounts and virt fses should work?
[07:29] <pitti> stgraber: indeed, that sounds even better
[07:30] <pitti> stgraber: what I have in mind is to create an arm64 cloud instance, then create armhf lxd containers inside that and test there; so even if there's a bad test it can't get *that* far out
[07:30] <pitti> stgraber: and if we have someone uploading bad tests to ubuntu, we have a bigger problem anyway :)
[07:31] <stgraber> yup, and if someone manages to escape an unprivileged container even with apparmor turned off, we have a very serious kernel security bug on our hands anyway :)
[07:32] <pitti> $ lxc launch images:ubuntu/xenial/amd64 x1
[07:32] <pitti> root@x1:~# mount -t proc proc /p
[07:32] <pitti> mount: proc is write-protected, mounting read-only
[07:32] <pitti> mount: cannot mount proc read-only
[07:32] <stgraber> that's with raw.lxc: lxc.aa_profile=unconfined ?
[07:32] <pitti> [11077.685109] audit: type=1400 audit(1448436715.772:43): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxd-x1_</var/lib/lxd>" name="/p/" pid=12078 comm="mount" fstype="proc" srcname="proc" flags="rw"
[07:32] <pitti> [11077.685189] audit: type=1400 audit(1448436715.772:44): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxd-x1_</var/lib/lxd>" name="/p/" pid=12078 comm="mount" fstype="proc" srcname="proc" flags="ro"
[07:32] <pitti> ah ok, that's apparmor
[07:32] <stgraber> yup
[07:32] <pitti> stgraber: no, that was just testing the default ocnfig
[07:34] <pitti> stgraber: sorry, still trying to find the right lxc config setting; is that per-container or global? I tried
[07:34] <pitti> lxc config set raw.lxc=lxc.aa_profile=unconfined
[07:34] <pitti> lxc config set x1 raw.lxc=lxc.aa_profile=unconfined
[07:35] <stgraber> lxc config set CONTAINER raw.lxc lxc.aa_profiled=unconfined
[07:35] <stgraber> or to apply it to all containers using the default profile:
[07:35] <pitti> oh, so not an '=' but a space
[07:35] <stgraber> lxc profile set default raw.lxc lxc.aa_profile=unconfined
[07:35] <stgraber> also, typoed my first command, it's aa_profile, not aa_profiled :)
[07:36] <pitti> \o/ works -- merci !
[07:36] <pitti> stgraber: ah, so it sounds like I should create a new profile "autopkgtest", disable apparmor there, and create containers with that profile?
[07:37] <stgraber> yep. You can either make that profile include the stuff usually in the default profile, or you can have your containers use both profiles:
[07:37] <stgraber> lxc launch ubuntu blah -p default -p autopkgtest
[07:37] <pitti> bind mounts work too
[07:38] <stgraber> (note that anything using raw.* in the config is a bit of a hack, we'll hopefully soon have security.* knobs that will do that stuff for you without having to use raw.lxc ;))
[07:38] <pitti> stgraber: more generally, would you say that it's a good idea to move tests from lxc to lxd at this point, or still too early?
[07:38] <pitti> (from an upstream support perspective)
[07:39] <pitti> the killer feature why I'd like to add an lxd backend is that it seamlessly talks to remote containers
[07:39] <pitti> which lxc itself can't do, but that's what I need for moving armhf testing into scalingstack as long as that doesn't have native armhf support
[07:39] <Logan> zul: are you planning on merging in python-networkx?
[07:40] <pitti> and thus I need to do this nesting of cloud instance → container
[07:40] <stgraber> The more users we get the better. We're still very busy fixing various stuff in LXD but the core features are all there and working. If you're using the command line tool to drive LXD, things should be pretty stable, if you use the API or pylxd then you should expect to have to do minor changes every couple of upstream releases as we finalize the API.
[07:41] <pitti> stgraber: I'm actually limited to a CLI API in autopkgtest
[07:42] <stgraber> cool, so my only recommendation is to always make sure you run the same version of the client and the server, until we release 2.0 and have a clear commitment on API stability (February is our current plan)
[07:43] <pitti> stgraber: yes, that should be fine
[07:43] <pitti> stgraber: after "lxc profile create autopkgtest", how do I tell it to copy (i. e. "inherit from") default?
[07:44] <stgraber> I don't believe we've ever changed command names or arguments in a non-backward compatible way so far, but the occasional API fix will break older clients talking to newer server. Newer client talking to older servers is usually fine for a few releases as we add backward compat code when possible.
[07:45] <stgraber> pitti: profiles can't themselves inherit, so either you just copy/paste default in there (lxc profile show default => lxc profile edit autopkgtest) or you specify both when creating a container: lxc launch IMAGE CONTAINER -p default -p autopkgtest
[07:45] <pitti> stgraber: I'm not that concerned about API stability at this point; I guess I'll just run the same trusty PPA on the controller host and the arm64 instance that hosts the container, and I should be fine
[07:45] <stgraber> pitti: note that you don't even need a PPA, we keep trusty-backports updated with all xenial uploads
[07:45] <stgraber> oh, but no arm64
[07:45] <stgraber> yeah, use the PPA :)
[07:45] <pitti> $ lxc profile show default | lxc profile edit autopkgtest
[07:45] <pitti> error: Cannot change profile name
[07:46] <stgraber> oh yeah, that wasn't meant litteraly, you'd want to copy the devices section from default since that's the only thing we've got in there (eth0 config using lxcbr0)
[07:46] <pitti> I might have misunderstood cat profile.yml | lxc profile edit <profile> # read from profile.yml
[07:46] <pitti> and "lxc profile show default" looks YAMLish
[07:46] <stgraber> the show output does contain the profile name, so if piping one into the other, you'd have to sed the profile name
[07:47] <pitti> ah!
[07:47] <pitti> $ lxc profile show default | sed '/^name:/ s/default/autopkgtest/' | lxc profile edit autopkgtest
[07:47] <pitti> works
[07:47] <stgraber> yeah, I wonder if we can drop it from there actually, it's not useful to have in show since a) you passed it on the command line anyway b) you can't edit it from "lxc profile edit"
[07:49] <pitti> stgraber: cool, I now have the magic commands to create/inherit/amend the "autopkgtest" profile, build a container, and bind/proc mounts work
[07:49] <pitti> stgraber: cheers!
[07:49] <stgraber> yay!
[07:50] <stgraber> guess it's time for me to go to bed then :)
[07:53] <pitti> stgraber: bonne nuit
[09:02] <caribou> Hello, any Archive Admin in the room ?
[09:02] <caribou> I uploaded kdump-tools to debian where it works fine but it fails on install on Xenial
[09:02] <caribou> in a way that is rather annoying to remove (failing on configure)
[09:03] <pitti> how is that related to archive admin?
[09:06] <Laney> seb128: they are the same but the first one didn't have the right header to close the bugs, bdmurray wanted me to reupload it
[09:07] <seb128> Laney, ah ok, it means bdmurray did review the SRU and we might manage to get it approved now, good!
[09:08] <caribou> pitti: I thought that only AA could pull packages already in the archive
[09:09] <pitti> caribou: no, if it's in, it's in
[09:09] <caribou> pitti: ok
[09:09] <pitti> caribou: for really drastic cases IS could lobotomize it out, but this doesn't look like one
[09:10] <pitti> caribou: you could just upload a fix, no? this only affects the devel series
[09:10] <caribou> pitti: no, just a config script that errors out
[09:10] <caribou> pitti: that's what I'm working on
[09:10] <caribou> pitti: looks like debhelper is adding incomplete stuff
[09:10] <pitti> caribou: oh, the "missing fi"?
[09:10] <caribou> pitti: yep
[09:11] <pitti> caribou: I fixed that this morning in https://launchpad.net/ubuntu/+source/debhelper/9.20151117ubuntu2
[09:11] <pitti> caribou: ah, I checked https://lists.ubuntu.com/archives/xenial-changes/2015-November/ for potentially affected packages
[09:11] <pitti> caribou: but as your's was a sync, I didn't catch that
[09:11] <caribou> pitti: np
[09:11] <pitti> caribou: so this will only need a no-change "build1" upload
[09:12] <caribou> pitti: sorry for the nOOb question, but what is the *correct* way to do this ?
[09:13] <pitti> caribou: first, what is the *correct* package name? kdump-tools does not exist
[09:13] <caribou> pitti: makedumpfile is the source package
[09:13] <pitti> oh, makedumpfile
[09:13] <pitti> caribou: pull-lp-source makedumpfile, then dch --rebuild "Rebuild against fixed debhelper", and build/upload
[09:14] <caribou> pitti: good, thanks. ok will do in a minute
[09:14] <pitti> caribou: i. e. the version should be 1:1.5.9-1build1 so that it keeps autosyncing (*not* -1ubuntu1 -- there are no real changes)
[09:15] <pitti> caribou: I can upload it for you if you want (I broke it after all)
[09:15] <caribou> pitti: ah, that's the catch
[09:15] <caribou> pitti: no, I need the experience
[09:15] <pitti> caribou: unless you want to do it for the learning experience
[09:16] <pitti> caribou: I actually have a mass rebuild script which makes this rather simple: rebuild-lib-transition "fixed debhelper" makedumpfile
[09:16] <pitti> :)
[09:16] <pitti> (I guess every core dev involved in doing library transitions has one by now)
[09:17] <caribou> pitti: I'd love to see the script if you don't mind. That's part of the core dev work I never had to do so far
[09:17] <pitti> come on, scp
[09:17] <pitti> caribou: http://people.canonical.com/~pitti/scripts/rebuild-lib-transition
[09:17] <pitti> it's pretty stupid, but saves quite some typing if you have to upload 200 no-change rebuilds
[09:18] <caribou> pitti: got it
[09:18] <pitti> cjwatson: can we easily get a list of packages that got autosynced since yesterday evening?
[09:18] <caribou> pitti: so this is used when some library has changed & you need to rebuild all the packages that depends on it, right ?
[09:19] <pitti> caribou: correct; or in this case, against an updated build chain (debhelper, gcc, or what not)
[09:19] <caribou> pitti: ok, I'll remember that
[09:48] <caribou> pitti: uploaded
=== paulliu1 is now known as paulliu
[10:19] <cjwatson> pitti: logs are in http://people.canonical.com/~ubuntu-archive/auto-sync/
[10:20] <cjwatson> pitti: or you could use lp.distributions['ubuntu'].main_archive.getPublishedSources(distro_series='/ubuntu/xenial', order_by_date=True) and walk through the collection until you hit some cut-off date, to see everything in one go
[10:27] <pitti> cjwatson: ah, thanks!
[10:27] <pitti> cjwatson: I already checked the manual uplaods, so I'll check http://people.canonical.com/~ubuntu-archive/auto-sync/
[10:29] <mapreri> pitti: thanks! ♥
[10:29] <pitti> mapreri: I didn't do much, thanks to you for fixing!
[10:30] <cjwatson> pitti: fortunately one of the affected auto-sync runs did ~nothing - I'm assuming dinstall must have had a slight hiatus, everything seemed to be fine on our end
[10:30] <pitti>  liblinear1        | 1.8+dfsg-5   | xenial                   | amd64, arm64, armhf, i386, powerpc, ppc64el
[10:30] <pitti>  liblinear3        | 2.1.0+dfsg-1 | xenial-proposed          | amd64, arm64, armhf, i386, powerpc, ppc64el
[10:30] <pitti> sorry, ECHANNEL
[10:36] <xnox> pitti, cjwatson, reverse sorting that by default in apache would be nice. also did not know this is public now \o/
[10:38]  * xnox bookmarks /current.log pag
[10:38]  * xnox bookmarks /current.log page
[10:50] <killall> sladen, thanks :)
=== _salem is now known as salem_
[11:00] <pitti> caribou: ok, I went through the recent syncs, and these three packages are affected: xinetd, makedumpfile, knot
[11:01] <pitti> caribou: you said you were going to upload makedumpfile yourself? I'll kick the others then
[11:01] <pitti> ah, you did already
[11:01] <caribou> pitti: yep
[11:44] <TJ-> To save me a lot of searching, can anyone remember in which release  our gcc library builds switched from a minimum CPU of 586 (pentium) to 686 (pentium2) ?
[12:00] <xnox> TJ-, https://wiki.ubuntu.com/ToolChain should have the info
[14:03]  * Chipaca reads http://www.irishtimes.com/news/crime-and-law/courts/circuit-court/man-paid-friend-to-make-hoax-bomb-call-to-intel-to-avoid-work-1.2442051
[14:03]  * Chipaca looks at xnox 
[14:05] <xnox> Chipaca, i'm not a spokesperson for Intel =) you can get in touch with media representative in your country. And fyi, i'm based in the UK, not Ireland ;-)
[14:06] <Chipaca> xnox: i was going to ask if that was you :-D
[14:06] <Chipaca> xnox: but yeah, ireland
[15:01] <TJ-> I'm looking at the (lib)gcc-4.9 build logs for Wily. Compiler options all seem to be "-march=i486 -mtune=i686", cmov support (introduced in i686) in the assembler isn't found. Despite that, when I do, e.g., "objdump -S /usr/lib/gcc/i686-linux-gnu/4.9/libgcc.a | grep cmov | wc -l" ==> 1175 hits. I must be missing something obvious, but what is it?
[15:13] <mardy> seb128: do you have a minute? Got a question about patching a package which was uploaded to Debian (libgdata)
[15:13] <seb128> mardy, hey, sure
[15:14] <mardy> seb128: so, we'l like to have this bug https://bugzilla.gnome.org/show_bug.cgi?id=758524 fixed in Ubuntu ASAP
[15:14] <ubottu> Gnome bug 758524 in Google Documents service "Cannot search documents by title" [Major,New]
[15:15] <mardy> seb128: I used debcheckout to get the source
[15:15] <seb128> mardy, I can backport that patch to Ubuntu and then sync over from Debian next time they do an update which includes that commit
[15:15] <mardy> seb128: but it's svn; I'm not sure how to proceed
[15:16] <mardy> seb128: if you could, that would be awesome
[15:16] <seb128> or try to see if Laney wants to commit/upload that to Debian then we sync over
[15:18] <Laney> could do
[15:18] <Laney> is it important to have RIGHT NOW or can wait for the release?
[15:18] <seb128> when is the release? ;-)
[15:18] <seb128> there was none since septembre
[15:18] <seb128> unsure how regular this cycle is
[15:19] <seb128> I guess "would be nice to not wait for a release"
[15:19] <Laney> presumably a short time after asking upstream to make one
[15:19] <seb128> or if you can pull triggers to get that to happen wfm
[15:19] <Laney> this patch isn't even acn yet though
[15:20] <seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/libgdata/+bug/1173926
[15:20] <ubottu> Launchpad bug 1173926 in libgdata (Ubuntu) "unable to search for google drive documents in raring 13.04" [High,In progress]
[15:20] <seb128> seems like it's a piece of a bigger changeset
[15:21] <seb128> so would be nice to not delay too much so they can test/land the other bits
[15:21] <seb128> Laney, I can do a backport of the patch to xenial and we can sync over from Debian on next release
[15:22] <seb128> let's do that, it's probably simpler, Debian probably doesn't need the patch much since the reason we need it is for the unity lens
[15:22] <Laney> that's up to you, I would at least wait for it to be reviewed to include it in Debian
[15:22] <Laney> also the other branches aren't reviewed so they could presumably use a ppa package to verify them
[15:23] <seb128> right
[15:26] <seb128> Laney, k, let's wait a bit for it the be reviewed/merged and see if we can get a release, if that's not done in a few weeks I put a reminder to backport to change then
[15:27] <Laney> seb128: I can ping upstream to do a release once this is in
[15:28] <seb128> Laney, thanks
[15:28] <Laney> the first review came pretty fast last time
[15:28] <Laney> so doubt it will take long
[15:28]  * Laney subscribes to bug
[16:55] <mck182__> hey guys, I was sent here to ask for possibly backporting this patch to 15.10/qt5.5: http://code.qt.io/cgit/qt/qtbase.git/commit/src/corelib/kernel/qcoreapplication.cpp?id=6129be8a4ba976c42e51012ebaa9005eb402db80
[16:55] <mck182__> without this patch, user's QT_PLUGIN_PATH have no meaning
[16:56] <mck182__> and so it's hard to do custom development outside of úusr
[16:56] <mck182__> */usr
[16:57] <yofel> Mirv: ^
[18:11] <hallyn> arges: bug 1514690, what day are you likely to release that to wily-updates?
[18:11] <ubottu> bug 1514690 in lxcfs (Ubuntu Wily) "rebooting container with systemd >= 226 fails to create /lxc/adt-xenial/init.scope control group" [High,Fix committed] https://launchpad.net/bugs/1514690
[18:13] <stgraber> hallyn: did you notice the autopkgtest regression with this upload?
[18:14] <hallyn> no
[18:14] <stgraber> hallyn: seems to be caused by tests/test_confinment.sh not being executable
[18:14] <stgraber> http://people.canonical.com/~ubuntu-archive/pending-sru.html
[18:14] <stgraber> that lists all the current SRUs, how long they've in proposed for, state of bugs and autopkgtest state (on the left)
[18:14] <hallyn> why are the tests running?
[18:15] <stgraber> because we run autopkgtest for all uploads, including to stable releases
[18:15] <hallyn> yeah but we can't actually run lxcfs so shouldn't run the tests
[18:15] <stgraber> we sure can
[18:15] <stgraber> autopkgtest are run as root in a VM
[18:16] <hallyn> oh.  well that's what i was asking before
[18:16] <stgraber> ah, I thought you were talking about build time
[18:16] <hallyn> ok well screw that then - i'll make add the other two bugs that need to be SRUd and re-push with that fixed, thx
[18:16] <stgraber> package builds happen in a chroot as an unpriv user so we can't run tests there. But tests defined as autopkgtest (debian/tests/) run as root in VMs after the package has been built by LP and before it's released to user
[18:17] <stgraber> hallyn: ok, let me know when it's in the queue, I'll review and let it in.
[18:17] <stgraber> hallyn: make sure to pass -v0.10-0ubuntu2.1 to debuild when you generate the changes file
[18:18] <stgraber> hallyn: that way the published changelog will contain both the changelog entries for the 0ubuntu2.2 and 0ubuntu2.3 uploads together which makes tracking bug numbers and stuff easier
[18:18] <hallyn> stgraber: oh if you're going to do that i'll keep the other two sru's out then
[18:18] <hallyn> but, cna i just chmod the test files and build the pkg and they'll be extracted with the right perms?
[18:19] <stgraber> I don't think so, unless a diff can contain the change of the executable flag
[18:19] <stgraber> though 0.12-0ubuntu5 in xenial passed the tests, so whatever was done there should work :)
[18:19] <stgraber> http://autopkgtest.ubuntu.com/packages/l/lxcfs/ for the overview
[18:20] <stgraber> pitti: hey, any chance we can get e-mail notifications from adt setup again? that'd be kinda nice so I don't have to poll or wait for you to ping me :)
[18:25] <hallyn> stgraber: before i push, are you ok with http://paste.ubuntu.com/13504619/ ?
[18:40] <stgraber> hallyn: that's a bit of a workaround, but sure
[18:41] <hallyn> yeah, it is
=== tsimonq2 is now known as simonquigley
=== simonquigley is now known as tsimonq2
=== tsimonq2 is now known as tsq2
=== tsq2 is now known as tsimonq2
=== tsimonq2 is now known as walterlapchynski
=== walterlapchynski is now known as tsimonq2
=== rcj` is now known as rcj
[19:05] <ximion> Laney: you might want to make use of the X-AppStream-Ignore flag when renaming .desktop files
[19:05] <ximion> I am thinking of gedit specifically here
[19:06] <ximion> (just saw the odd metadata issues page ^^)
[19:19] <Mirv> mck182__: yofel: thanks, made a note about it although feel free to file bug at https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src too
[19:19] <Mirv> likely to the upcoming Qt 5.5 only or at least first
[19:21] <mck182__> Mirv: ok, can do
[19:28] <mck182__> Mirv: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1519927
[19:28] <ubottu> Launchpad bug 1519927 in qtbase-opensource-src (Ubuntu) "Please backport this patch into qtbase-5.5 for wily" [Undecided,New]
[19:32] <ben|> if a patch is not present in debian/patches/series is it still applied at any time during the build?
=== ben| is now known as ben___
[19:33] <sarnold> ben|: there's a handful of different debian patch management systems; even though quilt is most common these days, or at least it feels that way to me, there are other systems that don't use the debian/patch/series..
[19:33] <ben___> sarnold, exactly what i needed to know, thanks
[19:33] <sarnold> ben___: checking build logs is perhaps the best way to find out..
[19:33] <sarnold> at least I think they all show which patches are applied, if any
[20:04] <lamont> I know we were using biosdevname for network devices at some point... under what conditions do we use them instead of ethN, for what series?
=== salem_ is now known as _salem
=== ralsina is now known as ralsina_
=== ralsina_ is now known as ralsina
[21:04] <TJ-> lamont: I think it was new (not upgrade) installs of server. For systemd its systemd.link naming
[21:08] <attente> hello, i have finished packaging a project and am wondering if i would be able to upload it to the ubuntu archive
[21:11] <lamont> TJ-: ta
=== vrruiz_ is now known as rvr
=== lutostag_ is now known as lutostag
=== _salem is now known as salem_