User1: User7 Ahh, lovely, builds *everywhere*, it seems: https://buildd.debian.org/status/package.php?p=arrayfire&suite=unstable
User2: Good morning
User3: good morning
User4: pitti, bug #1532722 seems new from the ifupdown 0.8.5+ update
User5: bug 1532722 in ifupdown (Ubuntu) "/sbin/ifup:11:__GI_strncpy:strncpy:do_interface:main" [Undecided,New] https://launchpad.net/bugs/1532722
User4: though e.u.c has no backtrace for some reason, just the signature one
User2: User4 hm, that function has six strncpy() calls; I wish we had at least an unretraced one
User4: unsure why there are no backtrace on the error page
User4: bdmurray might be able to help there?
User6: User22 o/
User7: hi, can anybody retry gnuradio build on arm64 on a real hw?
User6: User22 I'm just replying to your email now.
User7: pitti, ^^^ (thanks for arrayfire fix)
User6: User7 you want me to press the rebuild button?
User6: "virtual memory exhausted: Cannot allocate memory"
User6: It might be worth trying I guess. Or is the buildd never going to be able to manage it?
User6: (as currently configured)
User2: cjwatson, User13 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
User2: and "ifdown eth0" should never work in that case
User2: Debian does not do anything like this either
 * pitti finds bug 457767, but it seems this got already fixed in partman-iscsi?
User5: bug 457767 in partman-iscsi (Ubuntu Karmic) "karmic: iSCSI root: boot hangs on starting iscsid" [High,Fix released] https://launchpad.net/bugs/457767
User2: having a "manual" stanza should work as well, but then we also don't need this ugly hack
User2: i. e. I wonder if we really still need this in open-iscsi
User7: quick question, how can I test an s390x and powerpc fix? does Ubuntu have an developer machine?
User7: doko, https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.7/+bug/1532716/comments/1
User5: Launchpad bug 1532716 in llvm-toolchain-3.7 (Ubuntu) " llvm-toolchain-3.7 FTBFS on powerpc and s390x [SRU]" [Undecided,New]
User7: it should be ok, but I don't like to blindly upload
User8: LocutusOfBorg, i can test things for you.
User8: LocutusOfBorg, there is no community access to ubuntu porter boxes for those architectures at the moment.
User7: https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+files/llvm-toolchain-3.7_3.7.1-1ubuntu3.dsc
User7: xnox, ^^^ :)
User7: or in the bug #1532716
User5: 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
User7: I think we can also SRU to wily
 * LocutusOfBorg if it works lol
User8: LocutusOfBorg, urls to a librarian are not helpful. =)
User8: LocutusOfBorg, url to the ppa would be better.
User8: found it.
User8: LocutusOfBorg, will build here - https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages
User7: thanks!
User2: doko, User13 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
User5: Debian bug 797112 in open-iscsi "open-iscsi: Prevent testing migration" [Serious,Open] http://bugs.debian.org/797112
User2: and I think we should drop the above ifupdown state hack and (if still necessary) fix our installer instead
User7: thanks xnox
User2: User13 then our remaining delta would be the open-iscsi-utils transitional package (can go after xenial), and the extra autopkgtest
User7: rbasak, unfortunately retrying the build doesn't help, unless you can force it on a real arm64 hardware
User6: User7 ah, OK. I can't do that, sorry. This may need help from #launchpad people.
User7: I can retry builds, but not in different machines
User7: infinity, did it for another package ^^^ :)
User7: maybe fixing the configuration might help even better ;)
User8: what other packages are you talking about?
User7: gnuradio
User7: arrayfire is fixed (but it has the same issue each time I upload a new debian version)
User9: User2 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
User9: User7 the bare-metal arm64 builders are going away in the nearish future.  is there no other workaround at all, perhaps reducing concurrency?
User7: cjwatson, how can I reduce concurrency? I just have --parallel set, you choose the parallel concurrency I think
User7: I think with DEB_BUILD_OPTIONS=parallel=2 it might work
User9: User7 there's a --max-parallel option
User9: User7 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
User7: the problem is that many packages have this issue
User9: User7 Uh, no, this is very rare
User7: well, so gnuradio and arrayfire are the only two? :) nice then
User7: xnox,  thanks you can drop the build!
User7: it is fine now
User7: not sure if the message has been received but xnox thanks, you can drop the build of llvm
User10: Laney, https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/1532799
User5: Launchpad bug 1532799 in gettext (Ubuntu) "[Merge] gettext 0.19.7-2 from debian unstable" [Undecided,New]
 * Laney teleports
