=== wedgwood is now known as Guest73785 [04:43] Good morning === gaughen is now known as gaughen_afk [06:18] that [07:06] good morning [07:06] cjwatson: I uploaded cdbs merge; do you want to merge debhelper yourself? (you're currently TIL) [07:10] When will everything be ready for the archive to re-open? [07:10] Or to upgrade to trusty [07:11] Noskcaj10: you can already upgrade to trusty :) (I did already) but of course it's just like saucy at this point [07:11] Noskcaj10: I take it will still be a few days until the toolchain is in place [07:11] Noskcaj10: but you can already do uploads, syncs, etc. [07:13] pitti, ok, thanks for the info. I'm upgrading now [07:18] is using "devel" or "trusty" (and update it for t+1) the preferred way to stay on the devel release? [07:19] apt doesn't actually like devel atm. [07:19] So you have to use trusty explicitly. [07:19] But once the implementation is complete you'll be able to just use devel [07:22] Are we still trying to get python3 only for 14.04? [07:26] pitti, do-release-upgrade and update-manager can't find trusty. How did you upgrade? [07:27] Noskcaj10: edit /etc/apt/sources.list and s/saucy/trusty/ :) [07:27] ok, i was hoping there was an "easy" way, i'll do that now [07:33] can someone accept all the xorg and mesa binaries in NEW for https://launchpad.net/ubuntu/precise/+queue?queue_state=0 === sraue_ is now known as sraue [08:01] hi everyone, maybe there is an error in resolvconf. it not include the file /etc/resolvconf/resolv.conf.d/base [08:02] How do i sync from deb-multimedia? [08:03] stgraber: can I get a MRE for libdrm backport from saucy to raring/quantal/precise again? [08:06] because a heap of the packages on http://qa.ubuntuwire.com/neglected/ need syncing from deb-multimedia [08:16] TheMuso`, Do you have any plan to keep maintaining avidemux since you are the most recent uploader? === Noskcaj10 is now known as Noskcaj [08:23] pitti: oh, yeah, I'll do debhelper, thanks [08:23] Noskcaj: deb-multimedia> most of those should probably be removed, but if you need a sync you'll have to do it manually (i.e. download / re-upload) [08:24] cjwatson, ok. Shall i start working on a list of stuff we take from deb-multimedia? [08:25] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: closed | 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: dholbach [08:25] Noskcaj: If you like. It was fairly misguided that we synced all that stuff in in the first place, IMO, but try to assess how useful/used they are [08:25] ok [08:28] Everything has a relatively high popcon, so i'll see what ones are worth syncing tomorrow [08:28] cjwatson, Mind if i merge rfkill? [08:30] wow, haven't looked at neglected for a while [08:30] edgy-wallpapers | 0.9-0ubuntu2 | saucy/universe | source, all [08:30] yay [08:31] ooh [08:31] We pushed most of the deb-multimedia stuff out years ago, I thought. [08:31] ubuntu-wallpapers only has >= karmic [08:31] But I guess there are bits left. [08:32] wgrant, libfame and ripmake are the main ones left [08:32] Noskcaj: What's the rush? In general all my merges are ones I intend to at least look at in the next week or so; I don't need help right now [08:33] ok, i'm just picking random packages on the merges page. I've not got much to do [08:33] Noskcaj: If you feel the desperate urge to take merges, at least start with inactive developers [08:33] ok [08:36] i just remembered i have one or two merges of my own. What'd the process for merging from unstable if it's a non-ubuntu arch FTBFS? [08:36] *what's === Sweetsha1k is now known as Sweetshark [09:06] can somebody remove my tornadio2 sync from the trusty new queue? I missed a message on the original bug report, sorry about that. [09:08] pitti, ^ maybe? [09:12] dholbach: rejected [09:12] thanks a lot cjwatson [09:16] is there still a tb? it only shows mark shuttleworth as member [09:20] mlankhorst: yes, everyone else timed out [09:21] I mailed/pinged sabdfl about it several times [09:21] ok so if I want to get a mre for libdrm, pixman, and some x11 libs should I ask him? :P [09:21] lool, ping [09:22] mlankhorst: best to mail the list as usual, we are still serving on an acting basis :) [09:23] oke [09:37] dholbach: I've seen a few syncs from you landing in NEW - you know it's unnecessary to request those manually since they'll be done in bulk once auto-sync starts, right? [09:38] (except in a few special cases which don't apply here) [09:39] cjwatson, I mainly synced them because they were in the sponsoring queue and I wanted to have something to report back... I guess it's causing additional work? in which case, I'd stop doing that [09:39] dholbach: A bit - it requires manually accepting, whereas auto-syncs will sail through [09:39] * dholbach nods [09:39] ok, understood [09:40] It's not *wrong*, but it's a waste of the sponsored person's time requesting them, so they should probably be advised to do something more useful :) [09:40] they were filed before saucy release [09:41] Yeah, although at a point when we were never going to accept new packages [09:41] yeah [09:43] Anyway, not the end of the world, just in case you didn't know, since auto-sync of new packages is a fairly new thing (about 1.5 years) [09:45] yeah, I've heard of it - I think among the exceptions were blacklisted packages and packages from contrib and non-free, right? [09:46] Blacklisted yes, packages from contrib and non-free no [09:46] They're still auto-synced [09:46] The main other exception is packages that used to be in Ubuntu and have been removed [09:48] all right, thanks [09:50] cjwatson: if I upload a package to -proposed, and that package only exists in -updates, it goes through NEW. Can this be fixed? [09:52] mlankhorst: it's a known bug but is fairly hard [09:53] hm :( [09:53] mlankhorst: the ancestry calculations are rather complex and implemented too many times [09:53] mlankhorst: I'd like to fix it but I can't do it on the spur of the moment for you based on an IRC prod [09:53] ok [09:53] It'd go through UNAPPROVED anyway, so it mostly only affects binary NEW [09:54] well no it ends up in NEW iirc [09:55] mlankhorst: Yes, I know. I mean that even if we fixed that it would still end up in UNAPPROVED. [09:55] Which is manual review either way. [09:56] And binary NEW is easy; so this isn't very high priority. [09:57] yeah but that does depend on someone accepting the binary new's manually, that part seems to be hard. I've been considering becoming an archive admin for that reason, to take some load off others. :s [09:59] mlankhorst: Uh, that part is easy, might just need a prod [10:00] It's not much load [10:00] The number of binary NEWs due to this bug ever probably consume less effort than fixing the bug :) [10:01] perhaps but repeated prodding doesn't seem to help :P [10:01] I don't remember seeing any prods from you about binary NEW. Which packages? [10:01] (And in which series?) [10:01] https://launchpad.net/ubuntu/precise/+queue?queue_state=0 [10:01] all binaries in there [10:02] mlankhorst: done [10:03] thanks :) [10:03] mlankhorst: Oh, only three days old, so people will have been dead from release or preoccupied with opening trusty, pick one [10:04] well dno, I'm busy preparing lts-s backports :) [10:04] only needs a few sru's this time [10:06] 6 or so === Sweetsha1k is now known as Sweetshark === shadeslayer_ is now known as shadeslayer [10:50] Any idea what the chances are of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708744 ever being solved? I'm wondering if I should build a workaround for it into CMake [10:50] Debian bug 708744 in clang "Debian patch uses wrong triple for arch-includes" [Normal,Open] === cjwatson changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [10:53] Riddell: apachelogger: Any idea ? ^ === MacSlow is now known as MacSlow|lunch [11:03] doko_: ^ if you could have a look [11:06] apachelogger, then make clang -target work ... [11:06] steveire: ^ [11:06] doko_: ? [11:07] $ clang -v -target arm-linux-gnueabihf --sysroot /home/stephen/rpi/rasp-pi -c main.c [11:07] ignoring nonexistent directory "/home/stephen/rpi/rasp-pi/usr/include/x86_64-linux-gnu" [11:07] doesn't seem to be a version out of the archive [11:09] woohoo! archive: open! [11:10] doko_: It is from the ubuntu repos: http://pastebin.kde.org/pd5cusahh [11:11] The triple x86_64-linux-gnu is appended for search, but arm-linux-gnueabihf should be appended instead. That seems to be the result of a debian patch [11:11] steveire, I didn't look at clang cross builds at all. feel free to submit patches [11:12] doko_: I'm asking you to remove a patch :) [11:12] apachelogger, then make clang -target work ... <<< What was this about? [11:13] steveire, just removing the patch would be wrong too [11:14] also please recheck with the llvm-toolchain-snapshot package first. you are citing patches applied for 3.0 ... [11:16] aptitude search llvm-toolchain-snapshot gives no results. [11:17] apt-get source llvm-toolchain-snapshot [11:17] aptitude search only searches *binary* package names [11:21] doko_: The 21- patch is indeed very different there. In conclusion, I don't know why the wrong triple is still appended. [11:21] And /usr/include/clang/3.2/include/ is empty. [11:22] ... which is what that patch currently adds to the search path. [11:22] Is there anywhere else I could grep? Apart from debian/patches? === doko_ is now known as doko [11:39] Laney: barry: https://launchpad.net/ubuntu/+source/emacs-defaults/45.0ubuntu1 [11:40] Oh good, no need to port emacs23 to arm64 then :) [11:41] neat [11:42] didn't see a reason not to do that. and unseeded too [11:43] doko: it's just all the r-depends will need porting/migrating to emacs24. [11:43] they all have alternatives [11:44] but yeah, we need it. [11:51] tvoss, do the pretty printers work for you? [11:51] doko, yup [11:56] tkamppeter, ping === psivaa is now known as psivaa-lunch === _salem is now known as salem_ [12:03] jdstrand: Could you reupload apparmor to trusty so that it builds against perl 5.18? I'd do it myself but lp:~ubuntu-core-dev/apparmor/master is out of date with your most recent upload. [12:07] barry, python compat ping === MacSlow|lunch is now known as MacSlow [12:17] doko: could you merge libhdate for the perl transition? [12:20] cjwatson, doing [12:20] ta [12:21] tvoss, hi [12:21] tkamppeter, hey there, how are you? [12:22] tvoss, fine. [12:22] tkamppeter, cool :) do you remember our discussion at one of the last vuds's about readying our printing stack for on-demand printing on the phone? [12:23] tvoss, currently I am working on the print filters for PPD-less printing. [12:23] tkamppeter, I remember that you talked about slimming down the printing stack. did you have a chance to tackle that? [12:25] tkamppeter, ah, so ppd-less printing is a prerequisite, isn't it? [12:25] tvoss, that is one of my intentions, to split up the cups and cups-filters packages more and (for the phone/tablet only) use Poppler as renderer and leave out GS, dropping support for PS as input format. [12:26] tkamppeter, ack. Do you have a blueprint somewhere tracking those items? [12:26] tvoss, yes, to not need to keep PPD collections on the device and to make printers with known protocols work without printer setup tool. [12:27] tvoss, yes, there are Blueprints. [12:28] tvoss, https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind [12:28] tvoss, this is the main Blueprint. [12:29] tvoss, here is also one with the print dialog, for the GUI devs: https://blueprints.launchpad.net/ubuntu/+spec/client-1305-mobile-print-dialog [12:29] tvoss, there is also one about the PDF renderer, but we finally opted for Poppler. [12:30] tkamppeter, ack, I'm fine with poppler. I do see a work-item for color profile mgmt, though [12:30] tkamppeter, that is, in the main blueprint [12:35] tvoss, on the phone we can start without Color Management and add it as soon as it gets completely working in Poppler. [12:41] tkamppeter, yup, sounds good. So what is missing to have cups start on demand on the phone? === psivaa-lunch is now known as psivaa [12:43] tkamppeter, I would think integrating it with upstart and its socket observer functionality shouldn't be too difficult [12:44] tkamppeter, also: for the scanner daemon: Would we really need it running all the time? I would think it should come up on demand if the user wants to print to something network local only. Does that make sense? [12:44] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [12:46] wgrant: You're touched-it-last for subversion; do you intend to merge it (new upstream, and for the perl 5.18 transition), or should I? [12:47] cjwatson: Feel free, though I'll hopefully get to them this week. [12:49] cjwatson: ack [12:49] isn't it nice to have a sh** load of merge work to do after finishing some things late in the previous cycle? ;p [13:01] tvoss, yes, we could start it when the user opens the print dialog and stop it when the print queues get empty. [13:02] tkamppeter, sounds good to me then :) also: do we have a filter for google cloud print for cups? [13:05] tvoss, no, we do not have anything which prints as client into the Google Cloud. I think we need to implement this in the print dialog, as the Google Cloud is one of the user's personal resources, and CUPS only handles system resources, not per-user queues for example. === Ursinha is now known as Ursinha-afk [13:06] tkamppeter, hmmm, could we just run cups in a user session? === Ursinha-afk is now known as Ursinha [13:08] tvoss, a user account manager must log in the user on Google so that he can use all Google services, then a print dialog backend needs to list the user's cloud printers and the user can print on them, these should work fine when sending PDF to them. [13:09] tkamppeter, ah okay. mardy, do online accounts support that scenario?^ [13:09] tvoss, theoretically CUPS can run in a user session, but it will get complicated for the packaging, the CUPS configs on desktop and mobile would be completely different then and Cloud Print only gets available for mobile. === freeflying_away is now known as freeflying [13:16] mlankhorst: you'd need a technical board for that, unfortunately we all expired a bit over a week ago so I'll be happy to process that once the elections are over and if I get re-elected [13:17] tvoss: if Google Cloud printing supports OAuth, yes [13:17] tkamppeter, ^? [13:17] stgraber: no lameduck TB? [13:17] tkamppeter, also: which packages would we need at a minimum on the phone? seeded that is? [13:18] tvoss: looks like it does, so yes, it should be quite feasible [13:18] * mardy needs to run out [13:18] mardy, ack and thx [13:22] doko, ping [13:23] tvoss, just ask [13:24] doko, any reason the static boost libraries are built without -fPIC for amd64? [13:24] tvoss, policy. Is there a reason not to use the shared ones? [13:25] xnox is our boosted expert [13:25] doko, well, for the sake of cutting a runtime dependency [13:26] we don't duplicate code in the archive for the sake of cutting runtime dependencies [13:26] as a general rule anyway [13:27] tvoss, there are a very few cases in the archive. but then these are called libfoo_pic.a [13:27] and those are generally for very special cases [13:27] cjohnston, ack [13:27] :-/ [13:28] cjwatson, ack [13:28] cjohnston, sorry :) [13:29] doko: thanks i'll look into removing boost static libraries all together, one day =) [13:29] never mind, xfuzz [13:32] doko, xfuzz ? shouldnt that be Mir-fuzz nowadays ? [13:32] :P [13:35] hi xnox, do you need your udd changes deployed? [13:37] tvoss, I do not know about the authentication mechanism of Cloud Print. There is a simple program in Universe (AFAIK named cloudprint) which shares out local printers to the user's cloud print account, perhaps it contains hints. [13:37] james_w: last time I've checked branch-distro was still in progress. [13:37] tkamppeter, ack [13:38] xnox: ok [13:38] james_w: if/when that finished I or wgrant can restart udd. [13:38] xnox: ah, you can deploy yourself? perfect [13:38] thanks for working on it [13:38] james_w: i have access to that machine, but no access to lp:udd =) which is a bit backwards =)))) [13:38] heh [13:38] james_w: can you add me to the team, please? =) [13:39] tvoss, needed are CUPS (made smaller by binary package splitting, no web interface, no online help, no command line printing), cups-filters (also made smaller by package splitting), Poppler AFAIK. [13:39] so demanding! [13:39] xnox: done [13:40] james_w: thanks a lot =)))) === Guest73785 is now known as wedgwood [14:16] slangasek, hello :) are you still having this issue? https://bugs.launchpad.net/compiz/+bug/763148 [14:16] Ubuntu bug 763148 in Compiz Core "Adding/Removing an external monitor causes open windows to move to another workspace" [Medium,Fix committed] [14:22] jamespage, maven induced mismatches: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt === freeflying is now known as freeflying_away [14:28] doko,jamespage: looks like it's due to a change in libjaxen-java? [14:42] cjwatson, yes, - Use the upstream pom instead of debian/pom.xml [14:42] - Switched to Maven to build the package [15:04] does anybody mind if I add the trusty symlink to precise's deboostrap? [15:04] or is somebody already working on this? [15:11] hey, does anyone know how the grub file grubx64.efi.signed is generated? [15:12] it contains absolute references to the ubuntu distribution, causing trouble for sub-distributions such as kubuntu! [15:17] cjwatson, doko: urgh [15:17] jamespage, be happy, up to now it's just one package ;) [15:20] Harbort: most of it's in the grub2 package. and exactly which reference are you talking about? the /EFI/ubuntu path is correct for Kubuntu too [15:22] cjwatson: apart from kubuntu, using /EFI/kubuntu path for some reason. [15:22] cjwatson: I mean that in the file grubx63.efi.signed there is a (unique) reference to /EFI/ubuntu. But since kubuntu 13.04, the dev of kubuntu decided to change the path for the kubuntu boot from /EFI/ubuntu to /EFI/kubuntu [15:22] xnox: exactly [15:22] cjwatson: bug #1242417 [15:22] bug 1242417 in grub2 (Ubuntu) "UEFI install broken on Kubuntu 13.10" [Undecided,Confirmed] https://launchpad.net/bugs/1242417 [15:22] cjwatson: and there are similar against ubiquity "finished kubuntu install, black screen, uefi no boot" [15:23] Harbort: that Kubuntu change must be reverted [15:23] Harbort: that's rather bug in kubuntu packages that modify it. [15:23] cjwatson: so in the end, it seems that if kubuntu could re-generate the efi image, changing the reference from /EFI/ubuntu to /EFI/kubuntu, it would work [15:23] It's foolish [15:23] Harbort: No, I'm not going to build separate signed images for Kubuntu [15:23] It's pointless busy-work for no reason [15:23] Kubuntu shouldn't have made that change without consulting the GRUB maintainer [15:23] Harbort: you can't regenerate .signed easily, as it need to be signed by microsoft. [15:23] xnox: no, please don't spread misinformation! [15:23] that file is signed by us [15:23] cjwatson: bug 1242417 so what do we do? [15:23] cjwatson: oh, ok. [15:23] bug 1242417 in grub2 (Ubuntu) "UEFI install broken on Kubuntu 13.10" [High,Triaged] https://launchpad.net/bugs/1242417 [15:24] but nevertheless, it is cumbersome to generate other versions of it - they're referred to by grub-install etc. [15:24] apachelogger: revert whatever changes you made to use /EFI/kubuntu [15:24] And check with me next time? [15:24] we only define GRUB_DISTRIBUTOR [15:24] apachelogger: argh, not that again [15:24] apachelogger: I'm tempted to revert all the GRUB_DISTRIBUTOR=kubuntu changes [15:25] They cause far more trouble than they're worth [15:25] I know, you'd think such a tiny thing would be a no-brainer xD [15:26] The GRUB distributor here is Ubuntu - Kubuntu uses the same GRUB as all other flavours [15:26] So it's really inaccurate [15:26] But I know you were trying to handle branding :( [15:27] apachelogger: I guess I will slather on some more complexity to deal with the complexity. [15:27] Because what could possibly go wrong ... [15:27] cjwatson: see bug comment for options, I am somewhat indifferent at this point ... though I'd argue that the maintainer scripts are misbehaving if they expect EFI/G_D to work and we don't support that [15:27] lol [15:28] cjwatson: actually another approach is to add slightly more complexity that allows changing the name that shows up in the created grub entries without changing GRUB_DISTRIBUTOR [15:28] The maintainer scripts weren't misbehaving until Kubuntu broke the rules [15:28] as you said, it's really just about the branding [15:28] Well, I don't know, it may depend on which involves the larger patch [15:29] Saviq: pong, albeit I'm on leave until Thursday (inclusive), but perhaps I can help? [15:30] lool, just a quick question, hopefully: ideas on how should we tackle the /usr/bin/unity8 hack when upgrading the unity8 package (for automated testing in -ci jobs) [15:30] lool, we could ship a pre-inst script that would unmount it [15:30] apachelogger: I don't think I want to change the menu generation - that's more likely to result in a patch that's more work to maintain going forward [15:30] cjwatson: i think kubuntu is not the only one that customized GRUB_DISTRIBUTOR. [15:30] * xnox goes to check. [15:30] xnox: It's the only one I know of in the Ubuntu archive [15:30] or maybe adding a post-stop script to the unity8-setcap job (and stopping it) would be better [15:31] Saviq: Hmm that's a good question, but do we reboot then? [15:31] Saviq: Actually rather than invest in this, could we prioritize ripping this off? [15:31] xnox: And it's the only one with support for it in other parts of the grub2 source package [15:31] lool, sure, what's the plan on that? bumping the rootfs to ext4? [15:31] lool, have we a bug? who do I talk about this to? [15:32] Saviq: My understanding is that we don't need the hack; first, we already start unity8 with a negative score, and second we could also simply restrain to positive scores; in both cases, we don't need the setcap hacks [15:32] Saviq: tvoss was working on the logic picking up scores; don't think we have a bug for this, but he had a WIP branch [15:33] lool, thanks, will follow up with him [15:33] lool, https://code.launchpad.net/~thomas-voss/unity-mir/less-aggressive-scores [15:33] Saviq, ^ [15:33] tvoss, and that would rid us of having to setcap unity8? [15:33] Saviq, yup [15:33] oh cool [15:33] greyback, can you please prioritize ↑↑? [15:34] Saviq: okey [15:34] greyback, thanks [15:35] greyback: Reason it's urgent is probably because it breaks ci runs of unity8 right now due to /usr/bin/unity8 being a bind-mount in the read-only images [15:35] apachelogger: do you have any way to test fixes for this in trusty? [15:36] lool: tvoss really? I don't see how changing OOM scores has any impact on that bind-mount problem [15:36] cjwatson: yes, I only today noticed that my laptop supports UEFI and secureboot and that pile of madness ^^ [15:36] cjwatson: i.e. I have already tested if you change the build script to use EFI/kubuntu instead it works as expected [15:36] greyback: we thought we had to setcap /usr/bin/unity8 as to allow it to set OOM scores; it actually only needs this for scores lowers than itself, and we don't really need this [15:36] greyback, what lool says [15:37] greyback: we need to bind-mount it because we're using ext2 as the read-only base [15:37] greyback: we use ext2 due to limitations in our recovery ROM [15:37] (we should lift these too BTW) [15:37] lool: interesting. Ok, thanks for the answer [15:38] cjwatson: Ubuntu Studio also sets GRUB_DISTRIBUTOR to != Ubuntu, see http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/ubuntustudio-default-settings/saucy/view/head:/etc/default/grub.d/50_ubuntustudio.cfg [15:38] cjwatson: looking at merges.u.c I appear to be TIL on grub-installer, should I let you deal with that one? [15:38] xnox: Grr, well Ubuntu Studio will be even more broken, they need to revert [15:38] I wish this trend hadn't been started without my consent [15:39] It needs actual design rather than ad-hocery [15:40] stgraber: Sure, I can take that [15:41] cjwatson: thanks [15:43] Ursinha: well, adding/removing an external monitor still moves windows around in ways that it shouldn't, but now they all stay on the same workspace.. [15:45] slangasek, right... well, in here it's pretty random, sometimes windows are all moved to the same workspace, sometimes they are in different workspaces but not where they're supposed to be [15:45] hmm [15:45] yeah, nothing quite that bad here [15:46] slangasek, have you opened another bug for the remaining issue? I found one regarding fullscreen windows, that's not really the case here [15:47] I have another bug in my intel driver that combined with this one is driving me crazy [15:47] Ursinha: I think there is one but I don't remember where [15:49] Laney, pitti: is bug #1240673 something that should get some attention in upower? Seems to affect a wide range of Dell machines [15:49] bug 1240673 in upower (Ubuntu) "Reports 0% charged for fully charged batteries" [High,Confirmed] https://launchpad.net/bugs/1240673 [15:49] ScottK: ^^ escalating to the upowers that be ;) [15:51] slangasek: Thanks. [15:52] apachelogger: Perhaps you could try http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/trusty/grub2/trusty/revision/2359 ? [15:53] Mmm, pitti's going to be better at debugging that than me [15:54] apachelogger: If that works, I can do the upload to trusty, but I'd appreciate it if somebody Kubuntuish could take care of the SRU ... [15:56] ok [16:00] cjwatson: and about studio? revert. Or grub2 will start maintaining a list of "supported" ubuntu aliases. [16:04] /win/win 3 [16:04] err [16:13] xnox: Studio should revert for saucy [16:13] xnox: Maybe we can figure out something for trusty [16:14] xnox: I'm treating Kubuntu differently because it already had partial support in the grub2 source package - Studio didn't [16:15] cjwatson: i wonder if kubuntu's snippet should include # WARNING! below only works due to special casing in grub2 packages [16:16] cjwatson: to prevent more derivaties just looking up "how kubuntu did it" [16:16] seems useful [16:16] I'll add one [16:16] distro-info-derivatives anyone? [16:16] oh my [16:18] xnox,apachelogger: I'll do something in the next Debian upload [16:18] apachelogger: if you could leave the Ubuntu branch alone for the meantime it would help me be less confused about its state :) [16:20] cjwatson: the snippet is in lp:kubuntu-settings [16:20] I assume xnox was talking about the cfg file setting GRUB_DISTRIBUTOR [16:22] apachelogger: ah, sure [16:26] don't we usually sync ltses from stable? [16:26] http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-settings/kubuntu-settings/revision/571 [16:26] mdeslaur: since britney migration available in ubuntu, we always sync from unstable. [16:27] xnox: ah! that makes sense I guess. Thanks. [16:27] mdeslaur: cause we get all the same benefits, sans 10-day delay. (well RC-bugs in debian is something to keep an eye on) [16:32] mdeslaur: we never synced from stable anyway - testing in the past. but what xnox said [16:32] cjwatson: er, yes, I meant testing === chuck_ is now known as zul_ === mdeslaur is now known as chuck_ === chuck_ is now known as mdeslaur === gaughen_afk is now known as gaughen [17:08] arges: I'll take the ifupdown merge. [17:09] stgraber: ok. thanks [17:25] slangasek: do you have any ideas on the problem in bug 1241487? [17:25] bug 1241487 in ubuntu-release-upgrader (Ubuntu) "Release upgrade aborts with error message" [Undecided,Confirmed] https://launchpad.net/bugs/1241487 === psivaa is now known as psivaa-afk [17:30] bdmurray: is that after we fixed the gnome-bluetooth thing? [17:30] because that seems to be the same problematic loop as in the gnome-bluetooth case [17:30] slangasek: yeah, I tried used the upgrader in -proposed and it still failed [17:30] hmm [17:31] The following packages have unmet dependencies: libgdm : Breaks: gdm (< 3.8.3-3~) but 3.6.1-0ubuntu4 is to be installed [17:31] that's from trying a dist-upgrade with apt [17:31] ok, the log also shows gnome-bluetooth in the heart of this [17:32] Investigating (0) gnome-shell [ amd64 ] < none -> 3.8.4-0ubuntu5 > ( universe/gnome ) [17:32] Broken gnome-shell:amd64 Depends on gnome-bluetooth [ amd64 ] < none -> 3.8.1-2ubuntu2 > ( gnome ) (>= 3.0.0) [17:32] Considering gnome-bluetooth:amd64 3 as a solution to gnome-shell:amd64 0 [17:32] Holding Back gnome-shell:amd64 rather than change gnome-bluetooth:amd64 [17:40] slangasek: so why does it choose not to install gnome-bluetooth? [17:40] dunno yet [17:41] walking back through the list, gnome-bluetooth isn't the root cause this time though [17:41] obex-data-server is the next one [17:47] bdmurray: in the reproducer environment, what do you get with just an 'apt-get install obex-data-server'? [17:47] (trying to install the saucy one, not raring) [17:48] The following packages will be REMOVED: obexd-server [17:48] right [17:48] so they have a conflicting package installed [17:50] hmm and that only appears in the installed packages list in the aptclone file afaict [17:51] bdmurray: obexd-server is brought via recommends from bluez-tools; I think the right solution is to figure out if that Recommends can be changed to obexd-server | obex-data-server, or possibly dropped altogether === chuck_ is now known as zul [18:29] slangasek, ScottK: I'll respond with some debugging questions, shouldn't be too hard to reproduce in a test [18:30] pitti: Excellent. I've got an affected system, so I'm glad to help out. === Ursinha is now known as Ursinha-afk === mbarnett` is now known as mbarnett [18:49] cjwatson: r2359 fixes UEFI for trusty [18:50] cjwatson: the bcfg entry still has Desc kubuntu though, not sure if that matters === Ursinha-afk is now known as Ursinha [18:54] mh, one could argue it's part of the branding, I guess I am happy ;) === seb128_ is now known as seb128 [18:59] jamespage, can you take care about the maven issues? or should I? [19:10] I have a bug, not sure which package to file under... btrfs /home on an encrypted volume (luks). Mountall doesn't wait for it during boot. It does ask for the password and calls cryptsetup to open it, but I have to manually call #mount /home after boot is complete. [19:42] ev, could you have a look to https://bugs.launchpad.net/ubuntu/+source/activity-log-manager/+bug/1198681 ? it's ranked 7 on the saucy issues today [19:42] Ubuntu bug 1198681 in activity-log-manager (Ubuntu) "gnome-control-center crashed with SIGSEGV in on_properties_changed()" [Medium,Confirmed] [20:08] python-apt 0.9 is now in the Debian archive, merging the Ubuntu changes; many bug fixes; and entries for trusty in data/templates/Ubuntu.info.in [20:17] apachelogger: Yeah, I assumed you wanted to keep that bit [20:17] apachelogger: Thanks for the test, I'll upload to trusty shortly === ara is now known as Guest23418 === salem_ is now known as _salem [21:10] stgraber: would you mind pushing http://people.canonical.com/~serge/lxc-halt.debdiff to precise-backports? [21:13] hallyn: I can't push to backports (well, I can but am not supposed to) [21:13] hallyn: I think what we should do is test the saucy package on precise and if that works ok, then ask for a backport of that one [21:14] that should give the missing features some users have been asking for a while and get us rid of lxc-halt in the process [21:14] well i'm running daily ppa not saucy, but it works terrific for me on precise :) [21:14] ok, this just seemed like an easy way to avoid some cursing in our general directions [21:15] so after we test, we should talk to ... ScottK ? [21:15] yeah, same here. I'll try to find an hour or so to stress test the current saucy package on precise and if that works, then just ask a backport of that one [21:15] ok, thanks. testing the getting-rid-of-anonpath right now [21:34] sarnold, jdstrand: so given that libestr is now a hard dependency of rsyslog upstream, I guess that the result of the audit is going to be "fix these bugs", not "you can't have this in main"... would it be ok for me to upload the rsyslog merge to -proposed, and let it sit there waiting for build until the MIR is done? [21:34] slangasek: fine by me === qengho_ is now known as qengho === jono is now known as Guest78132 [21:51] Damn. I wrote "Trusty Thar" instead of "Trusty Tahr" in python-apt 0.9.0. Stupid /me [21:55] apw, this has to build something on i386 ... https://launchpad.net/ubuntu/+source/linux-meta-ppc/3.11.0.3.5/+build/5127063 [21:56] doko thanks, i'll have a look as it doesn't seem it should indeed, must be a control foul up [22:15] Why is /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so in the non-multi-arch p11-kit package? :( [22:19] YokoZar: because it's a plugin for a package that only looks in /usr/lib/x86_64-linux-gnu/pkcs11/ [22:20] slangasek: Wine is still throwing this error: [22:20] p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory [22:20] (on 64-bit). So it seems to be trying to look there :/ [22:20]