[00:32] I'm trying to recompile gimp 2.6 for trusty (I hate the new 2.8 interface and its impedance to simple workflows). I run into http://paste.debian.net/94136/ How can I fix that? I'm basing my work on the https://launchpad.net/~malcscott/+archive/gimp-2.6/ PPA that compiled gimp 2.6 for saucy and raring. === Laibsch1 is now known as Laibsch === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === zz_nhayashi is now known as nhayashi === TheDrums is now known as TheMaster === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === TheMaster is now known as DalekSec [06:42] good morning === apachelogger is now known as hsitter === hsitter is now known as apachelogger [08:08] happy distro-info-data outdated day [08:08] :-) [08:25] it seems there are some major problems with linux-crashdump package [08:26] 1.) it does not get enabled by default ... /etc/default/kdump-tools does set 0 and comment out vital options to make it work [08:27] (according to the wiki installing linux-crashdump and reboot should make it work, which is apperently not the default behavior with the current package) [08:27] cat /sys/kernel/kexec_crash_loaded will show 0 after reboot [08:28] So I manually enabled the options in /etc/default/kdump-tools and rebooted === popey_ is now known as popey [08:28] now cat /sys/kernel/kexec_crash shows 1 [08:29] dmesg | grep -i crash does not indicate memory has been reserved for the crash kernel [08:30] simulating a kernel crash just freezes the system, no kernel is started [08:30] only a kexec_cmd can be found in /var/crash afterwards [08:37] jamesh, happy birthday! :) [08:37] kdeuser56: I' [08:38] kdeuser56: I'm not sure that's the case but I believe we disable some kernel crash debugging for non-development releases [08:38] zyga: ? [08:39] zyga: my install is from the daily image days [08:39] zyga: okay how to enable it? [08:41] zyga: https://wiki.ubuntu.com/Kernel/CrashdumpRecipe and https://help.ubuntu.com/12.04/serverguide/kernel-crash-dump.html do not confirm what you say [08:47] mardy, hey, could you have a look to bug #1194465 and reassign it if needed? it's a segfault in libsignon-glib, could be a bug in the client code or in the lib... [08:47] bug 1194465 in unity-scope-gdrive (Ubuntu) "scope-runner-dbus.py crashed with SIGSEGV in auth_session_remote_object_destroyed_cb()" [Medium,Confirmed] https://launchpad.net/bugs/1194465 [08:47] seb128: OK [08:47] mardy, thanks [08:47] zyga: do you know who to ping in order to get help? [08:51] kdeuser56: I don't know, I'm sorry [08:51] zyga: does it work for you? [08:52] kdeuser56: I don't use that [08:54] guy with the same problem http://comments.gmane.org/gmane.linux.debian.user/459540 no solution :-( [09:09] yay i has non-fugly chromium again. [09:15] happyaron: That ubuntukylin-default-settings doesn't actually contain the change it claims to. [09:16] infinity: re-uploading [09:17] happyaron: So, uhm. We had planned to release in hours. Did you really want to respin and retest all your images? [09:17] happyaron: Well, all two of them. [09:17] infinity: that really depends on the will of JackYu, not mine. [09:17] JackYu didn't answer that question when I asked them on #-release [09:18] :( [09:18] So it's kind of hard to tell what their will is [09:18] sudo kdump-config load gives me "efi memory descriptor version 0 is not supported!" [09:18] dholbach: thanks! [09:19] kdeuser56: ubuntu-bug kdump-tools [09:19] infinity: any idea what I could try? [09:19] cjwatson: they asked me in #ubuntukylin-devel for uploading [09:19] kdeuser56: You could try filing a bug. [09:20] happyaron: yeah, that's not quite the same thing as a multi-hour respin cycle [09:20] infinity: always instantly filing a bug without doing research is bad behavior [09:20] happyaron: Can you determine if they really intend for a respin (about an hour from now, it would be), and then re-validating the ISOs, all within, say, 2/3 hours? [09:20] bug 1308889 is pretty bad for polish, I'll grant [09:20] bug 1308889 in Ubuntu Kylin "ubuntu-kylin-docs was not installed by default in latest image" [Critical,New] https://launchpad.net/bugs/1308889 [09:21] infinity: let me ask again [09:22] cjwatson: I totally read your sentence as Polish, not polish, and was monumentally confused. [09:22] infinity: they say yes. [09:23] happyaron: Alright. Let's shove this through as quickly as we can manage, then. [09:27] infinity，yeap, we want to check the problem before final release. We will re-validating the ISO asap === shuduo_ is now known as shuduo [10:07] rbasak: it looks as though mod-auth-mysql has been ported, and it's in trusty; see https://launchpad.net/ubuntu/+source/mod-auth-mysql/+changelog. Do we still need to proceed with bug 1278995? [10:07] bug 1278995 in mod-auth-mysql (Ubuntu) "Please remove mod-auth-mysql from Trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1278995 [10:08] dead upstream or not, it's useful enough that I'm sort of inclined to keep it if it's working [10:14] mvo, could you look at bug 1308657 ? it is another multiarch upgrade issue similar to grep:i386 but in this case apt prefers to upgrade the foreign arch than native and fails to find an upgrade path. [10:14] bug 1308657 in ubuntu-release-upgrader (Ubuntu Trusty) "Ubuntu 13.10 to 14.04: failed to upgrade libsmbclient:amd64 with libsmbclient:i386 installed." [High,Triaged] https://launchpad.net/bugs/1308657 [10:19] jibel: I have seen it, I'm a bit unsure what to do about it === paulliu is now known as paulliu-dinner [10:21] jibel: but let me have another look right now [10:21] jibel: (and thanks for making me aware of the issue) [10:24] infinity, ubuntukylin-default-settings becomes ready, should we request a rebuild now? [10:26] maclin: I'm going to rebuild for you in a just a second when the mirror settles. [10:27] infinity, nice, thanks a lot:) === MacSlow is now known as MacSlow|lunch [10:34] cjwatson: I'm not sure if it's working. When I looked, I got the impression that it would be functionally broken without a significant port, due to API changes [10:35] xnox: ^^ any thoughts? Do we have something that builds now, but is actually functionally broken? [10:37] rbasak: which package / bug are you talking about? [10:38] xnox: sorry, https://bugs.launchpad.net/ubuntu/+source/mod-auth-mysql/+bug/1278995. See backscroll. [10:38] Launchpad bug 1278995 in mod-auth-mysql (Ubuntu) "Please remove mod-auth-mysql from Trusty" [Undecided,Confirmed] [10:39] xnox: looks like you fixed the FTBFS, but when I looked previously I left it because it looked like more major changes were needed to get it functional with Apache 2.4. [10:39] rbasak: right, i found patch on upstream bug tracker and fixed FTBFS, because that was quickest way to complete a transition or some such. [10:40] rbasak: if it's buggy we can sru fixes for it. [10:40] rbasak: no need to remove it. [10:42] xnox: ok. cjwatson: I'll mark the bug invalid, thanks. [11:02] jamespage: do we still want to do bug 1252375? the samba migration issues seem to have been long since solved [11:02] bug 1252375 in zentyal-samba (Ubuntu) "Please remove zentyal-samba + zentyal-printers from trusty" [Medium,Confirmed] https://launchpad.net/bugs/1252375 [11:03] (by way of Depends: samba (>= 4) | samba4, apparently) [11:03] happyaron / maclin: Your images are done, please test in a hurry. [11:04] cjwatson, hmmm - I don't actually have any way of confirming that its functional [11:04] infinity: thanks! [11:05] happyaron: Please do make sure it's done very quickly, I intend to push things our quite soon. [11:05] s/our/out/ [11:05] ok [11:05] xnox: similarly, Adam fixed node-stringprep's build a day after you filed bug 1264691 - do we still need that? [11:05] bug 1264691 in node-stringprep (Ubuntu) "RM from -release / demote to -proposed, not in testing, FTBFS, possibly incompatible with current nodejs" [Medium,Confirmed] https://launchpad.net/bugs/1264691 [11:05] infinity, thanks, we will do the test asap [11:05] maclin: Ta. [11:06] cjwatson: mark invalid. [11:06] xnox: ok, will do, thanks [11:06] jamespage: I guess if there's doubt I'd prefer to leave it in its current state and maybe SRU fixes [11:07] running out of time :) [11:07] cjwatson, ok - leave it in then [11:09] infinity, there are no zsync file? [11:11] infinity, I get an error when download the image: The requested URL /ubuntukylin/daily-live/20140417.1/trusty-desktop-i386.iso was not found on this server [11:11] infinity: did you let the Mythbuntu people know to mirror their images, btw? [11:26] cjwatson: Who was asking for that? [11:26] cjwatson: They should probably also *test* their images. :P [11:28] infinity: tgm4883 and Daviey === greyback is now known as greyback|lunch [11:34] hi infinity, the images of 20140417.1 for Ubuntu Kylin is still not ready, according to http://cdimage.ubuntu.com/ubuntukylin/daily-live/ [11:35] odd, no obvious rsync activity on nusakan [11:36] infinity, cjwatson, should we rebuild it again? [11:36] no no no no no no no no no [11:37] zaniah has plenty of space, though it is pretty low on inodes [11:37] but there are only 5000-odd files on cdimage; that can't be making a huge dent there [11:38] I've poked another sync to see if that helps [11:38] oh, there we go, either that worked or it had caught up by itself just before [11:38] JackYu: http://cdimage.ubuntu.com/ubuntukylin/daily-live/20140417.1/ looks fine now [11:38] \o/ [11:39] JackYu: for reference, hitting rebuild for this kind of internal mirroring thing will be actively counterproductive, so please don't reach for that first [11:39] wow, great! [11:39] cjwatson, sure:) === MacSlow|lunch is now known as MacSlow === maclin_ is now known as maclin === paulliu-dinner is now known as paulliu === _salem is now known as salem_ [13:25] if there is one script in a package that depends on python2 and the rest is python3 is it acceptable to use a Depends: python2 for just that package containing the file? [13:31] bdmurray: hi, the libvirt saucy-proposed addressed 4 bugs; 3 are verification-done, one apparently is not fixed, but nothing regressed. i think security team wants to push something. === greyback|lunch is now known as greyback [13:31] bdmurray: can we promote the libvirt to -updates, or should i push a new package without the 4th (unverified) fix? [13:31] (in which case i'd do it after security teampushes a new one) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === nhayashi is now known as zz_nhayashi [14:04] maclin: Are you happy with your ISOs? [14:06] infinity, sorry that we are still syncing the ISOs. the network is so slow... [14:07] maclin: I see lots of tests registered for your ISOs, so someone has tested them, I assume... [14:07] maclin: But no one's marked them ready. [14:07] we have submit test results of 20140417 ISO. [14:11] I cannot confirm wheather the new ISOs would be downloaded before I mark the tracker ready. So the results are submitted. === maxb_ is now known as maxb [14:24] Hi [14:24] Hi people! ready for the release? [14:26] bad news http://geebzor.com/tech/linux/canonical-delays-release-of-ubuntu-14-04-trusty-tahr/ [14:27] well I dont know if this is authentic, someone posted that in the other channel [14:28] it's nonsense [14:28] and please don't pollute #ubuntu-devel with #u-r-p madness :) [14:28] hehe [14:29] cjwatson: Would you please voice me in #-release [14:30] Hola [14:31] done [14:31] ta [14:44] hallyn: how are you certain that libvirt has not regressed? [14:44] bdmurray: 3 other verification-done's with no regressions reported? :) [14:45] bdmurray: the one which was not verified was the scaries one so if you want to drop it i'm ok with that [14:45] scariest [14:45] let's just do that. [14:45] mdeslaur: ^ you have something to push for libvirt saucy-security? [14:45] pls just drop what's in -proposed [14:46] hallyn: eventually, yes [14:46] hallyn: it can still wait a while if there's a chance someone will verify it [14:48] mdeslaur: no verification failed on one out of 4. so i'll have to re-push a version with only the other 3. [14:48] bdmurray: ^ after that do the three bugs need to be re-verified? [14:49] hallyn: hmm, I'm not positive. [15:00] bdmurray: well i pushed a new one without the bad fix. reverification should be simple actually. is smb around to re-verify bug #1248025 ? [15:00] bug 1248025 in ubuntu-cloud-archive "[SRU] libvirt-bin fails to start inside Xen" [High,Confirmed] https://launchpad.net/bugs/1248025 [15:02] hallyn, I am around [15:06] hallyn, So I should look at 1.1.1-0ubuntu8.9 [15:11] smb: no [15:11] .10, if bdmurray accepts it [15:11] Ah ok [15:13] hi all, i have a package that has both python2 and python3 code in it (related to upstream stuff that we're gluing together; I can't change either) [15:13] is there a nice way to include these both in the same source package? [15:13] or do i need two separate source packages? [15:19] hallyn, ok. I got a guest ready which shows to issue with current updates version. So I can verify when you yell (after it gets accepted) :) [15:21] smb: thanks [15:21] zul: bug 1304167 i intend to push a new libvirt as soon as trusty is open for srus. do you have anything to add? [15:22] bug 1304167 in libvirt (Ubuntu) "syntax error, trusty beta-2 cloud image" [High,Confirmed] https://launchpad.net/bugs/1304167 [15:31] hallyn: nope [15:32] ok i'll just push it now then [15:49] infinity: if i'm pushing somethingn for trusty-proposed, i don't gum up the works for release at all do i? [15:49] i.e. shoudl i wait a few hours? [15:53] hallyn: You can upload it. [15:53] thx [15:57] infinity: hallyn: wrong version number, it should be 1.2.2-0ubuntu13.1 for an sru?! =) [15:57] gah [15:57] xnox: well to be fair i expect the first t+1 upload to be 1.2.3 by zul :) [15:58] hallyn: might be ok, just being pedantic =) [15:58] i assume you've rejected? [15:58] no no i'll reupload [15:58] hallyn: i am nobody [15:58] pshaw [15:58] hallyn: I'll reject for you. [15:58] thanks [15:58] * hallyn hangs his head in shame. again [15:58] hey, when will u-series archive open? [15:59] bah, i'm mor einterested in what follows z, and what sort of names can we do starting with 'aa' :) === bschaefer_ is now known as bschaefer [16:10] hallyn: aardvark? :) [16:12] yeah but for an adj? maybe we should switch to dutch === sz0 is now known as sz0` === sz0` is now known as sz0 [17:36] hallyn, Is libvirt for Saucy getting in foreseeable future? [17:36] in in ... [17:36] bdmurray: ^ [17:39] hallyn: accepting [17:39] thanks [17:40] smb said he'll verify asap today, i'll verify the other bug today as well [17:40] so hopefully we can get this thing done [17:41] * smb jsut grabs a bite while things are building [17:44] Is this the right channel to ask about https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1258642 [17:44] Launchpad bug 1258642 in gdb (Ubuntu) "gdb: Python 3 incompatible with libstdc++ pretty printers." [High,Confirmed] [17:48] jcw4: that sounds like it might be an upstream python issue? [17:49] I guess.. on my machine I don't even seem to have python3 installed [17:49] and certainly not the files mentioned in the workaround [17:49] or the patches [17:49] then what's the issue? [17:49] are you on 12.04 or something? [17:50] dobey: uh. yeah I think so. [17:50] :( [17:50] Isn't that the latest LTS [17:50] it is. [17:50] no [17:50] 14.04 is now :) [17:51] welcome to release day [17:51] !isitout [17:51] No Meerkat, it's not out yet. It's due out some time on the 17th :) [17:52] lol [17:52] well, python3 is installable on 12.04 as well, it's in the archives, i just don't think it's installed by default on 12.04 [17:52] actually I am on 13.10 [17:52] I thought I was on 12.04 [17:52] oh [17:52] on 13.10, python3 is definitely installed by default [17:53] S 10:52:31 [0]$ python --version [17:53] Python 2.7.5+ [17:53] I certainly didn't change any python packages myself [17:53] "python" will never be "python3" [17:53] you have to use "python3" not "pythoN" [17:53] * jcw4 smacks forehead [17:54] okay so I have python3 but I don't have the printers.py file referenced in the fix [17:55] dobey: thanks. It sounds like I'll need to try and rebuild gdb [17:56] jcw4: /usr/share/gdb/python/gdb/printing.py is probably the file referenced [17:56] or maybe not [17:57] dobey: I'll look for that... locate printing.py didn't work for me before [17:57] ah, but after doing updatedb it did [17:57] hallyn, Ok, verification done for bug 1248025 [17:57] bug 1248025 in ubuntu-cloud-archive "[SRU] libvirt-bin fails to start inside Xen" [High,Confirmed] https://launchpad.net/bugs/1248025 [17:58] smb: wow it built already? [17:58] awesome, thanks [17:58] * hallyn goes to verify the other [17:58] hallyn, amd64 yes [17:59] jcw4: didn't the error message from gdb mention the full path to the script causing the problem? [17:59] dobey: I did "2to3 -w printing.py" but that doesn't seem to have fixed the problem [18:00] tarpman: yes, but the patch in the bugreport applied to the printing.py file not the file with the syntax error [18:01] no idead [18:01] idea [18:01] dobey thanks for your help [18:01] :) [18:05] smb: bdmurray: verified bug 1287232 [18:05] bug 1287232 in libvirt (Ubuntu Saucy) "/usr/lib/libvirt-lxc.so missing from libvirt-dev" [High,Fix committed] https://launchpad.net/bugs/1287232 [18:10] jcw4: replied to you on the bug [18:12] tarpman: hmm. The patch wasn't for the same file as the error... my error was identical to the one in the original bug report [18:14] tarpman you're right I'm sorryy [18:14] I confused Martin Olssons comment with the original report [18:15] jcw4: that makes more sense. :) so yeah, you'd need a different patch for go's pretty-printer than for the libstdc++ pretty-printer [18:17] tarpman thanks [18:20] the web site has 14.04 iso download now, btw [18:21] * dobey favors do-release-upgrade though [18:21] well done everyone! Here's to another 5 years of trusty! [18:21] yeah! [18:35] it appears the default vmware vga mem size for pc-1.0 machine type has gone down from qemu-kvm to qemu (precise to raring+). i.e. bug 1308756. is it too late to add something to the release notes? [18:35] bug 1308756 in qemu (Ubuntu) "pc 1.0 machine type regressed with -vga vmware" [Medium,Confirmed] https://launchpad.net/bugs/1308756 [18:35] zul: jamespage: ^ [18:36] eh, i'll add it to https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes [18:36] i don't know if that seeds anything else === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr === salem_ is now known as _salem === sz0 is now known as sz0` [21:57] robru: Do you know why the account-plugins version is different in the saucy proposed queue from the one in the sru staging ppa? === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr [22:29] hello. Why bitcoin-qt is not in the new version of ubuntu? [22:29] is an open source programme why you have get out of the official repositories? [22:30] chek2fire: see the thread starting at https://lists.ubuntu.com/archives/ubuntu-motu/2013-December/007597.html [22:31] chek2fire, https://lists.ubuntu.com/archives/ubuntu-motu/2013-December/007597.html [22:31] hah [22:31] ogra_: ^5 [22:31] :) [22:31] yes but is a new technology and open source [22:33] chek2fire, but it is not nice to not respect the will of the developer of that opensource software [22:33] i think is not nice when you dont follow a new technology like bitcoin [22:33] and you drop it [22:34] even if the developer asks you to drop it because he considers his software nnot ready for wider distribution yet [22:34] ? [22:35] bitcoin is not for spread to public? [22:35] ready* [22:35] bitcoin is not ready to be frozen for five years. [22:35] did you read the mail ? [22:35] yes i have [22:35] this decision is only for lts versions? [22:36] you have to ask the developer of the software [22:37] the mail offers how to install it from them [22:37] so they are not bound to the distro release schedule [22:37] ok thx i hope ppa maintainer will release the new bug fix version 0.9.1 without the hearbleed bug [22:37] s/offers/describes/ [22:38] ugh, I hope they don't bundle their own openssl [22:38] they should just rely upon the system-supplied openssl [22:39] right [22:43] the debs in the bitcoin ppa appear (at a glance) to use the system libssl [22:44] a ok [22:44] for that is not need for an update? [22:44] 14.04 is safe ... and older releases got it with security system upgrades [22:45] yes i have get the update and now in bitcoin channel they told me that is better bitcoin-qt to has its own ppa [22:45] is more safe [22:45] ok thx again for the info and sorry :) [22:46] and keep the great work with ubuntu guys [22:46] i use the distro 8+ years now [22:46] kubuntu mostly.. :P === bschaefer_ is now known as bschaefer [23:00] chek2fire: thanks :) have fun