=== _salem is now known as salem_ === salem_ is now known as _salem === Guest90505 is now known as LoganCloud === LoganCloud is now known as Guest11784 === Guest11784 is now known as LoganCloud [03:47] xnox: Thanks for cleaning up those last two boost1.53 rdeps. [03:48] xnox: And it looks like librime and yaml-cpp are caught up with some other fun, but we can deal with that later. [03:49] Oh, a simple SONAME transition there. I'll fix that. [04:03] xnox: On, but neither rivet nor opencolorio actually build with the new yaml-cpp. Fun. === freeflying is now known as freeflying_away === tdmackey is now known as staticvector === staticvector is now known as tdmackey [04:24] Good morning [04:24] infinity: I'm around now [04:24] slangasek: we didn't yet enable LP crash reports for trusty again [04:25] jibel: oh, my fault, thanks; I'll fix that one way or the other [04:25] slangasek: just comment out the whole problem_types line [04:25] bdmurray: ^ yes, you are right [04:26] * infinity finds pitti catching up on backscroll oddly fascinating. [04:26] pitti: Does anyone other than you (and GSA, I guess) have access to the ddeb-scraping stuff on germanium? [04:26] Alt+N FTW :) [04:27] infinity: according to getent groups, it's cjwatson, seb128, slangasek, and me [04:28] pitti: Curious. Okay, more importantly, does anyone else know how it works? :) [04:28] infinity: you ought to have access as well [04:28] pitti: We've going to take a buildd offline tomorrow, and I'd like to do a final scrape before we do, so we don't lose any ddebs. [04:29] infinity: it's more or less a checkout of https://code.launchpad.net/~pitti/%2Bjunk/ddeb-retriever/ plus this crontab: http://paste.ubuntu.com/6374416/ [04:29] pitti: I ought to as in you think I have access already, or you think it would be good if I did? [04:29] infinity: ah, sure; so whoever is around of these four, should run this command: ~/ddeb-retriever/ddeb-retriever today [04:29] infinity: yes, I do; filing an RT [04:34] infinity: RT sent, CCed you [04:34] pitti: Cheers. [04:34] infinity: if it doesn't happen by tomorrow, do you have enough flexibility there to wait for one of these four? [04:34] pitti: I can get the RT done. :P [04:34] the command takes some 30 seconds [04:34] infinity: heh, if you have r00t, what am I complaining about :) [04:35] pitti: No root, but I have friends in low places. ;) [04:36] (or high, depending on your endianness) [04:39] infinity: that was fast [04:40] pitti: ;) === BruceMa is now known as BruceMa-afk === freeflying_away is now known as freeflying === wedgwood is now known as Guest32887 === BruceMa-afk is now known as BruceMa [05:54] oh, I have access to germanium? ;) [05:56] slangasek: not sure about ssh etc., but you are in the ddebs group there anyway [05:57] huh [05:57] no one ever told me :) [05:58] then, good that infinity asked and I checked :) === slomo_ is now known as slomo [09:22] @pilot in === 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: Laney [09:22] * Laney gets scared [09:23] Laney, bah, I did some sponsoring yesterday, I would have left you those if I knew you were piloting today ;) [09:24] :( [09:39] ooh fun bug [09:39] https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1247607 [09:39] Ubuntu bug 1247607 in Nouveau Xorg driver "Libdrm compiled with gcc 4.8 makes card hang on resume from s2disk" [Medium,Confirmed] [09:48] does anyone experienced with launchpadlib know how to update tags in a bug? [09:48] if i try writing to the tags attribute of a bug then it gives me a strange error [09:49] is that the right way to do it, or something else? [09:49] What's your current code? [09:49] There are some bugs in this area; you can do it but you have to be a bit careful [09:49] Specifically https://bugs.launchpad.net/launchpadlib/+bug/254901 [09:49] Ubuntu bug 254901 in launchpadlib "appending tags to bug.tags is not supported properly on lp_save()" [Low,Triaged] [09:50] A form that works is: tags = bug.tags; tags.append("name-of-tag"); bug.tags = tags; bug.lp_save() [09:51] Or, as suggested in that bug, bug.tags = bug.tags + ["name-of-tag"] rather than trying to use list operations on bug.tags directly [09:51] cjwatson, mine was something like 'bug.tags = bugs.tags + ['name-of-tag']' [09:51] :/ [09:52] cjwatson, so that *should* work [09:52] cjwatson, let me fish out the error i get [09:53] *** NoBoundRepresentationError: Resource is not bound to any representation, and no media media type was specified. [09:53] media media [09:53] heh [09:54] Perhaps you could give me a way I can reproduce this. [09:54] So that I can get a proper traceback ... [09:54] cjwatson, sure i'll create a simple test case [09:55] which will of course, not trigger the bug ! [09:55] let's see [09:55] hello! anyone in the SRU team would have a look to this unapproved upload? https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=pm-utils [09:55] the bug description should be now SRU compliant [09:55] thanks! [09:59] any tech board members awake? Could someone add me to ~uds-organizers? [10:00] ev: What tech board? [10:01] infinity, the sabdfl one :p [10:01] ev, you need sabdfl until we get a TB back... [10:01] ev: (GSA or WeBops can add you, or Mark) [10:06] @pilot in === 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: henrix, Laney [10:10] cjwatson, ok so i think the problem is that i'm accessing the bug via a task [10:12] cjwatson, yep so doing bug = task.bug, then proceeding to use bug works [10:12] cjwatson, but task.bug.tags = task.bug.tags + ['tag'] doesn't [10:12] problem 'solved' [10:13] Yeah, I can believe that. lazr.restfulclient is odd [10:13] yeap [10:23] doko_: Is there any reason python-setuptools depends on python rather than python:any (and similarly python3-setuptools), or is it just an oversight? I see it overrides the standard substvar generation === freeflying is now known as freeflying_away [10:47] Laney: I'm going to do 5 sponsors as dholbach asked, mind if I look at the libpng, lighthttp, spacefm, sks, libxvmc merges? [10:47] Laney: (don't want to step on your toes if you are already at them) [10:48] henrix: ^ question for you, too [10:48] pitti: go for it [10:49] So who isn't asking the touched-it-last person about merges, then? [10:49] $ grep-merges cjwatson | grep lighttpd [10:49] lighttpd Colin Watson [10:49] It was me that asked btw, not dholbach [10:49] I was just channeling him [10:49] :P [10:50] Frankly this kind of thing is why I'm increasingly demotivated to sponsor [10:51] some "Mattia Rizzolo" -- cjwatson, do you want to handle that one? (didn't look at it yet, just listed the first 5 merges I saw) [10:51] cjwatson, it's not obvious to most contributors that merges are not "free to grab" I think :/ [10:51] Sponsoring merges is twice as hard as doing them [10:51] So not really [10:52] seb128: Shame nobody reads, apparently ... [10:52] cjwatson: I meant, should I reject and say "cjwatson wants to do it", or review/upload it? [10:52] I mean, it's the first bullet point on the MoM output pages [10:53] pitti: ack, thanks. i can do kernel only btw... [10:53] pitti: Go ahead and review/upload if you want, I guess [10:53] As it happens I hadn't finished working on that [10:54] Please be careful though, IIRC that isn't an entirely trivial merge and a naive merger could easily accidentally drop important bits [10:54] *nod* [11:02] * infinity is pretty sick of this whole "stealing merges are a good way for people to contribute" thing too. === freeflying_away is now known as freeflying [11:03] xnox: someone did the sks merge (bug 1247908), any objection as the TIL? [11:03] bug 1247908 in sks (Ubuntu) "Merge sks 1.1.4-2 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1247908 [11:03] Well, "stealing" is a silly word to use there, but. As has been pointed out on many occasions, merges come in 2 flavours: 1) So simple that it's faster to do the merge yourself than to properly review and sponsor someone's patch to do one, or 2) So complex that you have to do the merge yourself anyway just to verify that the person you're sponsoring did it right by comparing your work. [11:03] well, I don't mind much for the "fly-by" fixes that I do to random universe packages, but I would mind merging "my" packages without asking me [11:04] Oops, didn't notice you said libpng in your list [11:04] pitti: Not convinced that most people who don't personally know you make that distinction. :P [11:04] pitti:please steal. I only had a no-change rebuild. Last "TIL with changes" was LoganCloud though. [11:05] infinity: yeah, that's the problem :) (and that's why I go over all my merges at the beginning of the cycle usuallY) [11:05] xnox: You told caribou to take libpng but it already had a merge branch up for sponsoring [11:05] the ones that are left over in main.html are the ones where the Debian updates don't bring anything substantial [11:05] Laney: yeah, I sent an email to the previous dev who merged it [11:05] Laney: turns out he had done the work already [11:05] xnox: ah sorry, https://merges.ubuntu.com/universe.html thinks you were [11:05] Laney: /o\ damn. sorry, caribou. [11:06] xnox: nm [11:06] xnox: hah, you are :) (No change rebuild against db 5.3.) [11:06] xnox: I'll do another one later to get more experience [11:06] pitti: yeah, not sure how to version no-change rebuilds on top of Xubuntu1, without "stealing" TIL =) [11:07] xnox: You don't, you just get to end up owning half the archive (and be very motivated to push things back to Debian) [11:07] xnox: I read that as "you don't care", I'll review/merge [11:08] infinity: or, in this case, teach LP to do binNMUs? :-) [11:08] xnox, https://code.launchpad.net/~ankitbko/ubuntu/saucy/eject/fix-for-795239/+merge/173335 ... no reply on the debian side, do you think it would make sense to sponsor it (were you happy with the changes?) [11:08] infinity: i like doko's hands off approach =) upload -defaults bump and wait for archive to "naturally" migrate. [11:08] infinity: all we need is binNMUs.... [11:09] * infinity is still very binNMU-averse... [11:09] xnox: I have a sneaking suspicion doko's "pull db-defaults from experimental" thing is about to backfire when they upload 5.3.x (without an epoch) to unstable, and we get to whine and ask them to add the epoch back. [11:09] Just wait for it. [11:11] seb128: yeap, go ahead. [11:11] xnox, thanks === wccanary is now known as wcchandler [11:13] infinity: well, debian's maintainer is also thinking to request db6.0 removal from the archive. [11:15] xnox: And rightfully so. [11:27] seb128, infinity: thanks! [11:32] Laney: apache-log4j1.2 and xmpi as well, while I'm at it? === _salem is now known as salem_ [11:40] pitti: sure thing [11:40] Laney: ack (I'm using the bug assignment you suggested in the mail) [11:53] Laney: ok, all merges on sponsoring page done [11:53] \o/ [11:55] pitti: thanks for helping out on that === glebihan_ is now known as glebihan [11:55] 85, looking a bit better already [11:55] Laney: you called to the flags :) [12:03] infinity, cjwatson, pitti, others: do we have a means of extracting coverity data, code coverage, and test results inside packages built in a PPA (from dep8 tests)? Could we (ab)use binarypkgmangler for such a task? [12:04] we're trying to be good citizens of Launchpad in the new CI Airline architecture, but this is one area where we've seemingly needed pbuilder hooks === MacSlow is now known as MacSlow|lunch === Wellark_ is now known as Wellark [12:16] Laney: FYI, I did contact the previous owner who had done the work but left the "please take" comment on merge.ubuntu.com [12:17] Laney: timezone did the rest; I got his reply while I was gone [12:17] caribou: fair enough [12:17] Still was good experience, I hope [12:20] Laney: it was; I'll try some other one later === stokachu_ is now known as stokachu === tjaalton_ is now known as tjaalton === iahmad is now known as iahmad|afk [12:46] can I close launchpad bugs in packages uploaded to debian? [12:46] when synced back [12:46] yes, that works [12:48] found an awesome undefined behavior bug, struct->member++ = func(struct); will func() see old or new struct->member? :P [12:48] oops [12:48] *struct->member++ = func(struct); === kfunk_ is now known as kfunk [12:58] @pilot out === 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: henrix [12:59] ev: not pkgbinarymangler, as that runs too late; AFAIK you need to change the ./configure/CFLAG arguments, don't you? [13:00] ev: so it might be a modified dpkg which supplies these extra CFLAGS by default, or something like that [13:01] ev: I don't know whether it's just CFLAGS or whether the build system needs to support gcov/lcov in other ways; so far I've just used the gnome-common macros [13:04] yesterday I worked on fixing the FTBS on the crash package [13:05] the fix got implemented in the debian package [13:05] which had the same FTBS [13:06] So now the package that builds correctly is 7.0.3-2 but we carry 7.0.1-2 in the archive [13:06] will the most current crash package be eventually picked up from Debian ? [13:06] pitti, took the liberty of pushing some pending changes to apport branch for your next upload for trusty [13:07] or is there something to be done for this to happen ? [13:07] pitti, pulling up the fixes we did for precise and will be needed in 14.04 [13:08] apw: ah, thank you [13:08] caribou: yes, we auto-sync daily [13:09] pitti: then any reason why crash is at 7.0.1-2 in our archive and 7.0.3-2 in debian's ? [13:09] crash | 6.1.6-1ubuntu2 | trusty | source, amd64, armhf, i386, powerpc [13:09] pitti: 7.0.2-1 got uploaded to debian/unstable on 10-30-2013 [13:10] caribou: because it has ubuntu modifications, so it needs a merge [13:10] pitti: yeah, this is because 7.0.1-2 fails to build in -proposed [13:10] caribou: or someone needs to check that the ubuntu modifications are obsolete and can be synced [13:10] crash | 7.0.2-1ubuntu1 | trusty-proposed | source, amd64, armhf, powerpc [13:10] caribou: still, ubuntu modifications [13:11] pitti: ah, yes, the autopkgtest [13:11] caribou: and the aarch64/armhf/autopkgtest changes are not in Debian, so need merge [13:11] pitti: so what would you suggest : merge 7.0.3-2 or backport the FTBS fix ? [13:12] caribou: usually merging [13:13] pitti: ok, I'll take care of it [13:16] cjwatson: umh... I think I have to make my esce [13:17] Excuse... [13:20] I choose to don't ask you because you made a very simple upload and I thought you don't have particular knowledge on the package.... I went wrong. [13:20] pitti ^ (FYI) [13:22] pitti: btw, wouldn't it be simpler to get the ubuntu specific modifications in the debian package if possible ? [13:22] caribou: yes, absolutely [13:22] caribou: whoever did these changes should usually file a Debian bug with the patch [13:22] pitti: ok, I'll check with Troy === MacSlow|lunch is now known as MacSlow [13:49] pitti: sorry, I'm not sure I follow. How can we provide a modified dpkg to a PPA? If you upload dpkg to a PPA does it automatically pick up and use that version (if so, very clever). Does pkgbinarymangler really run too late for extracting out the coverage, coverity, and test case artifacts? [13:50] It does [13:50] Since the PPA itself is in sources.list for any builds to that PPA, and the builder upgrades its chroot at the start of each build [13:51] pkgbinarymangler could certainly be hacked to extract artifacts, provided that something has arranged to generate them in the first place ... [13:51] (dpkg seems a bit low-level for this though, and that would be an utter pain to maintain) [13:52] You could divert dpkg-buildflags, as long as you only care about packages that use it (we could reasonably mandate that for things we own) [13:52] Most of our stuff probably uses it already by way of dh9 [13:53] mapreri: Thanks. It's a good idea to check anyway; it's not so much about whether the person who touched it last has specific knowledge, it's because by default they're the person responsible for the merge and if you steal it from them without asking then there's a risk of duplicated work. In fact I had already started on the merge, though hadn't got very far yet. [13:53] @pilot out === 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: [13:57] ev: right, I actually meant dpkg-buildflags (I thought that was in dpkg) [14:00] pitti: It's in dpkg-dev, yes, but it would be quite a bit of ongoing cost to do that by uploading a modified dpkg - would have to keep merging [14:00] Should be easy enough to divert if that's what's needed - call the underlying one and tweak [14:00] right === Guest32887 is now known as wedgwood [14:07] cjwatson: you right.... Sorry again. [14:08] np [14:12] well the problem then becomes how do you make the package doing the diverting of dpkg-buildflags a requirement for all the packages in the PPA without explicitly asking for it in their control files [14:12] at least as I see it [14:15] ev: That's not a problem if it's one of the things that's already preinstalled in the chroot; pkgbinarymangler would qualify [14:19] cjwatson: I thought while pkgbinarymangler was determined to be a good target for extracting the artifacts, it ran too late to divert dpkg-buildflags? Or did I misunderstand what you said above? [14:25] ev: it currently only diverts dpkg-deb, but it could additionally divert dpkg-buildflags [14:29] pitti: ohh. So if I understand correctly: given a PPA that we want to extract gcov data from, we upload a fork of pkgbinarymangler that diverts dpkg-buildflags to include the gcov flags and also splits out the coverage data into a "-coverage" package? [14:33] ev: or upload that mangler to ubuntu, and make it check something in the PPA to see whether you want cov enabled [14:36] ev: of course the first tests should actually happen with a forked pacakge in a PPA, yes [14:43] mhall119, hey, you probably know but checking ... are the hours on summit.ubuntu.com UTC ones? (e.g are sessions from 14utc to 20utc)? === Maple__ is now known as Guest23765 === slomo_ is now known as slomo [14:51] seb128: yes [14:51] mhall119, thanks === Guest23765 is now known as Mapley [14:55] Mirv: do you have anything against /me uploading a qtsensors merge with Debian NEW queue? I need the renamed -dev package for my PyQt5 sync. [15:08] mitya57: it sounds ok (it's a switch from git snapshot to released version with not too many commits in between), but can you check qtubuntu-sensors continues to build against it? [15:09] caribou: stud uploads - you can't upload the same version to multiple series like that [15:09] * mitya57 checks [15:09] caribou: 2/3 of them will fail [15:10] cjwatson: i'll fix that. do they need to be rejected first? [15:10] cjwatson: I don't understand, I tested each one of them [15:10] arges: Doing so [15:10] cjwatson: thanks [15:10] cjwatson, should work with :any. the substvars overwrite is only there to build it for all available versions before they are supported [15:11] cjwatson: I'm assuming this is the correct way to version for same version in two releases: lahttps://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging [15:11] caribou: two out of three of the uploads would have failed because you can't have the same version with different contents [15:11] arges: exactly, just mentioned that in the reject message [15:11] cjwatson: oh, I see [15:11] cjwatson: hey, I asked you this in #ubuntu-touch. in case you didn't see: [15:11] 06:08 < jdstrand> cjwatson: hi! if I do 'pkcon install-local ' is 'pkcon remove ' expected to work now [15:11] 06:11 < jdstrand> cjwatson: click list tells me it is installed, but both 'pkcon remove ' and 'pkcon remove ' fail with: [15:12] 06:11 < jdstrand> Command failed: This tool could not find the installed package: could not find com.example.am-i-confined [15:12] jdstrand: That's not a syntax pkcon accepts [15:12] jdstrand: https://lists.launchpad.net/ubuntu-appstore-developers/msg00553.html shows the syntax in the last bullet point [15:12] ah, I see [15:13] Mirv: copied to my test ppa (to simulate a clean environment), will now prepare a merge in Bzr and upload it tomorrow(?) if the build succeeds [15:13] cjwatson: thanks (I tried looking at pkcon help, but that didn't actually help) [15:13] no, quite ... but I didn't write pkcon, I'm just attaching to it because it's better than doing my own dbus interface from scratch :) [15:13] * jdstrand nods [15:14] doko_: ok, do you want me to upload for that or will you fix it in Debian? [15:14] I see we're in sync at the moment, so maybe better the latter ... [15:14] mitya57: ok, sounds like a plan. thanks! [15:14] need to merge with setuptools, barry's already pestering me [15:15] well, I'm just trying to unblock people who are trying to do cross-building [15:15] ok [15:16] but then, you almost always need to make cross-buildable python modules be aware of the cross build [15:17] admittedly it's been *ages* since I used VNC to an Ubuntu desktop, but I'm trying to do so right now, to a 13.10 desktop, over gigabit LAN, and it's unusably slow... is unity3d to blame? [15:17] doko_: hm, the one I'm looking at is an odd case, it builds some other arch-dependent stuff but it looks like all its Python module handling is arch-indep [15:17] doko_: (ubuntu-keyboard) [15:18] sure, go ahead [15:19] ok, thanks [15:58] jibel: what's the current status of cherrypy3? last thing I remember is that the py3 package is broken? [15:58] jibel: (it doesn't have any test output, just "exit with status 70") [15:59] oh, no zul [15:59] pitti, I notified zul that the package must be fixed [15:59] pitti, it doesn't install the deamon to the right location and python3 is half-done [16:00] ah [16:00] jibel: thanks [16:12] hi cjwatson, on fat click packages, are all the binaries supposed to be installed on disk? [16:12] yes [16:13] tedg, ^ [16:13] cjwatson, Do they have specific directories based on arch? [16:13] that's up to the SDK / app developer conventions [16:13] cjwatson, Or is that for the app to decide? [16:13] cjwatson, we briefly discussed t'other day, and I understood that fat packages are arch "multi", and have a lib/$arch/qml, lib/$arch/lib etc folder (naming to be decided), and the app runner takes care of putting lib/$arch/lib on LD_LIBRARY_PATH before running the app, or something similar? [16:13] we should have a convention and common dispatcher code to handle it; we don't yet [16:13] I think the question that aquarius had there was how do I handle that if I can't have a shell script. [16:14] I suggest lib// [16:14] tedg: we need common code in the platform for this [16:14] aquarius: something along those lines [16:14] cjwatson, K, do we have someone with a work item to do that? [16:14] I think we want lib/$multiarchtriplet/thingy because there are different thingies -- qml components to go on QML2_IMPORT_PATH, libraries for LD_LIBRARY_PATH, etc [16:14] tedg: I don't think so yet, haven't managed to con anyone into doing it [16:14] * tedg says "not it!" ;-) [16:15] what I'm not sure about is... how does it work if your main executable is a binary? [16:15] aquarius: I'd prefer lib/$triplet, qml/$triplet, etc. [16:15] aquarius: bin/$triplet? [16:15] I mean you still need a dispatcher anyway ... [16:16] so my .desktop file contains Exec=binaryname, and the dispatcher says "aha! this looks like a fat package to me, so I shall look for and execute bin/$triplet/binaryname ?" [16:16] cjwatson, The only thing I'm curious about is how much we want to put in generic dispatcher vs. app specific. For instance, some apps may not have QML. [16:16] aquarius: well, we already mangle desktop files, we could mangle differently [16:16] or maybe it just adds bin/$triplet to $PATH, qml/$triplet to QML2_IMPORT_PATHS, lib/$triplet to LD_LIBRARY_PATH, and then just execs as normal? [16:16] tedg: I'm honestly not sure and don't feel I have enough knowledge about what people tend to do in apps to implement this [16:16] aquarius, I imagine we'll say "fat package, set PATH to include that dir" [16:17] Yeah, I think just setting the env is best. [16:17] all I can do is lay down some general guidelines for what I think will work well with click and what I think is suitably cognate with the rest of the system [16:17] And we already do that for PATH [16:17] and hope that if I repeat it enough times then somebody will implement something sensible and people will stop asking me about it :) [16:17] * tedg knows what cjwatson wants for Christmas ;-) [16:19] If it's just adding those env vars, I think upstart-app-launch should do it for that case. And jdstrand's aa-exec-click would need to as well. [16:19] lib/$triplet/bin is actually more used location by many tools out there. [16:20] I personally don't care abou tthe names, as long as there are some chosen :) [16:20] tedg, it's a tiny bit more complex than that because you have to *get* the arch triplet from somewhere [16:20] and dpkg-architecture is not in the image [16:20] aquarius, I can get it at compile time. [16:21] e [16:21] er [16:21] that works? [16:21] tedg: it's a fat one, one has multiple. [16:21] xnox, Compile time of upstart-app-launch [16:21] tedg: i can totally execute armhf binary on my amd64 desktop. [16:21] tedg: and i386. [16:21] xnox, were the libnih issues solved, or are there any more? [16:22] xnox, I think he means that upstart-app-launch doesn't ask at runtime "which arch am I on"... we compile the arch triplet into upstart-app-launch at compile time [16:22] xnox, Sure, you can. My dad can't :-) [16:22] yeah, as long as the dispatcher is arch-dependent this is fine [16:22] xnox: then execute by hand; that is out of scope [16:23] upstart-app-launch is currently a real executable rather than a script [16:23] We could put it as a var in the upstart job though. Then it could be overriden easily enough. [16:23] doko_: i solved it by writting more simplistic code. I will dig into it at one point in the future - cause it seemed like for that code it, it was doing something sensible on !arm - and something it cannot compile itself on arm* [16:23] which I discovered when I assumed it was a script and looked at it to see how it worked :) [16:24] probably good for it to be a real executable since it's fairly performance-sensitive [16:24] aquarius, It's a very special scripting language defined by Intel ;-) [16:24] doko_: but i want something smaller than 12k LOC & 40MB big *.i / *.s files for you =) [16:24] tedg: I hope it's not defined by Intel on the phone :-) [16:24] ha! [16:24] xnox, is this in libnih multi-k line's test functions? === sraue_ is now known as sraue [16:27] doko_: yeah. which use #define magic, to actually generate unrolled massive loops, from that multi-k line's test functions, into even bigger ones. I've dared to touch the magic, and it was too much for arm to handle. [16:30] I never understood why those test functions weren't just split up === and`_ is now known as and` [16:33] cjwatson: yeah, it's boggling to me. but libnih is still keybuk upstream, so i don't want to modify it too much. [16:34] cjwatson: but then again, i do plenty of work on it lately. [16:34] (spare time stuff) [16:42] doko_: so, regarding TLS and bionic [16:43] we've done some evil, evil things in the thread handling... effectively making pthread mutexes no-ops on the bionic side, to account for the fact that the TLS struct on glibc is smaller than it is in bionic [16:44] doko_: do you think it would be practical to rebuild glibc with a padded struct? or would this be horribly abi breking? [16:44] breaking [16:44] and maybe I should be asking infinity this [16:44] infinity: ^^ [16:45] slangasek, ugh, should I know about that? [16:45] maybe? you know things ;) [16:45] this is ultimately the "reasons Nexus 7 is painful" thread, right? [16:45] cjwatson: yes - but I'm now wondering whether it's also why the emulator is failing [16:45] depending on where and how the TLS neutering was done [16:47] slangasek: hm. i thought TLS struct was smaller on bionic side, which is now fixed in kitkat (it's up to 128bits now) [16:47] slangasek: not the other way around. [16:48] cjwatson: hm, was that thread somewhere I can see? [16:48] xnox: no, I'm told it's larger on bionic, which is why when it's allocated by glibc (as it would be in the case of any Ubuntu apps), you get segfaults [16:49] ok. [16:51] ah, yeah. https://code.google.com/p/android/issues/detail?id=43040 [16:52] no that's something else. anyway. === doko_ is now known as doko === Nisstyre-laptop is now known as nisstyre [17:43] xnox: "thread" = "pub conversation" [17:44] at least in my case [17:44] ok [17:44] pub local storage [17:45] hi - just curious, anyone know offhand why the re2 package hasn't gotten past debian experimental? [17:45] (I ask bc lmctfy - google's cgroup manager - depends on it) [17:45] the maintainer is probably the best person to answer that` [17:46] however: "ROM; NPOASR; moved to experimental, pending upstream ABI stability" [17:46] feh [17:46] where does that info come from? [17:47] I went to http://packages.qa.debian.org/r/re2.html and clicked on Removed 0+hg23+dfsg-1 from unstable [17:47] Appears to have dropped the library package for that reason too [17:49] oh, iw as looking at http://packages.qa.debian.org/r/re2.html but didn't see that history, thx [17:49] that doesn't bode well for me [17:51] tumbleweed is your man === bfiller is now known as bfiller_afk [18:20] rsalveti: can you tell me where I should look to see any patches to the android tree regarding the pthreads hybris hack-around? Or were the changes all handled in libhybris itself? [18:22] slangasek: they are mostly in hybris, there's only one in android that changes the tsl slot, but that's only used when qemu is using the host gl [18:22] slangasek: we're actively debugging it as we speak, so hopefully we should know better soon [18:23] translator can't find the qemu pipe and sw emulation is busted, debugging now why [18:24] ok [19:28] slangasek: I'm not positive that the TLS struct is actually part of libc's advertised ABI, but even if not, mangling it sounds like the sort of thing that could have all sorts of undesired and hard-to-find knock-on effects. [19:34] hello. i tried upgrading to trusty via 'do-release-upgrade -d' - however I am getting problems because the package sources seem to be unavailable at the moment... is this known? [19:49] dkessel: same for me, but I cannot remember the exact error message [19:49] anyone got a script for doing a mass-give-back in a PPA? [19:49] brainwash, i think i got it. disabling the extras package sources worked... downloading packages now [19:54] oh, that was simple [19:54] dkessel: yeah, you might be right, it was related to the extras repository I think [19:55] blah... for b in builds: if b.can_be_retried: b.retry() === bfiller_afk is now known as bfiller [20:11] slangasek, how come you get to upload SRUs without bug reference? ;-) [20:36] seb128: Because he's a cowboy. [20:41] infinity, he's from Portland, how comboy is that?! [20:43] people in portland own -chickens-! [20:43] sarnold: But do they ride them? [20:43] infinity: I hope not :) [20:44] who knows, slangasek might? [20:52] Laney, hallyn_: yeah, I've just had a request for it in unstable. I guess I need to start the ABI rollercoaster (at least development has slowed down now) [20:53] tumbleweed: oh yippe, that's good for me :) [20:54] tumbleweed: otherwise i'd have tolook at the licensing to see about simply including a snapshot in with the lmctfy source [21:10] tumbleweed: what kind of timetable do you think there'll be for that ? [21:10] i.e. can it possibly hit in time to make trusty before FFE? [21:11] hallyn_: hard to say. I haven't been very active recently. But yes, that seems reasonable [21:12] it's just resurrecting some work I've already done, and tidying it up a bit [21:12] just need to do it [21:14] tumbleweed: excellent, thanks (if you find time to do it :) === salem_ is now known as _salem [21:21] tumbleweed: so did you ever write any programs linking aginst the liblmctfy.so ? [22:27] seb128: shim was special, because it was a binary copy; shim-signed should've been done with proper bug refs, but no one called me on it until it was too late. :P The next one will be better. [22:27] these were hardware enablement SRUs, effectively [22:31] slangasek, k, it just looks weird in the sru report page, the sru team has been good about enforcing the requirement to have a bug linked with update otherwise ;-) [22:32] seb128: there was a global SRU bug with a test case for all of them, it just couldn't be included retroactively in the shim changelog [22:32] so this covered shim, sbsigntool, shim-signed, gnu-efi [22:32] k [22:32] in the future, we should only need shim + shim-signed; binary copies (again) for shim, and shim-signed for the SRU tracking === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [22:34] also, there seem to be several other packages in the SRU queue with no bug refs, heh. (plasma-nm? xserver-xorg-video-savage?) === tkamppeter_ is now known as tkamppeter [22:36] slangasek, those should probably be rejected [22:37] seb128: indicator-messages in quantal was yours, it unfortunately had wrong bug syntax in the changelog... do you want to fix that? [22:38] slangasek, quantal... [22:38]