=== freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [04:12] Good morning [04:14] tyhicks: hey Tylor! [04:15] tyhicks: sorry, Tyler [04:15] tyhicks: your new d-bus introduces a stderr message "AppArmor D-Bus mediation is enabled"; that looks like a debugging leftover? [04:15] tyhicks: it breaks the bluez test (https://jenkins.qa.ubuntu.com/job/saucy-adt-bluez/66/) [04:17] hm, it's just a DBUS_SYSTEM_LOG_INFO [04:17] pitti: actually logging that the MAC is enabled is standard practice, we have 3 messages in the kernel about apparmor enablement [04:18] its a way of verifying that your mediation is enabled for an audit trail [04:18] jjohansen: that should go to kmsg though, right? [04:19] tyhicks: FYI, dbus doesn't currently propagate because britney thinks that the fluidsynth test is still running; once jibel comes online we'll clean that up [04:19] so it'll land today [04:21] pitti: yeah the kernel one go through kmesg, the dbus message might not be able to go through the audit system, I know there was problems with audit not being available or something like that when dbus came up. I've forgotten the details, tyhicks would know better [04:21] pitti: thanks [04:22] so I'll look at the bluez test and adjust it for the stderr message [04:23] meh, it breaks the network-manager, upstart, and ubuntuone-dev-tools tests too [04:24] ah no, that was the new kernel [04:26] pitti,jjohansen: as I understand it, to log through auditd would require dbus daemons to run with CAP_AUDIT_WRITE -- which the user-started ones won't have and probably shouldn't have. [04:28] which considering that now log messages will go through two separate logging systems, we may wish to reconsider using fscaps to start dbus with CAP_AUDIT_WRITE so we can return to a single log sink. [04:41] sarnold: yeah that sounds familiar, I remembered their being issues, but just didn't remember what they where [05:00] cjwatson, how do we change the syslinux theme on Ubuntu GNOME CD? [05:05] cjwatson, as in where does the image builder get the themes from? I couldnt find anything for the other flavours? [05:49] lifeless: hey Robert, how are you? [05:51] lifeless: I want to have a go at adding a python3-junitxml binary; a couple of other patches piled up in Debian BTS (dh_python2, unused build dep, etc.); are you interested in an NMU? [05:52] pitti: hello - the "AppArmor D-Bus mediation is enabled" message should be context aware [05:52] pitti: the message from the session bus should go to stdout and the message from the system bus should go to syslog [05:53] tyhicks: the bluez test runs its own dbus-daemon, I guess it comes from there; but it goes to stderr [05:53] oh, that isn't happening [05:53] pitti: hi [05:53] pitti: NMU away [05:53] pitti: I keep meaning to move that and a number of pythons into the Python packaging team [05:53] pitti: I'm good :) [05:53] tyhicks: but anyway, I guess that's really a problem in the bluez test, but I wondered why debug messages need to go to stderr if anything else goes to stdout [05:54] pitti: well, it is more than a debug message [05:54] pitti: but it should go to stdout [05:56] lifeless: while I'm at it, would you like me to do some other packaging refreshing, like updating to a non-deprecated dh level, dropping simple-patchsys and move to 3.0(quilt), and so on? [05:58] pitti: be my guest [05:58] pitti: though, hmm, quilt - eek [05:58] pitti: I still have the packaging for that in straight bzr [05:58] pitti: and the Python packaging team is svn [05:59] pitti: I'm not sure what setup works best there; but whatever it is, thats what I'd want to converge on. [05:59] lifeless: well, it' doesn't actually have patches; but I'd like to convert it to pybuild which makes things a whole lot easier [06:00] pitti: I created bug #1217710 for the stderr issue [06:00] i. e. drop teh cdbs bits and just use the current python packaging stuff [06:00] bug 1217710 in dbus (Ubuntu) "Message about AppArmor mediation status goes to stderr instead of stdout" [Medium,Confirmed] https://launchpad.net/bugs/1217710 [06:00] tyhicks: thanks, I'll investigate that a bit more and follow up there [06:00] tyhicks: ah, you can reproduce? good [06:00] pitti: I'll be happy to fix it tomorrow [06:00] tyhicks: thanks [06:00] pitti: that sounds great [06:01] pitti: to be clear, ubuntu4 can land as it is today and then I can prepare an ubuntu5 with the fix tomorrow, correct? [06:01] pitti: all I ask is you cross-check with the python packagnig team standard setup and use that [06:01] pitti: that *might* be 3.0(quilt), and if so cool. [06:01] pitti: I'm sure it's pybuild etc :) [06:01] tyhicks: yes; in theory britney should hold back dbus because it breaks the bluez test, but it doesn't (I'll ask jibel about that once he comes online) [06:02] pitti: great - thanks! (jibel just came online) [06:25] pitti, tyhicks good morning. Investigating the bluez case (once X stops crashing :( ) [06:26] jibel: bonjour [06:26] jibel: we have a handle on the actual failure; I just wondered why it isn't in excuses for holding back dbus [06:26] hi jibel [06:26] jibel: btw, could you please run your magic script to fix the "fluidsynth 1.1.6-2: RUNNING"? it finished long ago [06:28] lifeless: first time that I have used pybuild; it's lovely [06:28] pitti, right, that's the part I'm checking. The result is correct in the history file, I'm looking why it is not reported correctly to britney [06:29] lifeless: it's quite straightforward now: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/pyjunitxml/saucy/revision/11 [06:29] * pitti remembers the time of all these "set -ex; for python in $(shell py3versions -r); do" overrides [07:00] lifeless: ok, all done; I'll upload to saucy, and (with a consolidated changelog) to Debian [08:24] jibel: I removed the broken libgtkada from saucy-proposed again; how would I convince britney to stop blocking cairo now? (libgtkada test is green again) [08:27] wgrant: ~package-import is member of ~ubuntu-branches (which i thought gives the privileges to set the branch for series), but now core-dev is member of ~ubuntu-branches as well. [08:27] so ~ubuntu-branches doesn't sound that special any more. [08:28] xnox: Right, ~ubuntu-branches used to be a celebrity, but now it just owns the branches. === smb` is now known as smb [08:28] ~package-import's primary permission today is its membership in ~ubuntu-core-dev. The upload privs allow it to set official branches. [08:30] wgrant: maybe ~package-import shouldn't be direct member of ~ubuntu-branches then, since it's part of ~ubuntu-core-dev anyway. [08:30] It shouldn't make any difference now. [08:31] wgrant: shall i file a bug against udd & launchpad, to figure out what udd is trying to do, why, whether it's needed and how to fix it (in either udd or launchpad) [08:31] I think there's a question open atm that I haven't had time to look at yet. [08:31] https://answers.launchpad.net/launchpad/+question/234047 [08:33] wgrant: and there is comment from maxb about it as well. [08:33] Right [08:35] infinity: did you shelve libav 9? [08:37] * pitti sobs at lillypilly having a load of 35 [08:37] "The upload privs allow it to set official branches." .... they used to [08:37] it never fell < 10 in the past week [08:37] But now, they don't for old series [08:37] maxb: Not quite. [08:38] maxb: It used to be able to set for obsolete series because ~ubuntu-branches was a celebrity. [08:38] Which could set anything anywhere. [08:38] Oh [08:39] I thought it had not been a celebrity for a long time, I didn't realise that was a relatively recent change [08:39] Though this particular failure may be because of the new obsolete series restrictions, it could occur with the release pocket since we made ~ubuntu-branches a non-celebrity. [08:39] In fact, let's see if relaxing the obsolete series restriction works. [08:40] Laney: It's not Thursday yet! [08:40] siretart: *nudge* [08:40] heh [08:40] well... I'm trying to upgrade to gstreamer 1.1 and gst-libav1.0 1.1.3 requires this version [08:41] of course, there's always the internal copy of libav :-) [08:41] Laney: Ew, no. [08:41] Laney: Bad Laney. [08:41] see my previous poke [08:41] Laney: Honestly, I'd probably grant an FFe and try to jam the transition through ANYWAY, just to avoid having to do it in the 14.04 cycle. [08:41] xnox, maxb: I've relaxed the obsolete series restriction for the primary archive and requeued cloud-init, so we'll see if this works. [08:42] siretart: I'll be your best friend if you get me the new libav in saucy before Thursday. [08:43] OK, I'll upload the rest and leave libav for a bit then [08:43] Laney: If it had a sane versioned build-dep, you can do it now, and just assume libav9 is on the way. [08:44] Mmm, yeah it does. [08:46] * infinity debates debugging this eglibc test failure further, doing expense reports, or napping. [08:46] Note that's "napping in oppressive humidity and heat", so not actually much more fun than the other two activities. [08:46] Didn't you promise messagingmenu-sharp? :P [08:46] Laney: Did I? [08:46] infinity, Laney, cjwatson: current dbus in proposed is creating issues (basically the apparmor integration is buggy on buildds and prevent dbus from starting, which makes tests unhappy and block landing) [08:47] infinity, Laney, cjwatson: do you have any objection to delete it to reupload once we have the issue fixed? [08:47] seb128: oh, I just fixed the wrong "RUNNING" in excuses, should I un-fix that to keep it in -proposed? [08:47] seb128: (IOW, it'll migrate soon) [08:47] pitti, yes, please [08:47] or just delete it from proposed [08:47] I was asking before doing it, in case there is a good reason we shouldn't [08:48] pitti: You fixed at the jenkins level you mean, or...? [08:48] infinity: no, jibel said to update the .history file on lillypilly [08:48] Ick. [08:48] Please just use britney hints for one-time things like that. [08:49] something else is wrong there; the failing bluez test ought to hold back dbus [08:49] Hacking the actual infrastructure doesn't seem helpful unless we're FIXING the infrastructure. [08:49] infinity: well, jibel is at debugging it [08:49] ok, I take that as "no objection" [08:49] * seb128 deletes [08:49] seb128: ack [08:49] seb128: Yeah, delete away. [08:50] seb128: I assume a fix is on the horizon, though? [08:50] infinity, yes, tyhicks is on it [08:50] yep [08:51] infinity: I'll reupload an entirely new dbus that includes the fix [08:53] infinity: I thought you said so to hyperair [08:53] pitti, jibel: cairo moved to saucy, thanks! [08:53] the upstream / Debian guy has been asking us about it with increasing frequency [08:53] seb128: yw [08:54] Laney: Oh, I think he asked me about it last week, I told him to poke me later, and he never poked, and I forgot. [08:54] Doh. [08:54] tyhicks, https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/1217757 might be due to that dbus as well [08:54] Well, here be a poke. [08:54] Launchpad bug 1217757 in gedit (Ubuntu) "Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. " [Undecided,New] [08:54] infinity: i did, but i don't think you read your scrollback pings [08:54] infinity: at least, you appeared afk all the times i tried [08:54] hyperair: I normally do. May have missed some, it's been a weird week. [08:54] heh oh well [08:54] hyperair: So, is this going to Debian as well, or just us? [08:55] it's in debian already i think [08:55] oh wait [08:55] It sure isn't. [08:55] it'll get into debian when rdeps are done [08:55] it's messaging menu stuff after all. the status of packaging all of the indicator stack is rather incomplete in debian iirc [08:55] hyperair: See, this would have been much less hassle if you got it into Debian and synced, but meh. I'll review it here quickly. [08:56] Isn't MessagingMenu an Ubuntu thing? [08:56] infinity: ^ that's the problem. [08:56] Laney: It is, but there's no reason we can't have it in Debian too, and some of the bits are, AFAIK. [08:56] some bits are, but it's horribly incomplete [08:56] Yeah. We should fix that. [08:56] But not today. :P [08:56] yeah [08:57] * hyperair thinks zhenech was taking care of that.. [08:57] seb128: thanks - I'll look into that some more [08:57] tyhicks, I commented on the bug [08:57] tyhicks, the a11y stack uses its own private bus, not the session one [08:57] tyhicks, so that's sort of a special case, maybe that's not handled well by the confinement? [08:58] seb128: it is a possibility if an app on one end of the dbus connection is confined [09:01] infinity: oh yeah, i think i recall why i didn't get involved in packaging indicator stuff for debian. it's all bzr. >:( [09:02] I'm not sure that pkg-ayatana team is really active any more [09:02] bleh [09:03] It could probably do with a friendly hijack by someone who actually intends to use the stack in Debian. [09:03] maybe if it didn't use bzr.. [09:03] You mean upstream? [09:04] Cause I don't really care what my upstreams use. Hide it in a get-orig-source debian/rules target and scream "LA LA LA" while you ignore the upstream VCS. [09:04] gosh [09:04] yeah for vcs trolling... [09:04] pitti: you were right about lillypilly [09:04] If you mean the Debian packaging, as Laney points out, pkg-ayatana is probably dead. [09:04] even http sucks [09:04] it's the same commit/diff/push/etc than with most other vcses, that should be good enough for packaging [09:07] infinity: no, pkg-ayatana uses bzr. [09:07] maybe it deserves a hijack.. [09:08] seb128: that's if you only use commit/diff/push/etc [09:09] Laney: too much stuff running on it these days :/ [09:09] and i was just being grumpy about it, not intentionally trolling. you turned it into trollbait and bit on it. [09:09] pitti: the archive box should offload some of that [09:09] hyperair, which, for a packaging vcs, is mostly the case ... (at least if you don't do full source based on upstream style) [09:09] hyperair: Accepted, built, and accepted again. [09:10] infinity: thanks [09:10] seb128: which i do. [09:10] seb128: while i'm at it, i also use pristine-tar. [09:10] and i have a whole bunch of custom scripts built around my workflow on git, and bzr breaks all of that [09:11] and i dislike the way the bzr tools work [09:11] can we end this here now? [09:12] well, you started it :) [09:12] hyperair: Only via a fight to the death with foam swords emblazoned with catchy sayings about your favourite VCS. [09:12] pitti: 17:09:17 and i was just being grumpy about it, not intentionally trolling. you turned it into trollbait and bit on it. [09:12] infinity: Etched in reverse runes? [09:12] * hyperair sighs [09:12] RAOF: Etching a foam sword is hard. I was thinking written in Sharpie. [09:13] couldn't a foam cutter thing work? [09:13] Lasers. [09:13] It's the solution to everything! [09:13] Lasers solve everything. [09:13] Jinx. [09:13] oh yes, lasers. [09:13] to be cheap you could just use a soldering iron as well [09:14] Well, a nice precision CNC would do the trick. But a laser CNC would be nicer. Maybe it's time to upgrade. [09:30] wgrant: failed due to existing merge-proposal \o/ set it to rejected. [09:31] wgrant: requeued cloud-init again. [09:31] xnox, hi [09:31] darkxst: hello. [09:32] so I got no where trying to setup a pam session, python3-pam seems broken [09:32] but anyway can you merge my changes before feature freeze? [09:35] darkxst: sure. Gnome-shell is not listed as alternative dependency, but I can fix that up. [09:35] xnox, and really need to get the sso thing fixed before beta, but I have no idea what is causing it other than presumably some missing dep [09:35] xnox, or just disable sso on ubuntu GNOME [09:35] darkxst: i'll check / fix u1 [09:38] darkxst: the syslinux and gfxboot themes (you probably need to change both - just make sure to keep the exact same image formats) are in data/saucy/ in lp:~ubuntu-cdimage/debian-cd/ubuntu [09:40] pitti: cool, thank you! [09:42] roaksoax: seems like everything works now "checking for COROSYNC... yes" will upload lvm2 in a moment. [09:42] cjwatson, thanks [09:47] doko_, if you are around can you take a look at the build failure for libunwind - I can get things building OK on amd64 but all other archs are failing with a lzma linking error [10:00] roaksoax: lvm2 uploaded, now it build-dep-waits on dlm to be promoted to main. pinged release team about it. [10:03] can we drop the packagekit stuff from the sync-blacklist now? [10:03] jbicha: I just did [10:04] jbicha: I'm working through a sequence of things to sponsor provided by glatzor [10:04] cool, thanks [10:10] cjwatson: I have gnome-packagekit ready or I can defer to you if you just want to handle it === freeflying is now known as freeflying_away === DrKranz is now known as DktrKranz [10:16] jbicha: is it the same as glatzor's work in bug 1200303? [10:17] bug 1200303 in gnome-packagekit (Ubuntu) "Sync gnome-packagekit 3.8.2-4 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1200303 [10:17] (mistitled, it's not a sync) [10:18] yes [10:19] jbicha: feel free then === sergiuse1s is now known as sergiusens [11:07] pitti, latest upload of cloud-utils broke the test VMs [11:07] jibel: yeah, I noticed; but it's not really uninstallable in saucy [11:08] jibel: is that because it's already pre-installed? [11:09] pitti, not sure what's wrong. cloud-utils is installed by default on cloud images and 0.27-0ubuntu3 splits cloud-utils into cloud-guest-utils and cloud-image-utils [11:09] furthermore there is no daily cloud-image for today [11:12] pitti, ah file conflict during package upgrade http://paste.ubuntu.com/6036233/ [11:12] smoser, ^ [11:13] when I start soffice on saucy; and select a sheet - it's displaying a ludicrous number of columns/rows that I can hardly see - is that just me or are others seeing it? [11:13] jibel, smoser: indeed, cloud-*-utils need a C:/B: on cloud-utils (<< 0.27-0ubuntu3) [11:13] err, C:/R: === gusch is now known as gusch|lunch [11:33] jamespage, will do [11:34] doko_, thanks [11:38] jibel: annoying, this is breaking even more tests.. [11:39] jibel, smoser: as smoser didn't respond, I'll upload cloud-utils now [11:39] bug 1217846 [11:39] bug 1217846 in cloud-utils (Ubuntu) "package cloud-image-utils (not installed) failed to install/upgrade: trying to overwrite '/usr/bin/ubuntu-cloudimg-query', which is also in package cloud-utils 0.27-0ubuntu2" [Undecided,New] https://launchpad.net/bugs/1217846 [11:39] pitti, k, that'll be faster than me fixing all the base VMs manually [11:41] jibel: done [11:42] pitti, thanks [11:43] yay, all i386 builders busy [11:43] shouldn't last that long [11:43] yeah, compiz is almost done [12:04] xnox: That looks like success. [12:06] wgrant: \o/ === gusch|lunch is now known as gusch [12:11] jibel, i'm sorry. and i told you yesterday i wouldn't break things. [12:13] thank you pitti and jibel [12:13] sorry. [12:18] smoser, it's okay, I'm running the tests again with the new package. It seems fine now. === _salem is now known as salem_ === doko_ is now known as doko [13:02] jibel: ah, you already retried the recent lot, thanks [13:02] (back from lunch, was about to kick them) [13:07] Hi everyone [13:07] I would need some core-dev to ACK the following packaging change: http://paste.ubuntu.com/6036553/ [13:08] ogra_: ^? ;) [13:08] kenvandine: ! [13:08] sil2100, looks fine [13:08] kenvandine: morning, as you just joined I guess you have 15 seconds? [13:08] hey sil2100 [13:08] ogra_: thanks! [13:08] kenvandine: nevermind ! [13:08] :-D [13:10] kenvandine: but while you're still around, maybe you know something from the daily-release bits... [13:10] kenvandine: since I'll be switching to manualpublish: True for all stacks (request from asac which got ACKed more-or-less by seb128) [13:11] kenvandine: do you know if I have to redeploy a stack after that? [13:11] kenvandine: hi, let me forward the mail./ also to cypher [13:11] i think so [13:11] ;/ [13:11] kenvandine: thanks [13:11] sil2100, but i doubt you need to reconfigure the branches, so use the flag to skip that part [13:13] Hello everybody. Why does "bzr branch ubuntu:saucy-proposed/blackbox" say "ERROR: Not a branch"? https://launchpad.net/ubuntu/+source/blackbox shows a version in saucy-proposed. [13:14] Because http://package-import.ubuntu.com/status/blackbox.html [13:14] cjwatson: Thanks. [13:23] xnox: cool thanks! [13:32] xnox: dh-python fails with real errors now (the cloud-init problem is fixed in saucy now) [13:32] pitti: looking. it passed here. [13:33] xnox: it can't ever have, as the nosetest outputs to stderr [13:33] pitti: and declares that stderr is allowed... [13:33] xnox: "Restrictions: allow-stderr" or teach it to output to stdout [13:33] xnox: ah, then I guess it's the dh-python test which errors out with 1 [13:34] pitti: yeah t205 failed. [13:38] pitti: haha, so python-support must be installed for the dh_python2 tests to work *lol* [13:38] * xnox goes to fix. [13:51] xnox: uh, how that? not dead enough yet? [13:52] pitti: dh_python test-suite doesn't use --with python2, instead it was doing "override_dh_pysupport:" to call dh_python2. Well, neither dh_pysupport nor override_dh_pysupport are called any more, if python-support is not installed. [13:52] so i ported those tests, to not rely on dh_pysupport =))) [13:54] *applaud* === Dr_Who is now known as tgall_foo === sam113101 is now known as sam113101_afk === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === sam113101_afk is now known as sam113101 [14:59] barry beuno cjwatson dholbach sergiusens ssweeny xnox lool: can I move this session up to be 18:00 today? tvoss__ needs his session moved to tomorrow. http://summit.ubuntu.com/uds-1308/meeting/21909/foundations-s-touch-download-service/ [15:00] slangasek: fine by me, but I am not mandatory [15:00] slangasek: yep. i see no other conflicts at that slot [15:01] slangasek, sure [15:01] xnox: nice, it passed now [15:01] slangasek, sure thing [15:01] slangasek: sure. [15:01] sure [15:02] slangasek: I might need to be in the click/appstore CI session at that time, but I doubt I'm required for all of that, and in any case I already gave xnox my feedback on the rapid start session to pass on in case I couldn't make it [15:02] slangasek: yes [15:03] slangasek: I have some conflicts, but nothing critical [15:03] ok, moving - thanks [15:04] slangasek, thanks for the help [15:06] oh, you said the touch download service session anyway, not rapid start ... [15:17] do we support updates from LTS to newer non versions when they are out of their support period? [15:17] nonLTS versions [15:18] to give some context, that's being asked in the libreoffice session [15:19] e.g if next year precise get a libreoffice newer than quantal, is that an issue? [15:19] (that would be problematic for precise->quantal updates) [15:23] seb128: definitely not supported, we have a hard time even supporting upgrades from EOLed non-LTS versions to a supported LTS [15:23] slangasek, ok, thanks [15:42] cjwatson, libunity-webapps hits "autopkgtest for unity-firefox-extension 2.4.7bzr13.04.15-0ubuntu1: FAIL (Jenkins: public, private) " [15:43] cjwatson, well, we get the rebuild uploaded, but it's blocked by britney on that, seems like those tests were never green, you might want to force it [15:43] yeah, I was just checking that [15:44] if nobody cares about that test, maybe it should be deleted? [15:44] More always broken tests that nobody cares about :| [15:44] (it looks like it's failing due to trying to go off to pypi, rather than because the package is broken ... i.e. test framework failure) [15:45] seb128: force-badtest'ed, anyway [15:45] k [15:49] Mirv: Debian's already started uploading 5.1.1, so a direct merge ought to be easy enough when the time is right. [15:50] ScottK: that's nice, I'd like to sync at least 9 packages directly [15:51] we've some package transitions because of raring, and then qtbase+qtdeclarative+qtwebkit additional patches, as approximate summary [15:52] Also qtcreator. [15:52] It'd be nice to get the Ubuntu SDK stuff into a different source so we could sync that too. [15:53] yes, that's the plan of the SDK team, now partially done but the real compiled plugin also needs to move to lp:qtcreator-plugin-ubuntu [16:04] Lamont Jones has uploaded bind9_9.9.3.dfsg.P2-3 to incoming.debian.org and I know he planned to get it into saucy prior to the FeatureFreeze, but I am not seeing the package in Ubuntu yet. Ubuntu doesn't have an incoming.ubuntu.com and I checked http://archive.ubuntu.com/ubuntu/pool/main/b/bind9/, where else should I look for it? [16:05] lamont: ^- [16:05] linuxtech: https://launchpad.net/ubuntu/+source/bind9 [16:05] if it's not visible there it hasn't been uploaded [16:05] I was letting it age until this afternoon [16:06] It's not there yet, thanks! [16:06] we don't have an incoming.ubuntu.com because we don't need one :-) === dholbach_ is now known as dholbach === dholbach_ is now known as dholbach [16:48] barry: os.path.exists is lying to me! It says False, when the right answer is to raise PermissionError [16:49] Not sure I agree [16:49] I think of os.path.exists as something that should parallel test -e [16:50] Anyway it's documented behaviour :-) [16:50] xnox: well, os.path.exists() returns False if os.stat(path) raises an OSError [16:51] does not check what kind of OSError you get [16:52] cjwatson, xnox: correct :) http://docs.python.org/3/library/os.path.html#os.path.exists [16:52] barry: but "try: found=True; os.stat(path) except OSError: found=False" is ugly! [16:53] xnox: EAFP! [16:54] barry: European Association of Fish Pathologists ? [16:54] * xnox is confused [16:54] add "python" to your google search terms :) [16:55] i see. ok [16:55] * xnox goes to apply. === bschaefer_ is now known as bschaefer [17:27] seb128: 1217841 has been six hours without retracing, are they broken again? [17:29] sarnold, yep, down again [17:29] I hate those retracers :p [17:29] the stacktrace doesn't really make sense to me [17:29] I guess I'm going to untag the bug it fails on so it can keep retracing others [17:30] then check with pitti tomorrow [17:33] seb128: heh, yes, I can imagine :) they're very nearly magical, and when they work, it's impressive, but daily work stoppages is less than ideal. Thanks for re-poking them. :) === bfiller is now known as bfiller_ === bfiller_ is now known as bfiller [17:35] sarnold, is that your own reported bug you are checking on or do you watch some list of bugs coming from somewhere? [17:35] anyone has an idea why a package can build on amd64, armhf, and powerpc but not on i386? See https://launchpad.net/ubuntu/+source/ghostscript/9.10~dfsg~rc1-0ubuntu1. [17:36] tkamppeter, i386 builds the arch all binaries, the other archs not [17:38] seb128, yes "make" seems to have succeeded, so it seems that it is in the distribution of the built files in the binary packages, but there is no useful error message after the succeeded "make". [17:38] tkamppeter, that doesn't seem the case here [17:38] tkamppeter, the error is at the start of the log [17:38] tkamppeter, [17:38] seb128: I just go through the pile of bugs labelled 'security' and try to shove them on their way. When I notice something hasn't been retraced in a handful of hours, I ask if it's been held up. not that I care abou any specific bug, but that it'd be nice to keep things moving for users. :) [17:38] "cp ./openjpeg/opj_config.h.in.user ./obj/opj_config.h [17:38] cp: cannot create regular file './obj/opj_config.h': No such file or directory [17:38] make[1]: *** [obj/opj_config.h] Error 1" [17:38] sarnold, right ;-) [17:39] seb128: since nearly everything with a coredump is labeled a private security problem, I figure they won't get any attention at all from anyone until we can knock that 'private' off of them :) [17:39] tkamppeter, could be a race bug combined with the -j option [17:39] tkamppeter, let me retry the build [17:41] sarnold, any news on the openjpeg mir btw? ;-) (seeing that ghostscript build made me think to it) [17:42] seb128: yes, I think I'm about 1/3 of the way through it. it's highly intricate / global-variable heavy code. :/ [17:42] sarnold, I guess there is no hurry, ghostscript went back to use their copy because some fix didn't made upstream yet it seems [17:43] sarnold, I'm mostly asking because I would like to build poppler with it though [17:43] sarnold: If other image manipulation libraries are anything to go by, I think we can just count on it being insecure by design and weep quietly as we let it in anyway, right? :P [17:43] infinity: haha, yes. :) [17:44] seb128, sarnold, from the Ghostscript side I will not need openjpeg in this cycle. My attempts to build GS with system openjpeg failed and I returned to Ghostscript's own openjpeg. [17:44] cripes that's just as bad :) hehe [17:45] it'd be nice to only have one copy of whatevre it is... hehe. [17:45] Indeed. [17:46] seb128: You mentioned "some fix didn't make it upstream", surely we could identify that and carry it in our system copy, rather than perpetuating the code duplication of this (apparently hideous) codebase. :P [17:46] tkamppeter, ^ [17:47] infinity, right, I was mostly reading the changelog from that ghostscript upload from tkamppeter [17:47] sarnold, infinity: btw I should try to update our version to the current serie (1.5 at least) [17:48] seb128, it seems that the "make" of GS seems to try to copy a file into obj/ before mkdie obj/, perhaps I have to call mkdir obj before running "make"? [17:49] tkamppeter: That usually means they're missing a dependency in one of their makefiles. [17:49] seb128: I know a guy who needs help getting a dependency of his project updated. Who should I point to his (non-Desktop, Universe) bug report to? https://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/1212481 [17:49] tkamppeter, why did it work on other archs? [17:49] Launchpad bug 1212481 in couchdb (Ubuntu) "Saucy: CouchDB 1.4.0 needed to work with Erlang 16.b.1" [Undecided,Confirmed] [17:49] tkamppeter: Which is exacerbated by building with multiple threads. [17:49] qengho, tell them to subscribe ubuntu-sponsors I guess? [17:49] Thx! [17:50] seb128, why it fails on 1386 and succeeds on all the others I do not understand. [17:51] tkamppeter: Because i386 calls different rules than other arches. [17:51] tkamppeter: It can probably be reproduced on amd64 by using "dpkg-buildpackage -b" instead of "dpkg-buildpackages -B". [17:52] s/buildpackages/buildpackage/ [17:55] infinity, and the build server does "make -j8", my machines at home do not use the -j option when building GS. [17:55] tkamppeter: They would if you used DEB_BUILD_OPTIONS="parallel=8" :P [17:56] If your package claims to support that, it will be used. [17:56] seb128, infinity, should I perhaps make -j on the build servers be suppressed, perhaps by DEB_BUILD_OPTIONS="parallel=1"? [17:57] seb128: thanks, amd64 is again catching up [17:57] Anyhow, got the same failure here with -j4. [17:57] Let me try with 1. [17:58] Ugh, why is this still CDBS? [17:59] tkamppeter: I believe the CDBS way is to set DEB_PARALLEL_JOBS to 1. [17:59] I think. [17:59]