| infinity | slangasek: Your trusty hints now work. | 02:03 |
|---|---|---|
| infinity | bdmurray: Your yaml scraper might need love to ignore test regressions with a "should wait, but forced" note on them. | 02:04 |
| RAOF | infinity: Oh, are we both complaining about sru autopkgtest failures at the same time? :) | 02:13 |
| infinity | RAOF: Well, you're complaining, we're trying to fix, but yes. ;) | 02:26 |
| RAOF | Ah, good, good. | 02:29 |
| pitti | Good morning | 04:20 |
| === salem_ is now known as _salem | ||
| pitti | jdstrand: why don't we have libseccomp on arm64? Debian builds it there | 05:52 |
| sarnold | probably poor guy's been stuck in meetings since then :) | 05:56 |
| zyga | cjwatson: oh, I'll check out getByPath, thanks | 06:20 |
| zyga | cjwatson: hmm, I cannot find that method, I'm looking at https://api.launchpad.net/1.0.html | 06:20 |
| zyga | ah, devel/ | 06:20 |
| lifeless | zyga: yea, ignore 1.0. | 06:50 |
| zyga | lifeless: thanks, I was actually about to ask cjwatson if thre will be a new API version (since he recommended to rm stale wadl files) | 06:52 |
| lifeless | zyga: magic 8 ball says no | 06:52 |
| zyga | :) | 06:53 |
| lifeless | zyga: so, the original idea was that each API version would be guaranteed for a period | 06:53 |
| lifeless | zyga: but the reality is nearly everyone is using devel now | 06:53 |
| lifeless | zyga: and its being evolved pretty gracefully | 06:53 |
| lifeless | zyga: so, if there was some radical stuff; deprecations for instance to remove - that weren't reflecting LP stopping doing something, just the API not showing it or something crazy | 06:54 |
| lifeless | then cutting a 1.1/2.0 and removing the stuff in devel would be sensible | 06:54 |
| zyga | lifeless: yeah, makes sense | 06:54 |
| lifeless | but, since there's effectively no reason to remove stuff from the API and not LP itself, I don't think there's cause to do that | 06:54 |
| lifeless | a major overhaul of pagination maybe | 06:54 |
| lifeless | but - there are comaptible graceful ways to roll that out incrementally | 06:55 |
| lifeless | which are ultimately better IMO | 06:55 |
| === tvoss|dinner is now known as tvoss | ||
| sil2100 | @pilot in | 07:41 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100 | ||
| zyga | barry: hey, I have a question about debian packages and PEP440 | 08:32 |
| zyga | barry: some things, on import of pkg resources, produce noisy warnings because pkg-resources seems to parse the full ubuntu version | 08:33 |
| zyga | barry: e.g. /usr/lib/python3/dist-packages/pkg_resources/__init__.py:2512: PEP440Warning: 'apturl (0.5.2ubuntu6)' is being parsed as a legacy, non PEP 440, version. You may find odd behavior and sort order. In particular it will be sorted as less than 0.0. It is recommend to migrate to PEP 440 compatible versions. | 08:33 |
| lifeless | zyga: thats the version thats in the distutils metadata for apturl I would say | 08:41 |
| lifeless | zyga: and its right, that version isn't, and needs fixing | 08:41 |
| zyga | lifeless: so what is the recommended approach, it seems that pkg-resource somehow sees debian/ubuntu version | 08:43 |
| zyga | lifeless: patch the world? | 08:43 |
| zyga | lifeless: (or just pkg-resources) | 08:43 |
| lifeless | I've seen no evidence that that is the case | 08:43 |
| zyga | lifeless: that what is the case? | 08:44 |
| lifeless | cat /usr/lib/python3/dist-packages/apturl-0.5.2ubuntu4.egg-info | 08:44 |
| lifeless | Version: 0.5.2ubuntu4 | 08:44 |
| lifeless | that one package | 08:45 |
| lifeless | has a non-PEP-440 version in its Python metadata. | 08:45 |
| lifeless | so that one package needs to be fixed | 08:45 |
| zyga | lifeless: I suspect many more packages are affected | 08:45 |
| * zyga does a quick grep | 08:45 | |
| zyga | hmm, perhaps it's more isolated, it's just python-apt/apturl and ufw | 08:46 |
| cjwatson | Most Python packages aren't native, so they likely just have the upstream version there | 08:51 |
| cjwatson | I expect it's only native packages | 08:51 |
| lifeless | yup | 08:54 |
| lifeless | I was assuming things maintained in the Debian universe would be much more likely to use Debian versions :) | 08:54 |
| sil2100 | @pilot out | 09:03 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| FourDollars | No! No patch pilot now! XD | 09:40 |
| sil2100 | FourDollars: you need any package sponsored? ;) | 09:51 |
| FourDollars | sil2100: Yes. | 09:51 |
| FourDollars | sil2100: https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1455533 | 09:51 |
| ubottu | Ubuntu bug 1455533 in udisks2 (Ubuntu Trusty) "Dell systems showing "DIAGS" in Nautilus bar" [Undecided,In progress] | 09:51 |
| FourDollars | sil2100: Thx a lot. :D | 09:52 |
| sil2100 | FourDollars: hmmm, ok, it's a main package so my MOTU-powers are not enough to sponsor it for you sadly | 09:53 |
| sil2100 | But I can at least review it and try finding someone else | 09:54 |
| FourDollars | sil2100: No problem. Thx for your help anyway. | 09:54 |
| FourDollars | sil2100: That's good. Thx a lot. :D | 09:54 |
| doko | Riddell, cantor ftbfs everywhere | 10:36 |
| Laney | Riddell / shaderslayer: Do you use pkg-kde git now? How do you want commits for that? | 11:27 |
| === MacSlow is now known as MacSlow|lunch | ||
| === _salem is now known as salem_ | ||
| barry | zyga, lifeless: i dreamed about pep 440 version numbers last night | 13:01 |
| smoser | pitti, responded in bug 1463461. i can give you access to this environment if you want, but other than the 300M download it is easy enough to recreate. | 13:03 |
| ubottu | bug 1463461 in open-iscsi (Ubuntu) "resolvconf not updated by /lib/systemd/system/ifup@.service.d/open-iscsi.conf" [High,Incomplete] https://launchpad.net/bugs/1463461 | 13:03 |
| pitti | smoser: ok, I'll try to recreate; but I would still have been interested in the ifup@*.service output | 13:05 |
| smoser | its there now | 13:05 |
| pitti | smoser: coldplugging udev during boot ought to trigger those | 13:05 |
| pitti | and I wonder why that didn't happen | 13:05 |
| smoser | coldplugging ? | 13:05 |
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | smoser: right, you gave the vivid ones, which look fine; I meant the failing wily status output | 13:06 |
| smoser | i gave wily too | 13:06 |
| pitti | smoser: during boot, we udevadm trigger all devices, to run udev rules for devices which are already "there" (from the kernel and initramfs) | 13:06 |
| smoser | its just so non-interesting that you missed it :) | 13:07 |
| smoser | (comment 4) | 13:07 |
| smoser | what udevrule does run ifup ? | 13:07 |
| pitti | oh :) | 13:07 |
| pitti | /lib/udev/rules.d/80-networking.rules | 13:08 |
| pitti | smoser: ah, I have an idea | 13:08 |
| pitti | smoser: in vivid that started ifup@.service directly, in wily we use Debian's net.agent | 13:08 |
| pitti | I suppose that somehow filters it out | 13:08 |
| smoser | bah. '!= remove' | 13:08 |
| smoser | i just read 'remove' and thought remove | 13:08 |
| pitti | smoser: I suppose you run http://bazaar.launchpad.net/~smoser/maas/maas-ephemeral-sniff/view/head:/README.txt with s/trusty/wily/ ? | 13:09 |
| smoser | right. | 13:09 |
| smoser | pitti, xkvm is http://smoser.brickies.net/git/?p=tildabin.git;f=xkvm;hb=HEAD | 13:12 |
| smoser | i just use it as a wrapper around kvm to more easily put NICs onto a bridge. | 13:12 |
| pitti | ah, nice -- I suppose everyone has such scripts (mine is http://people.canonical.com/~pitti/scripts/vmbr) | 13:13 |
| pitti | nicely points out how qemu should be easier to use :) | 13:13 |
| pitti | smoser: "eth0" in tgt-boot-test should be my primary wlan interface? or something that's hanging off the bridge (using lxcbr0)? | 13:19 |
| smoser | pitti, by default its going to put a NIC on virbr0 (libvirt bridge) | 13:20 |
| pitti | the sed doesn't work either, I'll just hardcode an IP | 13:20 |
| smoser | you can change that string to whatever you want | 13:21 |
| smoser | it will dhcp on it. | 13:21 |
| smoser | and 'eth0' there is the guest's eth0 | 13:21 |
| pitti | smoser: no, I mean tgt-boot-test tries to call ifconfig (and sed) on my *host* eth0 | 13:21 |
| smoser | ah. i see, yeah. | 13:21 |
| pitti | # this is the IP address of the tgtd | 13:21 |
| smoser | just set it. | 13:21 |
| pitti | ipaddr=$(ifconfig wlp3s0 | sed -n '/inet addr/s/\([^:]*:\)\([^ ]*\)\( .*\)/\2/p') | 13:21 |
| pitti | I don't know what a tgtd is, so not sure what to put in here | 13:21 |
| smoser | it has to be the ip that tgt is listening on. i think it listens on all) | 13:21 |
| smoser | tgtd is the iscsi daemon | 13:22 |
| pitti | ah, I now get some VM booting | 13:22 |
| pitti | smoser: hm, it seems on reboot my changes to files aren't persistant | 13:28 |
| pitti | smoser: e. g. I added some debugging to /lib/udev/net.agent, but on reboot they are gone | 13:29 |
| pitti | some kind of overlayfs? | 13:29 |
| pitti | overlayroot on / type overlayfs | 13:29 |
| pitti | aah | 13:29 |
| smoser | pitti, they're not persistent. | 13:31 |
| smoser | yeah. overlayroot. | 13:31 |
| smoser | if you want you can probalby remove thoes kernel params, and moutn read-write. | 13:31 |
| smoser | but you can also mount the image RW and make changes inside | 13:32 |
| pitti | manual eth0 | 13:32 |
| pitti | aah! | 13:32 |
| pitti | so ifup@ isn't triggered because this is a manual interface | 13:32 |
| pitti | smoser: I'm testing with udevadm trigger now, easier/fastet | 13:32 |
| pitti | faster | 13:32 |
| smoser | well, its manual for good reason. | 13:32 |
| smoser | well, i dont know. maybe. its manual though, and that has worked before. | 13:33 |
| pitti | I see how it worked in vivid, I'm not sure how it worked in utopic and before | 13:33 |
| smoser | i have known in the past | 13:34 |
| smoser | but dont remember without lookoing. | 13:34 |
| smoser | pitti, network/interfaces is written in initramfs by http://bazaar.launchpad.net/~cloud-initramfs-tools/cloud-initramfs-tools/trunk/files/head:/dyn-netconf/ | 13:35 |
| smoser | just fyi | 13:35 |
| pitti | ok, so we have an eth0 which is set up by the initramfs, and not wanted to set up by ifupdown | 13:35 |
| smoser | right | 13:37 |
| pitti | ah, /etc/init/iscsi-network-interface.conf | 13:38 |
| ogra_ | just dump a "manual" config into /etc/network/interfaces.d | 13:38 |
| pitti | mount: cannot remount /dev/sda read-write, is write-protected | 13:39 |
| smoser | pitti, yeah, tgt is exported ro | 13:39 |
| pitti | hm -- how do I make this r/w to get this actually persistant | 13:39 |
| smoser | s/readonly/ | 13:39 |
| smoser | in the tgt-boot-test | 13:40 |
| smoser | you'll see. | 13:40 |
| pitti | cheers | 13:40 |
| === strikov is now known as strikov-lunch | ||
| smoser | ogra_, well, the dyn-netconf converts ipconfig/klibc to network/interfaces and puts it in /run. that could subsequently or optionally be linked into /etc/network/interfaces.d, but that still requires that there is nothing in /etc/network/interfaces for those | 13:44 |
| smoser | and in this case, /etc/network/interfaces.d is RO | 13:44 |
| pitti | smoser: ok, I understand how it worked pre-vivid, I followed up to the bug | 13:46 |
| === joet is now known as josepht | ||
| jdstrand | pitti: re libseccomp-- it looks like because they pulled in 2.2 which wasn't available until a few weeks ago | 13:56 |
| jdstrand | 'add newly supported arm64, mips, and mipsel' | 13:57 |
| pitti | jdstrand: ah; I just wondered why we have a delta for the Architectures: line in the first place, as opposed to just using Debian's | 13:57 |
| jdstrand | pitti: that's why | 13:57 |
| jdstrand | 2.1 didn't have those | 13:57 |
| pitti | jdstrand: ooh! 2.2.1 vs. 2.1.1, I mis-looked | 13:58 |
| * jdstrand nods | 13:58 | |
| pitti | jdstrand: ack, thanks; so that'll just come with the next merge | 13:58 |
| jdstrand | yes | 13:58 |
| pitti | jdstrand: these numbers were just too similar :) | 13:58 |
| jdstrand | indeed :) | 13:58 |
| * jdstrand updates the backlog to mention this is a merge now | 13:59 | |
| pitti | nameserver 10.0.3.1 | 14:00 |
| === cmagina_ is now known as cmagina | ||
| pitti | smoser: ^ got that in my /etc/resolv.conf now, as opposed to "empty"; looks good? | 14:01 |
| pitti | smoser: I can ping out and have network and DNS and stuff | 14:01 |
| pitti | smoser: followed up to the bug again, I'd like to hear your opinion | 14:05 |
| smoser | k | 14:06 |
| hallyn | infinity: qemu in wily isn't promoting from -proposed - presumably because of new binary pkgs? | 14:06 |
| pitti | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qemu says "missing builds" | 14:07 |
| pitti | ah yes, binNEW | 14:07 |
| hallyn | oh sorry, i'll go ask in -release :) | 14:10 |
| smoser | pitti, i like the arp search that yours does. | 14:27 |
| smoser | (vmbr). i was just wanting that recently. | 14:27 |
| === strikov-lunch is now known as strikov | ||
| dobey | mdeslaur: hi. the new nettle in wily seems to be breaking on arm/ppc: https://bugs.launchpad.net/ubuntu/+source/nettle/+bug/1463875 any chance you could look at this? it's causing build failures in silos | 15:04 |
| ubottu | Ubuntu bug 1463875 in nettle (Ubuntu) "Crash in libnettle6 on armhf and powerpc archs" [Critical,New] | 15:04 |
| mdeslaur | dobey: looks like there's a nettle transition in progress | 15:05 |
| mdeslaur | dobey: I guess someone in foundations needs to rebuild stuff | 15:05 |
| dobey | mdeslaur: oh, these builds are using -proposed already, so i guess it's what is causing the crash perhaps, and not the version in wily release? | 15:06 |
| mdeslaur | dobey: yeah, that's probably it | 15:07 |
| mdeslaur | infinity: can you sort that out? ^ | 15:08 |
| dobey | mdeslaur: updated the description with the package version/pocket info. | 15:11 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| caribou | a while ago I asked why there was such a gap in rsyslog versions (7.4.4 .vs 8.9.0) | 15:17 |
| caribou | and was told that most probably it was because nobody cared to merge it | 15:18 |
| caribou | is that true ? | 15:18 |
| mdeslaur | caribou: that's plausible. it's marked as "please take" on merges.u.c | 15:20 |
| caribou | mdeslaur: I feel like this could be a good candidate for me to increase my merge knowledge, but I will need help | 15:21 |
| caribou | mdeslaur: would people around be ready to help a young merging padawan ? | 15:22 |
| caribou | I've done a few small ones | 15:22 |
| mdeslaur | caribou: that one seems to be big :) | 15:23 |
| mdeslaur | caribou: best thing is to try it, then file a bug with your debdiff | 15:23 |
| mdeslaur | and get whoever's on patch piloting duty to take a look | 15:23 |
| caribou | mdeslaur: ok, I'll see if I can spare some time to give it a try | 15:23 |
| infinity | mdeslaur: What am I sorting? | 15:52 |
| mdeslaur | infinity: stuff is segfaulting in wily-proposed because I think nettle needs a transition | 15:53 |
| mdeslaur | infinity: see dobey's bug above | 15:53 |
| infinity | mdeslaur: So, it's clearly needing a transition, but what makes you think that's causing the segfaults? Assuming both versions are being loaded and curbstomping each others' symbols? | 15:54 |
| infinity | (Can't really see that happening in the sparse bug report...) | 15:54 |
| mdeslaur | infinity: it's just a probably cause, I have no idea if that's the reason or not | 15:55 |
| mdeslaur | probable | 15:55 |
| infinity | mdeslaur: Oh, see, I thought you might have evidence, rather than superstition. You're no better than my parents. :P | 15:56 |
| mdeslaur | infinity: heh, no evidence at all, which is why I'm bugging you :) | 15:56 |
| infinity | mdeslaur: Right-o. I can have a look at completing that transition, but would be nice to verify the segfaults will clear up when I do. | 15:57 |
| infinity | mdeslaur: Thankfully(?) it won't all migrate when it's done, cause I think nettle's also stuck in the current haskell transition, so that should buy a bit of time to test and fix the actual bug. :P | 15:57 |
| mdeslaur | I'm sure dobey can help test it...I'm not even sure why I am part of this discussion at all :P | 15:58 |
| cjwatson | infinity: It is, though we might find it easier to demote stuff temporarily to forcibly decouple that ... | 15:59 |
| infinity | mdeslaur: Cause you inserted yourself? :) | 15:59 |
| cjwatson | Haskell still has some weird busted doctest stuff that I'm clueless about, and misc broken packages | 15:59 |
| infinity | cjwatson: Whee. Well, I'll cross that bridge when it collapses in my path and I need to untangle my metaphors with a flamethrower. | 16:00 |
| mdeslaur | infinity: I wish | 16:00 |
| === Malsasa_ is now known as Malsasa | ||
| dobey | infinity: i don't think finishing the transition will fix the issue. it seems the cause is the new version of nettle that is currently in transition | 16:20 |
| dobey | oh, so the binary is apparently linked to both libnettle.so.6 and libnettle.so.4 | 16:24 |
| cjwatson | Right, classic mid-transition segfault city stuff with indirect linking | 16:25 |
| dobey | ah, libcurl3-gnutls is linked to both | 16:26 |
| dobey | cjwatson: so i guess just finishing the transition will end up fixing it, assuming everything gets rebuilt properly to only link to the one version? | 16:30 |
| xnox | stgraber: can one define lxcbr0 purely with systemd-networkd configuration files? | 16:30 |
| cjwatson | dobey: Sounds like it from what you said | 16:30 |
| dobey | ok | 16:30 |
| dobey | hopefully happens quickly then :) | 16:31 |
| infinity | dobey: Can you include a link to the failing build in your bug report? | 16:35 |
| dobey | infinity: sure. | 16:35 |
| infinity | dobey: Ta. | 16:35 |
| dobey | done | 16:36 |
| === ejat is now known as ejat- | ||
| smoser | pitti, you're probably afk now aren't 'you | 16:39 |
| shaderslayer | Laney: yes, we already have commits for t | 16:39 |
| shaderslayer | unless the question is, how do you get commit rights for that, in which case it's basically, talk to the pkg-kde maintainers, and ask nicely | 16:41 |
| infinity | dobey: Why is it that whenever I ask someone to link a build, the link a log instead? :) | 16:42 |
| Laney | shaderslayer: no, it's what do I do when I upload one of those packages? | 16:42 |
| Laney | shaderslayer: before I could just push to bzr | 16:42 |
| dobey | infinity: oh, right. | 16:43 |
| dobey | infinity: there :) | 16:44 |
| infinity | dobey: Yeah, I'd already tracked it back and linked it in a comment. :P | 16:44 |
| infinity | dobey: But thanks. :) | 16:44 |
| shaderslayer | Laney: uh, good question ... maybe send a patch to pkg-kde on alioth | 16:45 |
| shaderslayer | Laney: FWIW we have an entire worfklow, for landing changes via a CI | 16:45 |
| Laney | CI... ktrain? | 16:46 |
| shaderslayer | something along those lines | 16:46 |
| shaderslayer | Laney: https://community.kde.org/Kubuntu/CI | 16:46 |
| cjwatson | What would it take to move the Kubuntu branches to git on Launchpad so that we can use normal Ubuntu ACLs for them? | 16:52 |
| cjwatson | s/branches/repositories/ | 16:53 |
| cjwatson | (LP probably needs some bits and pieces of work before that's smooth, but it wouldn't take much at this point) | 16:53 |
| Laney | shaderslayer: ^ | 17:01 |
| shaderslayer | cjwatson: would require a 2 way mirror between launchpad and pkg-kde | 17:03 |
| shaderslayer | the idea was to be very close to debian folks by working in the same repos so that they could more easily reuse our work | 17:03 |
| GunnarHj | arges: Hi Chris, see that you are working with the vivid queue. Can you please accept ubuntu-docs also, since it needs to be build during this week. | 17:28 |
| arges | GunnarHj: sure i'll take a look | 17:43 |
| GunnarHj | arges: Thanks! | 17:51 |
| shaderslayer | ScottK: do you know if python2.7 armhf installs on a amd64 system | 18:04 |
| shaderslayer | or well, is it supposed to | 18:04 |
| shaderslayer | because I seem to be running into http://paste.ubuntu.com/11691499/ | 18:05 |
| sarnold | what are you trying to accomplish? | 18:06 |
| shaderslayer | sarnold: trying to install the python2.7 armhf packages in a chroot? | 18:07 |
| shaderslayer | sarnold: basically, we're trying to install some armhf packages that depend on python2.7:armhf | 18:16 |
| shaderslayer | ( inside a x86 chroot ( | 18:16 |
| sarnold | shaderslayer: do you need to be able to execute those programs? | 18:17 |
| shaderslayer | sarnold: well, that's the thing, I don't have to execute anything, it seems to be a dep of some other armhf packages, I'm trying to figure which one | 18:18 |
| sarnold | shaderslayer: maybe use dpkg --unpack on the deb files in question? | 18:20 |
| shaderslayer | sarnold: http://paste.ubuntu.com/11691583/ | 18:20 |
| shaderslayer | which actually doesn't tell me why it doesn't want to install python | 18:21 |
| shaderslayer | sarnold: heh | 18:21 |
| shaderslayer | sarnold: we need some way of reproducing this, since it's not a one off thing :P | 18:22 |
| shaderslayer | or atleast afaik | 18:22 |
| infinity | shaderslayer: python's postinst executes python, there's no way around that really. | 18:23 |
| infinity | shaderslayer: So, if you have a dep chain that pulls in python, there are two options: | 18:23 |
| infinity | 1) Look into what's pulling it in and if it's actually necessary, and if we can fix the world to not do that, thus making cross-building more pleasant. | 18:23 |
| sarnold | shaderslayer: .. but you're trying to execute armhf instructions on amd64. you could break out qemu if you don't mind it being glacial.. | 18:24 |
| infinity | 2) install qemu-user-static and copy /usr/bin/qemu-whatever-arm into the chroot. | 18:24 |
| infinity | shaderslayer: The super unhelpful "file not found" from python is actually it saying that it has no PE for python2.7, thus can't run it. qemu-user-static would fix that. | 18:24 |
| shaderslayer | infinity: yeah now I understand it a bit better :) | 18:25 |
| infinity | But if this is a chain we expect people to install for crossing, breaking the dep is probably better, if we can. | 18:25 |
| shaderslayer | so it unpacks it just fine | 18:25 |
| shaderslayer | infinity: yeah, except I can't understand http://paste.ubuntu.com/11691583/ | 18:25 |
| shaderslayer | or well, I can't understand why python2.7 is pulled | 18:25 |
| shaderslayer | I don't see anything in there which would explain it | 18:25 |
| infinity | pkgProblemResolver doesn't show you all the dependency resolution, just the bits it needs to work hard to try to fix. | 18:26 |
| shaderslayer | I see | 18:26 |
| infinity | shaderslayer: "apt-get install foo bar python2.7-minimal:armhf-" might be enlightening. | 18:27 |
| infinity | shaderslayer: As you might get a "foo depends on python2.7, but it's not going to be installed" message. | 18:27 |
| shaderslayer | I see | 18:27 |
| shaderslayer | I'll try it out | 18:27 |
| infinity | Repeat for python:armhf- and python2.7:armhf- | 18:28 |
| lifeless | barry: poor thing :) | 18:32 |
| barry | lifeless: it's okay. i woke up laughing | 18:33 |
| doko | Mirv, I think for ciborium you have to find somebody to port it to the next qml go version | 18:47 |
| sarnold | is there a "best bug" for the "package ... is already installed and configured" that we should be duping all these to? | 19:06 |
| infinity | sarnold: It's a dpkg bug, we think, but no one's ever been able to reproduce it reliably enough (or at all) to debug it. | 19:21 |
| infinity | sarnold: Not sure if there's a master bug for it. | 19:21 |
| infinity | sarnold: But if you feel like cleaning up my dpkg bug list, you're welcome to dupe a few dozen. :P | 19:22 |
| infinity | sarnold: I'd be much more interested in a reproducer, though. | 19:22 |
| sarnold | infinity: interesting. up til now i've assumed it was something like the updater pops up, gets ignored, then the user runs apt-get dist-upgrade manually, and then eventually clicks "go ahead" in the dialog a day or two later | 19:23 |
| infinity | sarnold: It happens so infrequently that it could be FS corruption, or cosmic rays, or kittens lobbing string cheese at computers, but at scale, with the number of users we have, it looks pretty common. :/ | 19:23 |
| sarnold | infinity: for a while I was checking dmesgs on those to try to see if there were sata errors or other segfaults or something but .. figured there's so many of them and never any indication of other errors that there had to be a bug elsewhere in th eupdate stack | 19:24 |
| infinity | sarnold: Your assumption would be a pretty magnificent locking failure, which I'm about 99% sure can't happen. | 19:24 |
| sarnold | infinity: man I ignore those dialog boxes for days | 19:24 |
| sarnold | hehe | 19:24 |
| infinity | sarnold: As a useless data point, I've never seen the bug on any of my machines, ever. Which is super unhelpful. | 19:25 |
| sarnold | infinity: me neither! our two useless datapoints now draw a useless data curve :) | 19:25 |
| infinity | sarnold: Actually, you know, it might be an apt batching bug. | 19:30 |
| infinity | sarnold: You get that error message if you try to configure something that's already configured. eg: "dpkg --configure libc6" | 19:31 |
| infinity | sarnold: Do the logs on the most recent one seem to show the package in question being configured successfully, then a second attempt happening later? | 19:31 |
| infinity | sarnold: It's possible I've been blaming this on dpkg all along and it's really just apt being stupid and trying to do a configure pass on the same package twice. | 19:32 |
| === adrian is now known as alvesadrian | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| luc4 | Hello! I’m trying to use the arm-linux-gnueabihf-g++ crosscompiler to cross-build a lib on ubuntu for a ubuntu arm device. When I try I notice this happens: http://pastebin.com/HDkLxEQ9. STL is not found. The iterator header is in /usr/arm-linux-gnueabihf/include/c++/4.9.2 in the host system. But why isn’t the compiler looking up into that dir when building? Am I doing something wrong or should the compiler look in th | 20:20 |
| luc4 | as well? | 20:21 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| dobey | luc4: in your paste, it appears that directory is not included in the search path | 20:41 |
| luc4 | dobey: are you saying I should add that manually? | 20:42 |
| luc4 | dobey: but shouldn’t that be a system search path? | 20:42 |
| dobey | i'm not entirely sure. i don't know what you installed. all i can say is that i've not ever had that issue when cross-compiling packages that use STL | 20:43 |
| dobey | plenty of other problems, but not finding the stl headers wasn't one of them :) | 20:43 |
| luc4 | dobey: is “iterator” supposed to be in /usr/arm-linux-gnueabihf/include/c++/4.9.2? | 20:44 |
| luc4 | dobey: ah, wait… | 20:44 |
| luc4 | dobey: cross-compiling works | 20:44 |
| dobey | i don't know | 20:44 |
| luc4 | dobey: it does not when I set —sysroot. | 20:44 |
| dobey | well, there you go | 20:45 |
| luc4 | dobey: question now is: is the compiler supposed to look for “iterator” in the sysroot or in the host? | 20:45 |
| === joet is now known as josepht | ||
| dobey | luc4: i'd guess the g++/gcc documentation explains what happens when -sysroot option is used | 20:47 |
| luc4 | dobey: yes, I read that but it does not clear this out | 20:48 |
| dobey | you are changing the root from / to something else; the default include paths added by gcc follow the root specified. | 20:48 |
| luc4 | dobey: if you look at the output I reported above, it seems it looks into some host paths first, and then some paths in the sysroot. | 20:49 |
| luc4 | dobey: in either cases, iterator is in a different dir. | 20:49 |
| luc4 | dobey: in the target filesystem it is in /usr/include/c++/4.9. | 20:49 |
| dobey | yes, the /usr/lib include paths are special | 20:49 |
| dobey | i'm guessing you probably need to install the stl headers and libstdc++ you want to use, in the sysroot | 20:50 |
| luc4 | dobey: yes, I installed that. | 20:51 |
| luc4 | dobey: in the sysroot I have “iterator”. | 20:51 |
| dobey | i mean, the error message is pretty clear about where it's looking | 20:51 |
| luc4 | dobey: but still not in one of the dirs the compiler is looking. | 20:51 |
| luc4 | dobey: yes, iterator is not there. | 20:51 |
| luc4 | dobey: it is like the expected layout was different. | 20:51 |
| dobey | no, but probbably the raspbpi has a different gcc version or at least, the headers are installed in a different path, than the compiler in ubuntu uses. so you will have to add the path, or not build with -sysroot, or something similar | 20:53 |
| luc4 | dobey: version is 4.9.2 for both. And on pi I’m using ubuntu mate. | 20:53 |
| luc4 | dobey: I suppose it should be identical... | 20:53 |
| dobey | yeah, i wouldn't expect ubuntu mate to change the gcc build | 20:54 |
| dobey | i don't know how you installed the headers there though. i can only tell you that the error message in your pastebin is quite clear :) | 20:55 |
| luc4 | dobey: clear? :-) in the sense that it is not looking where it should? | 20:55 |
| dobey | luc4: well your definition of "should" may not match the compiler's definition | 20:56 |
| dobey | luc4: it is clear in the sense that it reports all the locations where it looked for the header. it's up to you to find out why it isn't there :) | 20:56 |
| luc4 | dobey: that’s the reason why I came here in the first place :-) | 20:57 |
| luc4 | dobey: when I was cross-building the same way with other distros like raspbian it was working... | 20:57 |
| dobey | were you using -sysroot then? | 20:57 |
| luc4 | dobey: the crosscompiler used its own version of system libs + headers | 20:57 |
| luc4 | yes | 20:57 |
| luc4 | I was using the linaro toolchain and raspbian | 20:58 |
| luc4 | also the toolchain was different from the system, but providing the proper libs, everything was working | 20:58 |
| luc4 | here for some reason it seems that when setting sysroot, the compiler does not look for system headers were they are on the host | 20:59 |
| dobey | well, there's nothing more i can tell you. | 21:00 |
| luc4 | do you know if there is someone maintaining those packages? | 21:00 |
| dobey | gcc? yes, the foundations team maintains the toolchain | 21:02 |
| luc4 | dobey: in the output of the link there is “ignoring nonexistent directory "/opt/rpi/sysroot_mate/usr/arm-linux-gnueabihf/include/c++/4.9.2””. That dir “/usr/arm-linux-gnueabihf/include/c++/4.9.2” exists in the host but not in the target… maybe just some missing package…? | 21:07 |
| dobey | you mean /usr/lib/arm-... there right? | 21:08 |
| luc4 | yes | 21:09 |
| luc4 | ah, now I got this! http://pastebin.com/20JCVkyv | 21:10 |
| dobey | anyway, i'm not sure. and i don't have root on your machine. i'm sure you can look and figure it out :) | 21:10 |
| luc4 | not sure if it makes sense to install a cross compiler for arm on a arm system... | 21:10 |
| dobey | probably doesn't | 21:11 |
| luc4 | unfortunately I spent a day on this… not sure I can find the issue | 21:11 |
| dobey | you're doing the build on the arm device? | 21:11 |
| luc4 | dobey: no, I need to cross compile. | 21:11 |
| dobey | oh ok | 21:13 |
| dobey | anyway, i don't really have any other suggestions for you myself. and i have to go now. good luck | 21:20 |
| dobey | later | 21:20 |
| luc4 | dobey: no problem, thanks for your time | 21:21 |
| luc4 | dobey: my suspect is that those three dirs should not be prepended by the sysroot path. | 21:21 |
| cjwatson | shaderslayer: I suppose that could be done, but surely the main obstacle previously was revision control, and it's really not hard to add another remote to a git clone ... | 21:40 |
| shaderslayer | requires pushing twice then :( | 21:40 |
| shaderslayer | and I'm sure people will screw up pushing twice | 21:41 |
| cjwatson | Only if you're committing to two different branches ... | 21:43 |
| shaderslayer | IIRC branches track only one remote don't they? | 21:44 |
| cjwatson | I was suggesting that the Kubuntu branches could actually move back to Launchpad so that they could make use of Ubuntu project ACLs | 21:44 |
| shaderslayer | ah | 21:44 |
| cjwatson | Now that it doesn't have to involve using a different VCS | 21:44 |
| cjwatson | (Or at least that we could explore that and figure out what else we need to fix in LP to make it workable) | 21:44 |
| shaderslayer | dunno, maybe we could write our own mirroring tech | 21:44 |
| shaderslayer | cjwatson: oh oh | 21:44 |
| cjwatson | Two-way mirrors are inherently problematic | 21:44 |
| cjwatson | A one-way mirror is obviously fairly easy | 21:44 |
| shaderslayer | cjwatson: does Launchpad provide hook delivery | 21:45 |
| cjwatson | shaderslayer: YM webhooks? | 21:45 |
| shaderslayer | since we use that on our jenkins | 21:45 |
| shaderslayer | cjwatson: yep | 21:45 |
| cjwatson | shaderslayer: It's our top development project | 21:45 |
| shaderslayer | so git.debian allows us to delivery commit hits to Jenkins to allow us to do per commit builds | 21:45 |
| cjwatson | We hope to have that in a month or so | 21:45 |
| shaderslayer | cjwatson: I think the consensus at the moment is that anyone who wants to contribute to Kubuntu can ask for debian-qt-kde commit rights | 21:51 |
| cjwatson | Yeah, in practice when that's been tried elsewhere in the past the result is that uploaders who are doing things across the distro rather than just in Kubuntu simply don't commit | 21:52 |
| cjwatson | It's always been tried with good intentions, but ... | 21:52 |
| cjwatson | Maybe when we have dgit of everything or something | 21:53 |
| === salem_ is now known as _salem | ||
| infinity | luc4: The whole point of -sysroot is to look in your sysroot for everything. If it allowed you to pollute your environment with your real root, that would defeat the entire puropse. | 22:06 |
| infinity | luc4: In other words, you got what you asked for, you just weren't sure why you were asking for it. ;) | 22:07 |
| luc4 | infinity: not exactly, my sysroot has the header “iterator”, but still, the compiler won’t find it. | 22:07 |
| luc4 | infinity: also, if you look here: http://pastebin.com/HDkLxEQ9 you’ll see the crosscompiler also looks into the host system for some headers | 22:08 |
| luc4 | infinity: which, according to your sentence, should be wrong, shouldn’t it? | 22:09 |
| infinity | luc4: The gcc-cross stuff is either "special" or a bug, I'm not sure. But what you're doing when you set sysroot is explicitly saying "instead of /usr/include and /usr/arm-linux-gnueabihf/include, I want you to prepend /opt/rpi/sysroot_mate to that". | 22:10 |
| luc4 | infinity: I’m not entirely sure about that, however, let’s suppose it is: my question is “why isn’t it finding the headers in the sysroot”? | 22:11 |
| infinity | luc4: So, you'd need to install libstdc++-dev and g++ in your sysroot to find the headers there. Or not compile with sysroot. | 22:11 |
| luc4 | infinity: precisely, done already | 22:11 |
| infinity | luc4: Oh, that may still not work, mind you, because our cross-compilers are set up to look in the cross locations, but not the native ones. That might be a bug. | 22:13 |
| infinity | luc4: Clearly, this is not how any of us call our compilers. :P | 22:13 |
| luc4 | infinity: the header “iterator” is in the sysroot, it is just in a system directory that the compiler is not searching. | 22:13 |
| luc4 | infinity: I could add it manually, and that way it works, but it doesn’t seem right. | 22:14 |
| luc4 | infinity: I’m not sure I’m following. You say you don’t set the sysroot? | 22:15 |
| infinity | luc4: No, it may well be broken. I would expect to see $sysroot/usr/include/c++/4.9.2 on the search path, I think, when calling it that way. But it's a bit messy, since that absolutely *can't* be on the search path when not sysrooting. | 22:15 |
| infinity | luc4: No, I don't use sysroots for crossing. | 22:16 |
| luc4 | infinity: and how can you ensure that the build finds all the proper libs and headers? | 22:17 |
| infinity | luc4: I use an amd64 chroot with armhf as a foreign arch, and install the armhf build-deps in said chroot. | 22:17 |
| infinity | luc4: Whereas, I assume your sysroot is pure armhf, which isn't quite the scenario we packaged our cross-compilers for (but that doesn't mean it shouldn't work... Like I said, this is probably a bug you should file) | 22:18 |
| luc4 | infinity: at the moment I’m adding three paths manually… not sure it will work but I’ll try... | 22:18 |
| luc4 | infinity: I can file the issue but I’m not a compiler expert. So… what do you think? | 22:22 |
| infinity | luc4: One doesn't need to be an expert to file bugs. :) | 22:27 |
| luc4 | infinity: no, but as you seem to be a little more used, you probably can tell me if I should or not. | 22:28 |
| infinity | luc4: Can't hurt to file it. Like I said, we don't really use the sysroot feature much (or at all), so I'm entirely willing to believe it's broken and needs looking into. | 22:29 |
| misspapaya | I un-tar'd ubuntu-core onto an SD card for a system without a display and I don't get a login prompt | 22:49 |
| misspapaya | via serial | 22:50 |
| misspapaya | how do I set that up? | 22:50 |
| misspapaya | (armhf) | 22:50 |
| infinity | misspapaya: Which version? | 22:50 |
| misspapaya | infinity: trusty | 22:50 |
| infinity | misspapaya: You want something like this: http://paste.ubuntu.com/11692880/ | 22:51 |
| infinity | misspapaya: Alter the filename and tty* in the file to match your actual serial port. | 22:51 |
| misspapaya | kk thanks :( | 22:52 |
| infinity | misspapaya: Whatever you're passing on the cmdline as console= | 22:52 |
| misspapaya | s/(/)/ | 22:52 |
| misspapaya | can't ubuntu just magically know the hardware it's running on? :P | 22:54 |
| infinity | misspapaya: The core tarball is just a rootfs, there's no installer, and precisely zero magic. | 22:55 |
| misspapaya | infinity: that worked. Thanks :) | 22:56 |
| misspapaya | I just forgot to add a user | 22:56 |
| infinity | Users are overrated. | 22:56 |
| misspapaya | init=/bin/sh | 22:56 |
| misspapaya | now to get back to seeing if GPS works in orbit :P | 23:03 |
| sarnold | misspapaya: check the datasheet or manual; some of the gpses I've looked at recently include e.g. ""altitude < 18000 meters or velocity < 515m/s COCOM limit, either my be exceeded by not both" -- which probably rules out orbit | 23:11 |
| jrwren | anyone familiar with dh_python? I'm trying to extract some functionality for some other purpose, but i cannot follow how the shebang option is used. I see parser.add_option shebang, and then its never used. | 23:26 |
| misspapaya | sarnold: haha thanks for the input but I'm not the head of this project so it's not a major concern of mine | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!