User11: thanks!
User12: good morning!
User10: doko, hi, do you have any plans to update libtool to its recent release?
User10: Laney, whoa, did you confirm that there is going to be a gstreamer 1.8 release in time for xenial?
User11: there will be
User11: upstream asked for it too
User10: ah good :)
User13: pitti, "I think we should drop the above ifupdown state hack and (if still necessary) fix our installer instead"
User14: ricotz, it's in sync
User13: the point of that is really to prevent bouncing the network interface over which / was mounted in the initramfs.
User13: unless we're convinced that systemd somehow makes it unnecessary to do that.
User10: doko, I am more speaking of upstream releases
User10: and yeah, of course in debian ( where only you dared to touch it in the last 2 years ;-) )
User14: ricotz, package it and put it in a ppa
User10: doko, so there is no actual known breakage which is holding this back?
User14: ricotz, look at the build log for that answer
User10: 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
User14: ricotz, no, I did not. so if you want to know it, you have to package it
User10: alright, that is more clear
User2: User13 this is between d-i, open-iscsi, and ifupdown, doesn't involve init
User2: User13 why would it bounce the network interface?
User2: User13 it would do that if ifupdown had a config stanza for it, but it really really shouldn't
User2: User13 or a "manual" one at least, but certainly not "dhcp" or something
User13: pitti, that is a good point. however, it is tricky in something like a cloud or a maas image.
User13: where the goal is to distribute an image that can be booted with iscsi root without modification of the image in any way.
User13: the image has 'auto eth0'
User13: but the user booted the kernel/initramfs with iscsi root and ip=
User13: having *no* network configuration in /etc/network/interfaces would make the image useless for many other purposes.
User2: User13 ah, so this isn't a d-i issue, but to counteract static configuration in our cloud images?
User2: User13 that's the kind of background I was missing :) (it's not documented in the changelog)
User2: hardcoding an eth0 config in the cloud image itself is bad for other reasons, though
User13: well... cjwatson added that code long before i was around (or the cloud images)
User2: 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
User13: there is a more general issue that could be solved though, and then open-iscsi woudln't have to solve it itself.
User13: 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.
User2: s/init system/ifupdown/
User13: well, they're kind of one and the same from one perspective.
User13: i have to convince *something* to not unconfigure it.
User13: and also, in the use case we have, resolvconf also needs keeping
User2: well, I think we should have done this by not telling ifupdown to configure eth0 in the first place then
User2: configuring ifupdown one way and then adding a hack to not do it after all was what I was wondering about
User13: pitti, well how would you do that ?
User13: we want to have one image that supports iscsi root booting and also booting in cloud environment with metadata coming from a network.
User13: i'd much rather not distribute 2 images that have something ont he order of 32 bytes of delta in one file in /etc
User2: User13 no, of course not
User13: i have work to do in this area, and i'd love for your input on it.
User2: User13 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
User13: right.
User2: User13 e. g. when you boot it in QEMU with some custom options, eth0 doesn't even exist
User13: pitti, i agree. i'd really like your help/input on getting this right.
User2: User13 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
User13: :)
User13: i have it on my list of things to improve
User13: and i owe jgrimm a doc on what we plan to do too.
User2: User13 so, for sure we need to deal with existing systems that have a dhcp config + iscsi on eth0
User13: so how about i get that together and share it with you... attempt to list what things we're hoping to acommplish.
User2: 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
User2: (if/once we have a solution to not set up newly installed systems that way)
User2: (replace it with "manual eth0")
User2: err, "iface eth0 inet manual" I think is what I meant
User2: User13 how does the current image "know" that it should configure itself for an iscsi boot?
User2: User13 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?
User13: hm..
User13: so actually right now, we have cloud image, which does not really expose the external kernel/initramfs/kernel-command line.
User13: so iscsi root is not *really* an option there.
User13: it has a hard coded eth0 in e/tc/network/interfaces
User13: that is a pain for reasons you're aware of (systemd device naming)
User13: then we have the maas image... which largely *is* the iscsi root with 32 bytes of delta in /etc :)
User13: in the maas image, currently, we have /etc/network/interfaces as a symlink to /run/network/dyn-netconf-interfaces (or some such)
User13: that target of that link is managed by cloud-initramfs-dyn-netconf
User13: 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.
User2: User13 that sounds useful for non-MaaS use cases as well, like using it in qemu, LXC, or snappy?
User13: 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 ?
User2: User13 sounds great
User13: pitti, i *really* appreciate your input here.
User2: User13 in the meantime, let's see what Christian says about adopting the other two changes; I suppose merging open-iscsi isn't really urgent?
User13: ah. yeah... i've had some interaction with Christian
User13: with the goal of getting rid of our delta
User2: I think doko just stumbled over it when he reviewed the "not merged in ages" list, it's not an OMGweneeditnow
User13: and he is open to carrying ubuntu specific and non-intrusive patches
User13: ie, as long as they're not negatively affecting debian, he's ok to have code that is only going to run on ubuntu.
User2: User13 if we could replace the ifupdown messing with a postinst snippet and drop that post-16.04, that'd be nice indeed
User13: Christian was very helpful when i chatted with him.
User2: User13 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
User2: User13 oh yes, he's great; I met him at debconf
User2: 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
User13: can you determine inside an autopkg test if you're ubuntu ?
User13: ie:
User13: #ifdef UBUNTU
User13: run these tests with testlib.py
User13: #endif
User13: then we'd run them when we synced and he'd not be bothered unless intentionally
User9: you could have the test depend on dpkg-dev and use 'dpkg-vendor --derives-from Ubuntu'
User2: User13 no, Christian's issue was not that the test wouldn't apply to Debian, but he dislikes the testlib.py thing
User2: User13 i. e. he doesn't want to maintain this
User15: 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
User2: User15 I actually don't, but that sounds like vivid or wily
User2: User15 ISTR that Colin said something about "vivid based" the other day
User2: but don't take this for granted
User9: User15 https://launchpad.net/~launchpad/+archive/ubuntu/buildd-staging/+packages is current
User9: User15 (for xenial-based buildds, we just use the one in the archive)
User15: cjwatson, oh great, thanks
User9: np
User16: User8 Do you know if the s390x images we're producing ATM would work in lxc?
User16: User8 (AIUI, the missing parts are all bootloader-y, which obviously isn't an issue for lxc :)
User8: 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.
User8: Odd_Bloke, i'm in the middle of doing surgery on the disk1.img, please bare with me =)
User16: User8 Sure; just asking so I can clear out my inbox, no rush. :)
User8: Odd_Bloke, do cloud images need root= parameter or some such?
User8: Odd_Bloke, e.g. how do uefi images on x86_64 boot?
User8: i presume just by magic ;-)
User16: User8 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.
User8: Odd_Bloke, what's CLOUD_IMG_STR ?
User8: wait... C
User8: sed -i "s,root=.* ,root=LABEL=cloudimg-rootfs ,g" mountpoint/boot/grub/grub.cfg
User8: is nice.
User8: so i should do the same
User16: User8 It's just "# This has been modified by the cloud image build process" or something to that effect.
User8: cool.
User17: ubuntu-bug linux  on my xenial 64-bit desktop says that linux-image-4.3.0-2-generic isn't an official Ubuntu package
User8: Odd_Bloke, /sbin/plymouthd: not found =)
 * xnox ponders why we have plymouth thingies in the initramfs, without plymouth.
