sbeattiesarnold: 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:00
sarnoldsbeattie: ahhhh. that works.00:01
sbeattiethat 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:01
tdaitxbdmurray, 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
ubottuLaunchpad 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/145165600:26
ubottuLaunchpad 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/144833100:26
mwhudsonhow much space does an archive mirror take up? roughly?00:48
mwhudsonmm i guess i'd want a sid mirror too really00:48
lifelessdepends on the suites you're mirroring00:49
lifelessthere's rough docs on the wiki for mirror operators IIRC00:49
mwhudsonhttps://wiki.ubuntu.com/Mirrors says 777gb00:52
=== _salem is now known as salem_
=== salem_ is now known as _salem
pittiGood morning04:29
pittiutlemming: ah, are http://cloud-images.ubuntu.com/xenial/ being produced regularly now? nice!04:53
pittiutlemming: ppc64el images are still missing?04:53
pittioops, I broke debhelper05:08
pitti*phew*, only iscsitarget and apport were affected, and these were both held back by tests05:34
seb128sru 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 reviewed07:17
seb128though it seems Laney did another upload with the same version07:18
seb128confusing :-/07:18
dholbachgood morning07:20
seb128same with the libreoffice one, that was supposed to be a SRU landing around release time and it's sitting in the queue :-/07:20
seb128hey dholbach!07:20
pittistgraber: 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#n4907:21
pittistgraber: some autopkgtests rely on that07:21
dholbachhey seb12807:21
pittistgraber: or is that a question of capabilities and not apparmor, and thus difficult in an unpriv container in principle?07:21
stgraberpitti: 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 fine07:27
stgraberpitti: 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 container07:28
stgraberpitti: 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
pittistgraber: ah, bind mounts and virt fses should work?07:29
pittistgraber: indeed, that sounds even better07:29
pittistgraber: 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 out07:30
pittistgraber: and if we have someone uploading bad tests to ubuntu, we have a bigger problem anyway :)07:30
stgraberyup, 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:31
pitti$ lxc launch images:ubuntu/xenial/amd64 x107:32
pittiroot@x1:~# mount -t proc proc /p07:32
pittimount: proc is write-protected, mounting read-only07:32
pittimount: cannot mount proc read-only07:32
stgraberthat'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
pittiah ok, that's apparmor07:32
pittistgraber: no, that was just testing the default ocnfig07:32
pittistgraber: sorry, still trying to find the right lxc config setting; is that per-container or global? I tried07:34
pittilxc config set raw.lxc=lxc.aa_profile=unconfined07:34
pittilxc config set x1 raw.lxc=lxc.aa_profile=unconfined07:34
stgraberlxc config set CONTAINER raw.lxc lxc.aa_profiled=unconfined07:35
stgraberor to apply it to all containers using the default profile:07:35
pittioh, so not an '=' but a space07:35
stgraberlxc profile set default raw.lxc lxc.aa_profile=unconfined07:35
stgraberalso, typoed my first command, it's aa_profile, not aa_profiled :)07:35
pitti\o/ works -- merci !07:36
pittistgraber: ah, so it sounds like I should create a new profile "autopkgtest", disable apparmor there, and create containers with that profile?07:36
stgraberyep. 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
stgraberlxc launch ubuntu blah -p default -p autopkgtest07:37
pittibind mounts work too07:37
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
pittistgraber: 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:38
pittithe killer feature why I'd like to add an lxd backend is that it seamlessly talks to remote containers07:39
pittiwhich 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 support07:39
Loganzul: are you planning on merging in python-networkx?07:39
pittiand thus I need to do this nesting of cloud instance → container07:40
stgraberThe 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:40
pittistgraber: I'm actually limited to a CLI API in autopkgtest07:41
stgrabercool, 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:42
pittistgraber: yes, that should be fine07:43
pittistgraber: after "lxc profile create autopkgtest", how do I tell it to copy (i. e. "inherit from") default?07:43
stgraberI 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:44
stgraberpitti: 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 autopkgtest07:45
pittistgraber: 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 fine07:45
stgraberpitti: note that you don't even need a PPA, we keep trusty-backports updated with all xenial uploads07:45
stgraberoh, but no arm6407:45
stgraberyeah, use the PPA :)07:45
pitti$ lxc profile show default | lxc profile edit autopkgtest07:45
pittierror: Cannot change profile name07:45
stgraberoh 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
pittiI might have misunderstood cat profile.yml | lxc profile edit <profile> # read from profile.yml07:46
pittiand "lxc profile show default" looks YAMLish07:46
stgraberthe show output does contain the profile name, so if piping one into the other, you'd have to sed the profile name07:46
pitti$ lxc profile show default | sed '/^name:/ s/default/autopkgtest/' | lxc profile edit autopkgtest07:47
stgraberyeah, 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:47
pittistgraber: cool, I now have the magic commands to create/inherit/amend the "autopkgtest" profile, build a container, and bind/proc mounts work07:49
pittistgraber: cheers!07:49
stgraberguess it's time for me to go to bed then :)07:50
pittistgraber: bonne nuit07:53
caribouHello, any Archive Admin in the room ?09:02
caribouI uploaded kdump-tools to debian where it works fine but it fails on install on Xenial09:02
caribouin a way that is rather annoying to remove (failing on configure)09:02
pittihow is that related to archive admin?09:03
Laneyseb128: they are the same but the first one didn't have the right header to close the bugs, bdmurray wanted me to reupload it09:06
seb128Laney, ah ok, it means bdmurray did review the SRU and we might manage to get it approved now, good!09:07
cariboupitti: I thought that only AA could pull packages already in the archive09:08
pitticaribou: no, if it's in, it's in09:09
cariboupitti: ok09:09
pitticaribou: for really drastic cases IS could lobotomize it out, but this doesn't look like one09:09
pitticaribou: you could just upload a fix, no? this only affects the devel series09:10
cariboupitti: no, just a config script that errors out09:10
cariboupitti: that's what I'm working on09:10
cariboupitti: looks like debhelper is adding incomplete stuff09:10
pitticaribou: oh, the "missing fi"?09:10
cariboupitti: yep09:10
pitticaribou: I fixed that this morning in https://launchpad.net/ubuntu/+source/debhelper/9.20151117ubuntu209:11
pitticaribou: ah, I checked https://lists.ubuntu.com/archives/xenial-changes/2015-November/ for potentially affected packages09:11
pitticaribou: but as your's was a sync, I didn't catch that09:11
cariboupitti: np09:11
pitticaribou: so this will only need a no-change "build1" upload09:11
cariboupitti: sorry for the nOOb question, but what is the *correct* way to do this ?09:12
pitticaribou: first, what is the *correct* package name? kdump-tools does not exist09:13
cariboupitti: makedumpfile is the source package09:13
pittioh, makedumpfile09:13
pitticaribou: pull-lp-source makedumpfile, then dch --rebuild "Rebuild against fixed debhelper", and build/upload09:13
cariboupitti: good, thanks. ok will do in a minute09:14
pitticaribou: i. e. the version should be 1:1.5.9-1build1 so that it keeps autosyncing (*not* -1ubuntu1 -- there are no real changes)09:14
pitticaribou: I can upload it for you if you want (I broke it after all)09:15
cariboupitti: ah, that's the catch09:15
cariboupitti: no, I need the experience09:15
pitticaribou: unless you want to do it for the learning experience09:15
pitticaribou: I actually have a mass rebuild script which makes this rather simple: rebuild-lib-transition "fixed debhelper" makedumpfile09:16
pitti(I guess every core dev involved in doing library transitions has one by now)09:16
cariboupitti: 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 far09:17
pitticome on, scp09:17
pitticaribou: http://people.canonical.com/~pitti/scripts/rebuild-lib-transition09:17
pittiit's pretty stupid, but saves quite some typing if you have to upload 200 no-change rebuilds09:17
cariboupitti: got it09:18
pitticjwatson: can we easily get a list of packages that got autosynced since yesterday evening?09:18
cariboupitti: so this is used when some library has changed & you need to rebuild all the packages that depends on it, right ?09:18
pitticaribou: correct; or in this case, against an updated build chain (debhelper, gcc, or what not)09:19
cariboupitti: ok, I'll remember that09:19
cariboupitti: uploaded09:48
=== paulliu1 is now known as paulliu
cjwatsonpitti: logs are in http://people.canonical.com/~ubuntu-archive/auto-sync/10:19
cjwatsonpitti: 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 go10:20
pitticjwatson: ah, thanks!10:27
pitticjwatson: I already checked the manual uplaods, so I'll check http://people.canonical.com/~ubuntu-archive/auto-sync/10:27
mapreripitti: thanks! ♥10:29
pittimapreri: I didn't do much, thanks to you for fixing!10:29
cjwatsonpitti: 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 end10:30
pitti liblinear1        | 1.8+dfsg-5   | xenial                   | amd64, arm64, armhf, i386, powerpc, ppc64el10:30
pitti liblinear3        | 2.1.0+dfsg-1 | xenial-proposed          | amd64, arm64, armhf, i386, powerpc, ppc64el10:30
pittisorry, ECHANNEL10:30
xnoxpitti, cjwatson, reverse sorting that by default in apache would be nice. also did not know this is public now \o/10:36
* xnox bookmarks /current.log pag10:38
* xnox bookmarks /current.log page10:38
killallsladen, thanks :)10:50
=== _salem is now known as salem_
pitticaribou: ok, I went through the recent syncs, and these three packages are affected: xinetd, makedumpfile, knot11:00
pitticaribou: you said you were going to upload makedumpfile yourself? I'll kick the others then11:01
pittiah, you did already11:01
cariboupitti: yep11:01
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) ?11:44
xnoxTJ-, https://wiki.ubuntu.com/ToolChain should have the info12:00
* 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.244205114:03
* Chipaca looks at xnox 14:03
xnoxChipaca, 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:05
Chipacaxnox: i was going to ask if that was you :-D14:06
Chipacaxnox: but yeah, ireland14:06
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:01
mardyseb128: do you have a minute? Got a question about patching a package which was uploaded to Debian (libgdata)15:13
seb128mardy, hey, sure15:13
mardyseb128: so, we'l like to have this bug https://bugzilla.gnome.org/show_bug.cgi?id=758524 fixed in Ubuntu ASAP15:14
ubottuGnome bug 758524 in Google Documents service "Cannot search documents by title" [Major,New]15:14
mardyseb128: I used debcheckout to get the source15:15
seb128mardy, I can backport that patch to Ubuntu and then sync over from Debian next time they do an update which includes that commit15:15
mardyseb128: but it's svn; I'm not sure how to proceed15:15
mardyseb128: if you could, that would be awesome15:16
seb128or try to see if Laney wants to commit/upload that to Debian then we sync over15:16
Laneycould do15:18
Laneyis it important to have RIGHT NOW or can wait for the release?15:18
seb128when is the release? ;-)15:18
seb128there was none since septembre15:18
seb128unsure how regular this cycle is15:18
seb128I guess "would be nice to not wait for a release"15:19
Laneypresumably a short time after asking upstream to make one15:19
seb128or if you can pull triggers to get that to happen wfm15:19
Laneythis patch isn't even acn yet though15:19
seb128Laney, https://bugs.launchpad.net/ubuntu/+source/libgdata/+bug/117392615:20
ubottuLaunchpad bug 1173926 in libgdata (Ubuntu) "unable to search for google drive documents in raring 13.04" [High,In progress]15:20
seb128seems like it's a piece of a bigger changeset15:20
seb128so would be nice to not delay too much so they can test/land the other bits15:21
seb128Laney, I can do a backport of the patch to xenial and we can sync over from Debian on next release15:21
seb128let'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 lens15:22
Laneythat's up to you, I would at least wait for it to be reviewed to include it in Debian15:22
Laneyalso the other branches aren't reviewed so they could presumably use a ppa package to verify them15:22
seb128Laney, 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 then15:26
Laneyseb128: I can ping upstream to do a release once this is in15:27
seb128Laney, thanks15:28
Laneythe first review came pretty fast last time15:28
Laneyso doubt it will take long15:28
* Laney subscribes to bug15:28
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=6129be8a4ba976c42e51012ebaa9005eb402db8016:55
mck182__without this patch, user's QT_PLUGIN_PATH have no meaning16:55
mck182__and so it's hard to do custom development outside of úusr16:56
yofelMirv: ^16:57
hallynarges: bug 1514690, what day are you likely to release that to wily-updates?18:11
ubottubug 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/151469018:11
stgraberhallyn: did you notice the autopkgtest regression with this upload?18:13
stgraberhallyn: seems to be caused by tests/test_confinment.sh not being executable18:14
stgraberthat lists all the current SRUs, how long they've in proposed for, state of bugs and autopkgtest state (on the left)18:14
hallynwhy are the tests running?18:14
stgraberbecause we run autopkgtest for all uploads, including to stable releases18:15
hallynyeah but we can't actually run lxcfs so shouldn't run the tests18:15
stgraberwe sure can18:15
stgraberautopkgtest are run as root in a VM18:15
hallynoh.  well that's what i was asking before18:16
stgraberah, I thought you were talking about build time18:16
hallynok well screw that then - i'll make add the other two bugs that need to be SRUd and re-push with that fixed, thx18:16
stgraberpackage 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 user18:16
stgraberhallyn: ok, let me know when it's in the queue, I'll review and let it in.18:17
stgraberhallyn: make sure to pass -v0.10-0ubuntu2.1 to debuild when you generate the changes file18:17
stgraberhallyn: 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 easier18:18
hallynstgraber: oh if you're going to do that i'll keep the other two sru's out then18:18
hallynbut, cna i just chmod the test files and build the pkg and they'll be extracted with the right perms?18:18
stgraberI don't think so, unless a diff can contain the change of the executable flag18:19
stgraberthough 0.12-0ubuntu5 in xenial passed the tests, so whatever was done there should work :)18:19
stgraberhttp://autopkgtest.ubuntu.com/packages/l/lxcfs/ for the overview18:19
stgraberpitti: 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:20
hallynstgraber: before i push, are you ok with http://paste.ubuntu.com/13504619/ ?18:25
stgraberhallyn: that's a bit of a workaround, but sure18:40
hallynyeah, it is18:41
=== 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
ximionLaney: you might want to make use of the X-AppStream-Ignore flag when renaming .desktop files19:05
ximionI am thinking of gedit specifically here19:05
ximion(just saw the odd metadata issues page ^^)19:06
Mirvmck182__: yofel: thanks, made a note about it although feel free to file bug at https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src too19:19
Mirvlikely to the upcoming Qt 5.5 only or at least first19:19
mck182__Mirv: ok, can do19:21
mck182__Mirv: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/151992719:28
ubottuLaunchpad bug 1519927 in qtbase-opensource-src (Ubuntu) "Please backport this patch into qtbase-5.5 for wily" [Undecided,New]19:28
ben|if a patch is not present in debian/patches/series is it still applied at any time during the build?19:32
=== ben| is now known as ben___
sarnoldben|: 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, thanks19:33
sarnoldben___: checking build logs is perhaps the best way to find out..19:33
sarnoldat least I think they all show which patches are applied, if any19:33
lamontI know we were using biosdevname for network devices at some point... under what conditions do we use them instead of ethN, for what series?20:04
=== salem_ is now known as _salem
=== ralsina is now known as ralsina_
=== ralsina_ is now known as ralsina
TJ-lamont: I think it was new (not upgrade) installs of server. For systemd its systemd.link naming21:04
attentehello, i have finished packaging a project and am wondering if i would be able to upload it to the ubuntu archive21:08
lamontTJ-: ta21:11
=== vrruiz_ is now known as rvr
=== lutostag_ is now known as lutostag
=== _salem is now known as salem_

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!