| infinity | doko: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52445 | 00:01 |
|---|---|---|
| ubottu | gcc.gnu.org bug 52445 in tree-optimization "[4.6 Regression] conditional store replacement causes segfault in generated code" [Normal,Assigned] | 00:01 |
| infinity | doko: There are a few long threads around arm-linux and other lists about how that bug causes some kernel driver miscompilations. | 00:01 |
| === cpg|away is now known as cpg | ||
| infinity | Now, if only I could remember who it was who brought it to my attention a few weeks ago... | 00:02 |
| === fisted_ is now known as fisted | ||
| === Guest5764 is now known as vibhav | ||
| === vibhav is now known as Guest74795 | ||
| === Guest74795 is now known as vibhav | ||
| === vibhav is now known as Guest65373 | ||
| === Guest65373 is now known as vibhav | ||
| === vibhav is now known as Guest79079 | ||
| === Guest79079 is now known as vibhav | ||
| === vibhav is now known as Guest84459 | ||
| === Guest84459 is now known as vibhav | ||
| cjwatson | jdstrand: Disabling normal.mod doesn't make sense. That's the module that provides the menu. | 01:14 |
| cjwatson | jdstrand: You should be able to copy /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed into your environment as grubx64.efi and execute it from firmware configured to trust the Canonical key (or via shim from firmware configured to trust the Microsoft key). | 01:16 |
| cjwatson | jdstrand: Or, if you already have an installed system that you're booting in OVMF rather than trying to bootstrap one from scratch, install the grub-efi-amd64-signed package and run 'grub-install --uefi-secure-boot'. | 01:18 |
| cjwatson | jdstrand: (I believe I have a work item to make that the default even on non-SB systems, with a few associated tweaks) | 01:18 |
| cjwatson | jdstrand: And rereading, it sounds as though you probably want the latter approach. | 01:19 |
| cjwatson | jdstrand: A message refusing to load normal.mod indicates that you've tried to sign a minimal GRUB image (perhaps the one generated by plain grub-efi-amd64) that's expecting to load much of its brain from /boot/grub/x86_64-efi/*.mod - but GRUB insmod is forbidden in secure boot because all the boot loader code must be signed. | 01:20 |
| Shinobi | The only rdp client I can get to connect is rdesktop, none of the rdp clients I've tried in 10.10 will connect. Is there some library that I need to add or something? | 01:41 |
| Shinobi | Sorry. None of the rdp clients with GUI front ends will connect. CLI is fine. | 01:42 |
| ScottK | 10.10 is long out of support in any case. This isn't a help channel, but certainly not for old releases. | 01:44 |
| infinity | Shinobi: This isn't a support channel, try #ubuntu. Also, 10.10 is an EOL product, you might want to try 12.04 (or later) before asking for help. | 01:44 |
| infinity | ScottK: Jinx. | 01:44 |
| ScottK | ;-) | 01:44 |
| Shinobi | infinity: Sorry. Nobody seemed to know in Ubuntu, so I thought I'd see if someone may have known. I plan to upgrade to 12.04 tonight. | 01:46 |
| SpamapS | Shinobi: I seem to recall some serious bugs that were fixed somewhat recently in one of the other rdp clients | 01:56 |
| === Tonio_ is now known as Tonio_aw | ||
| jdstrand | cjwatson: thanks-- let me try grub-install --uefi-secure-boot. I that sounds like the missing piece-- but you gave a lot of info I can play with. much appreciated | 02:54 |
| jdstrand | cjwatson: that was exactly it. perfect-o! | 03:08 |
| jdstrand | cjwatson: huge thanks. I'll fiddle with the other options later as well (ie, Canonical key, shim, etc) | 03:09 |
| === attente is now known as attente_zzz | ||
| pitti | Good morning | 05:37 |
| ion | hi | 05:39 |
| pitti | infinity: do you plan to do an initramfs-tools merge soon, or want me to ignore the warning in u-d-common for now? | 06:22 |
| infinity | pitti: I plan to merge tonight or (more realistically) first thing in the morning. That eglibc upload I just did a couple of hours ago was occupying me. | 06:25 |
| pitti | infinity: ah cool, thanks! | 06:26 |
| infinity | doko_: Ugh. Shouldn't there be a /usr/include/i686-linux-gnu to match the cross target, rather than i386-linux-gnu to match the Debian arch (or maybe one a symlink to the other)? | 06:43 |
| infinity | doko_: Or maybe I get to special-case i?86 in glibc's configure and it won't be upstreamable. | 06:44 |
| * infinity ponders. | 06:45 | |
| infinity | doko_: Yeah, all the stuff that used to be in /usr/include/c++/4.7/`g++ -dumpmachine` is now in /usr/include/$DEB_HOST_MULTIARCH/c++/4.7 which is subtly different on i386. | 06:48 |
| infinity | doko_: Oh, I guess I can conditionally use g++ -print-multiarch and still have this upstreamable. | 06:52 |
| * infinity kicks himself for only testing on amd64 and powerpc. | 06:52 | |
| infinity | pitti: You wake up too early. It always makes me thing (very incorrectly) that I can start talking to other Germans and expect a response. :P | 07:21 |
| infinity | s/thing/think/ | 07:21 |
| pitti | hah, hardly | 07:21 |
| pitti | infinity: I usually start between 5:30 and 6:30 these days | 07:21 |
| infinity | pitti: I often stop around then... | 07:22 |
| infinity | So, now that armel's out of the archive, can we get rid of i386 too? | 07:23 |
| infinity | I'm sick of its quirks. | 07:23 |
| dholbach | good morning | 07:47 |
| pitti | hey dholbach | 07:57 |
| dholbach | hi pitti | 07:57 |
| === smb` is now known as smb | ||
| dholbach | @pilot in | 08:13 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach | ||
| infinity | doko_: Alright, fix uploaded for glibc/i386, you can ignore my whining about dumpmachine versus multiarch. | 08:21 |
| didrocks | dholbach: hey, FYI, I'll have to swap my pilot timing for Thu/Fri I guess | 08:21 |
| dholbach | didrocks, sure - I'll leave that to you - I split up my patch pilot session yesterday/today because there was no other way | 08:22 |
| didrocks | dholbach: ok ;) | 08:22 |
| pitti | Daviey: are you aware of the maas autopkgtest failure? It's reproducible locally as well (https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-maas/lastFailedBuild/ARCH=amd64,label=albali/) | 08:23 |
| pitti | Daviey: looks like a dependency or component mismatch issue | 08:23 |
| === agateau_ is now known as agateau | ||
| dholbach | didrocks, do you know if there's plans to get the new libnice from Debian experimental? it seems to be needed for bug 1078991 | 08:25 |
| ubottu | Launchpad bug 1078991 in farstream (Ubuntu) "Sync farstream-0.2 0.2.2-1 (universe) from Debian experimental (main)" [Wishlist,Triaged] https://launchpad.net/bugs/1078991 | 08:25 |
| infinity | Setting up tgt (1:1.0.17-1ubuntu3) ... | 08:26 |
| infinity | start: Job failed to start | 08:26 |
| infinity | invoke-rc.d: initscript tgt, action "start" failed. | 08:26 |
| infinity | dpkg: error processing tgt (--configure): | 08:26 |
| infinity | subprocess installed post-installation script returned error exit status 1 | 08:26 |
| infinity | pitti / Daviey : That's your bug ^^ | 08:26 |
| didrocks | dholbach: I didn't hear about any blocker on that, it seems it didn't change its soname, and have gstreamer 0.10 and 1.0 bindings | 08:27 |
| didrocks | dholbach: so if you want to test/sync… ;) | 08:27 |
| dholbach | why did Robert file a sync request for this and not just sync it? | 08:28 |
| infinity | Maybe he still lives in the past and no one's told him he can sync things? | 08:28 |
| Daviey | pitti: i am now :).. thanks. We'll get that fixed up today. | 08:29 |
| didrocks | dholbach: maybe he's not aware we can sync directly | 08:29 |
| infinity | Curious, tgt starts here just fine. | 08:30 |
| pitti | Daviey: great, thanks; I start prodding people now as soon this will become critical path, and you couldn't land uploads any more when their tests fail | 08:33 |
| pitti | I got a lot of them fixed, but I can't keep up with them all | 08:33 |
| infinity | pitti: Curiously, I can't make it fail locally. | 08:33 |
| infinity | (Not that I care terribly, cause I should be napping, but I figured I'd give it a try) | 08:33 |
| pitti | "run-adt-test -s maas" fails with the same reason | 08:34 |
| infinity | pitti: Sure, I was just installing the package that failed to start, rather than running the full test environment. | 08:34 |
| infinity | pitti: Perhaps it fails to start because the daemon relies on a recent kernel? | 08:35 |
| Daviey | pitti: well, fixing it directly in the archive wouldn't last.. as this package is strictly managed via bzr. | 08:35 |
| pitti | infinity: the kernel in the VM is just as recent as raring is | 08:36 |
| infinity | Was just a thought, since I can't make it die in a quick test here. | 08:38 |
| pitti | mvo: do you happen to understand the metaclass magic in aptdaemon in https://code.launchpad.net/~pitti/aptdaemon/pygobject-fixes/+merge/134942 ? | 08:41 |
| pitti | mvo: I wondered if it can/should be fixed, or just dropped completely for simplicity | 08:41 |
| pitti | infinity, Daviey: "sudo apt-get install tgt" in a VM reproduces it well | 08:43 |
| pitti | I'll file a bug with the details | 08:43 |
| infinity | pitti: Right, it's the "in a VM" bit I'm missing here. :P | 08:43 |
| infinity | pitti: Worked fine in a chroot on bare metal, which is curious. | 08:43 |
| pitti | Daviey: I filed bug 1081495 with the output of tgtd | 08:46 |
| ubottu | Launchpad bug 1081495 in tgt (Ubuntu) "E: Sub-process /usr/bin/dpkg returned an error code (1)" [Undecided,New] https://launchpad.net/bugs/1081495 | 08:46 |
| infinity | pitti: Oh, out of curiosity, do you have autopkgtests for eglibc, binutils, and gcc? | 08:46 |
| pitti | infinity: no, we don't | 08:46 |
| pitti | infinity: well, the new eglibc triggered all autopkgtests that we have of course | 08:46 |
| pitti | so we do rdepends check | 08:47 |
| pitti | but not for eglibc itself | 08:47 |
| infinity | pitti: I'd suggest (since things like "try to rebuild the whole archive lololol" would be pointless) they their tests should consist of each one triggering a rebuild test of the other two. | 08:47 |
| infinity | pitti: If upgrading any of those three manages to keep the testsuite of the others passing, that's a win. | 08:47 |
| pitti | infinity: i. e. the test script woudl more or less be "apt-get build-dep binutils; apt-get source -b binutils", right? | 08:48 |
| infinity | pitti: (This came up today after I just spent hours fixing a regression in glibc due to the new gcc, and the inverse happens all the time too) | 08:48 |
| infinity | pitti: Yeahp. | 08:48 |
| infinity | pitti: Oh, and linux-libc-dev (so, the linux source package) should also trigger those three to a rebuild test, same reason. | 08:49 |
| infinity | pitti: If linux-libc-dev's headers survive the GCC and glibc testsuites, they're good enough for regular users. :P | 08:49 |
| infinity | (And if they break regular users but not the toolchain, I'd humbly suggest the users are wrong) | 08:49 |
| infinity | *cough* | 08:50 |
| pitti | hehe | 08:50 |
| infinity | Definitely would have been nice to know when gcc and the kernel were uploaded (so, a couple of weeks ago) that they broke glibc, instead of finding out today while I was uploading for other reasons. | 08:52 |
| infinity | But, yeah, toolchain rdep testing needs to have some sane limits, cause I assume our resources aren't infinite (and our time certainly isn't, when we start plugging this in as a britney blocker) | 08:53 |
| pitti | so binutils seems to have a proper Vcs-Bzr:; gcc-4.7 is just apt-get source/UDD? | 08:53 |
| infinity | pitti: apt-get source is the only "proper" way to get any of them for a rebuild test... | 08:53 |
| pitti | infinity: yeah, bintuils and glibc tests are bearable, but gcc does take some time | 08:53 |
| infinity | pitti: We don't want to know if something staged in a VCS is broken, we want to know if the archive is. | 08:53 |
| pitti | infinity: no, I mean for adding the autopkgtests | 08:54 |
| pitti | these need to go into their source | 08:54 |
| infinity | pitti: Oh. These end up in the source package themselves? | 08:54 |
| pitti | yes | 08:54 |
| infinity | pitti: Right, forward the binutils and gcc ones to doko, the eglibc one to me, and the linux one to apw, then. | 08:54 |
| pitti | okay | 08:54 |
| infinity | pitti: I'd rather have a modicum of control over how often toolchains get uploaded for non-critical things. :) | 08:54 |
| pitti | yeah, I wasn't going to upload them just for that, hence I was looking for the VCSes | 08:55 |
| infinity | Righto. eglibc's VCS header is a filthy lie, I need to fix that. | 08:55 |
| infinity | And no idea about doko's. | 08:56 |
| infinity | And the kernel's isn't a lie, but you can't commit to it. :P | 08:56 |
| infinity | pitti: To cut down on the pain, we could potentially refine the tests to do something like only build a single pass of libc6 and run the tests, only build a single kernel, etc. Most of these things take so effin' long cause they build 4 times. | 08:57 |
| pitti | yeah | 08:57 |
| pitti | let's put that into a bug to keep track of the status and have a place to attach patches to | 08:58 |
| infinity | Be my guest. I'm thinking a nap at 2am might not be a bad plan. | 08:58 |
| * infinity snickers at jcm getting flooded off freenode. | 08:59 | |
| infinity | pitti: If you file a big meta bug, can you toss me the number? I suck at bugmail filtering about as much as someone who doesn't put much effort into filtering bugmail. | 09:00 |
| infinity | (I should probably fix that some day) | 09:00 |
| pitti | infinity: bug 1081500 | 09:01 |
| ubottu | Launchpad bug 1081500 in linux (Ubuntu) "Add autopkgtest for mutual rebuild-testing amongst glibc, linux-libc-dev, gcc, and binutils" [Undecided,New] https://launchpad.net/bugs/1081500 | 09:01 |
| infinity | pitti: Great. I look forward to patches that teach me all about autopkgtest by example. ;) | 09:02 |
| pitti | infinity: http://developer.ubuntu.com/packaging/html/auto-pkg-test.html : | 09:03 |
| pitti | :) | 09:03 |
| infinity | I don't accept HTML patches. | 09:03 |
| pitti | nah, I'll send a first one, and maybe a second | 09:04 |
| pitti | I expect they will look pretty much alike, except for the "only build one flavour" bit | 09:04 |
| infinity | The only one flavour bit may take some refinement. | 09:04 |
| infinity | The kernel's pretty good at it (you can call individual targets out of debian/rules), glibc might actually take some wrangling to convince it to try. | 09:05 |
| infinity | I'm happy to do that bit myself. :P | 09:05 |
| infinity | Anyhow, nap time before morning meetings. | 09:06 |
| pitti | yeah, once we enable those on armhf, any speedup will be greatly appreciated | 09:06 |
| infinity | Gah, and that override bug. | 09:07 |
| * infinity promotes kernels to main before going to bed. | 09:07 | |
| lifeless | good times | 09:07 |
| lifeless | infinity: what TZ is infintytime aligned with atm ? | 09:08 |
| pitti | lifeless: all of them :) | 09:08 |
| infinity | lifeless: I reside in MST7MDT, I'm currently awake in... Actually, close to that. It's only 2am. Not a horrible bedtime. | 09:08 |
| lifeless | pitti: I think that would get a dividebyzero error :) | 09:09 |
| === Tonio_aw is now known as Tonio_ | ||
| === Tonio_ is now known as Tonio_aw | ||
| cjwatson | jdstrand: cool | 09:43 |
| === Tonio_aw is now known as Tonio_ | ||
| infinity | cjwatson: Having to override all the kernels in raring again after britney promoted them reminded me to be annoyed by that bug. Did you have something filed for it? | 09:46 |
| infinity | cjwatson: (Still wildly confused by why this happens for proposed->release but not proposed->updates, unless britney's somehow copying differently than sru-release does...) | 09:46 |
| === Sweetsha1k is now known as Sweetshark | ||
| cjwatson | I don't think I filed one | 09:47 |
| cjwatson | I was just doing morning "oh, images failed, oh look, component-mismatches" | 09:47 |
| cjwatson | But the output suggests you beat me to it | 09:48 |
| infinity | Yeah, c-m is a lie, I already fixed. | 09:48 |
| infinity | Thankfully, you didn't notice until the publisher started. :P | 09:48 |
| infinity | That double-override-eats-binaries bug is also a lovely one. | 09:48 |
| infinity | And likely to get stumbled on a lot while this current "oops, I forget everything during migration" business is going on and people scrable to fix the release pocket. | 09:49 |
| infinity | s/scrable/scramble/ | 09:49 |
| cjwatson | Overriding twice to main doesn't count, though, since that doesn't actually produce new pubs. | 09:49 |
| infinity | Even if it was previously in universe? | 09:50 |
| * infinity is unfamiliar with that bit, and is suddenly happy he is. | 09:50 | |
| cjwatson | infinity: By the time of the second override attempt, it's now in main so doesn't get re-overridden. | 09:54 |
| cjwatson | (Sorry, I was busy trolling a phone scammer.) | 09:55 |
| didrocks | hey cjwatson, it's been 10+ minutes I tried to copy 3 components from the ubuntu-unity ppa to the archive, and it seems the first attempt failed :/ any way to see what happened? | 09:57 |
| dholbach | tkamppeter_, hello - do you think you can have a look at https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/1069324 and see if you can upload the patch? | 09:58 |
| ubottu | Launchpad bug 1069324 in hplip (Ubuntu) "diagnose_queues.py crashed with NameError in su_sudo(): global name 'utils' is not defined" [Medium,Triaged] | 09:58 |
| infinity | didrocks: If it failed, you should have gotten an email with an OOPS in it. Maybe. | 09:58 |
| didrocks | infinity: the thing is that the bot is https://launchpad.net/~ps-jenkins and it's a ML. But mmrazik isn't around to check them | 09:58 |
| infinity | There's a bot auto-copying from PPAs to the archive? | 09:59 |
| cjwatson | infinity: Yeah, didrocks and I agreed on this | 09:59 |
| infinity | Fair enough. | 09:59 |
| cjwatson | didrocks: Package name? | 09:59 |
| didrocks | cjwatson: indicator-sound, indicator-power and indicator-messages | 10:00 |
| cjwatson | "Cannot copy DDEBs to a primary archive" | 10:00 |
| didrocks | ah, so we need to ask for removing the ddebs from the ppa | 10:01 |
| cjwatson | Hmm | 10:01 |
| didrocks | (would have been useful for the autopilot crash though) | 10:01 |
| infinity | Yeah. | 10:01 |
| pitti | infinity: actually, didn't we want to enable that for the main archive? | 10:01 |
| infinity | pitti: We do, yes. Hit me up tomorrow, and we'll talk. :) | 10:01 |
| didrocks | like if autopilot crashed with a stack, we would use those ddebs to debug | 10:01 |
| cjwatson | Nothing would take care of rebuilding the ddebs for the main archive, if you remove them | 10:01 |
| infinity | didrocks: It's a devirt PPA, right? | 10:01 |
| pitti | to replace those apache servers | 10:01 |
| cjwatson | Which would mean that errors.u.c will be unable to display useful tracebacks for those packages | 10:02 |
| infinity | cjwatson: No need to rebuild them. The trick is to do the same thing the kernel PPA does. | 10:02 |
| didrocks | infinity: yeah, it's building on all archs | 10:02 |
| pitti | infinity: I thought you wanted to go to sleep an hour ago :) | 10:02 |
| infinity | cjwatson: Which is to act like the primary archive. | 10:02 |
| didrocks | cjwatson: right, but the tests are runned before copying to the main archive, so being able to debug there was useful | 10:02 |
| infinity | cjwatson: IOW, not have the flag on that publishes ddebs in .changes | 10:02 |
| mitya57 | dholbach, I've already asked him to do that :) | 10:02 |
| dholbach | mitya57, ok, perfect :) | 10:02 |
| cjwatson | infinity: And they then get picked up for ddebs.u.c? | 10:03 |
| cjwatson | Presumably as long as versions never clash. | 10:03 |
| infinity | cjwatson: Sure, they're all slammed in public_html. | 10:03 |
| infinity | Right. | 10:03 |
| infinity | The real solution is some JFDIing by pitti and I to switch this all over. | 10:03 |
| didrocks | how does the kernel do to have ddebs? | 10:03 |
| didrocks | as it's not rebuilt | 10:03 |
| infinity | And then scour the world for PPAs that do weird things and make them do what didrocks's does. | 10:03 |
| infinity | didrocks: The kernel's PPA acts just like the primary archive. It builds ddebs, but doesn't upload them. | 10:04 |
| infinity | didrocks: And they get scraped off the buildds by pitti's evil script, the same as they are for the primary archive. | 10:04 |
| pitti | cjwatson: we'd eventually like to stop having to stage them on the buildds for 7 days and those rather unreliable apache servers to publish them; I'd much rather pull them from the librarian | 10:04 |
| didrocks | infinity: ah, ok, so evil hack :) | 10:04 |
| infinity | But yes, we should fix all of this hackish crap. | 10:04 |
| cjwatson | didrocks: In infinity's proposal, you'd debug by getting the ddebs from ddebs.ubuntu.com instead. | 10:04 |
| infinity | My proposal is the "right way" to do things today. | 10:05 |
| infinity | It may not be in a few days, if pitti and I get some ducks in a row. | 10:05 |
| pitti | well, ddebs.u.c. would continue to only publish Ubuntu ddebs; but copying packages from PPA into the ubuntu archive shoudl copy the ddebs along? | 10:05 |
| infinity | (The right way to do things if your PPA is essentially an extension of the primary archive, like kernel and security are) | 10:05 |
| cjwatson | pitti: In some new world order that might be possible, sure. I'm aware of the plans. | 10:06 |
| infinity | pitti: Yeah, in the new world order, ddebs would be attached to build records, and copying with binaries will get the ddebs too. | 10:06 |
| dholbach | @pilot out | 10:06 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| infinity | pitti: That part looks like it might need an LP patch, but likely just removing a check. | 10:06 |
| infinity | (We probably also need to test and make sure that the publisher doesn't try to vomit ddebs on disk when they show up in the primary archive) | 10:07 |
| infinity | I guess I might need to dust off a local LP instance tomorrow, since I don't have dogfood to play with. :/ | 10:07 |
| infinity | Aaaanyhow. pitti's right, I'm supposed to be asleep. | 10:08 |
| didrocks | how can I help to make things happen? :) | 10:08 |
| infinity | didrocks: Depends on which things. | 10:08 |
| pitti | sing "soft kitty" to infinity, so that he gets to sleep, and is awake tomorrow? :-) | 10:08 |
| didrocks | pitti: can do that :) | 10:09 |
| * infinity might not appreciate this so much. | 10:09 | |
| didrocks | infinity: I'm not really familiar with the whole copy to ddeb.u.c process, but if you think I can be of any help | 10:09 |
| cjwatson | infinity: Better to construct a unit test that exercises it, since you'll want one of those to go with any change anyway. | 10:09 |
| === tkamppeter_ is now known as tkamppeter | ||
| infinity | cjwatson: Sure, this doesn't preclude the value of doing actual end-to-end testing to make sure it does what you think you claim the unit test is testing. | 10:10 |
| cjwatson | didrocks: For the meantime, you could copy without binaries. I know that strictly that partially invalidates your testing, but confirming that the source builds sensible binaries in autopilot is still a lot better than nothing. | 10:10 |
| didrocks | cjwatson: well, if it's just a question of days, I think I'll better to wait | 10:11 |
| infinity | Or, he could ask webops to twiddle his PPA to make it look "like the kernel team's". | 10:11 |
| tkamppeter | dholbach, I can do so. Simply for Raring or as Quantal SRU? | 10:11 |
| dholbach | mitya57, ^? | 10:11 |
| infinity | But if you do that, you need to trat it like the primary archive, never reuse version numbers (even if you delete something), etc. | 10:11 |
| infinity | didrocks: It could be more than days to get this all tested and sane. I'm not about to commit. | 10:11 |
| infinity | didrocks: But it's seconds to make your PPA behave differently. | 10:12 |
| didrocks | infinity: I already do that, depends on the timing for the "proper fix" in your mind | 10:12 |
| didrocks | infinity: ok, so right now, asking webops to twiddle the PPA seems to more robust idea? | 10:12 |
| didrocks | the* | 10:12 |
| mitya57 | tkamppeter, it would be good to have this SRUed if you plan a SRU, otherwise I don't think it's worth that | 10:12 |
| didrocks | waiting for the real fix? | 10:12 |
| infinity | didrocks: Either that or, as Colin suggests, copying source-only. | 10:12 |
| infinity | didrocks: But the kernel PPA method DTRT for now. | 10:13 |
| didrocks | I'm not confortable with that, as we won't have in proposed the real stack/build order we tested | 10:13 |
| infinity | didrocks: Where "the right thing" is "exactly the same awful hack as the primary archive". | 10:13 |
| didrocks | infinity: yeah, I understood that ;) do you have anyone in mind knowledgeable about it in IS? | 10:13 |
| cjwatson | Don't do that, ask webops. It's an alias. | 10:13 |
| cjwatson | Duty admins highlight on it. | 10:14 |
| didrocks | ok, doing so :) | 10:14 |
| cjwatson | (#launchpad-ops, internal) | 10:14 |
| didrocks | thanks cjwatson, doing that right now :) | 10:14 |
| infinity | cjwatson: Actually, they prefer #webops. | 10:15 |
| cjwatson | Ah, that works too | 10:15 |
| didrocks | ah, too late :) | 10:16 |
| mitya57 | hi barry | 10:18 |
| mitya57 | barry: do you know python's cElementTree code? If yes, maybe you can take a look at http://bugs.python.org/msg175235? | 10:19 |
| mitya57 | (this is cause of debian bug 692285) | 10:20 |
| ubottu | Debian bug 692285 in src:python-docutils "python-docutils: FTBFS with Python 3.3: TypeError: must be Element, not _ElementInterfaceWrapper" [Important,Open] http://bugs.debian.org/692285 | 10:20 |
| infinity | doko_: Oh, for the love of... How am I meant to divine the mystery path for the multilib c++ includes? *sigh* | 10:42 |
| mlankhorst | :-) | 10:42 |
| mlankhorst | gcc -v? | 10:43 |
| infinity | Yeah, I was avoiding using the whole output of gcc -v, since it includes paths I might not want. | 10:43 |
| infinity | Not much point in using nostdinc if you then end up appending all of stdinc's paths to your call. | 10:46 |
| mlankhorst | gcc -print-file-name=include | 10:47 |
| infinity | Wrong one. | 10:47 |
| infinity | Are there others? :P | 10:47 |
| infinity | What I'm after is /usr/include/c++/4.7 /usr/include/c++/4.7/backward /usr/include/x86_64-linux-gnu/c++/4.7 | 10:47 |
| infinity | That last one is a bitch to construct for multilib builds. | 10:48 |
| infinity | Since it ends up as /usr/include/x86_64-linux-gnu/c++/4.7/32 or /usr/include/x86_64-linux-gnu/c++/4.7/x32 | 10:48 |
| infinity | Rather than using the target triplet. | 10:48 |
| infinity | (I suppose to avoid clashing with the multiarch version of same) | 10:48 |
| mlankhorst | g++ -E -x c++ - -v < /dev/null | 10:49 |
| infinity | Yes, I know. That's where I copied and pasted the above from. | 10:50 |
| infinity | But the list also includes things I don't want. | 10:50 |
| mlankhorst | yeah :/ | 10:50 |
| infinity | If I could guarantee the top three were always the ones I want, I'd go with that. | 10:50 |
| infinity | But I'm not sure that's a sane assumption. | 10:50 |
| infinity | (Though currently true) | 10:51 |
| mlankhorst | |grep c++ ? :P | 10:54 |
| infinity | mlankhorst: Well, that's definitely correct today. Almost certainly not upstreamable. | 10:54 |
| infinity | mlankhorst: But meh. For now, it might do. | 10:54 |
| mlankhorst | what are you trying though | 10:55 |
| mlankhorst | and if it's meant for upstream, you could just add a -dump-includes to gcc or something | 10:55 |
| infinity | Hrm? This is the glibc test suite. | 10:55 |
| infinity | Which worked fine in hackish ways until doko's new gcc. | 10:55 |
| mlankhorst | still, could be better in long term to just get it over with and add it, even though that menas dealing with gcc coding style.. | 10:56 |
| * mlankhorst shivers | 10:56 | |
| === pcarrier_ is now known as pcarrier | ||
| infinity | Ahh, -print-multi-directory gets me that... | 11:00 |
| cjwatson | Hmm, has libnss-files started to autocreate /etc/{protocols,services} or something? | 11:00 |
| infinity | Except I can't get the multiarch dir in the same invocation, cause that ends up wrong. | 11:00 |
| * cjwatson is trying to debug chroot weirdness | 11:00 | |
| infinity | cjwatson: No, schroot copies those in unless you tell it not to. | 11:00 |
| cjwatson | Oh is *that* it | 11:00 |
| cjwatson | OK, thanks | 11:00 |
| infinity | /etc/schroot/default/copyfiles | 11:00 |
| infinity | Or, no. /etc/schroot/default/nssdatabases | 11:01 |
| infinity | That one. | 11:01 |
| infinity | And in mine, #services and #protocols are commented out. :P | 11:01 |
| pitti | didrocks: ^ please try the "soft kitty" approach :) | 11:01 |
| infinity | Likely due to debugging a weird unreproducible "should have build-depended on netbase" build failure. | 11:01 |
| cjwatson | Right, that explains rather a lot of failures any time netbase gets upgraded. | 11:01 |
| cjwatson | Or rather, installed, since it isn't in the base. | 11:02 |
| didrocks | pitti: yeah, it seems that's really needed, he will never stop! :) | 11:02 |
| === Quintasan_ is now known as Quintasan | ||
| infinity | pitti: WRT your reverse-dep analysis, note that any of those packages having build-deps on each other is purely due to versioned build-deps (which can, and often do, go away). | 11:08 |
| infinity | pitti: Since all of those packages are build-essential, they don't need to be in build-deps at all. :P | 11:08 |
| pitti | infinity: right, I was mostly checking how the current deps would work wiht our current parser | 11:09 |
| infinity | pitti: I suspect that relying on rdep triggering to always work for that set is either asking us to always carry build-dep cruft (which seems wrong), or just being naive. :) | 11:09 |
| cjwatson | infinity: are services and protocols the only ones you have commented out there? | 11:10 |
| pitti | infinity: I'm just discussing that with apw | 11:10 |
| pitti | infinity: we can probably introduce an XS-Test-Depends: field or something like that | 11:10 |
| infinity | cjwatson: Yeah, none others have caused me personal grief. | 11:10 |
| cjwatson | OK, great | 11:10 |
| * cjwatson tweaks his charm | 11:10 | |
| pitti | infinity: problem is that debian/tests/control isn't exposed in the apt indexes, so we cannot trigger on changes of pure test dependencies right now | 11:10 |
| pitti | infinity: (mind you, this is stretching what autopkgtest was designed for quite a lot, so we need to make up things here) | 11:11 |
| pitti | infinity, apw: of course we could also just special-case those four pacakges and hardcode their mutual trigger dependencies in our scripts | 11:11 |
| infinity | pitti: That was sort of what I was suggesting when I brought it up. | 11:12 |
| infinity | pitti: I thought it would be something server-side, not in the packages. | 11:12 |
| apw | XS-Testsuite-Depends: i suspect if we do it there | 11:12 |
| pitti | we still need to add the actual tests to the packages | 11:12 |
| infinity | Yeah, we need the tests in packages, I'm fine with that. | 11:12 |
| infinity | Does anyone in Debian use this stuff (ie: is it upstreamable without annoying people with "useless cruft")? | 11:13 |
| pitti | infinity: no, the tests themselves should be in the packages, but I'm ok with hardcoding the depends set for this particualr "mini rebuild test" case | 11:13 |
| pitti | infinity: yes, we upstream a lot of tests | 11:13 |
| infinity | Alright, cool. | 11:13 |
| pitti | they are supposed to run in http://jenkins.debian.net/ at some point | 11:13 |
| pitti | infinity: dep-8 is a Debian standard, after all :) | 11:13 |
| infinity | The only slight problem with hardcoding the set is that one of these four packages keeps changing its name. | 11:13 |
| * infinity glares at gcc-X.X | 11:13 | |
| pitti | infinity: ah, if only there was some way of expressing that with a pattern or so.. | 11:14 |
| pitti | "regular patterns" or "globby expressions" or so | 11:14 |
| infinity | pitti: Well, but if you express it as a regex, you just triggered a rebuild of ALL gcc versions in the archive, when that may or may not be what we want. Actually, maybe it would be. | 11:14 |
| infinity | But we wouldn't want the inverse. | 11:15 |
| infinity | That's the problem. | 11:15 |
| infinity | When gcc-4.5 revs (if it's still in the archive, too lazy to look), we don't care that it can't build the kenrel and glibc properly. | 11:15 |
| pitti | infinity: anyway, hardcoding this in the scripts requires manual maintenance anyway; having to change it with each new compiler version isn't that big of a deal | 11:15 |
| infinity | Nor do we care if gcc-4.8 can't do either of those things. | 11:15 |
| infinity | (yet) | 11:15 |
| pitti | infinity: but it can parse the defualt version from the "gcc" metapackage | 11:15 |
| infinity | But we do care if glibc makes gcc-4.8 worse. | 11:16 |
| infinity | pitti: If only it were that simple. ;) | 11:16 |
| infinity | pitti: (Last cycle, the default gcc was 4.7, but glibc was built with 4.6, not sure what the kernel used) | 11:16 |
| apw | so the source packages expressing that works no? | 11:16 |
| infinity | apw: Yeah, expressing things in the source package might make more sense. | 11:16 |
| apw | as i am saying linux -> gcc-4.7 | 11:16 |
| pitti | infinity: but that's fine -- glibc would then have a gcc-4.6 build dep, and the normal reverse dep parsing would kick in | 11:16 |
| infinity | pitti: Oh, fair. | 11:17 |
| infinity | I think I'll skip on the brown-paper-bag glibc upload tonight and finally go nap. | 11:17 |
| infinity | And fix this in the morning with an ugly non-upstreamable hammer. | 11:18 |
| infinity | And die a little inside. | 11:18 |
| apw | pitti, so i think you are saying the following is enough: http://paste.ubuntu.com/1374603/ | 11:18 |
| pitti | apw: looks good, except that we don't implement XS-Testsuite-Depends ATM | 11:19 |
| === _salem is now known as salem_ | ||
| pitti | apw: and in fact we might not use that yet, as it's not covered by DEP-8 | 11:19 |
| pitti | apw: I think we should start with hardcoding those | 11:19 |
| infinity | apw: And if that header actually worked, you'd want binutils in there too. | 11:19 |
| apw | infinity, i think i already dep on that in reality, so its ok | 11:19 |
| pitti | not needed, linux-source pulls in binutisl | 11:19 |
| apw | though it might be clearer indeed | 11:20 |
| apw | ack | 11:20 |
| infinity | Eh. While it's okay that there's an implicit one, I'd prefer being explicit. | 11:20 |
| infinity | (Thinking of my specific glibc use-case where build-deps come and go more often than people I date) | 11:20 |
| pitti | well, if no part of linux depends on eglibc, do we actually need to test that then? | 11:21 |
| infinity | pitti: I'm trying to sort out what that header will mean. | 11:21 |
| apw | i am expecting to need to test eglibc will still build after linux publishes | 11:21 |
| infinity | pitti: Is it "when this is upgraded, test these" or "when these are upgraded, test this"? | 11:21 |
| apw | as it consumes my binary packages | 11:21 |
| pitti | infinity: the latter | 11:22 |
| infinity | apw: Yes, I want to test eglibc when linux-libc-dev lands. The inverse isn't necessary. | 11:22 |
| pitti | but as I said, I wouldn't add this new header just yet | 11:22 |
| pitti | and instead put that into lp:auto-package-testing for now | 11:22 |
| pitti | we can clean it up when it works and we can convince Debian to adopt the header into DEP-8 | 11:22 |
| pitti | (and Debian's autopkgtest) | 11:22 |
| infinity | pitti: Oh, and as to the DEB_BUILD_OPTIONS=whatever thing, that would probably be a DEB_BUILD_PROFILE in the new world. | 11:23 |
| infinity | DEB_BUILD_PROFILE=autopkgtest or something. | 11:23 |
| pitti | WFM :) I just wanted to take a variable taht already exists | 11:23 |
| apw | pitti, ok so i'll add it commented out so we remember | 11:23 |
| infinity | Yeah, this is precisely why DEB_STAGE was changed to DEB_BUILD_PROFILE, so it could be genericized into a "mangle your build order/output" thing. | 11:24 |
| apw | pitti, when you are expressing those, linux-libc-dev only ever comes from linux | 11:24 |
| pitti | infinity: it should be "rebuild-test", not "autopktest", IMHO (we'd want that for the full rebuild tests too, I think) | 11:25 |
| apw | pitti, so DEB_BUILD_PROFILE=autopkgtest or DEB_BUILD_PROFILE=rebuild-test | 11:25 |
| pitti | apw: right, but we'd set that in lp:auto-package-testing globally then | 11:25 |
| apw | indeed, just adjusting my support within the package | 11:26 |
| pitti | a package can't set the environment in autopkgtest | 11:26 |
| infinity | pitti: I dunno. A full rebuild test should just be a normal build. | 11:26 |
| infinity | pitti: (My current glibc build failure wouldn't be a failure if I wasn't building the second pass, actually) :P | 11:26 |
| apw | infinity, i am proposing to use it to build just the first flavour on each arch | 11:27 |
| apw | infinity, for the autopkgtest case | 11:27 |
| infinity | apw: Right, which is why I think it's wrong for it to be for "all rebuild tests". | 11:27 |
| pitti | so if it's wrong for the "all rebuild tests", how is it not wrong for the "mini rebuild test"? | 11:27 |
| infinity | pitti: It's a speed-versus-accuracy tradeoff. The "right" thing to do when uploading a new toolchain is to rebuild test the whole archive before we let the toolchain in. We're not going to do that, cause we'll get lynched. | 11:28 |
| infinity | pitti: So, autopkgtest as a blocker to migration needs to hit good test coverage without being too heavy. | 11:28 |
| pitti | okay | 11:29 |
| infinity | pitti: A full rebuild test is async, and can be as heavy as you want. | 11:29 |
| pitti | well, except that it still takes like a month on arm :) | 11:29 |
| infinity | Not true. | 11:29 |
| infinity | The last time was because buildds kept ABORTing every few minutes. | 11:29 |
| infinity | The time before that, armhf finished before amd64. | 11:29 |
| doko_ | infinity, g++ -E -x c++ - -v < /dev/null | fgrep /c++/ | 11:29 |
| infinity | People have short memories. | 11:29 |
| infinity | doko_: Yeah, I was going to settle on the grep c++ solution. | 11:30 |
| infinity | doko_: Is that guaranteed to always only be the internal includes? | 11:30 |
| pitti | apw: oh, and you might want to add a bug ref to #1081500 to the commit ? | 11:30 |
| infinity | doko_: Like, in an unstreamably reliable way? | 11:30 |
| doko_ | ig glibc is that backward, it even includes the backward headers | 11:30 |
| apw | pitti, will do | 11:30 |
| doko_ | bug 1081500 | 11:30 |
| ubottu | Launchpad bug 1081500 in linux (Ubuntu) "Add autopkgtest for mutual rebuild-testing amongst glibc, linux-libc-dev, gcc, and binutils" [Low,Triaged] https://launchpad.net/bugs/1081500 | 11:30 |
| apw | once you lot hash out what the DEB_PROFILE is going to be | 11:30 |
| infinity | doko_: It might not actually need the backward ones, but it does need the tricky-to-construct arch-path ones. :P | 11:31 |
| infinity | apw: Doesn't matter, we can change it once guillem tells us we're wrong. | 11:32 |
| pitti | apw: so DEB_PROFILE=autopkgtest WFM at the moment | 11:32 |
| infinity | (s/DEB_PROFILE/DEB_BUILD_PROFILE) | 11:32 |
| infinity | / | 11:32 |
| apw | ifeq ($(DEB_BUILD_PROFILE),autopkgtest) | 11:32 |
| infinity | apw: I bet you're having a good laugh now about having implemented all that do_* stuff reusably. :/ | 11:33 |
| * infinity suspects he's going to have to take some dull scissors to glibc to make this work. | 11:33 | |
| xnox | ifneq (,$(ADTTMP)) ? | 11:33 |
| apw | infinity, i am feeling somewhat smug at having rejected those original crosscompile patches about 4 times before implementing them right indeed :) | 11:34 |
| apw | pitti, so i guess are you happy enough for me to push these to our package for the next upload ? | 11:34 |
| pitti | apw: sounds good, thanks! I'll commit http://paste.ubuntu.com/1374628/ then | 11:35 |
| apw | expect carnage in the next upload :) | 11:37 |
| pitti | apw: so the next linux upload would trigger a binutils autopkgtest, provided that we get the binutils test in by then | 11:38 |
| pitti | apw: if that works, I can add the remaining "virtual" dependencies, so that the next upload will trigger all three | 11:38 |
| apw | pitti, and presumably its own build test too | 11:38 |
| pitti | but let's start small first | 11:38 |
| pitti | apw: right | 11:38 |
| apw | indeed small please | 11:38 |
| infinity | pitti: Hrm, I guess this would be something I could add to glibc tomorrow as well, so my brown-paper-bag comes with the frills of at least some other change. :P | 11:38 |
| pitti | infinity: yeah, hides much better in a changelog that way :) | 11:39 |
| infinity | (Though mine won't do the "only one flavour" thing straight away) | 11:39 |
| didrocks | cjwatson: infinity: it worked \o/ Thanks a lot :) | 11:39 |
| pitti | infinity: so that should be http://paste.ubuntu.com/1374603/ with the obvious debian.master/control.stub.in → debian/control | 11:40 |
| infinity | didrocks: NP. | 11:40 |
| pitti | infinity: and dropping the XS-Testsuite-Depends thing | 11:40 |
| * infinity is curious about needing a fake test to trigger a rebuild, but whatever. | 11:40 | |
| infinity | (I know why, it just feels a bit inelegant) | 11:41 |
| doko_ | infinity, if you have other suggestions for the path, I'm fine, but the current location wasn't good enough for multiarch | 11:41 |
| pitti | infinity: this actually is intended for building the tests that you are about to run | 11:41 |
| pitti | infinity: this is just abusing this to provide a rebuild test :) | 11:41 |
| infinity | pitti: Well, because our rebuild also happens to run tests, so this makes some sense. | 11:42 |
| pitti | infinity: but if we can run the built test suite against the installed glibc, this would be the intended (and ideal) case | 11:42 |
| apw | pitti, it would be nice perhaps if you could just have Tests: <empty> | 11:42 |
| infinity | doko_: Yeah, I'm not sure I have better ideas. The mixing of both multiarch and multilib on the same path just hurts a bit. | 11:42 |
| === Tonio_ is now known as Tonio_aw | ||
| pitti | apw: that might or might not work, I haven't tried | 11:42 |
| infinity | pitti: You mean after installing the one we just built? Cause running it against the archive one is almost pointless. | 11:43 |
| pitti | infinity: no, running it against the archive one is the whole idea of autopkgtest | 11:43 |
| infinity | pitti: Yes, but pointless in THIS case. | 11:43 |
| infinity | pitti: Cause we're trying to see if a new toolchain misbuilds everything. | 11:43 |
| pitti | right | 11:43 |
| pitti | in the context of a rebuilt test | 11:43 |
| infinity | pitti: I agree that detached testsuites are handy for other things. | 11:44 |
| infinity | Also a pain in the ass to do to some larger suites. :/ | 11:44 |
| pitti | but it's a good thing in its own right | 11:44 |
| infinity | (We did it a ton at Nokia/Maemo, cause they also had an out-of-package-run-against-installed-packages test harness) | 11:44 |
| infinity | The telepathy suite was very violently mangled to make this work. | 11:45 |
| apw | pitti, i guess the sort of thing our real package test should do is check that the abi does not change | 11:45 |
| infinity | Not my finest work. | 11:45 |
| apw | pitti, as in check that the rebuild abi matches the binary packages we have in the archive | 11:45 |
| pitti | apw: right, or integrate your existing tests to run in autopkgtests (file system tests and what not) | 11:46 |
| * apw shudders | 11:46 | |
| pitti | apw: do we ship the abi files? | 11:46 |
| apw | pitti, yep | 11:46 |
| infinity | pitti: Yes, but not in the source that produced them. | 11:46 |
| infinity | So, the test needs to grab the debs from the archive to compare. | 11:46 |
| infinity | Which isn't hard, just a bit weird. | 11:47 |
| apw | infinity, well i should be able to make the test build-dep: on the kernel binaries | 11:47 |
| pitti | well, the kernel is already installed | 11:47 |
| pitti | the files should be "just there" | 11:47 |
| infinity | pitti: Oh, I suppose there's that. If it's the same flavour that Andy builds. :) | 11:47 |
| apw | are all my binar spawn installed then ? | 11:47 |
| pitti | apw: all build, binary, and test depends are installed | 11:48 |
| pitti | and of course whatever is in a base system (currently the cloud images) | 11:48 |
| apw | ok so we can depend on the real binary generated packages if we need them | 11:48 |
| infinity | Right, so just test-depending on all his kernel images would get him all his ABI files. | 11:48 |
| pitti | you still need to check the installed kernel version of course, as the -proposed one might bump api | 11:48 |
| pitti | abi | 11:48 |
| infinity | Yeah, hence the test-depends, cause that could be exact versions. | 11:49 |
| infinity | No guesswork. | 11:49 |
| pitti | *nod* | 11:49 |
| apw | sounds 'awsome' :) | 11:49 |
| pitti | apw: debian/tests/control: Depends: @ | 11:49 |
| pitti | will install all binaries produced by that source package | 11:49 |
| pitti | (which is in fact the default if you don't specify anything) | 11:49 |
| apw | oh great, so it'll just be there | 11:50 |
| infinity | What if the source produces conflicting binaries? | 11:50 |
| pitti | you lose and can't use @ | 11:50 |
| infinity | I guess autopkgtst just explodes until you specify it? Check. | 11:50 |
| pitti | you can split your test and set different depends: for each of them | 11:50 |
| pitti | infinity: yes, it'll fail with a package installation failure | 11:50 |
| * infinity nods. | 11:51 | |
| pitti | much like maas' test | 11:51 |
| pitti | (in which case it's a legitimate failure) | 11:51 |
| infinity | didrocks: Alright, I'm ready. Soft Kitty me. Do it. | 11:51 |
| infinity | Friggin' 5am. | 11:51 |
| infinity | Oops. | 11:51 |
| pitti | ♩ soooft kitty, waaarm kitty, little ball of fur ♪ | 11:51 |
| cjwatson | didrocks: Oh good | 11:52 |
| didrocks | infinity: :) | 11:57 |
| didrocks | cjwatson: rerunning for checking that it's skipping part of the stack now, added the cron to lillypilly and we should be fine! :) | 11:57 |
| cjwatson | Is this in cu2d/ ? | 11:58 |
| cjwatson | (BTW you know the singular of "series" is also "series", right? :-) ) | 12:00 |
| doko_ | infinity, but g++ in eglibc is only needed for the tests, not the build, afaik | 12:02 |
| infinity | doko_: Yep. I'll fix this when I wake up, using your grep suggestion. | 12:03 |
| infinity | (Well, paring down the whole thing to be saner and upstreamable too) | 12:04 |
| infinity | Nap time. | 12:04 |
| didrocks | cjwatson: right cu2d :) | 12:04 |
| didrocks | cjwatson: hum, I powndered, I'll fix it :) | 12:04 |
| doko_ | I think I won't upstream the gcc patch upstream | 12:04 |
| infinity | cjwatson: I might not be at the meeting in the morning for the team I'm only sort of a part of. Just pretend I'm American and took the week off. | 12:05 |
| didrocks | (english is confusing) | 12:05 |
| cjwatson | Mm, I suspect we'll have a low turnout | 12:05 |
| cjwatson | didrocks: In this case I blame Latin. | 12:05 |
| infinity | doko_: Well, I'm upstreaming the glibs bits cause I don't want to carry it. | 12:05 |
| didrocks | cjwatson: :) | 12:07 |
| nigelb | 32 | 12:07 |
| === tiagohillebrandt is now known as tiagoscd | ||
| === fisted_ is now known as fisted | ||
| didrocks | indicator-sound as well autolanded and other project ignored :) | 12:19 |
| pitti | https://launchpad.net/ubuntu/+source/indicator-sound/12.10.2daily12.11.21.1-0ubuntu1 | 12:20 |
| pitti | wow | 12:20 |
| pitti | didrocks, jibel: congrats! this is awesome | 12:20 |
| didrocks | thanks a lot to jibel :) | 12:20 |
| pitti | will there be sane version numbers at some point, at the end of the release? | 12:20 |
| didrocks | pitti: the goal is to have a simple version number before "daily" | 12:21 |
| didrocks | then, it's <number>daily12.11.21 | 12:21 |
| pitti | so you want to do away completely with upstream releases? | 12:21 |
| didrocks | there, the added .1 is because I had to rerun it ^ (I hopefully took care of this case) | 12:21 |
| didrocks | pitti: once a cycle I would say | 12:21 |
| didrocks | like, at the end | 12:22 |
| pitti | *nod* | 12:22 |
| didrocks | but it's up to upstream to do it | 12:22 |
| didrocks | so, if I rerun right now, for the same components | 12:22 |
| didrocks | and there is new code to land | 12:22 |
| didrocks | it will be .2, .3… | 12:22 |
| didrocks | until tomorrow :) | 12:22 |
| didrocks | pitti: also, the credit is given to who fixed the bug: https://lists.ubuntu.com/archives/raring-changes/2012-November/001547.html | 12:22 |
| didrocks | (don't worry about the 2 "Automatic snapshot from revision", one is for boostrap and was excepted. Didn't worth workarounding this) | 12:23 |
| === mcclurmc_away is now known as mcclurmc | ||
| === cpg is now known as cpg|away | ||
| === Tonio_aw is now known as Tonio_ | ||
| tumbleweed | didrocks: where is the script that's doing this published? | 13:09 |
| didrocks | tumbleweed: https://launchpad.net/cupstream2distro | 13:09 |
| tumbleweed | ta | 13:09 |
| didrocks | yw :) | 13:10 |
| tumbleweed | didrocks: should there not be a whitelist of packages that are allowed to be copied? not everyone in the team owning that PPA has upload rights | 13:25 |
| didrocks | tumbleweed: there should be no direct upload to the ppa | 13:26 |
| didrocks | tumbleweed: the scripts are doing the upload | 13:26 |
| tumbleweed | that's not enforced by anything, though | 13:26 |
| Daviey | Anyone have any thoughts on a merge of rsyslog from experimental ? | 13:26 |
| didrocks | tumbleweed: indeed, but only the package in a stack can be copied | 13:26 |
| tumbleweed | didrocks: what defines the stack? | 13:28 |
| didrocks | tumbleweed: the jenkins jobs: https://jenkins.qa.ubuntu.com/view/cu2d/ | 13:28 |
| === fisted_ is now known as fisted | ||
| === attente_zzz is now known as attente | ||
| tumbleweed | given that administation of that jenkins instance has no corellation to uplaod rights, I'd still prefer a whitelist | 13:31 |
| cjwatson | I tend to agree | 13:31 |
| tumbleweed | cjwatson: does the tech board intend to review this workflow? | 13:32 |
| cjwatson | tumbleweed: I reviewed it at UDS; I don't know that it needs full board consideration unless you want to raise a specific problem with us | 13:33 |
| didrocks | tumbleweed: what the whitelist will give? people will in ~ubuntu-desktop will be able to edit it, and the desktop package set doesn't covered all components here AFAIK | 13:33 |
| cjwatson | didrocks: Not if you put the whitelist in somewhere only ubuntu-archive@lillypilly gets to edit. | 13:34 |
| cjwatson | Given that that account is the one whose privileges are being used, it's entitled to limit them. | 13:34 |
| === morphis|away is now known as morphis | ||
| didrocks | cjwatson: I don't know what we try to fix here. We can have restricted access to jenkins to people who can have those upload rights | 13:35 |
| cjwatson | didrocks: This job is not supposed to be an end-run around the system of upload rights. | 13:35 |
| didrocks | cjwatson: it seems way easier that having a whitelist which will always be outdated compared to the stack | 13:35 |
| cjwatson | didrocks: tumbleweed is rightly objecting to what seems to be such a system. | 13:35 |
| didrocks | cjwatson: and it is not | 13:35 |
| cjwatson | But it is, as long as people without upload rights can cause any package they like to be uploaded. | 13:35 |
| tumbleweed | how often do you add new packages? | 13:35 |
| didrocks | so duplicated list of stack? one in jenkins, one in lillypilly | 13:35 |
| didrocks | tumbleweed: well, in the first weeks, it will be daily, as soon as they are bootstrapped to this process | 13:36 |
| cjwatson | I don't care where the list of packages lives as long as nobody without upload rights can edit it. | 13:36 |
| didrocks | cjwatson: so you are fine with that list being defined in jenkins? | 13:37 |
| tumbleweed | I have no idea who has access to the jenkins instance. If I'm assure that only core-devs can admin it then I guess that'd be OK. Somehow, I doubt that's true, though. | 13:37 |
| didrocks | knowing that only people with upload right can access to it (maybe not everyone, but some) | 13:38 |
| === lu_zero_ is now known as lu_zero | ||
| cjwatson | didrocks: I'm fine with anything that meets the condition I laid out; I don't know how your jenkins instance is administered. | 13:38 |
| cjwatson | So I can't answer that question. | 13:38 |
| didrocks | because then, you can say the same with the jenkins machine | 13:38 |
| didrocks | IS can administrate those macihnes | 13:38 |
| didrocks | as IS can change something in lillypilly | 13:38 |
| cjwatson | Yeah, I don't mind assuming IS aren't malevolent | 13:38 |
| cjwatson | There's no point going down a rathole here | 13:38 |
| didrocks | are you assuming that QA is? | 13:38 |
| cjwatson | I think I should leave this conversation. | 13:39 |
| tumbleweed | as an outsider, I accept that canonical have sysadmins who have root on all the machines | 13:39 |
| cjwatson | I am assuming that people will use privileges they believe themselves to have to get their jobs done efficiently. | 13:39 |
| didrocks | tumbleweed: QA are the sysadmins for jenkins | 13:39 |
| tumbleweed | I'm not convinced that the QA team should have a backdoor to the archive | 13:39 |
| didrocks | so we need to remove jenkins access to people administrating it? | 13:40 |
| cjwatson | You're the one who wants the list to live in jenkins. | 13:40 |
| didrocks | cjwatson: well, the list is one thing | 13:40 |
| didrocks | what we upload is way more important | 13:40 |
| didrocks | and the source packages are created by jenkins jobs | 13:41 |
| didrocks | so this is the part that QA can play with, change the content and so on | 13:41 |
| didrocks | the list won't prevent that | 13:41 |
| cjwatson | That depends on your point of view. There are plenty of things that the content of these packages doesn't affect at all. | 13:41 |
| cjwatson | ubuntu-archive@lillypilly can do *anything*. | 13:41 |
| cjwatson | But not all the world is Unity ... | 13:41 |
| tumbleweed | but they're only reviewed g:q! | 13:42 |
| tumbleweed | gaah | 13:42 |
| didrocks | cjwatson: I know that, but I mean, if we have a whitelist, they can get something in Unity and break the rule of the upload rights | 13:42 |
| didrocks | so I don't see what the whitelist is fixing here | 13:42 |
| didrocks | I can do it, but that will fix nothing | 13:43 |
| cjwatson | They can't decide that somebody isn't fixing a bug in some other package quickly enough and stick it temporarily (and well-meaningly) in jenkins | 13:43 |
| === l3on_ is now known as l3on | ||
| === Pricey_ is now known as Pricey | ||
| === jbernard_ is now known as jbernard | ||
| tumbleweed | personally, I'd like the automatic uploads to be approved for a particular set of packages | 13:44 |
| didrocks | tumbleweed: it's all packages that are from canonical upstream, the UDS session was clear for that | 13:44 |
| cjwatson | And all I want to do is enforce that it can only be used for such packages. | 13:44 |
| tumbleweed | didrocks: right, then it should be staright-forward to come up with a list of those | 13:44 |
| didrocks | cjwatson: I'll implement the whitelist on lillypilly, still unsure what it adresses those | 13:44 |
| cjwatson | I consider this due diligence. | 13:45 |
| didrocks | tumbleweed: there are those that are bootstraped and the others that are not | 13:45 |
| tumbleweed | didrocks: that doesn't concern me too much | 13:45 |
| didrocks | tumbleweed: it does for me | 13:45 |
| tumbleweed | it stops the robot doing things that it isn't allowed to | 13:45 |
| didrocks | but again, i'll implement that whitelist | 13:45 |
| tumbleweed | didrocks: thanks | 13:45 |
| didrocks | it's still fixing nothing IMHO compared to what others can do with this | 13:45 |
| didrocks | but I'll do it | 13:45 |
| cjwatson | The limitation of upload rights is an important part of our organisational security. | 13:46 |
| didrocks | cjwatson: I still reiterate that anyone having jenkins access to jenkins machines can change the tarball content | 13:46 |
| cjwatson | And it's still valuable to limit the set of packages even if changes to those packages' content are unrestricted. | 13:46 |
| tumbleweed | I'd also prefer it if the detection of packaging changes happened at the bot level, rather than jenkns. But that's a minor issue, compared to having unrestricted upload rights | 13:46 |
| === broder is now known as broder_ | ||
| cjwatson | Because it is easy to review changes to a single package, or a small set of packages; it is very hard to review changes to the entire archive. | 13:47 |
| didrocks | let me implement it, I'll ping you back then | 13:47 |
| cjwatson | So I accept your point that anyone with jenkins access can change the tarball content, but it doesn't change my mind. | 13:47 |
| cjwatson | tumbleweed: I agree, seems like the security boundary should be where the check happens | 13:47 |
| tumbleweed | s/minor/contained/ | 13:47 |
| GunnarHj | cjwatson: Hi Colin, wondering if you could take a look at the proposed solution to bug 952185. Saw Steve's comment at bug 584249, but I felt that a pam config change might still be ok. And it works. :) | 13:48 |
| ubottu | Launchpad bug 952185 in pam (Ubuntu) "~/.pam_environment not parsed when HOME is encrypted" [Undecided,In progress] https://launchpad.net/bugs/952185 | 13:48 |
| ubottu | Launchpad bug 952185 in pam (Ubuntu) "duplicate for #584249 ~/.pam_environment not parsed when HOME is encrypted" [Undecided,In progress] https://launchpad.net/bugs/952185 | 13:48 |
| cjwatson | GunnarHj: Sorry, I don't consider myself immediately competent to review that | 13:48 |
| GunnarHj | cjwatson: Is Steve the one and only? (Think he's on vacation.) | 13:49 |
| cjwatson | I don't know. | 13:49 |
| tumbleweed | didrocks: so, what happens if some core-dev uploads an emergency PS stack packaging fix to the archive? it doesn't like like it would stop the bot from overwriting it the next day | 13:50 |
| didrocks | tumbleweed: it would stop it | 13:50 |
| didrocks | see prepare-package | 13:50 |
| didrocks | and so the doc at the end of it | 13:51 |
| === NimeshNeema is now known as NimeshNeema_ | ||
| tumbleweed | ah, there it is, ta | 13:51 |
| GunnarHj | cjwatson: Think I'll wait til Steve is back, then, since he seems to do the bulk of the pam maintenance. Thanks anyway. | 13:52 |
| cjwatson | Sorry I can't help. | 13:52 |
| GunnarHj | cjwatson: No problem. | 13:53 |
| tumbleweed | didrocks: shouldn't that check should happen as close to the copy as possible? rather than before the source build? | 13:54 |
| didrocks | tumbleweed: we will never get to the "copy" state if the source build fails | 13:55 |
| cjwatson | But consider a race condition | 13:55 |
| didrocks | yeah, I can do a second check if needed | 13:55 |
| cjwatson | We can't actually close it, but we can make it as narrow as possible | 13:55 |
| didrocks | good point, adding that | 13:55 |
| mspencer | pitti: png re. bug 657275 | 14:06 |
| ubottu | Launchpad bug 657275 in apport (Ubuntu) "ubuntu-bug should save reports offline automatically rather than giving a cryptic error message" [Wishlist,In progress] https://launchpad.net/bugs/657275 | 14:06 |
| apw | pitti, as the kernel depends on kernel-wedge, under autopkgtest i assume an upload there would trigger testing in linux -- correctly too | 14:21 |
| === Tonio_ is now known as Tonio_aw | ||
| === Tonio_aw is now known as Tonio_ | ||
| didrocks | tumbleweed: cjwatson: whitelist built: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/86 | 14:46 |
| didrocks | I'll add the tests with the whole framework for testing | 14:46 |
| didrocks | I need more investigation to build properly the last-minute check for upload (particularly as I'm out of jenkins, how to get emails about those failures, even if I read -changes without being spammed with the rest) and passing the "previous last automated upload" version to the rsync file | 14:47 |
| nemo | Hey guys, I'm stuck on W:Failed to fetch gzip:/var/lib/apt/lists/partial/mirror.anl.gov_pub_ubuntu_dists_quantal_universe_i18n_Translation-en after attempted upgrade. | 15:01 |
| nemo | are not all the mirrors updated yet? | 15:01 |
| nemo | also "bzip2: (stdin) is not a bzip2 file." on console. | 15:02 |
| nemo | the other possibility is the idiots here screwed up their explicit whitelisting of mirror.anl.gov on the stupid Websense server. which I'm totally open to | 15:02 |
| nemo | oh. right. part of that error was "Encountered a section with no Package: header" | 15:05 |
| nemo | hm. maybe if I run ltrace -S on update-manager I can figure out what URL it is trying to hit | 15:05 |
| === Tonio_ is now known as Tonio_aw | ||
| didrocks | cjwatson: tumbleweed: and the extra check for an upload to distro just before doing the copy: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/87 | 15:09 |
| pitti | mspencer: hello | 15:09 |
| pitti | apw: right, that makes sense I guess? | 15:09 |
| tumbleweed | didrocks: thanks | 15:09 |
| apw | pitti, i think it does indeed | 15:10 |
| didrocks | tumbleweed: yw | 15:10 |
| nemo | hrm. that didn't work :-/ | 15:10 |
| dholbach | Laney, where can I file a bug on the transitions tracker? | 15:10 |
| mspencer | Hi pitti, for LP #657275, what do you want done with bug reports if there is no Internet connection? | 15:11 |
| ubottu | Launchpad bug 657275 in apport (Ubuntu) "ubuntu-bug should save reports offline automatically rather than giving a cryptic error message" [Wishlist,In progress] https://launchpad.net/bugs/657275 | 15:11 |
| Laney | dholbach: is it a bug in the software? | 15:12 |
| dholbach | Laney, it's a wishlist item and https://launchpad.net/ubuntu-transition-tracker does not let me file bugs | 15:12 |
| Laney | ubuntu-bug ben | 15:12 |
| nemo | ah. there's a tmp dir. let's see what's in there | 15:13 |
| Laney | yeah, that's a different version to the one we have deployed but ho hum | 15:13 |
| xnox | dholbach: what's the bug? | 15:13 |
| dholbach | [dholbach] file bug on transition tracker (lp:ubuntu-transition-tracker) to produce Harvest JSON output: TODO | 15:14 |
| pitti | mspencer: I'm not keen on implementing a wholly new UI for browsing .crash files; you can just double-click on them in nautilus after all; but the [Save] button sounds fine | 15:14 |
| === Tonio_aw is now known as Tonio_ | ||
| mspencer | pitti: So just save them to the user's home folder and tell them to report them later? | 15:15 |
| pitti | mspencer: but honestly it's not quite at the top of my list; there is a --save option if you really need to | 15:16 |
| dholbach | Laney, xnox: is there another place to report the bug then? | 15:16 |
| Laney | just report it against the ben package | 15:16 |
| dholbach | ok | 15:16 |
| nemo | ah. !@#$ websense | 15:16 |
| Laney | ben (newer versions) can output yaml already though | 15:17 |
| mspencer | pitti: I know it's not very important, it was just something I came across that I thought I could handle since I'm new. | 15:17 |
| xnox | dholbach: well. upstream is a package in debian called ben. Currently it can produce "text" and "html" outputs. | 15:17 |
| dholbach | ok, I had no idea | 15:17 |
| pitti | mspencer: oh, if you want to do that, great :) | 15:17 |
| xnox | dholbach: in ubuntu we only replaced the logo & use our own transition good/bad/affects stanzas. Nothing fancy. | 15:17 |
| pitti | mspencer: yes, it's not hard to do, just takes some time and love | 15:17 |
| dholbach | ok, I see | 15:17 |
| nemo | and the place to look is apparently /var/lib/apt/lists/partial | 15:17 |
| xnox | dholbach: it's written in OCaml , so don't expect major json developments =/ | 15:18 |
| mspencer | pitti: where should I save the reports to? Home folder or a "Bug Reports" subfolder? | 15:18 |
| Laney | xnox: I don't see what the language has to do with that? | 15:19 |
| xnox | Laney: doesn't like PTS query ben somehow to show which packages are in a transition? | 15:19 |
| Laney | via the yaml file I already mentioned | 15:19 |
| Laney | but you started talking about OCaml being a hindrance to this feature's development somehow | 15:19 |
| pitti | mspencer: it should show a file dialog IMHO | 15:20 |
| mspencer | pitti: Okay, that's what I'll do, thanks! | 15:20 |
| Laney | I would say that harvest should just work with the yaml file somehow, even if it's via some tool translating it to json. But it's moot ATM until we get the new ben deployed. | 15:20 |
| xnox | Laney: in ubuntu we don't have many people who know ocaml, that is all. Didn't mean it, to come across the way it did. | 15:21 |
| === beuno_ is now known as beuno | ||
| === Zic is now known as Guest98738 | ||
| === doko_ is now known as doko | ||
| === Tonio_ is now known as Tonio_aw | ||
| === Tonio_aw is now known as Tonio_ | ||
| === Zic_ is now known as Guest7270 | ||
| === Tonio_ is now known as Tonio_aw | ||
| === Tonio_aw is now known as Tonio_ | ||
| mspencer | Hi, I'm new to developing for Ubuntu and am interested in working on the Contributor Console (https://wiki.ubuntu.com/ContributorConsole). Is this something a beginner could do? So far I've worked on bug fixes. | 16:40 |
| ScottK | mpt: ^^^ since it's your page. Not sure who's working on development. | 16:46 |
| xnox | mspencer: as far as I know, there are only mockups and no coding has started yet. | 16:46 |
| mpt | mspencer, hi, I wondered if you'd be interested ;-) | 16:47 |
| mpt | mspencer, no-one's started it as far as I know. You're welcome to. | 16:47 |
| mspencer | mpt: I'm not very familiar with packaging - do I need someone else to start the project and then I contribute to it or can I start it myself? | 16:50 |
| bdrung | JFYI: I started the gnustep transition | 16:51 |
| mspencer | mpt: Would I be responsible for all the work on it or can I just work on as much as I can? | 16:51 |
| === stan_ is now known as stan | ||
| mpt | mspencer, you can start it yourself, and merge in branches contributed by other people. If you get bored of it later you can hand over ownership to someone else. | 16:53 |
| mpt | mspencer, for example, you might decide you're only interested in doing the "Bugs" tab, but others might contribute parts of other tabs. | 16:54 |
| mspencer | mpt, Okay, I'll work on it. | 16:54 |
| mspencer | mpt: So I'll just create a new project in launchpad and use quickly to do this? | 16:55 |
| mpt | mspencer, great! Yep, Launchpad and Quickly would be a good start. | 16:55 |
| mspencer | mpt: Will I need to do anything to get it included in the Ubuntu? | 16:56 |
| mpt | mspencer, yes, but you don't need to think about that until later. Others can work on the packaging, in the same way that they can work on parts of the code. | 16:56 |
| mspencer | mpt: Great, thanks for your help! | 16:57 |
| mpt | Thank you, mspencer | 16:57 |
| === yofel_ is now known as yofel | ||
| mspencer | Here's the new project: https://launchpad.net/contributor-console | 17:08 |
| === Ursinha is now known as Ursinha-afk | ||
| === Tonio_ is now known as Tonio_aw | ||
| === Guest7270 is now known as Zic | ||
| === deryck is now known as deryck[lunch] | ||
| slangasek | ogra-cb_: I didn't say plymouth would be an easy merge, I said *don't merge it from Debian*, you should pull the new upstream version first and ignore the Debian package for now :) | 17:40 |
| slangasek | ogra-cb_: s/would/wouldn't/ | 17:40 |
| slangasek | only after we're at the same upstream version, should we look at doing the packaging merge | 17:41 |
| ogra-cb_ | oh, k | 17:41 |
| slangasek | ogra-cb_: I see you and xnox both active on the package bug... is one of you going to take on the merge? | 17:41 |
| slangasek | (the upstream merge) | 17:41 |
| slangasek | or do you prefer to leave it for me to play with? | 17:42 |
| ogra-cb_ | slangasek, i can try my best after the image stuff is done | 17:42 |
| ogra-cb_ | i fear though that this will keep me busy for this week still | 17:42 |
| xnox | slangasek: ogra-cb_: I can poke it a little =) | 17:42 |
| * xnox really doesn't like 293kB long britney output.txt | 17:43 | |
| ogra-cb_ | slangasek, also, setting console=tty0 instead of tty1 seems to help with the hard crashing | 17:43 |
| ogra-cb_ | it still doesnt get us a splash but i havent seen any reboots anymore at least | 17:43 |
| slangasek | ah, nice | 17:43 |
| ogra-cb_ | (still it shouldnt crash this hard indeed) | 17:44 |
| GunnarHj | slangasek: Hi Steve, wondering if you could take a look at the proposed solution to bug 952185. Saw your comment at bug 584249, but I felt that a pam config change might still be ok. And it works. :) | 17:47 |
| ubottu | Launchpad bug 952185 in pam (Ubuntu) "~/.pam_environment not parsed when HOME is encrypted" [Undecided,In progress] https://launchpad.net/bugs/952185 | 17:47 |
| ubottu | Launchpad bug 952185 in pam (Ubuntu) "duplicate for #584249 ~/.pam_environment not parsed when HOME is encrypted" [Undecided,In progress] https://launchpad.net/bugs/952185 | 17:47 |
| === andreas__ is now known as ahasenack | ||
| sarnold | arges: btw, "Fromat" in "RSYSLOG_SyslogProtocol23Fromat" in https://bugs.launchpad.net/bugs/1059592 | 17:54 |
| ubottu | Launchpad bug 1059592 in rsyslog (Ubuntu Raring) "Message and memory corruption in rsyslog" [High,In progress] | 17:54 |
| arges | sarnold, whoops | 17:55 |
| arges | sarnold, fixed : ) | 17:56 |
| sarnold | arges: woo :) | 17:56 |
| slangasek | GunnarHj: hey there - so I'm still on vacation, don't know that I'll get a chance to look at that this week :) Off the top of my head I'm not convinced this is a completely correct solution, so I need to look at it in some detail | 18:01 |
| GunnarHj | slangasek: Oh, sorry, saw your comment here, so I thought you were back. Let's wait then. | 18:02 |
| slangasek | GunnarHj: yeah, "vacation" is a sliding scale ;) | 18:02 |
| GunnarHj | :) | 18:02 |
| mspencer | mpt: I've created the Contributor Console project in Launchpad. Should the wiki spec get updated to point to it? | 18:22 |
| === Ursinha-afk is now known as Ursinha | ||
| === deryck[lunch] is now known as deryck | ||
| seb128 | hum | 18:53 |
| seb128 | unity fails to build in raring without code change | 18:53 |
| seb128 | -- Found Gettext: /usr/bin/msgmerge (found version "0.18.1") | 18:53 |
| seb128 | CMake Error at CMakeLists.txt:106 (if): | 18:53 |
| seb128 | if given arguments: | 18:53 |
| seb128 | "STREQUAL" "TRUE" | 18:53 |
| seb128 | Unknown arguments specified | 18:53 |
| seb128 | 18:53 | |
| seb128 | is there any toolchain/gettext/cmake known issue? | 18:53 |
| === mcclurmc is now known as mcclurmc_away | ||
| bryce | Could an SRU admin approve the jockey 0.9.7-0ubuntu7.6 upload for precise? This includes two important fixes, one for the LTS point release backport drivers, and one for Valve experimental drivers. It should make things display correctly in jockey, and we'd like to get people able to start testing both fixes soon. | 19:02 |
| bryce | s/approve/approve into -proposed/ | 19:03 |
| bryce | (if it matters, I did a quick code review of the change diff.) | 19:04 |
| mterry | Is anyone familiar with passing file descriptors over dbus? Apparently it has support for it, but I'm not sure how it is supposed to work | 19:18 |
| === cpg|away is now known as cpg | ||
| === mterry is now known as do_not_highlight | ||
| === cpg is now known as cpg|away | ||
| === mrpouit is now known as mr_pouit | ||
| mlankhorst | tell mterry that unix fd's are probably sent as any other parameter.. | 21:32 |
| === Tonio_aw is now known as Tonio_ | ||
| tkamppeter | Someone knows the date of the next UDS? | 21:46 |
| === salem_ is now known as _salem | ||
| === mcclurmc_away is now known as mcclurmc | ||
| bdrung | robert_ancell: do you plan to SRU evolution 3.6.2 to quantal? evolution 3.6.2 crashes several time a day and i like to check the new version. | 22:21 |
| robert_ancell | bdrung, do you mean 3.6.0 is crashing? | 22:24 |
| seb128 | bdrung, check with cyphermox, he's maintaining evo | 22:24 |
| bdrung | robert_ancell: yes | 22:24 |
| robert_ancell | there's heaps of changes in 3.6.2 so I don't know about how that goes in an SRU, but yeah, cyphermox is the right guy to talk to | 22:25 |
| bdrung | robert_ancell: opening an mail with attachment has a high chance to let it crash | 22:25 |
| bdrung | cyphermox: ^ | 22:25 |
| cyphermox | I agree, it's crashy. Perhaps we can SRU the specific fixes though | 22:26 |
| ScottK | mails with attachments are a security risk. Security feature, not a bug. | 22:26 |
| cyphermox | ScottK: +1 | 22:26 |
| ScottK | ;-) | 22:26 |
| bdrung | ScottK: so i can tell people that i can't review their debdiff sent by mail -> less work for me :D | 22:27 |
| bdrung | s/debdiff/debdiffs/ | 22:27 |
| ScottK | Double win. | 22:27 |
| bdrung | cyphermox: is the wrong handling of signatures in evo 3.6 already reported? | 22:28 |
| bdrung | evo places my signature twice | 22:28 |
| === mcclurmc is now known as mcclurmc_away | ||
| cyphermox | bdrung: yeah, and I spent quite a few hours trying to make sense of it without luck :( | 22:30 |
| cyphermox | bdrung: did you look at 3.6.2 and whether things were better there? | 22:30 |
| bdrung | cyphermox: not yet. i just tried to compile it under quantal without luck: http://paste.debian.net/211376/ | 22:31 |
| bdrung | the build dependencies seems to be not strict enough | 22:31 |
| bdrung | ScottK: can you let gnustep-base pass through new? | 22:32 |
| ScottK | bdrung: No time to review it now, sorry. | 22:33 |
| bdrung | ScottK: it's just binary new | 22:33 |
| bdrung | ScottK: are binary new package reviewed the same way new packages are reviewed? | 22:35 |
| ScottK | bdrung: The review is not identical (don't review licensing), but there are still some checks to do. | 22:38 |
| bdrung | ScottK: can you recommend someone i can nag? i have prepared the transition and like to get it done. | 22:40 |
| ScottK | Not really. This is a holiday period here in the US. | 22:40 |
| bdrung | ah, okay | 22:40 |
| ScottK | I don't recall if it is for Canada or not, so maybe infinity would do it. | 22:40 |
| bdrung | infinity: do you have a little spare time to review the binary new packages of gnustep-base? | 22:41 |
| infinity | bdrung: Yeah, I'll poke it in a sec. | 22:48 |
| bdrung | thanks | 22:48 |
| cyphermox | bdrung: I'll package evo 3.6.2 and push it to a PPA to begin with | 22:55 |
| cyphermox | or I guess upload to raring, instead | 22:56 |
| bdrung | cyphermox: robert_ancell uploaded evo 3.6.2 to raring. | 22:56 |
| cyphermox | ah | 22:56 |
| bdrung | cyphermox: if you upload evo 3.6.2 to a quantal ppa, i will be happy to test it | 22:57 |
| cyphermox | ok | 22:59 |
| cyphermox | bbl | 22:59 |
| === cpg|away is now known as cpg | ||
| === Tonio_ is now known as Tonio_aw | ||
| === Tonio_aw is now known as Tonio_ | ||
| doko | all gcc-multiarch target patches accepted upstream, doko is opening a bottle of beer | 23:37 |
| sarnold | doko: prost! | 23:38 |
| cjwatson | nice! sláinte | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!