User8: also RAID arrawys are incrementatlly started =/
User18: how else would we get it bloated to tens of megabytes !
User13: barry, are you about ?
User13: tox.ini with:
User19: User13 yppers
User13: http://paste.ubuntu.com/14470834/
User19: *yeppers
User13: tox -e py34-pylint
User13: creates a .tox/py34-pylint/bin/python
User13: that is python2.7
User13: when run on trusty.
User13: i thougth/hopwed that because it had 'py34-' in its name there was magic that picked the right python
User19: User13 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
User13: oh. ok. that makes sense.
User13: so how do i set it ? doc was confusing to me.
User19: User13 i think, in the [testenv:py34-pylint] section just add:
User19: basepython = python3.4
User13: ok. the dictionaries shown at http://tox.readthedocs.org/en/latest/config.html were confusing to me.
User13: but ... i think you're right. thank you
User19: User13 np.  fwiw, i absolutely love http://tox.readthedocs.org/en/latest/config.html#generating-environments-conditional-settings :)
User13: barry, but for the base 'py27' and 'py34', it does do the right thing, right?
User13: yeah, it seems to.
User13: thanks again
User19: User13 right, because those envs are built-in
User19: User13 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
User13: barry, fudge.
User13: so then on trusty, where there is no python3.5
User13: what woudl i do to not run the test there ?
User19: User13 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
User13: thanks.
User20: User11 whoops, thanks for fixing libosinfo
User11: User20 np!
User21: is rmadison an (the?) appropriate tool for determining if a package is in universe or main?
User8: nacc, there is $ check-mir, tool too
User8: nacc, rmadison queries things differently, but will give accurate info too.
User21: User8 thanks!
User21: User8 yeah, just trying to educate myself on various tools
User22: User6 yo
User6: User22 hello!
User7: is the auto-import from debian broken?
User9: User7 No, looks fine to me.
User9: (You may want to give more details of what you think should have been imported ...)
User7: liquidsoap
User7: it isn't picked up since 12 h or so
User9: User7 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.
User9: User7 I'd expect to see it in the next sync.
User7: mmm strange
User7: [11:57:23] <mapreri> User7 non Ã¨ che fra qualche ora dai un `syncpackage -s mapreri -V 1.1.1-7.1 -f liquidsoap` ? :)
User7: at that time it was uploaded
User7: the run has been at 14 or so
User7: finished at 16 or so
User7: and now we are 8 ours later, and debian unstable has it
User9: User7 Right, but our mirror updates every six hours.  That "or so" is pretty important.
User9: We last synced our mirror at 16:05 UTC.
User7: cjwatson, damn, I remembered it was around each 30 minutes
User9: Goodness me, no.
User9: Never has been.
 * LocutusOfBorg lacks of a sane memory
