[03:17] <sarnold> pitti: 1500193 is 14 hours without a retrace, are the retraces blocked by the recent lcy01 issues?
[06:29] <pitti> Good morning
[06:29] <NikTh> Hello, any kernel maintainer here, or a How To build *only one* flavor in a kernel package that is building via Launchpad (PPA) and configured via Git ?
[06:29] <pitti> sarnold: no, they just crash often because some ddeb download issues from LP; I'm hand-holding them
[06:34] <RAOF> NikTh: Pretty sure you could delete whichever of debian.master/control.d/vars.{generic,generic-lpae,lowlatency} you didn't want.
[06:36] <NikTh> RAOF: I'm missing something here. I have did what you say, but maybe I need to alter some scripts ? I don't know. Check (when you have time) a build fail here: https://launchpadlibrarian.net/218918782/buildlog_ubuntu-trusty-amd64.linux_4.2.1-999.2015Sep26_BUILDING.txt.gz
[06:36] <NikTh> RAOF: My propose is to minimize the building time, by removing any not required flavors(generic-lowlatency..etc).
[06:37] <NikTh> RAOF: I have removed some files from debian.master/config , debian.master/control.d/, also modified debian.master/rules.d/amd64 and i386 (skipabi, skipmodules, flavors)  but apparently something is missing
[06:38] <RAOF> Strange error, and I'm not deeply familiar with the kernel build system.
[06:41] <RAOF> NikTh: It might be quicker to just not bother restricting flavours; the whole kit and caboodle is a ~1hr build...
[06:41] <NikTh> RAOF: No prob , thanks for trying to help :) Any other suggestion is welcome. I'm testing various changes local with 'pbuilder' now. Still getting the same error.
[06:43] <RAOF> NikTh: I'd probably edit debian/rules.d/0-common-vars.mk to set AUTOBUILD=true (which will mean you can drop most of your other changes). That and deleting the control.d/vars.$FOO might be all you need?
[06:43] <NikTh> RAOF: 4-5 hours, not 1hr , from what I've seen. It's OK, packages are not building in my laptop but in a virtual launchpad builder, but it would be better if I could reduce this time and get rid of not required flavors (generic-lowlatency..etc) :)
[06:44] <NikTh> RAOF: I will try this ASAP. Thanks !
[07:02] <dholbach> good morning
[07:03] <seb128> hey dholbach
[07:03] <dholbach> salut seb128
[07:52] <SergioEDuran1> Hello
[07:52] <SergioEDuran1> I want to make some requests for you (for Ubuntu Willy
[07:52] <SergioEDuran1> )
[07:55] <SergioEDuran1> Here I will send you a paste of my bash sesion trying to install Minetest
[07:55] <SergioEDuran1> http://paste.ubuntu.com/12599522/
[07:55] <SergioEDuran1> and here what I got when trying to install libleveldb1
[07:55] <SergioEDuran1> http://paste.ubuntu.com/12600703/
[07:56] <SergioEDuran1> here we need to edit the Minetest packages to adapt them to the new dependencies names
[08:05] <SergioEDuran1> what do you say friends?
[08:06] <SergioEDuran1> I think its important to keep all the packages present on the Ubuntu's official repos up to date not only on the app's version, even on the dependencies of the apps
[08:06] <SergioEDuran1> no?
[08:06] <SergioEDuran1> hello Laney
[08:10] <SergioEDuran1> I saw something bad?
[08:10] <SergioEDuran1> :(
[08:11] <SergioEDuran1> I am trying to keep the Ubuntu's repo's packages up to date
[08:11] <SergioEDuran1> that is all :)
[08:28] <SergioEDuran1> dear admins
[08:28] <SergioEDuran1> somebody could help me?
[08:29] <Laney> SergioEDuran1: Ubuntu's minetest has the correct dependency - does apt-cache policy minetest show it as coming from a PPA?
[08:32] <SergioEDuran1> Laney it is from the official Ubuntu's repos
[08:32] <SergioEDuran1> http://paste.ubuntu.com/12599522/
[08:32] <Laney> No
[08:32] <SergioEDuran1> http://paste.ubuntu.com/12600703/
[08:32] <Laney> Depends: minetest-data (= 0.4.12+repack-2ubuntu1), libc6 (>= 2.15), libcurl3-gnutls (>= 7.16.2), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:4.1.1), libirrlicht1.8, libjsoncpp0v5, libleveldb1v5, libluajit-5.1-2, libopenal1 (>= 1.14), libsqlite3-0 (>= 3.5.9), libstdc++6 (>= 5.2), libvorbisfile3 (>= 1.2.0), libx11-6, zlib1g (>= 1:1.1.4)
[08:32] <SergioEDuran1> you can check the paste :)
[08:33] <SergioEDuran1> I have not used any Minetest ppa
[08:33] <Laney> Maybe run the command I gave you so we can see which minetest it is trying to install
[08:34] <SergioEDuran1> Ok
[08:36] <SergioEDuran1> here it is Laney
[08:36] <SergioEDuran1> http://paste.ubuntu.com/12600910/
[08:36] <Laney> "apt-cache policy minetest" please
[08:38] <SergioEDuran1> Ok
[08:41] <SergioEDuran1> I saw the problem, solved :)
[08:41] <SergioEDuran1> and why not packaging GNOME 2048?
[08:41] <SergioEDuran1> gnome-2048
[08:41] <SergioEDuran1> hehehehehe
[08:42] <SergioEDuran1> and maybe adding gnome-2048 gnome-taquin and hitori to the gnome-games Laney
[08:42] <SergioEDuran1> ?
[10:35] <SergioEDuran1> friends
[10:35] <SergioEDuran1> I am here again
[10:35] <SergioEDuran1> I have sleeped a little bit
[10:36] <SergioEDuran1> so... what do you think about including GNOME  2048 on Ubuntu 15.10 as part of the GNOME games?
[11:26] <Odd_Bloke> infinity: wgrant: cjwatson: What's the canonical way of finding the architecture that I'm building for in a livecd-rootfs (binary) hook?
[11:27] <cjwatson> Odd_Bloke: $LB_ARCHITECTURES (why it's plural I'm not quite sure)
[11:28] <cjwatson> hm let me just check it gets that bit of environment
[11:28] <Odd_Bloke> cjwatson: I don't _think_ it does.
[11:29] <cjwatson> Odd_Bloke: ok, just use dpkg --print-architecture then
[11:29] <cjwatson> Indeed, we use that in a few places in hooks
[11:31] <Odd_Bloke> OK, cool.
[12:44] <NikTh> RAOF: Unfortunately this gave me the same error. I'm trying now same thing but in addition I have modified debian.master/rules.d/amd64.mk and i386.mk to exclude generic and lowlatency from 'Flavors = ' line.
[12:46] <NikTh> Oh, and also I have remove config.flavor.generic and lowlatency from 'configs' folder.
[13:26] <jbl> anyone knows if ubuntu implements cpu shielding (cgroup cpuset) with systemd?
[13:59] <seb128> cyphermox, that has no working retrace but it's high ranked on wily e.u.c, https://errors.ubuntu.com/problem/e72162eedbbe2652de316ee8653c35ee9b3ddebe
[13:59] <seb128> so might be worth investigating
[14:00] <seb128> wpa_supplicant segfault, seems to have started with 2.4
[14:03] <cyphermox> yeah, I know :(
[14:03] <cyphermox> just, no retrace and already complicated bugs with one
[14:03] <seb128> bdmurray, do you know why https://errors.ubuntu.com/problem/56d2e995b3803bec644316604eb9cad22270532c claims "
[14:03] <seb128> The following packages are missing debug symbols: libtrust-store2" where http://ddebs.ubuntu.com/pool/universe/t/trust-store/ seems to have those?
[14:41] <Riddell> pitti: kcoreaddons looks blocked on regressions in knewstuff and khtml but there's no failures that I can see
[14:44] <pitti> Riddell: indeed; I'll deal with this
[14:45] <Riddell> pitti: some similar ones, kio and ki18n on kdelibs4support
[14:45] <pitti> Riddell: kwin, ktexteditor, and kdepim-runtime look real to me, but your's indeed not
[14:49] <pitti> Riddell: I'll check again in a bit, most stuff shold be right now
[14:53] <bdmurray> seb128: I don't and will look into it some more.
[14:53] <seb128> bdmurray, thanks
[14:54] <NikTh> RAOF: We got it :-)
[14:54] <NikTh> RAOF: Thank for you valuable help !
[15:08] <Riddell> pitti: now for kcoreaddons it seems all is good but it still says not considered and I'm unsure why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kcoreaddons
[15:09] <Riddell> pitti: also kwindowsystem has ktextwidgets as regressions but there is none http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kwindowsystem
[15:11] <pitti> Riddell: yup, currently doing the next iteration (sorry, at sprint, not much bandwidth)
[15:39] <pitti> Riddell: so a big bunch now landed
[15:39] <pitti> Riddell: http://autopkgtest.ubuntu.com/packages/k/kdepim-runtime/wily/amd64/ seems real, the rest is fixed (or covered by your force-*)
[15:40] <Riddell> pitti:  kdepim-runtime just got uploaded so maybe that fixes it
[15:40] <pitti> Riddell: FYI, I by and large know what's wrong in britney wrt. the false "regression" results, will fix after the sprint
[15:46] <dgadomski> hey pitti, I need to backport some stuff from Debian's ifupdown (to fix bug #1337873). How can I offer the changes if the Ubuntu ifupdown package format does not support quilt? Is there Ubuntu git tree for ifupdown?
[15:46] <pitti> dgadomski: it's a native package, just apply it inline
[15:46] <pitti> dgadomski: and attach debdiffs to the bug
[15:46] <dgadomski> pitti: alright, thanks!
[15:47] <smb> slangasek, stgraber, So I just wanted to bring up again that we are looking for a vic...volunteer aa who could do the final parts to let dpdk (bug 1487538) into wily. Note that the PPA version linked in the bug is behind by 2 commits (visible in git) that arges made when sponsoring.
[15:51] <slangasek> smb: I can probably take a look at that today, once my web browser decides it's also willing to come back from vacation
[15:52] <NikTh> If someone can confirm this : bug 1500216
[15:53] <smb> slangasek, cool. thank you and good luck. things always break when one isn't looking
[15:57] <infinity> slangasek: I have a bit (understatement) of context on dpdk, but would be much happier if you did the NEW review, since you're picky about different things than I am.  Feel free to waste time on our call today discussing it, though.
[16:19] <jamespage> slangasek, infinity: openvswitch-dpdk is also in the queue, depends on dpdk - it will pass its autopkgtests but only if the default cpu level if bumped via qemu options...
[16:19] <jamespage> needs sse3
[16:32] <seb128> dpm, pitti, wgrant, gedit.mo seems to be missing from the current wily langpacks (at least for de and fr), do you have any idea why?
[16:34] <seb128> dpm, pitti, wgrant, looks fine the most recent update dropped quite some translations :-/
[16:35] <seb128> $ debdiff language-pack-gnome-de_15.10+20150922_all.deb language-pack-gnome-de_15.10+20150924_all.deb
[16:35] <seb128> Files in first .deb but not in second
[16:35] <seb128> -rw-r--r--  root/root   /usr/share/locale-langpack/de/LC_MESSAGES/eog.mo
[16:35] <seb128> -rw-r--r--  root/root   /usr/share/locale-langpack/de/LC_MESSAGES/evolution-3.16.mo
[16:35] <seb128> -rw-r--r--  root/root   /usr/share/locale-langpack/de/LC_MESSAGES/file-roller.mo
[16:35] <seb128> etc
[16:36] <dpm> seb128, no idea. Let me look at the template
[16:37] <seb128> dpm, thanks
[16:38] <dpm> seb128, hm, I cannot see anything obvious. Last template update was on 2015-08-12
[16:38] <dpm> priority seems correct
[16:38] <seb128> dpm, there are like 10 of those which vanished in friday's update
[16:40] <dpm> I'm looking at the content of language packs to see if they are in the export that's used as the source of the packages
[16:40] <dpm> well,, downloading atm
[16:41] <seb128> same here
[16:41] <seb128> but they are 258M for the 22 and for the 24
[16:41] <seb128> so it doesn't look like the content changed
[16:41] <seb128> well, I'm speaking about the tarballs export on https://translations.launchpad.net/ubuntu/wily/+language-packs
[16:42] <dpm> yeah
[16:45] <sarnold> pitti: oh, that's a shame about the retracers; I hadn't noticed any issues in a long time so I thought you'd nailed down the worst of the issues.. I hadn't realized this whole time it was hand-holding
[16:45] <sarnold> pitti: thanks for doing a good job on the retracers :) like I said, I hadn't noticed anything in a while..
[16:50] <seb128> dpm, the pos are in the launchpad export, so it's something in the job that build the langpack sources from the export, do we have logs for that?
[16:51] <dpm> seb128, I can confirm that too, I can see at least gedit.po in the export. langpack-o-matic can probably tell us more, pitti should know if we've got any logs
[16:51] <seb128> right
[17:18] <smoser> $ sudo ifup eth0
[17:18] <smoser> sudo: unable to resolve host ubuntu
[17:18] <smoser> dhclient: error while loading shared libraries: libirs-export.so.91: cannot stat shared object: Permission denied
[17:18] <smoser> Failed to bring up eth0.
[17:18] <smoser> that make any sense to anyone ?
[17:18] <smoser> stgraber, ^ ?
[17:19] <stgraber> hmm, would guess apparmor
[17:19] <stgraber> anything in dmesg?
[17:21] <sarnold> what's libirs-export.so.91?
[17:21] <smoser> stgraber, good guess. http://paste.ubuntu.com/12604024/
[17:21] <smoser> now, i guess some background on the possible luser error here.
[17:21] <smoser> i grabed root-lxd.tar.xz for wily
[17:22] <smoser> put it into a ext4 file system. then tried booting it with kernel, initramfs from maas ephemeral
[17:22] <stgraber> do you have overlayfs in that mix?
[17:22] <smoser> and
[17:22] <smoser>   root=/dev/vda ro console=ttyS0 overlayroot=tmpfs init=/bin/bash
[17:22] <smoser> yes.
[17:23] <stgraber> oh, so it's yet another case of apparmor blowing up on overlayfs
[17:23] <smoser> maybe
[17:23] <smoser> but in an odd way
[17:23] <stgraber> kinda surprised we've not run into that one with the desktop image
[17:23] <smoser> because most certainly this works in maas booting maas ephemeral images.
[17:23] <smoser> so there might be some luser error in the mix.
[17:23] <smoser> but i dont know wht it woudl be.
[17:24] <smoser> the first error i saw was just that networking-online never fired.
[17:24] <stgraber> smoser: so one thing I notice in there is that none of the names contain a leading /
[17:24] <stgraber> smoser: which may explain why apparmor can't resolve the paths, though I'm not sure what you may have done on your side to cause that slight difference
[17:24] <smoser> hm.
[17:25] <sarnold> I think it's the overlayroot=tmpfs that did it
[17:26] <smoser> nah
[17:26] <smoser> that path works
[17:26] <sarnold> but this bug suggests the usual "attach_disconnected" workaround for files not visible in the process's namespace may not be sufficient for overlayfs: https://bugs.launchpad.net/apparmor/+bug/1408106
[17:26] <smoser> odd though..
[17:26] <smoser> it doesnt seem like i'm doing anything that maas doesnt do in its installation of wily
[17:27] <jjohansen> nah, well sort of its overlayfs use of clone_private_mount
[17:27] <smoser> and that is known working (at least as of a few days ago)
[17:27] <jjohansen> sarnold: that depends, it is sufficient for regular file accesses, it is not sufficient if the denial is in a mount, or pivot_root
[17:28] <sarnold> jjohansen: how about this?   < smoser>   root=/dev/vda ro console=ttyS0 overlayroot=tmpfs init=/bin/bash
[17:29] <stgraber> my current recommendation is to turn apparmor off in any environment where / is on overlayfs, so live media, maas and any relevant installer
[17:29] <smoser> sarnold, yea, i ditched that though, that was only for debugging.
[17:29] <sarnold> smoser: ah, sorry for confusing the issue
[17:29] <smoser> yeah. good eyes though
[17:29] <stgraber> that's very much of a selinux-sounding answer to the problem, but fact is, this is a problem affecting random paths in a bunch of cases and it'd be really annoying if $RANDOM_SRU starts breaking things because we were depending on something which isn't actually supported
[17:30] <jjohansen> sarnold: won't fix the apparmor bit, the current work around is using the attach_disconnected flag in the profile
[17:31] <jjohansen> but if it is failing in a mount (not this case) there is no work around, besides making the affected code unconfined
[17:31]  * jdstrand notes that we hope to re-engage with overlayfs upstream next month (ie, after current sprint that is in progress) and see what's what
[17:32] <stgraber> jjohansen: is there a way to set attach_disconnected for every single profile on the system without having to mangle them all?
[17:33] <stgraber> because with / being on overlayfs, it's potentially every single apparmor profile that would run into this and I'm really not sure we want to change them all to set attach_disconnected
[17:33] <jjohansen> stgraber: no
[17:33] <stgraber> so attach_disconnected isn't really an option then
[17:35] <octoquad> Hi, would someone mind looking at this patch in the next pilot run? https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1385868 does this perhaps need to be fixed upstream?
[18:01] <bdmurray> seb128: it looks to me like the Packages file at http://ddebs.ubuntu.com/dists/wily/main/binary-armhf/ is missing libtrust-store2
[18:01] <bdmurray> pitti: it looks to me like the Packages file at http://ddebs.ubuntu.com/dists/wily/main/binary-armhf/ is missing libtrust-store2 - probably among other things
[18:02] <bdmurray> pitti: wily/main/binary-amd64/ is missing it too
[18:21] <bdmurray> seb128, pitti: I reported bug 1500557 about it.
[18:39] <cyphermox> @pilot in
[19:10] <ypwong> Does Wily image now support 32-bit UEFI on x64 processor?
[19:19] <seb128> bdmurray, thanks for investigating
[20:22] <brendand> what's the 'correct' way to get the arch-specific part of /usr/lib/${arch}/...
[20:25] <brendand> dpkg-architecture -q DEB_HOST_MULTIARCH is certainly one way
[20:25] <brendand> hmm, the phone doesn't have dpkg-architecture installed... unfortunate
[20:32] <sarnold> do we have perl on the phones? that' sjust a 9k perl script..
[20:32] <sarnold> it feels like a useful enuogh thing to include
[20:38] <slangasek> sarnold: we have perl-base; we should not have perl; and dpkg-architecture is part of dpkg-dev which has other baggage
[20:40] <sarnold> slangasek: oh :/ I didn't think to check where it comes from..
[21:00] <brendand> slangasek, so any other way to work that out than dpkg-architecture?
[21:06] <TJ-> brendand: is coreutils installed? /usr/bin/arch
[21:06] <brendand> TJ-, that's only part of it
[21:07] <brendand> TJ-, in fact i'm not sure that's related to it at all
[21:07] <brendand> on the phone `arch` is "armv7l"
[21:08] <brendand> but i'm looking for something that gives "arm-linux-gnueabihf"
[21:08] <TJ-> that comes from the libc build triplet doesn't it?
[21:09] <brendand> TJ-, i guess so
[21:14] <slangasek> brendand: no good way to check this at runtime, no, sorry
[21:15] <slangasek> brendand: you can indeed have your own local table that maps architectures to paths, but there's nothing that does this mapping for you
[21:15] <bipul> Hi
[21:16] <brendand> slangasek, is there any reason 'armv7l' might not map to 'arm-linux-gnueabihf'?
[21:21] <bipul> Hello, I am new to bug fixing. I would love to fix and patch bugs
[21:21] <TJ-> Could you rely on the binutils package? It installs files under /usr/bin/ with the triplet encoded in the filename
[21:22] <bipul> But i am unable to get how to start and where to start?
[21:30] <TJ-> bipul: see https://wiki.ubuntu.com/Bugs
[21:30] <slangasek> brendand: you might have a 64-bit kernel, and then you don't get 'armv7l' at all but 'aarch64'?  so the more reliable check for "what architecture am I on" is "dpkg --print-architecture"
[21:37] <cjwatson> brendand: the correct way to get the multiarch path is to calculate it at package build time and embed it in your package
[21:38] <cjwatson> (which may require making your package architecture: any)
[21:38] <cjwatson> and then you can use dpkg-architecture at build time
[21:39] <brendand> cjwatson, the particular use-case here is to find the path of a binary during a test
[21:39] <brendand> cjwatson, so it will be well after build time
[21:39] <cjwatson> brendand: I stand by my advice
[21:40] <cjwatson> brendand: not saying you need to be able to construct the entire path of the binary in question at build time, but you can embed the multiarch bit; or else question why a binary that's needed outside of implementation details of its package is in a multiarch path with no non-multiarch-dependent way to get at it ...
[22:04] <infinity> brendand: Err, "find the binary of a path at runtime"?
[22:05] <infinity> brendand: If that relies on the triplet, you've failed to do something correctly, IMO.
[22:05] <infinity> brendand: Could you elaborate on the problem, rather than the proposed solution?
[22:05] <infinity> s/binary of a path/path of a binary/
[22:06] <infinity> But I'm not dyslexic...