=== xnox is now known as doko_ === doko_ is now known as xnox === Ursinha-afk is now known as Ursinha === Ursinha-afk is now known as Ursinha === jono is now known as Guest92387 [02:01] LoganCloud: When you sync -f over Ubuntu FTBFS fixes and then the package fails to build, the least you could do it bring back the patch in a merge. :P [02:15] infinity: Link paz [02:15] *Plz [02:16] LoganCloud: openimageio ... I'm re-fixing it now, don't worry. Just wanted to vent. [02:16] LoganCloud: If we have a delta, it would be nice to check WHY we have a delta, and not just sync over. [02:17] doanac, Mind if i merge sqlite3? It fixes an ftbfs in python-apsw [02:17] oops. doko_^ [02:21] infinity: Oh right. I had no way of testing on powerpc, so I synced to see if the new upstream release would fix it. I didn't get a build failed message for powerpc because I didn't do the latest changelog entry, so I forgot to go and check. Powerpc had a decent backlog at the time, so it didn't build immediately. My apologies. [02:22] If I could have it my way, people who copied over would get e-mail notification for failed builds as well. [02:22] Logan_: You could have noted that my patches still applied cleanly and blindly merged. Or, better yet, just asked me about it. [02:22] (I thought the uploader did get FTBFS notifications for copies...) [02:22] wgrant: ^ [02:23] I don't like blindly merging unless I know that the delta is necessary. [02:23] If they don't, that should be trivial to fix. [02:23] We definitely don't. [02:23] Logan_: Sure, so the "ask me" bit would have worked. [02:23] Understood. [02:23] infinity: http://cl.ly/image/2f1b1g041g22 [02:23] Logan_: I'm re-testing both my patches now. I know -latomic is needed (and will be pretty much forever, though I might convince the Debian maintainer to take my patch instead of his), the -ldl one might not be. [02:24] It doesn't appear that the -ldl is necessary anymore, given that it built on all architectures except for armhf and powerpc, and armhf is a carryover from last time. [02:25] Logan_: Yeahp, looks like my build here is finishing off with just the atomic fix. [02:26] dpkg-shlibdeps: warning: symbol dlopen used by debian/libopenimageio1.2/usr/lib/libOpenImageIO.so.1.2.3 found in none of the libraries [02:26] No, it's still underlinked. Just not FTBFS. Adding back both patches. :P [02:27] Alright, touché. You got me. :P [02:27] Although I still want build notifications for packages that I copy over. That seems like a no-brainer to me. [02:27] Yeah, I agree. [02:27] We'll see about sorting that. [02:27] Can I file a bug somewhere? I remember seeing someone complaining about that recently on a ML/ [02:27] s/\/// [02:29] Logan_: launcpad.net/launchpad/+filebug [02:29] But spelled right. [02:31] infinity: Cute. [02:32] Oh, I'm stupid. I didn't realize you were doing that against the launchpad project. [02:33] I wasn't trying to be funny, I just can't type to save my life. :P [02:35] infinity: Bug 1262952 [02:35] bug 1262952 in Launchpad itself "E-mail notifications should go to the copier as well" [Undecided,New] https://launchpad.net/bugs/1262952 [02:36] infinity: Also can we get powerpc PPAs? :P (Or PPAs that feed into the main buildds?) [02:36] Logan_: No, and no, but for the first, in the next year or so, maybe (no promises). Never the second. [02:37] :( [02:37] Public PPAs require a sane virtualization story, which we may have soonish on powerpc. And we'll never let public PPAs build on the distro builders, cause any twit with an email address can register a public PPA, they're impossible to audit. [02:37] So, naturally, I don't want that code running on the distro buildds. Ever. [02:38] Gotcha. [02:45] Logan_: do you ever ask the last uploader? [02:45] Logan_: it is expected for you to do so! [02:45] The last uploader did a no-change rebuild. [02:46] Oh and that was you. Awkward. [02:47] Well, the last uploader of substance it the better person to ask. :) [02:47] Logan_: if we had binNMUs in launchpad, there wouldn't be no-change rebuilds, so do skip over those. [02:47] Can we have those? [02:47] That would make transitions less of a pain in the ass. [02:47] Logan_: also note that e.g. if one tried to do syncrequest, it explicetely states the reason why the delta is dropped. [02:47] We can argue about them some more. [02:48] By the flagpole? [02:48] Logan_: "i don't understand this delta" or "i don't know if it's still needed" are never the right answer to drop something, or apply. [02:49] I never said that. Well, I kind of said the latter. But I had no way of testing the latter. But I should've asked Adam. So I'm silly. [02:50] xnox: I think he's been appropriately chastised by me, I don't need backup. :P [02:50] I feel victimized. :'( [02:51] Logan_: i'm sorry. [02:51] I'm going to go contribute to Debian instead. They'll be more forgiving, right? :P [02:51] xnox: Haha, it was my fault. No worries. [02:51] Hold up, updating the firmware on my router. brb [02:52] LoganCloud: Logan_: you do a lot of work, and it's mostly correct. It's just at times, you are tempted to jump ahead, instead of pinging people and wait a little =))))) [02:56] I am back and better than ever. [02:57] Okay so question. For the upx-ucl package, I was actually proactive and e-mailed the person who introduced a certain arm delta because I wasn't sure if it was necessary. But he never wrote back. What should I do? [02:58] I built the package myself in my armhf PPA, and it built successfully, but I'm not sure if it's just for optimization. [02:58] *the Debian package [02:58] - debian/rules: [arm] needs porting to thumb2; use -marm as the code does a lot of low level hacking not yet ready for thumb2. [02:59] ^ that's the delta that's been carried over for a good number of revisions, and I'm not sure if it's still necessary. [03:00] Logan_: You asked asac? [03:00] Correct. [03:00] And he never wrote back. It was sad. [03:00] Logan_: So, note that it has "ifeq (armel,$(DEB_BUILD_ARCH))" [03:01] > I noticed that you made this change to the upx-ucl package in 2010. I was wondering if it is still necessary, as I did a test build with the Debian package in my ARM PPA, and it built successfully. Or is this change deeper than just making the package build? Just trying to get rid of old deltas wherever possible. :) [03:01] Logan_: Which doesn't match any arch we build for. ;) [03:01] Okay well. [03:01] Go away. :P [03:01] So, if the patch is still necessary, it's wrong anyway. [03:01] * infinity looks at the original bug. [03:02] That's the most useless bug ever. Nice. [03:02] Logan_: If it currently builds on armhf and no one's complaining, just drop the delta. [03:02] Like what is thumb2. [03:02] Okay. [03:03] Logan_: thumb2 is an ARM instruction set. [03:03] The reason I thought it was for optimization purposes was because it built successfully on armel before asac's upload. So I don't know. [03:03] Okay, I will sync. [03:03] ...after I test build again, of course! :P [03:05] Logan_: Of course, while you're in there, I wonder if it might be trivial to port to arm64. :P [03:06] It doesn't look terribly trivial. At least, we'll see with this new upstream release. [03:07] infinity: This is probably a dumb question, but what is the endianness of arm64 in Ubuntu? [03:08] Logan_: little. [03:08] Logan_: Looking at src/miniacc.h, I imagine it's just a question of following all the ifdef trees and updating for a new arch. [03:09] If you know all the right values. :P [03:09] I think I'd trust you more with that. [03:09] Hi Noskcaj. [03:09] hey Logan_ [03:09] I'll probably disconnect soon so i can play dota. [03:10] Sounds reasonable. [03:16] Ah, another dota player [03:20] Where should you call dh_autoreconf in a traditional debhelper rules file? Configure or build? [03:22] I guess it would be where I would call dh_autotools-dev_updateconfig, which varies... [03:29] infinity: Okay, so if I see something like "dpkg-shlibdeps: warning: debian/gtk2-engines-equinox/usr/lib/gtk-2.0/2.10.0/engines/libequinox.so contains an unresolvable reference to symbol floor: it's probably a plugin," that means it's underlined? [03:29] *underlinked [03:36] ^ Or someone else. [03:37] Logan_: Well, in that case, it actually is a plugin, so if the thing it plugs into has that symbol, you're okay. [03:37] Logan_: But it could just as easily be underlinked (probably wants -lm) [03:38] How do I determine if something is a plugin or not? [03:38] If it's not a proper shared library in the library path, with an SONAME. [03:38] Then it's PROBABLY being dlopened by something else as a plugin. [03:38] So, if it doesn't provide a package for it, I'm good? [03:39] if i have a package that is i386-only, what's the proper way to have a dependency satisfied by any architecture (such as wget), versus requiring the i386 one? [03:39] Like a lib*# package. [03:39] Doesn't have anything to do with the packaging, really. Some packages have dozens of proper libraries in a single package. [03:39] arch:any I think [03:39] dobey: That was a little too genericized for me to be sure what you want. What's the exact thing going on here? [03:40] package:any actually [03:40] infinity: my package is i386-only, and i need to depend on wget, but don't want to require wget:i386, when installed on amd64. [03:40] no, foo:any doesn't work [03:40] Oh. :( [03:42] dobey: Oh yes, then Logan_ is right. If wget is multi-arch:allowed [03:42] infinity: so i want the installed wget:amd64 to be able to satisfy the dep on wget [03:42] eh i get dependency errors when trying to install, when depending on wget:any [03:43] infinity: I'm still confused about where to put dh_autoreconf in an old debhelper rules file, lol. The only logical place (to me) is build-stamp for the package I'm dealing with, and it complains about being run more than once. [03:43] Yeah, because wget is m-a:foreign, not allowed. Which is probably correct. [03:43] Logan_: Right before you run configure. [03:43] Well, ./configure is in build-stamp. [03:43] Logan_: And dh_autoreconf_clean before dh_clean. [03:44] Logan_: Does build-stamp get run more than once due to wildcard funkiness or something? [03:44] infinity: so i can't do it, or just having "wget" as the dep will work as i hope? [03:44] infinity: Apparently. [03:44] Logan_: If so, you'll want to make build-stamp depend on an autoreconf rule and put it in there. [03:45] ...I have no idea. Is depending like: build: build-arch build-indep [03:45] Logan_: Which package? [03:45] dobey: So, this could be a minor failing of the multi-arch spec. With a :foreign wget, I can't quite sort out how to say "any old one is good enough". [03:45] slangasek: ^ [03:45] infinity: leptonlib. I just did a config.{sub,guess} update with autotools-dev, but ppc64el needs the libtool fix. [03:46] dobey: One wonders why your package is i386 only. :) [03:46] infinity: because it's installing a proprietary thing that is only built as i386, and no 64-bit binary available [03:46] dobey: Fair enough. [03:51] Logan_: So, it seems to autoreconf fine here. [03:51] Really? Is it because I put it at the top of build-stamp instead of directly before ./configure? [03:51] * infinity waits for the build to finish... [03:52] Oh, lolz. [03:52] No, it's because this debian/rules is broken. Sec. [03:55] Logan_: I'll see if you can spot the error before I upload. :P [03:55] Ooh, I like that game [03:56] My laptop is grinding on a glibc build, so my pre-upload test-build could take a while. [03:56] You have a few minutes. [03:56] * infinity starts watch. [03:58] infinity: Is it because install depends on build? [03:58] Logan_: Sort of, but not really. [03:59] (It has to) [03:59] "touch builond-stamp" [03:59] Time's up, my build fi... [03:59] And you got there. [04:00] So, there's one other minor complaint I have with the rules file, but that's the glaring bug. :) [04:00] What's your minor complaint? [04:00] Other than it not being a dh sequencer? :P [04:00] http://paste.ubuntu.com/6603472/ [04:00] The other minor complaint is running dh_ commands before testdir completely defeats the purpose of running testdir. :) [04:01] infinity: Wait. Don't you not need the autotools commands if you're running autoreconf? [04:01] Logan_: That depends on if the project is using automake. Oh, which it is. [04:01] So, in this case, probably don't need both. [04:02] Logan_: Easiest way to check is to run dh_autoreconf and see if all copies of config.* got updated. [04:03] Logan_: In this case, they do, so yes, you can and should drop dh_autotools-dev [04:03] Do you want me to, or do you? [04:03] Logan_: Want me to upload this so I own it, or do you want the honors? [04:03] Hah. [04:03] I'll thank you in the upload. [04:04] Heh. [04:06] Logan_: So, your final diff looks like http://paste.ubuntu.com/6603500/ ? [04:06] Yessir. [04:07] Logan_: Shiny. Upload away. I can't wait for the glorious praise in your changelog. [04:12] infinity: https://launchpad.net/ubuntu/trusty/+source/leptonlib/1.69-4ubuntu3 [04:13] LOL, I misspelled the typo in the changelog. Whatever. [04:14] I had one job... [04:15] Logan_: Oh, the irony. :) [04:16] I give up. Fedora, here I come. :P [04:16] You'll be back. [04:23] Logan_: On the plus side, it fixed ppc64el, so you win in the end. [04:24] Yay! [04:24] Oh, by the way, be prepared to get an onslaught of uploads from a bored Logan over winter break. :P [05:20] Good morning [05:54] Why isn't the qa.ubuntuwire.com debcheck working? [06:29] roaksoax: hey, how are you? [06:29] roaksoax: any chance we can sort out bug 1254053 soon? [06:29] bug 1254053 in MAAS "Installing MAAS on trusty gives a big warning about deprecated postgresql 9.1" [High,Triaged] https://launchpad.net/bugs/1254053 [06:30] roaksoax: -9.1 dependencies are down to two, maas and glom [06:30] and the removal of 9.1 is waiting in trusty-proposed === iahmad__ is now known as iahmad [08:09] RAOF: ah, still one failure :/ http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-colord/26/ARCH=i386,label=adt/console [08:10] RAOF: sorry, https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-colord/26/ARCH=i386,label=adt/console [08:10] RAOF: not very useful output though, no cookies for the automake parallel runner :/ [08:11] No, it actually did manage some useful output [08:11] libcolord:ERROR:cd-self-test.c:3585:colord_icc_save_func: assertion failed (cd_icc_get_version (icc) == 4.09): (4.08 == 4.09) [08:12] ah [08:12] Also, grr? [08:12] That test works fine in my run-adt-tests VM [08:13] RAOF: did you run with proposed? (-P) [08:13] maybe there's some newer ICC stuff in -proposed [08:13] Maybe. [08:13] (nothing apparent, though) [08:13] * RAOF runs with -P [08:13] RAOF: also, does this actually test the installed colord, or the one from the build tree? [08:13] RAOF: (I probably already asked, but I forgot) [08:13] good morning! [08:14] It tests the installed colord, and the libs from the build tree. [08:14] this grub2 precise-proposed upload has all its bugs verified: https://launchpad.net/ubuntu/+source/grub2/1.99-21ubuntu3.14 [08:14] can we get it uploaded to -updates now, please? [08:16] sil2100: hi. Sorry I missed your reply yesterday: it got a bit late for me. === work_alkisg is now known as alkisg [09:00] good morning [09:15] morning [09:21] jibel: FYI, filed python-docutils failure as debian bug 732679; apparently some change (regression?) in 2to3 in python 3.3.3 [09:21] Debian bug 732679 in python-docutils "test_nodes.ElementTests.test_empty fails for py3: "•" != "\\u2022"" [Normal,Open] http://bugs.debian.org/732679 === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [10:27] cjwatson, hey! could you upload grub2 to precise-updates, please? all the bugs are now marked as verified. thanks! [10:36] ara_: we don't normally release SRUs on Fridays, and I don't know if I'll be around over the weekend in case it explodes; can it wait until Monday? [10:36] (I'll be around a bit, but kind of hoping not to be pulled into a firefight) [10:37] cjwatson, sure, it can, I will let people waiting on it know, thanks! [10:37] :) [10:37] I can probably even do it on Sunday evening or something, will see [10:38] ara_: (thanks for the reminder though) [10:41] cjwatson, I think Monday should be OK, thanks! === doko_ is now known as doko [10:45] ev, xnox: any idea about https://launchpad.net/ubuntu/+source/whoopsie/0.2.24.2 ? [10:55] robru, charles, Saviq: can one of you have a look at https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194? [10:55] (you all seem to be here and have done some work or review work on it before) [10:57] doko: The glibc strstr fix is in, BTW. You can un-gimp java. [11:03] doko: what about it? :) [11:04] oh [11:04] I see the failed builds ow [11:04] ev: the ftbfs [11:04] dholbach, I'll leave it to charles, I've not enough domain knowledge [11:05] not sure offhand. I wonder if glib has broken [11:05] apols, I don't have time to dig deeper at the moment [11:06] Saviq, gotcha, thanks [11:06] Saviq, it got a positive review from the security team already, so I hope we can get this in soon :) [11:07] dholbach, indeed, would be pretty useful [11:07] yep [11:10] dholbach, sorry, got a bit confused with epiphany-browser-webkit2 package, never actaully made it into the archives, have dropped it from the debdiff now [11:10] darkxst, cool [11:11] darkxst, I'll take a look at it later on, if nobody of the #ubuntu-desktop guys beats me to it [11:11] ev: it's okay, I think I know the fix [11:11] doko: ^ [11:11] Laney: star! Thank you so much [11:12] dholbach, thanks === tvoss is now known as tvoss|lunch [11:40] doko: wrt MIR for lcov and libjsoncpp, I think for llvm-3.3 we had the same issue and just disabled lcov and the external libjsoncpp copy [11:42] doko: https://bugs.launchpad.net/ubuntu/+source/libjsoncpp/+bug/1218220 [11:42] Ubuntu bug 1218220 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Won't fix] [11:42] infinity: what is the waitid linux/libc header mismatch issue? is there pointer to debian-bug or upstream discussion about it? [12:08] if I comment out the g_timeout_add_seconds it just sits there indefinitely - something wrong with the monitor_directory callback [12:28] pitti: Bah. Can't reproduce the adt failure, even with -P [12:28] RAOF: so, you have no idea where the unexpected 4.09 comes from? [12:31] No. [12:31] I wonder if that's i386 only? [12:32] ie: Is this actually a testcase bug to do with float precision? [12:32] 4.08 and 4.09 are very far apart even in float terms -- looks more like a version number? [12:33] RAOF: no, fails on both arches [12:35] pitti, are all the autopkg tests really running, e.g. for eglibc? [12:35] doko: what do you mean with "really"? [12:35] doko: for eglibc we ran maybe 40 or 50 tests [12:35] pitti: The relevant code is “cd_icc_set_version (icc, 4.09);”… “g_assert_cmpfloat (cd_icc_get_version (icc), ==, 4.09);” [12:35] doko: but they fell off excuses.html (known bug, jibel is on it) [12:36] i. e. only a display problem mostly [12:36] RAOF: o_O [12:36] ok [12:36] pitti: (For reference, before the cd_icc_set_version call the version in 3.40, so it's not simply failing to set the version or failing to write the test file) [12:36] doko: so yeah, when eglibc 2.18 landed, pretty much all the tests ran, that was a nice queue on Monday morning [12:37] RAOF: does qemu emulate Pentium FPUs? :-) [12:37] :P [12:46] doko: mind if I merge gnupg? [12:46] mdeslaur, not at all [12:46] doko: thanks [12:47] Is there anyone here running trusty on a cpu with rdrand that could test an openssl package for me? [12:47] I'm not cool enough to have one of those yet [12:49] mdeslaur: I appear to have that feature [12:50] mdeslaur: I do too [12:51] jamespage, stgraber: could one of you please try this debdiff just as a sanity check to make sure openssl still works on rdrand hardware before I upload it? http://paste.ubuntu.com/6605510/ [12:52] I believe the output of "openssl engine" should show rdrand without it, and should not with the patch [12:52] mdeslaur: trying now [12:52] jamespage: awesome, thanks [12:53] mdeslaur: I get rejects applying the patch [12:53] mdeslaur: ignore me - copy paste whitespace issue [12:54] jamespage: use the "download as text" link [12:55] mdeslaur: so I take it openssl doesn't know to mix sources of entropy then? [12:55] stgraber: unfortunately not [12:55] if you have rdrand, it's all that will be used [12:55] though I guess if it fallbacks to one of the random char device provided by the kernel, then it'll get rrand indirectly from there but mixed with some other sources [12:56] I have rngd running here mixing entropy from rrand, tpm and kernel generated random, that gives me a ton of entropy which is very very convenient when you're running test suites that generate a dozen of 4096bit rsa keys ;) [12:57] heh, yes, that would be sufficient :) [13:07] so if rdrand is already put into /dev/random, it seems that openssl reading it directly might actually be counter-productive? [13:09] pitti: I "think" the kernel now mixes it into /dev/random but that's all fairly new and that's why on my laptop I'm using a userspace tool to seed rrand and my TPM prng into the /dev/random pool [13:09] $ cat /proc/sys/kernel/random/entropy_avail [13:09] 151 [13:10] I vagueely remember some discussions on whether it was the kernel's job to integrate those other sources or if it was a userspace thing and that distros (as Fedora is currently doing) should provide rngd [13:10] I have rdrand, but that doesn't seem to be particularly much [13:10] stgraber@castiana:~$ cat /proc/sys/kernel/random/entropy_avail [13:10] 3096 [13:10] that's with rngd running [13:10] hm, how would that not be a kernel thing? [13:10] I haven't looked at the code in a while, but I believe openssl only seeds it's prng with stuff from /dev/random [13:11] yeah, I don't know, seems a bit counterintuitive having the kernel provide userspace with a way to access that stuff just for userspace to then seed /dev/random, but well... [13:16] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 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: jdstrand [13:18] mdeslaur: I see rdrand both with and without the patch [13:18] jamespage: ok, that may be fine. Does openssl appear to work? [13:40] jamespage: ? [13:40] mdeslaur: sorry - got presented with a baby part way through testing - multiarch mismatch is causing me niggles for install [13:41] oh, hehe, np [13:57] pitti: postgresql-server-dev-9.3 wants to get demoted to universe, is that correct? [13:58] xnox: hm, not really; -server-dev-all ought to depend on it [13:59] xnox: oh wait, yes; seems we don't have any packaged extension in main, so that's fine [13:59] ah, ack. [13:59] postgresql-server-dev-9.1 | 9.1.11-1 | trusty | amd64, arm64, armhf, i386, powerpc, ppc64el [13:59] I wonder what holds that in main [14:05] xnox@sochi:~$ reverse-depends -c main postgresql-server-dev-9.1 [14:05] No reverse dependencies found [14:05] xnox@sochi:~$ reverse-depends -b -c main postgresql-server-dev-9.1 [14:05] Reverse-Build-Depends [14:05] ===================== [14:05] xnox: ah, bacula builds against server-dev-9.1 (how strange..) [14:05] * bacula [14:05] xnox@sochi:~$ [14:05] =) [14:05] so, that needs transitioning, too [14:06] * xnox ponders if i should change my machine naming skim from "obscure large cities in russia" to "winter olympics hosting locations" [14:07] can we try to get http://reqorts.qa.ubuntu.com/reports/sponsoring/ down to something closer to 0 before the break? :) [14:19] mdeslaur: OK - no baby now so re-trying :-) [14:20] mdeslaur: a brief sniff looks OK [14:32] jamespage: great, thanks! [14:50] sergiusens, creating golang packages was worringly easy [14:59] jamespage, yeah, no complications with it at all [15:13] is there a reasonably good way to to say in a source package that a resulting binary package should own a file, and what the hash for that file is, without the file actually being in the binary package, but installed later (ie installed how flashplugin-installer installs flash)? [15:14] dobey: no, that would be wrong. but e.g. relevant pre/post-rm maintainer scripts should remove those files. [15:14] :( [15:15] dobey: it's similar to "non-conffile configuration files", just like one manually generates them (in e.g. pre/post-inst) one is responsible to clean them up (in pre/post-rm). Typically it's postinst & postrm. === greyback is now known as greyback|food === tvoss|lunch is now known as tvoss|dinner [16:56] * Laney does some festive sponsoring === Wubix_ is now known as Wubix [16:56] ho ho hupload [16:58] lol === greyback|food is now known as greyback [17:34] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 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: [17:36] weird. i just got an e-mail about trusty-adt-u1db being fixed now (i never got any e-mails about it breaking, and there haven't been any changes since the last version that was uploaded to saucy, which was copied to trusty) [17:40] dobey: some of those tests are re-triggered when a rdepend changes [17:40] and we had e-mail problems in the QA lab for a couple of weeks I believe [17:40] so that can account for why you didn't get the failure notification and why the tests were run when you didn't upload something [17:42] stgraber: right. the weird thing is that i have NEVER got any failure notifications, ever. even when i know they were failing [17:43] odd, though I know e-mail notifications were broken for quite a while and for various reasons (missing bits from IS, network re-org, ...) so in practice I only ever got a couple of those since the beginning of the cycle (so maybe just a 10th of what I should have got ;)) [17:46] ah === sil2100 is now known as KURWA === KURWA is now known as sil2100 === psivaa is now known as psivaa-holiday === Ursinha-afk is now known as Ursinha [19:26] jodh, Looking at upstart-dconf-bridge and it seems like it only emits events on values changing, is that correct? [19:27] jodh, Could it emit an event when the job is added to get the initial value? [19:27] Hmm, but that might not work. If a job runs, does that reset all the conditions? [19:30] Oops, seems I broke him. [19:30] Hello all. [19:33] tedg: i think the "typical" mode is that current values are emitted on the bridge start, for those events that jobs are sensitive to. [19:33] tedg: so if you have a job which is "start on dconf...." stopping and starting the dconf-bridge should emit the dconf event and thus start your job. [19:33] tedg: if that's not the case, it's a bug =) please file one. [19:34] tedg: as far as i know dconf bridge is not used yet ;-) [19:34] xnox, What happens after the job runs. Can it run again? [19:34] i.e. would the condition stay satisfied [19:34] tedg: is it a task or a daemon? events are fired, and are gone..... [19:34] tedg: there is no state information. [19:35] task [19:35] tedg: well, it will run again, if the event is ever emitted, which would be the case when dconf value changes, or dconf bridge starts a fresh. [19:35] Seems state is useful for somethings like this. Also xsession. [19:37] tedg: i know, but we don't have states. E.g. "start on started A and started B", "stop on stopped A or stopped B" does not do what one wants: after a & b started, the job is started, b stops, and the job stops. b starts again, the job is stuck in "waiting" for "started A" event which will never arrive, since A is already running. [19:37] tedg: so you cannot have a task which "run while dbconf", as there is no information provided for such thing. [19:37] tedg: "Also xsession" what do you mean? [19:38] xnox, So like "start on dbus-activation org.freedesktop.notification and xsession=foo" so then you could have multiple jobs do the dbus activation for a particular thing depending on the xsession. [19:38] xnox, But since it's not a state, that'd only work the first time. [19:39] Sorry "xession SESSION=foo" [19:39] dconf keys, I thought, were for things like "onboard" if a11y key is on, start onboard on desktop login, and stop it if dconf key disabled or desktop shutsdown. [19:40] tedg: don't do "and xsession=foo", do a prestart script checking the value of XDG_CURRENT_DESKTOP. [19:40] tedg: cause that environment variable does convey state. [19:40] (across all jobs, through the lifecycle of the session) [19:40] xnox, So, it can be used for that as well. I wanted to have a task run only if the user allowed it (i.e. could disable the task running with a dconf key) [19:41] So I'll check the key in the pre-start, that's fine. I was just expecting to use the dconf-bridge. [19:41] tedg: sure "start on dconf key", "pre-start check XDG_CURRENT_DESKTOP". or reverse, start on xsession, and check for dconf key in the pre-start. [19:42] tedg: bridges generate events only, and they are short-lived (fire once). [19:43] tedg: e.g. when one creates a new job, during a session, it will not see "xsession event" and thus doesn't auto-start straight away, one needs to poke it manually "$ start foo" or re-emit the event it's sensitive to. [19:44] That works. Just not what I was expecting. [19:45] Thanks for the explanation xnox! [19:45] tedg: also "start foo" by-passes "start on" conditions so you can't use it as a check, and make sure the job is not-started, whilst user disabled it via dconf. =/ [19:45] no worries, i do wish upstart could provide states. [19:45] it was proposed as a feature, but hasn't been at all started to be implemented. It is desired to have "while ...." instead of start-on/stop-on. [20:26] xnox: http://sourceware.org/bugzilla/show_bug.cgi?id=15544 [20:26] sourceware.org bug 15544 in libc "move idtype_t definition into sysdeps (bits) directory" [Normal,New] [20:42] infinity: sys/wait.h is confusing, on freebsd implementation it does not expose (include) definitions from signal.h and thus is at times useless by itself. [20:44] Ugh, the 1SS network explosion must have hung up all those jenkins jobs... [20:44] jibel: Can you sort out why it seems that all the autopkgtest jobs started by me glibc upload are still "running"? [20:44] jibel: Cause that doesn't seem reasonable. [20:45] jibel: (Also, can you restart the failed eglibc test itself, the failure is transient). [20:46] xnox: Or, if you have the VPN magic required to retry it? [20:46] * infinity has never bothered to get that going... [20:46] infinity: i have vpn magic to view the private jenkins, i have no magic loginz to push the buttons [20:47] also my fingers are in honey and it's hard to type [20:47] Heh. [20:48] I should have it - give me a moment [20:48] iz running [20:49] Tempted to just skiptest that eglibc upload, given that everything passed on the buildds, and the changes were very isolated. [20:49] now my fingers are clean, but some of the keyboard keys are in honey. [20:49] And I have on idea how all those autopkgtests could legitimately have been "running" for the last 12h, even with the 1SS network sadness. [20:49] now you have oasfyuiosdoasufyoa problems [20:49] s/on/no/ [20:49] infinity: they probably weren't, the britney integration often lies about running status [20:50] cjwatson: Will that magically clear up? [20:50] jenkins had the amd64 one down as failing, i386 passed [20:50] infinity: good question, I'm glad you asked that question [20:50] (quite possibly not, it's wonky) [20:50] * xnox internal compiler error at "oasfyuiosdoasufyoa" [20:51] cjwatson: Oh, eglibc/amd64 legitimately did fail, I was referring to all the rdep tests being "running" still. [20:51] cjwatson: Like, a couple dozen of them. [20:51] if jibel isn't around to investigate it properly then maybe just force-skiptest it once they go green in jenkins [20:51] Maybe I just broke jibel's jenkins. :P [21:35] infinity, cjwatson networking issue this morning broke autopkgtest in jenkins. And earlier this evening jenkins was marked for shutdown. I'll re-run the tests with an invalid status once the queue is empty. [21:41]