User7: thanks then :)
User7: cjwatson, with dinstall going slower each time I guess running the script half an hour later will make many packages picked up early
User9: I'll check the dinstall logs next time I get a chance.
User7: one dinstall already started a few seconds ago, I'll monitor and give you the finish time :)
 * LocutusOfBorg if I don't fall asleep
User9: User7 No, don't bother.
User9: User7 I'm going to want to check historical logs anyway, not just have a single data point.
User9: User7 And don't waste your time monitoring - I'm pretty sure the logs are timestamped.
User7: sure, it depends on many factors I guess, specially with many european developers I expect the first one to be slower
User9: 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.
User22: User6 did you get my reply to your email earlier today?
User23: ping uiteam
User22: does anyone know where I can grab nightly builds of ubuntu xenial?
User22: or at least a netinstaller that lets me install nightly code from the archive
User24: alpha1 images and apply updates?
User25: User22 http://cdimage.ubuntu.com/daily-live/ and not sure about the latter
User26: seb128, User2 that ifupdown crash, bug 1532722, really failed to retrace and several crashes are missing an initial StacktraceAddressSignature
User5: bug 1532722 in ifupdown (Ubuntu) "/sbin/ifup:11:__GI_strncpy:strncpy:do_interface:main" [Undecided,New] https://launchpad.net/bugs/1532722
User22: User25 thanks
User6: User22 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.
User6: User22 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.
User6: User22 there are also published daily EC2 images, etc.
User6: User22 uvtool uses the published daily cloud images and throws them at libvirt/kvm, or you can use the images directly with something else.
User6: User22 we could attempt a Google Hangout or similar to plan things tomorrow maybe? Perhaps with ondrej too?
User6: (and nacc of course)
User22: User6 yeah, a Hangout sounds good
User22: My personal system is a Fedora 23 system
User22: so I can build VMs or containers or whatever as I need
User22: and I have access to a personal virtualization server for whatever I need to do
User22: so as long as your images work with KVM, I'm solid
User6: User22 http://cloud-images.ubuntu.com/xenial/current/ should be all you need.
User22: are this cloud-init ones or do I need to do anything special?
User6: User22 those images use cloud-init though. You'll need to supply cloud-init metadata and userdata to boot a usable system.
User22: hmm
User22: I'm not too good with setting up things with cloud-init :/
User22: I don't suppose you guys spin netinstall ISOs yet?
User6: uvtool does this all automatically, but as I don't use Fedora I have no idea how well uvtool will work on it.
ubuntu-devel
Ubuntu IRC