| tumbleweed | infinity: can you steer a pypy build at a big buildd, again? https://launchpad.net/~stefanor/+archive/pypy/+build/5275420 | 01:38 |
|---|---|---|
| infinity | tumbleweed: Remind me which buildd qualified as big? | 01:41 |
| * infinity looks for successful builds. | 01:41 | |
| infinity | louvi, apparenrly. | 01:42 |
| infinity | apparently, too. | 01:42 |
| tumbleweed | yeah, that one | 01:43 |
| tumbleweed | thanks! | 01:43 |
| infinity | tumbleweed: The chindis were good enough for i386... Does the amd64 build need more oomph? | 01:43 |
| tumbleweed | my usual approach of just retrying from a script doesn't work when there are no big buildds in the pool | 01:43 |
| tumbleweed | 2G RAM isn't enough | 01:44 |
| tumbleweed | although, if they have enough swap, which stays in the host's RAM, it could work out | 01:44 |
| infinity | Anyhow, I'll just block off a few machines that have done it successfully in the past, and pick the first that's free. | 01:45 |
| tumbleweed | thanks | 01:46 |
| infinity | tumbleweed: Erm, did you retry the build? | 01:56 |
| infinity | I just went to retry and aim it at a buildd, and it's already building... | 01:57 |
| infinity | Well, it failed quickly at least. :P | 01:58 |
| tumbleweed | yeah, that's how it rolls | 02:03 |
| tumbleweed | thanks again | 02:03 |
| manchicken | Does anybody here know apt-pkg code well? I'm trying to figure out why `_config->FindFile("Dir::Etc::sourcelist")` would yield an empty std::string | 02:06 |
| xnox | cjwatson: apt-get --purge -yf build-dep hello, fails with E: Command line option âfâ [from -yf] is not known, with latest apt. | 02:37 |
| cjwatson | xnox: you can probably work out how to fix it by example from my most recent patch, but do send the patch to Debian | 02:39 |
| cjwatson | and maybe look through the other discrepancies in support between install and build-dep to see if they all make sense | 02:39 |
| cjwatson | I just fixed --purge because it was breaking sbuild | 02:39 |
| infinity | There's shouldn't be differences at all, really. build-dep is just a special install. | 02:40 |
| infinity | Just as remove and purge are. | 02:40 |
| infinity | Well, package arguments are different, but everything pre-command should be the same, I'd think. | 02:40 |
| cjwatson | build-dep wants -a/--host-architecture as well, I think | 02:41 |
| cjwatson | but it should probably be a superset ... | 02:41 |
| cjwatson | so handle it a bit more like upgrade | 02:41 |
| === freeflying is now known as freeflying_away | ||
| === xubincs is now known as xubincq | ||
| === xubincq is now known as xubincs | ||
| === freeflying_away is now known as freeflying | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| === xubincq is now known as xubincs | ||
| pitti | Good morning | 06:50 |
| pitti | sarnold, mdz: if the "suspend" panel menu also doesn't work, it's not settings-daemon or anything; that one directly talks to logind, which calls systemd-shim | 06:51 |
| pitti | mdz, sarnold: settings-daemon is supposed to inhibit logind's own handling of the suspend key; but that still doesn't explain why the indicator menu doesn't work; and if anything, this rather ought to cause a double suspend | 06:52 |
| pitti | mdz, sarnold: could it be that you don't have a running logind session? "loginctl"? | 06:52 |
| sarnold | pitti: hey, good morning :) | 07:24 |
| sarnold | pitti: http://paste.ubuntu.com/6488331/ | 07:24 |
| pitti | hey sarnold, how are you? | 07:24 |
| sarnold | pitti: pretty good, thanks; how's your thursday looking? :) | 07:25 |
| pitti | sarnold: snowy and icy :) | 07:25 |
| pitti | sarnold, mdz: you should check whether this works: | 07:26 |
| pitti | sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true | 07:26 |
| sarnold | pitti: oh, brrrrr :) | 07:26 |
| sarnold | pitti: Error: GDBus.Error:org.freedesktop.DBus.Error.Failed: Operation already in progress http://paste.ubuntu.com/6488337/ | 07:27 |
| pitti | aah | 07:27 |
| pitti | sarnold, mdz: so it works the first time, but then not any more | 07:28 |
| pitti | sarnold, mdz: that's either bug 1184262 which was fixed in saucy-updates a few days ago (and in trusty), or its successor bug 1252121 | 07:28 |
| sarnold | pitti: I'd guess it worked several times, often enough for me to find that networkmanager did not return ... | 07:28 |
| ubottu | bug 1184262 in systemd-shim (Ubuntu Trusty) "times out too early, stuck in PrepareForSleep, causing network and other services to not resume" [High,Fix released] https://launchpad.net/bugs/1184262 | 07:28 |
| ubottu | bug 1252121 in systemd-shim (Ubuntu) "missing PrepareForSleep signal after resuming, causing networking to stay disabled" [High,Incomplete] https://launchpad.net/bugs/1252121 | 07:28 |
| pitti | sarnold, mdz: worth trying the package in my sru-test PPA and telling me how it goes | 07:29 |
| pitti | this fixes another two bugs in -shim, but some people report it's still not working after that (but it works for several others) | 07:29 |
| sarnold | pitti: okay, I've got the new systemd-shim installed; it didn't work immediately, but it worked at least twice after rebooting. | 07:40 |
| pitti | sarnold: yes, after installing you at least need to kill the running logind | 07:40 |
| sarnold | pitti: I'm on vacation until monday, so I won't be testing it nearly as much as I'd like before your desired monday release, but i'll let you know how it goes | 07:40 |
| sarnold | pitti: would just a simple killall logind have done the job? | 07:41 |
| pitti | sarnold: thanks; not that urgent, I won't catch desrt before Monday either I suppose | 07:41 |
| pitti | sarnold: systemd-logind, but yes | 07:41 |
| sarnold | pitti: thanks :) | 07:41 |
| pitti | sarnold: that gets rid of the "system thinks it's still sleeping" state | 07:42 |
| dholbach | good morning | 07:42 |
| sarnold | pitti: hehe, I presume "can execute code" is good enough to know it's not asleep? :) | 07:42 |
| pitti | sarnold: not sure, it might be sleepwalking! | 07:47 |
| sarnold | pitti: hahaha :) | 07:47 |
| mlankhorst | any sru admin on? | 08:00 |
| mlankhorst | I need someone to approve the pixman sru for saucy, raring, q, p | 08:01 |
| sarnold | pitti: thanks for the help :) bedtime for me! \o/ | 08:40 |
| === doko_ is now known as doko | ||
| === freeflying is now known as freeflying_away | ||
| ara | hello all! | 09:56 |
| ara | For new packages in Ubuntu (that are not in Debian) what's the best approach? always try to have them in Debian first? or not that needed? what's the "official" Ubuntu policy? | 09:56 |
| seb128 | ara, hey, it's best to get those in Debian if possible | 09:57 |
| seb128 | that's not an absolute requirement/blocker | 09:57 |
| ara | seb128, OK, thanks :) | 09:57 |
| seb128 | but it makes things easier for everyone | 09:57 |
| seb128 | e.g Debian get the package, and we can share efforts | 09:58 |
| ara | zyga, ^ | 09:58 |
| zyga | ara: sounds good to me, I can maintain them in debian | 09:59 |
| zyga | ara: I guess we can transition packages over time | 09:59 |
| zyga | ara: not make it a priority/blocker but just keep pushing it until we are all in debian | 09:59 |
| zyga | seb128: is the ubuntu sdk in debian or goint there, by any chance? | 09:59 |
| ara | zyga, good point ;-) | 10:00 |
| seb128 | zyga, I doubt it | 10:00 |
| seb128 | well it's not | 10:00 |
| seb128 | I don't know what the plans are | 10:00 |
| ara | so, now we know a blocker for the UI packages :) | 10:00 |
| seb128 | but I doubt it's going to be there any time soon | 10:00 |
| seb128 | we would need the ubuntu platform api there | 10:00 |
| seb128 | maybe libhybris and stuff as well | 10:00 |
| zyga | seb128: how about the qml components? | 10:01 |
| zyga | seb128: I don't know how separated those things are, we basically depend on qt5 and the qml components added by the ubuntu sdk | 10:01 |
| seb128 | zyga, no sure, seems like a question for the sdk team | 10:03 |
| zyga | seb128: thanks | 10:03 |
| === freeflying_away is now known as freeflying | ||
| === freeflying is now known as freeflying_away | ||
| === txomon|fon_ is now known as txomon|fon | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === _salem is now known as salem_ | ||
| === Sweetsha1k is now known as Sweetshark | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === freeflying_away is now known as freeflying | ||
| xnox | infinity: when building a package on arm64, I get "undefined reference to `_mcount'" a presume that gprof is not available, but i'm failing to see how / why / where references to _mcount are generated =( | 13:48 |
| === psivaa is now known as psivaa-lunch | ||
| doko | xnox, is profiling already supported? | 14:10 |
| xnox | doko: i don't think it is. And i think I have found stray "-p" in some objects compilations. Removing that flag seems to make the build go further. | 14:10 |
| xnox | doko: i'm going by absence of libc6-prof:arm64 | 14:11 |
| doko | xnox, supposed to work, starting in trusty. so maybe infinity should build one ... | 14:14 |
| xnox | doko: hm, i've compiled all objects with "-p -pg" and got "undefined refrence to `_mcount'" at link time. So something somewhere doesn't work yet. | 14:15 |
| doko | xnox, where is this defined on other archs? | 14:16 |
| xnox | doko: i presume gcrt1.o provided by libc | 14:18 |
| xnox | (vs normal crt1.o) | 14:19 |
| doko | =) | 14:19 |
| === dholbach_ is now known as dholbach | ||
| === Mapley is now known as Maplez | ||
| === Maplez is now known as Mapley | ||
| === psivaa-lunch is now known as psivaa | ||
| xnox | well. it compiled. let's see if it succeeds on the distro builders now =) | 15:29 |
| rbasak | Is there an easy way to get the path to (eg.) /lib/x86_64-linux-gnu/libgcc_s.so.1 at a shell prompt? | 15:49 |
| rbasak | I can't hardcode it since that'll break other architectures. | 15:49 |
| Riddell | /lib/*/libgcc_s.so.1 | 15:50 |
| rbasak | Riddell: that'll break if I had multiarch things installed though, wouldn't it? | 15:52 |
| rbasak | Aha | 15:54 |
| rbasak | /lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/libgcc_s.so.1 | 15:54 |
| pitti | barry: halp! bug 1255505 (just responded to psivaa's mail and found this; I sent an initial analysis) | 16:20 |
| ubottu | bug 1255505 in python2.7 (Ubuntu) "unittest discover crashes with: module incorrectly imported from 'xxx'. Expected 'xxx. Is this module globally installed?" [Critical,Confirmed] https://launchpad.net/bugs/1255505 | 16:20 |
| pitti | barry: oh, turkey day I guess | 16:20 |
| pitti | barry, doko: http://bugs.python.org/file32304/unittest_loader_symlinks.patch looks easy enough to revert, though; should we do an upload which reverts this to unblock developers? | 16:21 |
| pitti | (I just confirmed that this fixes it) | 16:22 |
| doko | pitti, sure, go ahead, barry is on vacation, killing some turkeys today | 16:26 |
| pitti | doko: ack | 16:27 |
| pitti | doko: adding the patch to debian/patches/series.in will do? or do I need some extra magic? | 16:28 |
| doko | pitti, yes | 16:29 |
| doko | enough | 16:29 |
| doko | pitti, the upstream issue is still closed. could you add some information that this breaks some things? | 16:30 |
| pitti | doko: yes, can do (probably tomorrow, running out of time today) | 16:31 |
| doko | pitti, because this seems to be some multiarch related issue | 16:31 |
| pitti | oh? I only have amd64 python installed | 16:31 |
| pitti | rather looks related to our dh_python symlink setup? | 16:32 |
| doko | or that | 16:33 |
| doko | which really should go away | 16:33 |
| pitti | doko: python3 FTW! | 16:33 |
| pitti | :) | 16:33 |
| doko | pitti, well let autopilot use it ... | 16:33 |
| pitti | doko: it is | 16:34 |
| pitti | just most tests aren't yet | 16:34 |
| pitti | (it's underway) | 16:34 |
| pitti | I ported autopilot some months ago | 16:34 |
| pitti | doko: test-building locally now, but would you mind having a look at http://paste.ubuntu.com/6490243/ ? | 16:35 |
| pitti | doko: I didn't actually change anything in debian/control, seems that was some debian/rules magic | 16:36 |
| doko | looks fine | 16:36 |
| pitti | doko: danke | 16:36 |
| rbasak | pitti: do you know if I can have comments in a dep8 control file? I don't see anything in the spec for that. | 16:38 |
| pitti | rbasak: yes, you can | 16:40 |
| pitti | rbasak: with # | 16:40 |
| rbasak | pitti: thanks! | 16:40 |
| rbasak | pitti: I'm going to add tests that I know won't run because we don't do breaks-testbed yet, but this means that I need to mark the first test that can run breaks-testbed (since it is), but we can't tell the infrastructure that, since it won't run (IYSWIM). | 16:41 |
| rbasak | pitti: also I have a suspicion that a breaks-testbed test is treated as a failure by adt-run. | 16:41 |
| rbasak | Since it causes adt-run to exit with a (specific) non-zero exit code. | 16:42 |
| rbasak | pitti: so I'll upload dep8 tests now, since they're useful even locally (and for SRU verification), but leave them commented out. | 16:42 |
| rbasak | pitti: does that sound reasonable? | 16:42 |
| pitti | rbasak: no, breaks-testbed ones are currently skipped | 16:43 |
| pitti | rbasak: but yes, our scripts might interpret exit code 2 as "fail" | 16:43 |
| pitti | rbasak: sure, sounds fine; if you need a place to store them | 16:43 |
| rbasak | pitti: right. So in the cases of packages where all packages are breaks-testbed, then it's still useful to have one run in the infrastructure by not marking it breaks-testbed even though it is. | 16:44 |
| pitti | rbasak: perhaps don't put an XS-Testsuite: tag on it then, so that it won't needlessly fail and make pacakge propagation harder | 16:44 |
| pitti | rbasak: ah, I understand now | 16:44 |
| pitti | rbasak: right, so do enable tests, just have it run one, don't mark it as breaks-testbed and comment out the rest | 16:44 |
| rbasak | pitti: right. | 16:44 |
| rbasak | pitti: I'll email ubuntu-quality with a summary and comment a link to that or something so people can follow what's going on. | 16:45 |
| pitti | rbasak: oh, just in case you wonder, I shelved my adt-virt-qemu for now, need to work on something else first | 16:45 |
| rbasak | OK, thanks | 16:45 |
| === tkamppeter_ is now known as tkamppeter | ||
| pitti | good night everyone! and happy Turkey eating to our American friends | 16:51 |
| seb128 | pitti, 'night! | 16:52 |
| Saviq | mvo, ping | 20:12 |
| mvo | Saviq: pong | 20:14 |
| Saviq | mvo, hey, I saw you were dealing with a similar bug recently in apt | 20:14 |
| Saviq | mvo, I'm suddenly getting: E: Command line option 'f' [from -yf] is not known. when trying to cross-build with sbuild | 20:14 |
| Saviq | mvo, when it's trying to install build deps | 20:14 |
| Saviq | mvo, any pointers as to what might be the culprit? | 20:15 |
| mvo | Saviq: indeed, sorry for this regression, its fixed in git (ubuntu/master and debian/sid branches) | 20:15 |
| infinity | Things were shuffled recently so that build-dep doesn't recognize all the same options as install. | 20:15 |
| infinity | mvo: Did you get all the cases? | 20:15 |
| Saviq | mvo, for sbuild or apt? | 20:15 |
| infinity | mvo: If so, an upload would be quite appreciated by a lot of people, I think. | 20:15 |
| infinity | Saviq: apt. | 20:15 |
| mvo | Saviq: what infinity said - it got stricter and now refuses options who are not making sense in the context where it used to simply ignore it | 20:16 |
| Saviq | infinity, mvo, got it, thanks | 20:16 |
| mvo | infinity: yeah, I can do one now, was just chasing one more issue, but that can wait until tomorrow | 20:16 |
| infinity | mvo: People have been asking about it a fair bit, so I imagine an upload would shut 'em up. ;) | 20:16 |
| infinity | mvo: And I assume you've pulled in Colin's fix from ubuntu2? | 20:17 |
| mvo | infinity: yes, both ubuntu2 and ubuntu3 | 20:18 |
| mvo | infinity: I give it some testing and then I upload, I changed the patch from ubuntu2 a bit, but it should not cause issues | 20:20 |
| mvo | infinity: uploaded - and you can always ping me on irc if a fair amount of people ask about a regression (or a bug or whateva) | 20:41 |
| bkerensa | Happy Thanksgiving :) | 20:46 |
| === salem_ is now known as _salem | ||
| === Sweetsha1k is now known as Sweetshark | ||
| === seb128_ is now known as seb128 | ||
| === thomi_ is now known as thomi | ||
| slangasek | @pilot in | 22:07 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: slangasek | ||
| slangasek | seb128: say, do you know if the patch to freetype for bug #972223 is still needed? | 22:08 |
| ubottu | bug 972223 in FreeType "regression in gtk underlining rendering" [Unknown,New] https://launchpad.net/bugs/972223 | 22:08 |
| slangasek | the freetype upstream change is over two years old now | 22:08 |
| seb128 | slangasek, last time I tried (which I think was during the saucy cycle), it still was | 22:09 |
| slangasek | drat | 22:09 |
| seb128 | I can try again tomorrow if you want | 22:09 |
| seb128 | slangasek, what are you doing piloting? aren't you supposed to eat turkey today? | 22:10 |
| slangasek | seb128: some families watch football after dinner, others log onto IRC ;) | 22:10 |
| seb128 | lol | 22:11 |
| xnox | GO SAINTS! | 22:33 |
| doko | xnox, Go! | 22:38 |
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| brendand | is it just me or is branch.getMergeProposals completely fubar in launchpadlib? | 23:36 |
| brendand | always returns a zero size collection, even though i can *see* a merge proposal in the browser interface | 23:37 |
| xnox | well, doesn't tarmac monitors / notices merge proposals via that api? | 23:40 |
| xnox | (or does it do email notifications) | 23:40 |
| brendand | xnox, i thought it did too | 23:40 |
| xnox | brendand: and are you looking that up on the: source or target branch? | 23:41 |
| brendand | xnox, :P | 23:41 |
| brendand | xnox, there you go | 23:42 |
| brendand | xnox, so it only allows me to query for merge proposals *too* the branch | 23:42 |
| brendand | f*ck | 23:42 |
| brendand | pardon me | 23:42 |
| xnox | brendand: i think there are get merge proposal on the project & distro source packages as well. | 23:43 |
| xnox | i think that might be easier. | 23:43 |
| brendand | xnox, also the owner | 23:47 |
| brendand | xnox, it just makes the check a bit clumsier | 23:48 |
| brendand | xnox, i'm developing a tool to clean up branches locally on disk | 23:48 |
| xnox | but, but, but it's Restful =))))) | 23:48 |
| brendand | xnox, where the branch is merged | 23:49 |
| xnox | sounds cool, i bet i have a tonne of those. | 23:49 |
| brendand | xnox, most of the time i can just check lifecycle_status == 'Merged' | 23:49 |
| brendand | xnox, except where the branch was not merged to the trunk of the project | 23:49 |
| xnox | brendand: i did $ bzr init-repo ~/src/ a long time ago and I'm generally happy with disk-space, merge branches only waste a checkout. | 23:49 |
| xnox | s/merge/merged/ | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!