=== Guest34025 is now known as `Chef [03:54] LocutusOfBorg: Ahh, lovely, builds *everywhere*, it seems: https://buildd.debian.org/status/package.php?p=arrayfire&suite=unstable [05:54] Good morning [07:30] good morning === jhenke_ is now known as jhenke === marcusto_ is now known as marcustomlinson [09:35] pitti, bug #1532722 seems new from the ifupdown 0.8.5+ update [09:35] bug 1532722 in ifupdown (Ubuntu) "/sbin/ifup:11:__GI_strncpy:strncpy:do_interface:main" [Undecided,New] https://launchpad.net/bugs/1532722 [09:35] though e.u.c has no backtrace for some reason, just the signature one [09:46] seb128: hm, that function has six strncpy() calls; I wish we had at least an unretraced one [09:47] unsure why there are no backtrace on the error page [09:47] bdmurray might be able to help there? === henrix_ is now known as henrix [10:46] Pharaoh_Atem: o/ [10:46] hi, can anybody retry gnuradio build on arm64 on a real hw? [10:46] Pharaoh_Atem: I'm just replying to your email now. [10:46] pitti, ^^^ (thanks for arrayfire fix) [10:46] LocutusOfBorg: you want me to press the rebuild button? [10:47] "virtual memory exhausted: Cannot allocate memory" [10:47] It might be worth trying I guess. Or is the buildd never going to be able to manage it? [10:47] (as currently configured) [11:07] cjwatson, smoser: do you know some background about why open-iscsi does that "tell ifupdown that the interface is already up" dance? it seems wrong to have an ifupdown config for the iscsi interface, as the latter is handled by the initramfs [11:07] and "ifdown eth0" should never work in that case [11:08] Debian does not do anything like this either [11:09] * pitti finds bug 457767, but it seems this got already fixed in partman-iscsi? [11:09] bug 457767 in partman-iscsi (Ubuntu Karmic) "karmic: iSCSI root: boot hangs on starting iscsid" [High,Fix released] https://launchpad.net/bugs/457767 [11:09] having a "manual" stanza should work as well, but then we also don't need this ugly hack [11:10] i. e. I wonder if we really still need this in open-iscsi [11:23] quick question, how can I test an s390x and powerpc fix? does Ubuntu have an developer machine? [11:24] doko, https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.7/+bug/1532716/comments/1 [11:24] Launchpad bug 1532716 in llvm-toolchain-3.7 (Ubuntu) " llvm-toolchain-3.7 FTBFS on powerpc and s390x [SRU]" [Undecided,New] [11:24] it should be ok, but I don't like to blindly upload === _salem is now known as salem_ [11:30] LocutusOfBorg, i can test things for you. [11:31] LocutusOfBorg, there is no community access to ubuntu porter boxes for those architectures at the moment. [11:33] https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+files/llvm-toolchain-3.7_3.7.1-1ubuntu3.dsc [11:33] xnox, ^^^ :) [11:33] or in the bug #1532716 [11:33] bug 1532716 in llvm-toolchain-3.7 (Ubuntu) " llvm-toolchain-3.7 FTBFS on powerpc and s390x [SRU]" [High,Confirmed] https://launchpad.net/bugs/1532716 [11:33] I think we can also SRU to wily [11:33] * LocutusOfBorg if it works lol [11:34] LocutusOfBorg, urls to a librarian are not helpful. =) [11:34] LocutusOfBorg, url to the ppa would be better. [11:35] found it. [11:37] LocutusOfBorg, will build here - https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages [11:42] thanks! [11:46] doko, smoser: FTR, I forwarded most of our open-isci changes to Debian, but debian bug 797112 lists some issues which should get fixed before we merge [11:46] Debian bug 797112 in open-iscsi "open-iscsi: Prevent testing migration" [Serious,Open] http://bugs.debian.org/797112 [11:47] and I think we should drop the above ifupdown state hack and (if still necessary) fix our installer instead [11:47] thanks xnox [11:48] smoser: then our remaining delta would be the open-iscsi-utils transitional package (can go after xenial), and the extra autopkgtest [11:48] rbasak, unfortunately retrying the build doesn't help, unless you can force it on a real arm64 hardware [11:48] LocutusOfBorg: ah, OK. I can't do that, sorry. This may need help from #launchpad people. [11:49] I can retry builds, but not in different machines [11:49] infinity, did it for another package ^^^ :) [11:49] maybe fixing the configuration might help even better ;) [11:49] what other packages are you talking about? [11:54] gnuradio [11:54] arrayfire is fixed (but it has the same issue each time I upload a new debian version) === cpaelzer is now known as cpaelzer_afk [12:09] pitti: I'm assuming it was to do with booting a live image off iSCSI or something, but I'm afraid I really don't remember [12:10] LocutusOfBorg: the bare-metal arm64 builders are going away in the nearish future. is there no other workaround at all, perhaps reducing concurrency? [12:10] cjwatson, how can I reduce concurrency? I just have --parallel set, you choose the parallel concurrency I think [12:11] I think with DEB_BUILD_OPTIONS=parallel=2 it might work [12:11] LocutusOfBorg: there's a --max-parallel option [12:12] LocutusOfBorg: but I haven't looked closely at this case, it's just that "please retry on bare metal" is a very limited strategy and won't work for long [12:17] the problem is that many packages have this issue [12:25] LocutusOfBorg: Uh, no, this is very rare === jincreator is now known as jincreator_ [12:28] well, so gnuradio and arrayfire are the only two? :) nice then [12:53] xnox, thanks you can drop the build! [12:53] it is fine now [12:55] not sure if the message has been received but xnox thanks, you can drop the build of llvm === cpaelzer_afk is now known as cpaelzer [13:21] Laney, https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/1532799 [13:21] Launchpad bug 1532799 in gettext (Ubuntu) "[Merge] gettext 0.19.7-2 from debian unstable" [Undecided,New] [13:21] * Laney teleports [13:21] thanks! [13:24] good morning! === rickspencer3_ is now known as rickspencer3 [13:35] doko, hi, do you have any plans to update libtool to its recent release? [13:39] Laney, whoa, did you confirm that there is going to be a gstreamer 1.8 release in time for xenial? [13:39] there will be [13:40] upstream asked for it too [13:40] ah good :) [14:05] pitti, "I think we should drop the above ifupdown state hack and (if still necessary) fix our installer instead" [14:06] ricotz, it's in sync [14:06] the point of that is really to prevent bouncing the network interface over which / was mounted in the initramfs. [14:07] unless we're convinced that systemd somehow makes it unnecessary to do that. [14:08] doko, I am more speaking of upstream releases [14:10] and yeah, of course in debian ( where only you dared to touch it in the last 2 years ;-) ) === barry` is now known as barry [14:13] ricotz, package it and put it in a ppa [14:14] doko, so there is no actual known breakage which is holding this back? [14:15] ricotz, look at the build log for that answer [14:17] not quite an answer, but I assume you tried it then, I just ran into it due a libtool.m4 version mismatch, so I didnt look at the package itself yet [14:18] ricotz, no, I did not. so if you want to know it, you have to package it [14:18] alright, that is more clear [14:44] smoser: this is between d-i, open-iscsi, and ifupdown, doesn't involve init [14:45] smoser: why would it bounce the network interface? [14:45] smoser: it would do that if ifupdown had a config stanza for it, but it really really shouldn't [14:45] smoser: or a "manual" one at least, but certainly not "dhcp" or something [14:47] pitti, that is a good point. however, it is tricky in something like a cloud or a maas image. [14:48] where the goal is to distribute an image that can be booted with iscsi root without modification of the image in any way. [14:48] the image has 'auto eth0' [14:48] but the user booted the kernel/initramfs with iscsi root and ip= [14:49] having *no* network configuration in /etc/network/interfaces would make the image useless for many other purposes. [14:49] smoser: ah, so this isn't a d-i issue, but to counteract static configuration in our cloud images? [14:50] smoser: that's the kind of background I was missing :) (it's not documented in the changelog) [14:50] hardcoding an eth0 config in the cloud image itself is bad for other reasons, though [14:51] well... cjwatson added that code long before i was around (or the cloud images) [14:51] but at least if we did that in the past, i. e. we have existing installs which have a "dhcp eth0" with open-iscsi we mustn't break that on upgrades [14:51] there is a more general issue that could be solved though, and then open-iscsi woudln't have to solve it itself. [14:52] if the intiramfs brings up a network devcie (and intends for that device to be left up), then it should be able to signal that to the init system in some way. [14:52] s/init system/ifupdown/ [14:53] well, they're kind of one and the same from one perspective. [14:53] i have to convince *something* to not unconfigure it. [14:53] and also, in the use case we have, resolvconf also needs keeping [14:53] well, I think we should have done this by not telling ifupdown to configure eth0 in the first place then [14:54] configuring ifupdown one way and then adding a hack to not do it after all was what I was wondering about === vrruiz_ is now known as rvr [14:55] pitti, well how would you do that ? [14:56] we want to have one image that supports iscsi root booting and also booting in cloud environment with metadata coming from a network. [14:57] i'd much rather not distribute 2 images that have something ont he order of 32 bytes of delta in one file in /etc [14:59] smoser: no, of course not [14:59] i have work to do in this area, and i'd love for your input on it. [14:59] smoser: IMHO network config (or iscsi, depending on how you configure it) should be set up by cloud-init or some installer dynamically, not hardcoded in an image [14:59] right. [14:59] smoser: e. g. when you boot it in QEMU with some custom options, eth0 doesn't even exist [15:00] pitti, i agree. i'd really like your help/input on getting this right. [15:00] smoser: oh, since IRC has so little bandwidth: this wasn't meant as an assault or anything, I was just wondering about the history of it and whether we could improve thisi [15:01] :) [15:01] i have it on my list of things to improve [15:01] and i owe jgrimm a doc on what we plan to do too. [15:01] smoser: so, for sure we need to deal with existing systems that have a dhcp config + iscsi on eth0 [15:02] so how about i get that together and share it with you... attempt to list what things we're hoping to acommplish. [15:02] thinking aloud -- we could do that in a postinst snippet by replacing /etc/network/interfaces.d/eth0.cfg if eth0 is the iscsi root mount [15:02] (if/once we have a solution to not set up newly installed systems that way) [15:03] (replace it with "manual eth0") [15:03] err, "iface eth0 inet manual" I think is what I meant [15:04] smoser: how does the current image "know" that it should configure itself for an iscsi boot? [15:05] smoser: I thought in that case you don't even boot the actual cloud image, but you get the root fs served over PXE boot, no? [15:05] hm.. [15:06] so actually right now, we have cloud image, which does not really expose the external kernel/initramfs/kernel-command line. [15:06] so iscsi root is not *really* an option there. [15:06] it has a hard coded eth0 in e/tc/network/interfaces [15:06] that is a pain for reasons you're aware of (systemd device naming) [15:07] then we have the maas image... which largely *is* the iscsi root with 32 bytes of delta in /etc :) [15:07] in the maas image, currently, we have /etc/network/interfaces as a symlink to /run/network/dyn-netconf-interfaces (or some such) [15:08] that target of that link is managed by cloud-initramfs-dyn-netconf [15:08] that initramfs package basically writes a /etc/network/interface file there that has the interface that was brought up in the initramfs as the only one. [15:11] smoser: that sounds useful for non-MaaS use cases as well, like using it in qemu, LXC, or snappy? [15:12] pitti, can i spend today trying to write some of this in a well formed manner and then have you read it and we discuss ? [15:13] smoser: sounds great [15:13] pitti, i *really* appreciate your input here. [15:13] smoser: in the meantime, let's see what Christian says about adopting the other two changes; I suppose merging open-iscsi isn't really urgent? [15:13] ah. yeah... i've had some interaction with Christian [15:14] with the goal of getting rid of our delta [15:14] I think doko just stumbled over it when he reviewed the "not merged in ages" list, it's not an OMGweneeditnow [15:14] and he is open to carrying ubuntu specific and non-intrusive patches [15:14] ie, as long as they're not negatively affecting debian, he's ok to have code that is only going to run on ubuntu. [15:14] smoser: if we could replace the ifupdown messing with a postinst snippet and drop that post-16.04, that'd be nice indeed [15:15] Christian was very helpful when i chatted with him. [15:15] smoser: I think that this ifupdown state file nudging might have broken with the new ifupdown, the native networking.service does not do that "is the root fs a network mount" check any more [15:15] smoser: oh yes, he's great; I met him at debconf [15:16] I'm sure we can massage the extra autopkgtest in a form that doesn't require testlib.py, then he'll surely take this too [15:17] can you determine inside an autopkg test if you're ubuntu ? [15:17] ie: [15:17] #ifdef UBUNTU [15:17] run these tests with testlib.py [15:17] #endif [15:18] then we'd run them when we synced and he'd not be bothered unless intentionally [15:18] you could have the test depend on dpkg-dev and use 'dpkg-vendor --derives-from Ubuntu' [15:31] smoser: no, Christian's issue was not that the test wouldn't apply to Debian, but he dislikes the testlib.py thing [15:31] smoser: i. e. he doesn't want to maintain this [16:09] pitti, hey, you know your way around our buildd hosts, any idea where they take sbuild 0.65.2 from? wanted to use it in our Jenkaas [16:10] Saviq: I actually don't, but that sounds like vivid or wily [16:10] Saviq: ISTR that Colin said something about "vivid based" the other day [16:10] but don't take this for granted [16:11] Saviq: https://launchpad.net/~launchpad/+archive/ubuntu/buildd-staging/+packages is current [16:11] Saviq: (for xenial-based buildds, we just use the one in the archive) [16:11] cjwatson, oh great, thanks [16:12] np [16:33] xnox: Do you know if the s390x images we're producing ATM would work in lxc? [16:34] xnox: (AIUI, the missing parts are all bootloader-y, which obviously isn't an issue for lxc :) [16:34] Odd_Bloke, i know that lxc and lxd work, cause autopackage tests use them. I guess i can import the tarballs to validate that lxc off that tarball works. [16:35] Odd_Bloke, i'm in the middle of doing surgery on the disk1.img, please bare with me =) [16:35] xnox: Sure; just asking so I can clear out my inbox, no rush. :) [16:38] Odd_Bloke, do cloud images need root= parameter or some such? [16:39] Odd_Bloke, e.g. how do uefi images on x86_64 boot? [16:39] i presume just by magic ;-) [16:43] xnox: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-cpc/hooks/033-disk-image-uefi.binary is where we generate the UEFI images. [16:47] Odd_Bloke, what's CLOUD_IMG_STR ? [16:47] wait... C [16:47] sed -i "s,root=.* ,root=LABEL=cloudimg-rootfs ,g" mountpoint/boot/grub/grub.cfg [16:47] is nice. [16:47] so i should do the same [16:48] xnox: It's just "# This has been modified by the cloud image build process" or something to that effect. [16:51] cool. [17:16] ubuntu-bug linux on my xenial 64-bit desktop says that linux-image-4.3.0-2-generic isn't an official Ubuntu package [17:17] Odd_Bloke, /sbin/plymouthd: not found =) [17:17] * xnox ponders why we have plymouth thingies in the initramfs, without plymouth. [17:17] also RAID arrawys are incrementatlly started =/ [17:17] how else would we get it bloated to tens of megabytes ! [17:18] barry, are you about ? [17:18] tox.ini with: [17:18] smoser: yppers [17:18] http://paste.ubuntu.com/14470834/ [17:18] *yeppers [17:19] tox -e py34-pylint [17:19] creates a .tox/py34-pylint/bin/python [17:19] that is python2.7 [17:19] when run on trusty. [17:19] i thougth/hopwed that because it had 'py34-' in its name there was magic that picked the right python [17:20] smoser: you probably need to set basepython in that toxenv. iirc trusty's tox does not yet support generated environments, so you have to handle the basepython switch yourself. in xenial we have a newer tox that supports the generated environments, which is a *really* nice feature [17:21] oh. ok. that makes sense. [17:21] so how do i set it ? doc was confusing to me. [17:21] smoser: i think, in the [testenv:py34-pylint] section just add: [17:21] basepython = python3.4 [17:22] ok. the dictionaries shown at http://tox.readthedocs.org/en/latest/config.html were confusing to me. [17:22] but ... i think you're right. thank you [17:22] smoser: np. fwiw, i absolutely love http://tox.readthedocs.org/en/latest/config.html#generating-environments-conditional-settings :) [17:30] barry, but for the base 'py27' and 'py34', it does do the right thing, right? [17:31] yeah, it seems to. [17:31] thanks again [17:32] smoser: right, because those envs are built-in [17:33] smoser: also iirc, trusty's tox doesn't know about py35 so you'd have to add a stanza for that explicitly if you want it [17:35] barry, fudge. [17:36] so then on trusty, where there is no python3.5 [17:36] what woudl i do to not run the test there ? [17:41] smoser: i'm not aware of a way to have tox conditionally avoid an environment if the basepython is missing, though i think there's been discussion about that upstream. the best you can do right now i think is either not include py35 in the default set of envs, run tox without -e py35 explicitly, or just ignore the error that tox will give if you do run with -e py35 [17:42] thanks. [17:48] Laney: whoops, thanks for fixing libosinfo [18:11] mdeslaur: np! [18:29] is rmadison an (the?) appropriate tool for determining if a package is in universe or main? [18:35] nacc, there is $ check-mir, tool too [18:36] nacc, rmadison queries things differently, but will give accurate info too. [18:36] xnox: thanks! [18:36] xnox: yeah, just trying to educate myself on various tools === ajmitch_ is now known as ajmitch [19:49] rbasak: yo [20:03] Pharaoh_Atem: hello! [20:37] is the auto-import from debian broken? [21:12] LocutusOfBorg: No, looks fine to me. [21:12] (You may want to give more details of what you think should have been imported ...) [21:14] liquidsoap [21:14] it isn't picked up since 12 h or so [21:17] LocutusOfBorg: That's the upload time; it still needs dinstall to run before we can pick it up, and I suspect it was at a near-worst-case for that. [21:17] LocutusOfBorg: I'd expect to see it in the next sync. [21:17] mmm strange [21:17] [11:57:23] LocutusOfBorg: non è che fra qualche ora dai un `syncpackage -s mapreri -V 1.1.1-7.1 -f liquidsoap` ? :) [21:17] at that time it was uploaded [21:18] the run has been at 14 or so [21:18] finished at 16 or so [21:18] and now we are 8 ours later, and debian unstable has it [21:18] LocutusOfBorg: Right, but our mirror updates every six hours. That "or so" is pretty important. [21:18] We last synced our mirror at 16:05 UTC. [21:18] cjwatson, damn, I remembered it was around each 30 minutes [21:18] Goodness me, no. [21:18] Never has been. [21:19] * LocutusOfBorg lacks of a sane memory [21:19] thanks then :) [21:19] cjwatson, with dinstall going slower each time I guess running the script half an hour later will make many packages picked up early [21:20] I'll check the dinstall logs next time I get a chance. [21:21] one dinstall already started a few seconds ago, I'll monitor and give you the finish time :) [21:21] * LocutusOfBorg if I don't fall asleep [21:21] LocutusOfBorg: No, don't bother. [21:21] LocutusOfBorg: I'm going to want to check historical logs anyway, not just have a single data point. [21:22] LocutusOfBorg: And don't waste your time monitoring - I'm pretty sure the logs are timestamped. [21:22] sure, it depends on many factors I guess, specially with many european developers I expect the first one to be slower [21:23] I've been meaning to have it do "check more frequently and run import if Release timestamp changes" for ages anyway, which would obviate the need for that sort of log analysis. [21:40] rbasak: did you get my reply to your email earlier today? [21:55] ping uiteam === salem_ is now known as _salem [22:19] does anyone know where I can grab nightly builds of ubuntu xenial? [22:19] or at least a netinstaller that lets me install nightly code from the archive [22:20] alpha1 images and apply updates? [22:20] Pharaoh_Atem: http://cdimage.ubuntu.com/daily-live/ and not sure about the latter [22:21] seb128, pitti: that ifupdown crash, bug 1532722, really failed to retrace and several crashes are missing an initial StacktraceAddressSignature [22:21] bug 1532722 in ifupdown (Ubuntu) "/sbin/ifup:11:__GI_strncpy:strncpy:do_interface:main" [Undecided,New] https://launchpad.net/bugs/1532722 [22:26] tarpman: thanks [23:50] Pharaoh_Atem: yes. Sorry, the need to sync with nacc and the timezone difference is making things a little awkward. I only got ten minutes with nacc today and that wasn't enough to plan ahead. [23:51] Pharaoh_Atem: for testing things with Xenial I suggest using lxc, lxd or uvtool, though I don't know your environment. They make it really quick to manually test things. [23:52] Pharaoh_Atem: there are also published daily EC2 images, etc. [23:52] Pharaoh_Atem: uvtool uses the published daily cloud images and throws them at libvirt/kvm, or you can use the images directly with something else. [23:53] Pharaoh_Atem: we could attempt a Google Hangout or similar to plan things tomorrow maybe? Perhaps with ondrej too? [23:54] (and nacc of course) [23:56] rbasak: yeah, a Hangout sounds good [23:56] My personal system is a Fedora 23 system [23:56] so I can build VMs or containers or whatever as I need [23:56] and I have access to a personal virtualization server for whatever I need to do [23:57] so as long as your images work with KVM, I'm solid [23:57] Pharaoh_Atem: http://cloud-images.ubuntu.com/xenial/current/ should be all you need. [23:57] are this cloud-init ones or do I need to do anything special? [23:58] Pharaoh_Atem: those images use cloud-init though. You'll need to supply cloud-init metadata and userdata to boot a usable system. [23:58] hmm [23:58] I'm not too good with setting up things with cloud-init :/ [23:59] I don't suppose you guys spin netinstall ISOs yet? [23:59] uvtool does this all automatically, but as I don't use Fedora I have no idea how well uvtool will work on it.