infinityslangasek: Your trusty hints now work.02:03
infinitybdmurray: Your yaml scraper might need love to ignore test regressions with a "should wait, but forced" note on them.02:04
RAOFinfinity: Oh, are we both complaining about sru autopkgtest failures at the same time? :)02:13
infinityRAOF: Well, you're complaining, we're trying to fix, but yes. ;)02:26
RAOFAh, good, good.02:29
pittiGood morning04:20
=== salem_ is now known as _salem
pittijdstrand: why don't we have libseccomp on arm64? Debian builds it there05:52
sarnoldprobably poor guy's been stuck in meetings since then :)05:56
zygacjwatson: oh, I'll check out getByPath, thanks06:20
zygacjwatson: hmm, I cannot find that method, I'm looking at https://api.launchpad.net/1.0.html06:20
zygaah, devel/06:20
lifelesszyga: yea, ignore 1.0.06:50
zygalifeless: 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
lifelesszyga: magic 8 ball says no06:52
lifelesszyga: so, the original idea was that each API version would be guaranteed for a period06:53
lifelesszyga: but the reality is nearly everyone is using devel now06:53
lifelesszyga: and its being evolved pretty gracefully06:53
lifelesszyga: 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 crazy06:54
lifelessthen cutting a 1.1/2.0 and removing the stuff in devel would be sensible06:54
zygalifeless: yeah, makes sense06:54
lifelessbut, 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 that06:54
lifelessa major overhaul of pagination maybe06:54
lifelessbut - there are comaptible graceful ways to roll that out incrementally06:55
lifelesswhich are ultimately better IMO06:55
=== tvoss|dinner is now known as tvoss
sil2100@pilot in07: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
zygabarry: hey, I have a question about debian packages and PEP44008:32
zygabarry: some things, on import of pkg resources, produce noisy warnings because pkg-resources seems to parse the full ubuntu version08:33
zygabarry: 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
lifelesszyga: thats the version thats in the distutils metadata for apturl I would say08:41
lifelesszyga: and its right, that version isn't, and needs fixing08:41
zygalifeless: so what is the recommended approach, it seems that pkg-resource somehow sees debian/ubuntu version08:43
zygalifeless: patch the world?08:43
zygalifeless: (or just pkg-resources)08:43
lifelessI've seen no evidence that that is the case08:43
zygalifeless: that what is the case?08:44
lifelesscat /usr/lib/python3/dist-packages/apturl-0.5.2ubuntu4.egg-info08:44
lifelessVersion: 0.5.2ubuntu408:44
lifelessthat one package08:45
lifelesshas a non-PEP-440 version in its Python metadata.08:45
lifelessso that one package needs to be fixed08:45
zygalifeless: I suspect many more packages are affected08:45
* zyga does a quick grep08:45
zygahmm, perhaps it's more isolated, it's just python-apt/apturl and ufw08:46
cjwatsonMost Python packages aren't native, so they likely just have the upstream version there08:51
cjwatsonI expect it's only native packages08:51
lifelessI was assuming things maintained in the Debian universe would be much more likely to use Debian versions :)08:54
sil2100@pilot out09: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:
FourDollarsNo! No patch pilot now! XD09:40
sil2100FourDollars: you need any package sponsored? ;)09:51
FourDollarssil2100: Yes.09:51
FourDollarssil2100: https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/145553309:51
ubottuUbuntu bug 1455533 in udisks2 (Ubuntu Trusty) "Dell systems showing "DIAGS" in Nautilus bar" [Undecided,In progress]09:51
FourDollarssil2100: Thx a lot. :D09:52
sil2100FourDollars: hmmm, ok, it's a main package so my MOTU-powers are not enough to sponsor it for you sadly09:53
sil2100But I can at least review it and try finding someone else09:54
FourDollarssil2100: No problem. Thx for your help anyway.09:54
FourDollarssil2100: That's good. Thx a lot. :D09:54
dokoRiddell, cantor ftbfs everywhere10:36
LaneyRiddell / 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_
barryzyga, lifeless: i dreamed about pep 440 version numbers last night13:01
smoserpitti, 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
ubottubug 1463461 in open-iscsi (Ubuntu) "resolvconf not updated by /lib/systemd/system/ifup@.service.d/open-iscsi.conf" [High,Incomplete] https://launchpad.net/bugs/146346113:03
pittismoser: ok, I'll try to recreate; but I would still have been interested in the ifup@*.service output13:05
smoserits there now13:05
pittismoser: coldplugging udev during boot ought to trigger those13:05
pittiand I wonder why that didn't happen13:05
smosercoldplugging ?13:05
=== MacSlow|lunch is now known as MacSlow
pittismoser: right, you gave the vivid ones, which look fine; I meant the failing wily status output13:06
smoseri gave wily too13:06
pittismoser: during boot, we udevadm trigger all devices, to run udev rules for devices which are already "there" (from the kernel and initramfs)13:06
smoserits just so non-interesting that you missed it :)13:07
smoser(comment 4)13:07
smoserwhat udevrule does run ifup ?13:07
pittioh :)13:07
pittismoser: ah, I have an idea13:08
pittismoser: in vivid that started ifup@.service directly, in wily we use Debian's net.agent13:08
pittiI suppose that somehow filters it out13:08
smoserbah. '!= remove'13:08
smoseri just read 'remove' and thought remove13:08
pittismoser: I suppose you run http://bazaar.launchpad.net/~smoser/maas/maas-ephemeral-sniff/view/head:/README.txt with s/trusty/wily/ ?13:09
smoserpitti, xkvm is http://smoser.brickies.net/git/?p=tildabin.git;f=xkvm;hb=HEAD13:12
smoseri just use it as a wrapper around kvm to more easily put NICs onto a bridge.13:12
pittiah, nice -- I suppose everyone has such scripts (mine is http://people.canonical.com/~pitti/scripts/vmbr)13:13
pittinicely points out how qemu should be easier to use :)13:13
pittismoser: "eth0" in tgt-boot-test should be my primary wlan interface? or something that's hanging off the bridge (using lxcbr0)?13:19
smoserpitti, by default its going to put a NIC on virbr0 (libvirt bridge)13:20
pittithe sed doesn't work either, I'll just hardcode an IP13:20
smoseryou can change that string to whatever you want13:21
smoserit will dhcp on it.13:21
smoserand 'eth0' there is the guest's eth013:21
pittismoser: no, I mean tgt-boot-test tries to call ifconfig (and sed) on my *host* eth013:21
smoserah. i see, yeah.13:21
pitti# this is the IP address of the tgtd13:21
smoserjust set it.13:21
pittiipaddr=$(ifconfig wlp3s0 | sed -n '/inet addr/s/\([^:]*:\)\([^ ]*\)\( .*\)/\2/p')13:21
pittiI don't know what a tgtd is, so not sure what to put in here13:21
smoserit has to be the ip that tgt is listening on. i think it listens on all)13:21
smosertgtd is the iscsi daemon13:22
pittiah, I now get some VM booting13:22
pittismoser: hm, it seems on reboot my changes to files aren't persistant13:28
pittismoser: e. g. I added some debugging to /lib/udev/net.agent, but on reboot they are gone13:29
pittisome kind of overlayfs?13:29
pittioverlayroot on / type overlayfs13:29
smoserpitti, they're not persistent.13:31
smoseryeah. overlayroot.13:31
smoserif you want you can probalby remove thoes kernel params, and moutn read-write.13:31
smoserbut you can also mount the image RW and make changes inside13:32
pittimanual eth013:32
pittiso ifup@ isn't triggered because this is a manual interface13:32
pittismoser: I'm testing with udevadm trigger now, easier/fastet13:32
smoserwell, its manual for good reason.13:32
smoserwell, i dont know. maybe. its manual though, and that has worked before.13:33
pittiI see how it worked in vivid, I'm not sure how it worked in utopic and before13:33
smoseri have known in the past13:34
smoserbut dont remember without lookoing.13:34
smoserpitti, network/interfaces is written in initramfs by http://bazaar.launchpad.net/~cloud-initramfs-tools/cloud-initramfs-tools/trunk/files/head:/dyn-netconf/13:35
smoserjust fyi13:35
pittiok, so we have an eth0 which is set up by the initramfs, and not wanted to set up by ifupdown13:35
pittiah, /etc/init/iscsi-network-interface.conf13:38
ogra_just dump a "manual" config into /etc/network/interfaces.d13:38
pittimount: cannot remount /dev/sda read-write, is write-protected13:39
smoserpitti, yeah, tgt is exported ro13:39
pittihm -- how do I make this r/w to get this actually persistant13:39
smoserin the tgt-boot-test13:40
smoseryou'll see.13:40
=== strikov is now known as strikov-lunch
smoserogra_, 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 those13:44
smoserand in this case, /etc/network/interfaces.d is RO13:44
pittismoser: ok, I understand how it worked pre-vivid, I followed up to the bug13:46
=== joet is now known as josepht
jdstrandpitti: re libseccomp-- it looks like because they pulled in 2.2 which wasn't available until a few weeks ago13:56
jdstrand'add newly supported arm64, mips, and mipsel'13:57
pittijdstrand: ah; I just wondered why we have a delta for the Architectures: line in the first place, as opposed to just using Debian's13:57
jdstrandpitti: that's why13:57
jdstrand2.1 didn't have those13:57
pittijdstrand: ooh! 2.2.1 vs. 2.1.1, I mis-looked13:58
* jdstrand nods13:58
pittijdstrand: ack, thanks; so that'll just come with the next merge13:58
pittijdstrand: these numbers were just too similar :)13:58
jdstrandindeed :)13:58
* jdstrand updates the backlog to mention this is a merge now13:59
=== cmagina_ is now known as cmagina
pittismoser: ^ got that in my /etc/resolv.conf now, as opposed to "empty"; looks good?14:01
pittismoser: I can ping out and have network and DNS and stuff14:01
pittismoser: followed up to the bug again, I'd like to hear your opinion14:05
hallyninfinity: qemu in wily isn't promoting from -proposed - presumably because of new binary pkgs?14:06
pittihttp://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qemu says "missing builds"14:07
pittiah yes, binNEW14:07
hallynoh sorry, i'll go ask in -release :)14:10
smoserpitti, 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
dobeymdeslaur: 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 silos15:04
ubottuUbuntu bug 1463875 in nettle (Ubuntu) "Crash in libnettle6 on armhf and powerpc archs" [Critical,New]15:04
mdeslaurdobey: looks like there's a nettle transition in progress15:05
mdeslaurdobey: I guess someone in foundations needs to rebuild stuff15:05
dobeymdeslaur: 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
mdeslaurdobey: yeah, that's probably it15:07
mdeslaurinfinity: can you sort that out? ^15:08
dobeymdeslaur: 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
cariboua while ago I asked why there was such a gap in rsyslog versions (7.4.4 .vs 8.9.0)15:17
caribouand was told that most probably it was because nobody cared to merge it15:18
caribouis that true ?15:18
mdeslaurcaribou: that's plausible. it's marked as "please take" on merges.u.c15:20
cariboumdeslaur: I feel like this could be a good candidate for me to increase my merge knowledge, but I will need help15:21
cariboumdeslaur: would people around be ready to help a young merging padawan ?15:22
caribouI've done a few small ones15:22
mdeslaurcaribou: that one seems to be big :)15:23
mdeslaurcaribou: best thing is to try it, then file a bug with your debdiff15:23
mdeslaurand get whoever's on patch piloting duty to take a look15:23
cariboumdeslaur: ok, I'll see if I can spare some time to give it a try15:23
infinitymdeslaur: What am I sorting?15:52
mdeslaurinfinity: stuff is segfaulting in wily-proposed because I think nettle needs a transition15:53
mdeslaurinfinity: see dobey's bug above15:53
infinitymdeslaur: 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
mdeslaurinfinity: it's just a probably cause, I have no idea if that's the reason or not15:55
infinitymdeslaur: Oh, see, I thought you might have evidence, rather than superstition.  You're no better than my parents. :P15:56
mdeslaurinfinity: heh, no evidence at all, which is why I'm bugging you :)15:56
infinitymdeslaur: 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
infinitymdeslaur: 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. :P15:57
mdeslaurI'm sure dobey can help test it...I'm not even sure why I am part of this discussion at all :P15:58
cjwatsoninfinity: It is, though we might find it easier to demote stuff temporarily to forcibly decouple that ...15:59
infinitymdeslaur: Cause you inserted yourself? :)15:59
cjwatsonHaskell still has some weird busted doctest stuff that I'm clueless about, and misc broken packages15:59
infinitycjwatson: 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
mdeslaurinfinity: I wish16:00
=== Malsasa_ is now known as Malsasa
dobeyinfinity: 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 transition16:20
dobeyoh, so the binary is apparently linked to both libnettle.so.6 and libnettle.so.416:24
cjwatsonRight, classic mid-transition segfault city stuff with indirect linking16:25
dobeyah, libcurl3-gnutls is linked to both16:26
dobeycjwatson: 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
xnoxstgraber: can one define lxcbr0 purely with systemd-networkd configuration files?16:30
cjwatsondobey: Sounds like it from what you said16:30
dobeyhopefully happens quickly then :)16:31
infinitydobey: Can you include a link to the failing build in your bug report?16:35
dobeyinfinity: sure.16:35
infinitydobey: Ta.16:35
=== ejat is now known as ejat-
smoserpitti, you're probably afk now aren't 'you16:39
shaderslayerLaney: yes, we already have commits for t16:39
shaderslayerunless 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 nicely16:41
infinitydobey: Why is it that whenever I ask someone to link a build, the link a log instead? :)16:42
Laneyshaderslayer: no, it's what do I do when I upload one of those packages?16:42
Laneyshaderslayer: before I could just push to bzr16:42
dobeyinfinity: oh, right.16:43
dobeyinfinity: there :)16:44
infinitydobey: Yeah, I'd already tracked it back and linked it in a comment. :P16:44
infinitydobey: But thanks. :)16:44
shaderslayerLaney: uh, good question ... maybe send a patch to pkg-kde on alioth16:45
shaderslayerLaney: FWIW we have an entire worfklow, for landing changes via a CI16:45
LaneyCI... ktrain?16:46
shaderslayersomething along those lines16:46
shaderslayerLaney: https://community.kde.org/Kubuntu/CI16:46
cjwatsonWhat 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(LP probably needs some bits and pieces of work before that's smooth, but it wouldn't take much at this point)16:53
Laneyshaderslayer: ^17:01
shaderslayercjwatson: would require a 2 way mirror between launchpad and pkg-kde17:03
shaderslayerthe idea was to be very close to debian folks by working in the same repos so that they could more easily reuse our work17:03
GunnarHjarges: 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
argesGunnarHj: sure i'll take a look17:43
GunnarHjarges: Thanks!17:51
shaderslayerScottK: do you know if python2.7 armhf installs on a amd64 system18:04
shaderslayeror well, is it supposed to18:04
shaderslayerbecause I seem to be running into http://paste.ubuntu.com/11691499/18:05
sarnoldwhat are you trying to accomplish?18:06
shaderslayersarnold: trying to install the python2.7 armhf packages in a chroot?18:07
shaderslayersarnold: basically, we're trying to install some armhf packages that depend on python2.7:armhf18:16
shaderslayer( inside a x86 chroot (18:16
sarnoldshaderslayer: do you need to be able to execute those programs?18:17
shaderslayersarnold: 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 one18:18
sarnoldshaderslayer: maybe use dpkg --unpack on the deb files in question?18:20
shaderslayersarnold: http://paste.ubuntu.com/11691583/18:20
shaderslayerwhich actually doesn't tell me why it doesn't want to install python18:21
shaderslayersarnold: heh18:21
shaderslayersarnold: we need some way of reproducing this, since it's not a one off thing :P18:22
shaderslayeror atleast afaik18:22
infinityshaderslayer: python's postinst executes python, there's no way around that really.18:23
infinityshaderslayer: So, if you have a dep chain that pulls in python, there are two options:18:23
infinity1) 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
sarnoldshaderslayer: .. 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
infinity2) install qemu-user-static and copy /usr/bin/qemu-whatever-arm into the chroot.18:24
infinityshaderslayer: 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
shaderslayerinfinity: yeah now I understand it a bit better :)18:25
infinityBut if this is a chain we expect people to install for crossing, breaking the dep is probably better, if we can.18:25
shaderslayerso it unpacks it just fine18:25
shaderslayerinfinity: yeah, except I can't understand http://paste.ubuntu.com/11691583/18:25
shaderslayeror well, I can't understand why python2.7 is pulled18:25
shaderslayerI don't see anything in there which would explain it18:25
infinitypkgProblemResolver doesn't show you all the dependency resolution, just the bits it needs to work hard to try to fix.18:26
shaderslayerI see18:26
infinityshaderslayer: "apt-get install foo bar python2.7-minimal:armhf-" might be enlightening.18:27
infinityshaderslayer: As you might get a "foo depends on python2.7, but it's not going to be installed" message.18:27
shaderslayerI see18:27
shaderslayerI'll try it out18:27
infinityRepeat for python:armhf- and python2.7:armhf-18:28
lifelessbarry: poor thing :)18:32
barrylifeless: it's okay.  i woke up laughing18:33
dokoMirv, I think for ciborium you have to find somebody to port it to the next qml go version18:47
sarnoldis there a "best bug" for the "package ... is already installed and configured" that we should be duping all these to?19:06
infinitysarnold: 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
infinitysarnold: Not sure if there's a master bug for it.19:21
infinitysarnold: But if you feel like cleaning up my dpkg bug list, you're welcome to dupe a few dozen. :P19:22
infinitysarnold: I'd be much more interested in a reproducer, though.19:22
sarnoldinfinity: 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 later19:23
infinitysarnold: 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
sarnoldinfinity: 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 stack19:24
infinitysarnold: Your assumption would be a pretty magnificent locking failure, which I'm about 99% sure can't happen.19:24
sarnoldinfinity: man I ignore those dialog boxes for days19:24
infinitysarnold: As a useless data point, I've never seen the bug on any of my machines, ever.  Which is super unhelpful.19:25
sarnoldinfinity: me neither! our two useless datapoints now draw a useless data curve :)19:25
infinitysarnold: Actually, you know, it might be an apt batching bug.19:30
infinitysarnold: You get that error message if you try to configure something that's already configured.  eg: "dpkg --configure libc6"19:31
infinitysarnold: 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
infinitysarnold: 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
luc4Hello! 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 th20:20
luc4as well?20:21
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
dobeyluc4: in your paste, it appears that directory is not included in the search path20:41
luc4dobey: are you saying I should add that manually?20:42
luc4dobey: but shouldn’t that be a system search path?20:42
dobeyi'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 STL20:43
dobeyplenty of other problems, but not finding the stl headers wasn't one of them :)20:43
luc4dobey: is “iterator” supposed to be in /usr/arm-linux-gnueabihf/include/c++/4.9.2?20:44
luc4dobey: ah, wait…20:44
luc4dobey: cross-compiling works20:44
dobeyi don't know20:44
luc4dobey: it does not when I set —sysroot.20:44
dobeywell, there you go20:45
luc4dobey: 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
dobeyluc4: i'd guess the g++/gcc documentation explains what happens when -sysroot option is used20:47
luc4dobey: yes, I read that but it does not clear this out20:48
dobeyyou are changing the root from / to something else; the default include paths added by gcc follow the root specified.20:48
luc4dobey: 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
luc4dobey: in either cases, iterator is in a different dir.20:49
luc4dobey: in the target filesystem it is in /usr/include/c++/4.9.20:49
dobeyyes, the /usr/lib include paths are special20:49
dobeyi'm guessing you probably need to install the stl headers and libstdc++ you want to use, in the sysroot20:50
luc4dobey: yes, I installed that.20:51
luc4dobey: in the sysroot I have “iterator”.20:51
dobeyi mean, the error message is pretty clear about where it's looking20:51
luc4dobey: but still not in one of the dirs the compiler is looking.20:51
luc4dobey: yes, iterator is not there.20:51
luc4dobey: it is like the expected layout was different.20:51
dobeyno, 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 similar20:53
luc4dobey: version is 4.9.2 for both. And on pi I’m using ubuntu mate.20:53
luc4dobey: I suppose it should be identical...20:53
dobeyyeah, i wouldn't expect ubuntu mate to change the gcc build20:54
dobeyi 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
luc4dobey: clear? :-) in the sense that it is not looking where it should?20:55
dobeyluc4: well your definition of "should" may not match the compiler's definition20:56
dobeyluc4: 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
luc4dobey: that’s the reason why I came here in the first place :-)20:57
luc4dobey: when I was cross-building the same way with other distros like raspbian it was working...20:57
dobeywere you using -sysroot then?20:57
luc4dobey: the crosscompiler used its own version of system libs + headers20:57
luc4I was using the linaro toolchain and raspbian20:58
luc4also the toolchain was different from the system, but providing the proper libs, everything was working20:58
luc4here for some reason it seems that when setting sysroot, the compiler does not look for system headers were they are on the host20:59
dobeywell, there's nothing more i can tell you.21:00
luc4do you know if there is someone maintaining those packages?21:00
dobeygcc? yes, the foundations team maintains the toolchain21:02
luc4dobey: 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
dobeyyou mean /usr/lib/arm-... there right?21:08
luc4ah, now I got this! http://pastebin.com/20JCVkyv21:10
dobeyanyway, 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
luc4not sure if it makes sense to install a cross compiler for arm on a arm system...21:10
dobeyprobably doesn't21:11
luc4unfortunately I spent a day on this… not sure I can find the issue21:11
dobeyyou're doing the build on the arm device?21:11
luc4dobey: no, I need to cross compile.21:11
dobeyoh ok21:13
dobeyanyway, i don't really have any other suggestions for you myself. and i have to go now. good luck21:20
luc4dobey: no problem, thanks for your time21:21
luc4dobey: my suspect is that those three dirs should not be prepended by the sysroot path.21:21
cjwatsonshaderslayer: 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
shaderslayerrequires pushing twice then :(21:40
shaderslayerand I'm sure people will screw up pushing twice21:41
cjwatsonOnly if you're committing to two different branches ...21:43
shaderslayerIIRC branches track only one remote don't they?21:44
cjwatsonI was suggesting that the Kubuntu branches could actually move back to Launchpad so that they could make use of Ubuntu project ACLs21:44
cjwatsonNow that it doesn't have to involve using a different VCS21: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
shaderslayerdunno, maybe we could write our own mirroring tech21:44
shaderslayercjwatson: oh oh21:44
cjwatsonTwo-way mirrors are inherently problematic21:44
cjwatsonA one-way mirror is obviously fairly easy21:44
shaderslayercjwatson: does Launchpad provide hook delivery21:45
cjwatsonshaderslayer: YM webhooks?21:45
shaderslayersince we use that on our jenkins21:45
shaderslayercjwatson: yep21:45
cjwatsonshaderslayer: It's our top development project21:45
shaderslayerso git.debian allows us to delivery commit hits to Jenkins to allow us to do per commit builds21:45
cjwatsonWe hope to have that in a month or so21:45
shaderslayercjwatson: I think the consensus at the moment is that anyone who wants to contribute to Kubuntu can ask for debian-qt-kde commit rights21:51
cjwatsonYeah, 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 commit21:52
cjwatsonIt's always been tried with good intentions, but ...21:52
cjwatsonMaybe when we have dgit of everything or something21:53
=== salem_ is now known as _salem
infinityluc4: 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
infinityluc4: In other words, you got what you asked for, you just weren't sure why you were asking for it. ;)22:07
luc4infinity: not exactly, my sysroot has the header “iterator”, but still, the compiler won’t find it.22:07
luc4infinity: also, if you look here: http://pastebin.com/HDkLxEQ9 you’ll see the crosscompiler also looks into the host system for some headers22:08
luc4infinity: which, according to your sentence, should be wrong, shouldn’t it?22:09
infinityluc4: 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
luc4infinity: 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
infinityluc4: 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
luc4infinity: precisely, done already22:11
infinityluc4: 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
infinityluc4: Clearly, this is not how any of us call our compilers. :P22:13
luc4infinity: the header “iterator” is in the sysroot, it is just in a system directory that the compiler is not searching.22:13
luc4infinity: I could add it manually, and that way it works, but it doesn’t seem right.22:14
luc4infinity: I’m not sure I’m following. You say you don’t set the sysroot?22:15
infinityluc4: 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
infinityluc4: 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
infinityluc4: I use an amd64 chroot with armhf as a foreign arch, and install the armhf build-deps in said chroot.22:17
infinityluc4: 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
luc4infinity: at the moment I’m adding three paths manually… not sure it will work but I’ll try...22:18
luc4infinity: I can file the issue but I’m not a compiler expert. So… what do you think?22:22
infinityluc4: One doesn't need to be an expert to file bugs. :)22:27
luc4infinity: no, but as you seem to be a little more used, you probably can tell me if I should or not.22:28
infinityluc4: 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
misspapayaI un-tar'd ubuntu-core onto an SD card for a system without a display and I don't get a login prompt22:49
misspapayavia serial22:50
misspapayahow do I set that up?22:50
infinitymisspapaya: Which version?22:50
misspapayainfinity: trusty22:50
infinitymisspapaya: You want something like this: http://paste.ubuntu.com/11692880/22:51
infinitymisspapaya: Alter the filename and tty* in the file to match your actual serial port.22:51
misspapayakk thanks :(22:52
infinitymisspapaya: Whatever you're passing on the cmdline as console=22:52
misspapayacan't ubuntu just magically know the hardware it's running on? :P22:54
infinitymisspapaya: The core tarball is just a rootfs, there's no installer, and precisely zero magic.22:55
misspapayainfinity: that worked. Thanks :)22:56
misspapayaI just forgot to add a user22:56
infinityUsers are overrated.22:56
misspapayanow to get back to seeing if GPS works in orbit :P23:03
sarnoldmisspapaya: 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 orbit23:11
jrwrenanyone 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
misspapayasarnold: haha thanks for the input but I'm not the head of this project so it's not a major concern of mine23:59

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