[00:05] hi , how to check if we succesfully upload .changes to ppa ? since i didnt get the notification say its failed or accepted .. [00:06] ejat, how long ago did you upload to the PPA? [00:06] or try to... :P [00:06] about 1 hour ago [00:07] should've hit by now, unless your PGP key that you signed with wasn't recognized in LP (i've seen it just ignore such things before without messages) [00:07] hmm .. thanks for the hint .. so LP just ignore without giving any messages? [00:08] it may it may not [00:08] i've witnessed it ignore my uploads before, but its rare for me, since all my PGP keys autosync [00:22] ejat: As said. double check the gpg key [00:22] random question for devs: are packages ever synced to main from debian experimental? [00:22] s/synced/merged, synced, copied, or otherwise/ [00:23] on request when it makes sense [00:23] Bluefoxicy, ping. [00:23] jtaylor, mind answering Bluefoxicy's question to me that was in +1 then? [00:23] I don't use puppet so can't answer [00:23] pong [00:24] jtaylor, who would be able to know whether it makes sense? [00:24] (since puppet's in main i didn't want to give an answer in case i got it wrong) [00:24] (since i only really know universe's take on it: Only when requested) [00:24] (and when it makes sense) [00:24] jtaylor more of is it easier/better to get the package into Debian Experimental rather than trying to get Ubuntu to bypass Debian's out-of-date version with their own [00:25] god I'm making a mess of this every step of the way [00:25] Bluefoxicy, if i interpret jtaylor's words in my own wording: [00:25] assuming its a stable release you can file a request and see what people say [00:25] i think that is an "It depends." thing. [00:25] jtaylor, it needs to be in exp first - experimental's OOD as well [00:25] (OOD = Out Of Date) [00:25] it depends on a lot. Ruby, gems, several libraries [00:25] oh wait [00:25] wrong depends [00:25] * TheLordOfTime rdeps puppet [00:27] rdeps aren't bad, they should probably be checked with the new version, we generally prefer to merge/sync from experimental rather than introduce a new upstream version directly [00:28] Bluefoxicy, so to answer your question in +1 whether Debian should release 3.0.2 from their git to experimental, i'd say they should before you go looking into syncing it to ubuntu. [00:28] nod [00:28] micahg: are you a different micah? [00:28] different than? [00:29] There was one asking me this exact question on debian-devel list [00:29] that's not me (though I idle in the channel) [00:29] It seems now I am relaying a question from micah to micah :| [00:29] hehe [00:30] there needs to be a handbook for this [00:31] Q:"Does Ubuntu ever sync from Debian Experimental?" A:"It depends. The request has to make sense, and it has to have a limited chance of completely nuking everything else" <-- that perhaps? [00:31] That way I can read the handbook and not wind up annoying a bunch of people in the process of trying to get one piece of software (in like a dozen packages) updated before release freeze [00:33] Bluefoxicy: BTW, once 3.0.x is in raring, you can request backports to quantal and precise, we were doing backports regularly before, but there were some issues in the later versions of the packaging which made it difficult to backport earlier than previse [00:33] *precise [00:38] micahg: nod. Makes sense I guess. I heard Ubuntu was going to a rolling distribution eventually. [00:38] I thought that it was going to HAVE a rolling distribution rather than BECOME a rolling distribution, though [00:39] Bluefoxicy: not until after 14.04 at the earliest [00:39] Is that going to be essentially the culmination of backports? [00:39] backport ALL the things? [00:39] no, but it'll make it easier to backport to the LTSs :) [00:40] are there any functional rolling distributions now (besides Gentoo)? [00:40] I remember this being a distinctly hard problem to solve [00:41] Bluefoxicy: right, that's why there's time needed to improve the migration and QA processes on the devel release [00:41] testing is essentially a rolling release when it's not frozen [00:42] I have heard many times that Debian Testing essentially works [00:42] I assume you're trying to squeeze that last bit of mermaid tears and unicorn blood into it some time in the next year [01:11] TheLordOfTime and zequence : thanks .. [01:11] yep [01:51] https://launchpadlibrarian.net/129726782/buildlog_ubuntu-precise-i386.dnscrypt-proxy_1.2.0-1ubuntu1_FAILEDTOBUILD.txt.gz [01:51] can someone help me with that log [01:52] ejat: missing a build dependency on one of the llvm-*-dev [01:53] sorry, it just needs libltdl-dev [01:53] Yes, that. [01:53] ejat: http://packages.ubuntu.com/search?suite=precise&arch=any&mode=exactfilename&searchon=contents&keywords=ltdl.m4 [01:53] ejat: ^-- Handy for finding missing files. [01:53] it was hiding before the list of the llvm packages in the apt-file output ;) [01:54] And definitely libltdl-dev in this case, not llvm. :P [01:54] ok .. trying to add the dependencies .. [01:54] thanks guys [01:55] Didn't libtool used to depend on libltdl-dev instead of just Recommending it? [01:55] Maybe I'm misremembering. [01:55] I think so... [01:57] I find no mention of such a change in the changelog. I'm probably just suffering from getting old. [01:58] hrm, I guess not [01:59] It's a recommendation as far back as hardy, at least. Too lazy to look back further. [02:00] was there a previous broken behaviour of installing recommends in build chroots? [02:00] Not on my watch. [02:01] There may have been for a few weeks in one release when the apt default changed, but I stopped it pretty quickly, IIRC. [02:02] Actually, no, I don't think it was ever broken on buildds, come to think of it, cause back then, buildds still used the host apt. [02:02] So, I fixed it in the chroots pre-emptively. [02:17] http://paste.ubuntu.com/1578662/ [02:17] got this while trying with pbuilder .. === doko__ is now known as doko [04:12] LP builder freeze ? https://launchpad.net/~fenris/+archive/ppa/+build/4252002 [04:15] ejat: Sorted. [04:16] infinity: y using pbuilder successfully build .. but when upload to LP failed [04:19] ejat: It hasn't failed yet... [04:20] previous it failed .. then i try to rebuild .. [04:20] Well, I can't say why it failed previously, since there was no log, since it was retried. [04:22] ejat: If you mean "why did I have to add a build-dep on libevent-dev", I assume your pbuilder chroot is dirty. [04:23] ejat: You're also getting test failures in your testsuite that assumes you have internet access (the buildds don't). [04:23] how to check / clean pbuilder ? rebuild ? [04:24] I don't use pbuilder, so I couldn't say. [04:24] But yes, building a new chroot would make sense. [04:24] in pbuilder the testsuite OKAY [04:25] ejat: Yes, because your computer has internet access. Like I said, the buildds don't. [04:25] * ejat in progress building new chroot .. [04:25] ouch .. [04:25] debootstrap is idiotic about qemu-user-static [04:26] you have to use --foreign and then restart the second stage [04:26] so what should i do ? [04:26] to make testsuite work on buildds [04:27] ejat, just use cowbuilder and see what happens, qemu-user-static is only a cross compiling thing [04:29] means i cant use my ppa to build ? [04:29] :( [04:30] ejat: you have to disable the tests requiring network access [04:32] scientes_: How did qemu get involved in this? He's not building for other arches... [04:32] micahg: the code is not mine .. so i dont really know how to disable the testsuite ... anyone can guide me ? [04:33] ejat: The regular buildds don't have internet access either, this isn't PPA-specific. [04:33] infinity: ok tx for d info [04:41] Is there any quick way to find out all bugs between precise-updates and precise-proposed? === Nisstyre_ is now known as Nisstyre [04:44] FourDollars: All bugs fixed, you mean? [04:44] FourDollars: http://people.canonical.com/~ubuntu-archive/pending-sru.html may be a good start. [04:45] infinity: It is very useful. Thanks a lot. [05:00] sladen: hmm, mapping it to the Ubuntu logo would not be the solution I'm looking for [06:09] Good morning [06:47] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti [06:47] FTR, I don't have much time today, I'm on a (virtual) sprint [07:39] good morning === Nisstyre_ is now known as Nisstyre === tkamppeter_ is now known as tkamppeter [09:12] kirkland: can you describe again what you have in mind? (example use-case) [09:29] pitti: good mornign [09:29] pitti: do you have a minute? [09:30] hey zyga; what's up? [09:30] pitti: hi, I'm designing/implementing a feature for checkbox rewrite and I could use your help with regards to current desktop tech [09:31] pitti: I need to have a part of my app run as to be able to execute priviledged programs/scripts [09:31] pitti: and I was looking for options here [09:31] pitti: people point me at policykit and pkexec [09:32] zyga: right; you can write a .policy file for an executable which a process can run through pkexec [09:33] zyga: e. g. grep -r exec.path /usr/share/polkit-1/actions/ [09:33] pitti: so would that work for a specific command or could it be more generic? in practice checkbox would start the helper each time and keep it around to spawn additional commands [09:33] oh, let me check that [09:34] zyga: it should be specific; otherwise you introduce a (mostly unsafe) alternative to plain sudo [09:34] is that a pure shell / command interface or is there something I can poke from python? we may need to run headless in some cases [09:34] zyga: NB that any process can call that, not just checkbox; so if you have somethign which can execute arbitrary code you always need to ask for authentication [09:34] hmm [09:35] that's not good really, previously we did not (ask) [09:35] zyga: authentication needs a DISPLAY or a stdout/stdin [09:35] zyga: well, you can either do something very specific which is safe and cannot be parameterized by the user, or do something generic and ask [09:35] * zyga needs to check how it worked before but I'm pretty sure it was a sudo of some sort [09:35] (indepedent of the particular technology) [09:35] yeah, you are right [09:36] zyga: pkexec checks org.freedesktop.policykit.exec.path, shows the description and then asks or not depending on the allow_* values [09:37] pitti: looking at current checkbox code I see sudo all over the place [09:37] for example, pkexec /usr/lib/ubuntu-release-upgrader/do-partial-upgrade [09:37] zyga: sudo, not gksu? how does that work on a desktop tehn? [09:37] zyga: you can run graphical programs with true [09:37] that will pass on $DISPLAY to the executed program [09:38] pitti: it's a hybrid that tries kdesudo, gksu and sudo [09:38] pitti: it also greps for gnome-panel, nooo ;-) [09:39] zyga: so, as we are trying to get rid of gksu, pkexec is certainly the preferred method these days [09:39] yeah, I want to do it right so that we don't run as root 90% of the time [09:39] xdiagnose and update-notifier still depend on it, though [09:39] it's tricky as we pretty much run arbitrary (more less) shell as root often [09:39] well, packaged but arbitrary [09:40] is it possible to parametrize policykit based on stuff like user logged in at console? [09:40] yes [09:40] like not ask for authentication if I'm logged in interactively? [09:40] zyga: that's in fact how it always works [09:40] no [09:40] ok, I guess policy kit is the way [09:41] no [09:41] auth_admin [09:41] should I aim for direct execution of pkexec or some bindings? [09:41] zyga: execing pkexec is fine; I'm not aware of an API for it (but there might be) [09:41] ok, then last question [09:41] how does this fare with testing? [09:41] zyga: but still, you need to ask for auth if you execute something which can run arbitrary commands [09:42] in some cases we will want to run real stuff as root for automated testing [09:42] pitti: not arbitrary, only stuff packaged with checkbox, we can make sure it's not looking into arbitrary places === yofel_ is now known as yofel === henrix_` is now known as henrix [10:16] pitti: do you think it would be appropriate to have a bus-activated service that just sits there and can start/run checkbox "job" with polkit serving as guard to run a particular job; my motivation is that a typical checkbox "session" involves dozens of jobs, most of which want root, I'd like to spawn the notification at most once per started checkbox application [10:19] zyga: why is that additional indirection any better than just running it through pkexec? [10:20] zyga: usually you'd either have the spawned d-bus process be the service itself, or run it through pkexec, but why combine both? [10:20] pitti: not sure, I guess you are right that I could just spawn the daemon once via pkexec [10:20] pitti: er, scratch that [10:20] pitti: so dbus daemon is okay, but then it would allow anyone to just run checkbox jobs [10:21] depends what's more appropriate; i. e. you want the service to start when someone tries to talk to it, or when you know you are going to need it but it doesn't have a single D-BUS interface [10:21] pitti: for instnace anyone could request 30 sleep/resume cycles [10:21] right, that's the kind of backend service that needs authentication [10:21] pitti: so hence dbus (to run as root and get started on deman) and polkit (to ask the user if they really agree) [10:23] pitti: but I don't want to ask the user all the time, I guess this could be provided by having some session management inside the deamon itself, where some call to com.canonical.checkbox:OpenSession() would query polkit and provide some kind of object back that has actual RunJob() methods [10:24] zyga: there's always "auth_admin_keep" if you want to retain the priv for the current session [10:24] oh [10:24] maybe that's easier than [10:24] pitti: I'm sorry for throwing all the questions at you, I'm still reading polkit docs [10:24] no worries :) [10:25] zyga: but frankly, if most of your tests need root privs, why don't you just run the whole thing as root [10:25] zyga: things like "suspend" don't need root, but I guess there are things which do [10:25] pitti: I'm somewhat worried about the multitude environments in which polkit can be used (all the conbination of agents being or not being available, etc), I wonder if just using pkexec() is a simple workaround to make sure it will allways work (ssh to a headless server) [10:25] pitti: well we want a UI too, I don't want to run the UI as root [10:26] pitti: then the two want to talk [10:26] zyga: you want the UI as user so that you can talk to the user's session d-bus and the like? [10:27] otherwise you'll probably introduce ten times more attack vectors by having this rather open "execute 120 different things as root through PK" than having the whole thing run as root and benefit from the usual process isolation [10:27] pitti: as a user to keep root away from too many things, the UI will be basically something you start from the desktop so I don't suppose that should run as root; I don't expect it will talk to many things thoug. A few of the tests want to see the user's environment but those don't need to run as root (so can use the current job starting mechaism) [10:29] pitti: I could write a small tool, checkbox-run-job, that can be started with pkexec, that only runs commands from /usr/share/chcekbox/jobs [10:29] pitti: then all the app logic runs as normal user [10:29] pitti: and the helper would only load, validate and execute a job [10:29] (and passthrough the IO) [10:29] zyga: right, cf. "introduce more vectors than you close" :) [10:30] pitti: 'cf? [10:30] "refer to", "see above" [10:30] hmm, but how would that be more attack vectors? it would need to run as root and pkexec could handle that, there would be a prompt [10:30] pitti: is there a better way to do that? [10:31] (and it's still less risky than plain sudo shell) [10:31] zyga: if you really don't want to run the whole thing as root, then I don't know any [10:31] polkit is the standard tech for that then [10:31] pitti: when you say 'the whole thing', does that include the UI? [10:34] zyga: yes [10:34] pitti: would that be safer? [10:34] zyga: problem with auth-admin-keep is that from then on every other process in the session can run this process [10:34] I think privileges are by-session, not by-process, but I'm not 100% sure of that [10:35] pitti: then auth-admin-keep would not be what I want to use [10:35] if auth-admin-keep is given out by process, it's fine [10:35] pitti: ok, let me read on the docs a moment [10:38] pitti: we don't seem to have pkttyagent in quantal? [10:41] zyga: no, never heard of that [10:41] zyga: pkexec just asks on /dev/console / stdout for authentication [10:42] (unless something like polkit-gnome-authentication-agent-1 is available on the session bus) [10:42] http://www.freedesktop.org/software/polkit/docs/latest/pkttyagent.1.html [10:42] could be something new [10:43] pitti: to some degree this is okay, I suspect that the checkbox rewrite will only be in raring (if we push the package) and we always use ppa for certification [10:43] * zyga checks raring [10:55] yeah, it's in raring [11:22] * xnox is thinking to fork xchat [11:23] fork ? where to ? [11:27] which one? xchat or xchat-gnome? [11:27] mitya57: xchat-gnome sucks as it is, so to fork xchat. [11:28] * mitya57 +1's [11:28] ogra_: mitya57: I'm just annoyed that I sometimes hit "Ctlr+L" and it wipes the screen, when I was looking at the browser window on my right screen and was hoping focus-to-follow-eye and put my cursor in the adress bar ;-) [11:29] also new messaging indicator stuff, and other ZNC proxy fixes. [11:29] xnox, oh, i got the same prob with focus follow eye ! [11:29] is upstream not accepting patches? [11:29] file a bug ! [11:29] i'll confirm it [11:30] mitya57: isn't upstream dead for years now? === _salem is now known as salem_ [11:31] latest news from 28-Aug-2010 [11:31] the latest commit was on 2012-07-27 according to LP [11:31] I wonder if I should be running daily build. [11:34] * mitya57 wonders if patches from https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/xchat/raring/files/head:/debian/patches/ were forwarded [11:35] I'm going to need a bit of help with one of the Developer Week sessions. We have a 30 minute slot on Thu 31st Jan 18:30 UTC where we need a speaker. We were thinking of having a "here's a small bug, and here's how to fix it" demo or a short session on how to find stuff to work on - but at this stage we'd be happy about whatever session we can put into the schedule. Can anyone please help out? [11:35] (https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable) [11:38] dholbach: is how to fix a package to cross-build "small" enough? [11:39] (most of those patches are trivial, but does require understanding of autoconf terms build,host,targer-arch and the ~approx. similar DEB_HOST_ARCH & DEB_BUILD_ARCH Debian terms) [11:40] xnox, if you want to give a session and enlighten the audience about that, that'd be brilliant :) [11:40] I was thinking I could present the problem, point at how to setup the environment for cross-building and demonstrate a few fixes. [11:40] Q&A and hopefully get cross-building fixes from community =) [11:40] xnox, should 30 minutes be enough? [11:41] Yes. It's actually very easy. [11:41] And ties in nicely with Mobile Story ;-) [11:41] fantastic - does the timing work for you too? [11:41] yeah, should be fine. [11:41] * dholbach hugs xnox [11:41] thanks a lot! [11:42] xnox, would you like to use IRC or a Hangout-On-Air? [11:43] Hmm... IRC sounds nice, but with Hangout-On-Air I guess I can share my screen. [11:43] But with Hangout on Air, I'll need to shave. Hmm... I'll tinker with both and check what I will come up with. [11:43] it depends what you want to do - if you want people to copy/paste easily, IRC might work better [11:43] haha [11:44] just let me know beforehand, so we can plan it properly [11:44] I don't want people to copy & paste stuff interractively, cause e.g. cross-build chroot setup will take a while for some people due to download sizes. [11:44] Ok. [11:48] * Laney tries to imagine xnox with a beard [11:49] Laney: if you stock me on facebook enough there are some very obscure pictures when I had a thick even beard. I bet ev would be jealous. [11:50] ha! Hardly. In the time since you last saw me, my beard has grown tenfold. [11:50] BEARD WARS [11:51] I've started to prefix GNU/ on all of my nouns. [11:53] =))))))))))))))))))) [11:53] haha [12:09] Laney: heh [12:12] mlankhorst: I'm sort of considering releasing the enablement X stack to -updates - the only insufficiently-aged piece is mesa-lts-quantal, at 5 days [12:12] But given that it isn't installed by default, I'm not sure that's all that important [12:12] mlankhorst: Do you have any remaining concerns? [12:14] Maybe I should clean up http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html first [12:15] erm uninstallable? [12:15] Component mismatches, I think [12:15] I'm just sorting things out so that I get a better report [12:16] it would seem so, I can install the first one from mesa list just fine, but I'll try them all [12:16] (i.e. not your fault) [12:16] Don't waste time on it for now [12:17] ok well moving to updates is fine with me then [12:25] Hmm, none of this appears to reproduce in chdist [12:30] yeah I remember testing earlier revisions of xxv-omap too on panda, apart from compiz fail it worked [12:31] all the ones it reports have in common that they have libdrm or mesa as dependency [12:33] hey guys todays libc6 update triggered a debconf in the details terminal that wasn't obvious is this known already? [12:33] mlankhorst: I think it's failing to consider -updates - fixing [12:33] ah === security is now known as megha [12:40] mlankhorst: OK, report is better now [12:41] mlankhorst: If I just promote *-lts-quantal, am I missing anything? [12:43] I don't think so. xorg and mesa unrenamed were promoted already right? [12:44] Yep [12:46] that should be enough then :) [12:47] Oh, excepting linux*-lts-quantal of course [12:47] OK, promoting [12:47] you do want some form [12:47] of linux*lts-quantal [12:48] else xorg-lts-quantal will suggest a package that can't be installed [12:48] We already have earlier versions [12:48] It's just an ABI change in -proposed right now, insufficiently tested and aged [12:48] ah sure [12:50] *splat* [12:51] \o/ [12:53] That should make sru-report rather a lot faster [12:55] could always put https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport in -proposed :P [12:57] did glibc get an update? [12:59] I accepted one for {precise,quantal}-proposed this morning [13:01] ah right, the i386 version probably needs to update first. apt-get dist-upgrade wants to remove every 32-bits package I have [13:02] -proposed has no guarantee of multiarch safety [13:02] -updates does [13:09] indeed, would be nice if apt would choose to hold back packages in that case, instead of uninstalling an entire arch, though === chiluk_away is now known as chiluk [14:09] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [14:10] MacSlow, filed https://bugs.launchpad.net/notify-osd/+bug/1107919 if you or didrocks wants to handle it [14:10] Ubuntu bug 1107919 in Notify OSD "Should have builtin actions support" [Undecided,New] [14:15] hadess: but there is existing fallback to standard gtk implementation. [14:15] not sure which one it is. [14:16] the problem with that fallback is that it doesn't use GApplication, therefore if one sends ten same action notifications you get 10 poop-ups, instead of the first one to "re-focus"ed [14:17] so I am not sure how/where this has regressed. [14:17] xnox, there's no implementation of the notification daemon specs in gtk+ [14:17] xnox, and notify-osd still claims not to support actions in the latest quantal version [14:18] * xnox will have to look how some apps do end up showing GtkDialogs. [14:18] xnox, because each one of them has that code implemented as fallback [14:19] ideally we should patch them not to show actions at all. period. =) but hey, it's almost like swimming against upstream. [14:21] xnox, which is impossible when you have a yes/no question coming from a core part of the desktop [14:22] but the disk errors do create a GtkDialog with buttons to inspect or cancel. [14:22] do they do it themself? [14:28] xnox, I was just looking for an easy way to test it, but notify-send can't, and it seems like there's nothing in lp:notify-send/tests/ that does. === dous_ is now known as dous [14:29] mpt: yeah, since notify-osd doesn't support those =/ I was thinking to trow a python script together to test it. [14:37] xnox, pretty certain they do [14:37] xnox, or did, rather [14:38] still does actually === henrix is now known as henrix_ === henrix_ is now known as henrix === slank_away is now known as slank [14:57] hadess, there is a fallback that opens a gtk-dialog... === henrix is now known as henrix_ [14:57] hadess, but that's actually a debug/devel feature disabled by default [14:58] MacSlow, time to promote it! [14:58] hadess, a distro wanting to ship that enabled is free to do so... [14:58] MacSlow, the only distro shipping notify-osd as the default is ubuntu === henrix_ is now known as henrix [14:59] moving the burden to application developers to do something that can easily be implemented server side isn't too nice [15:00] and it also means patching up parts of the stack that you use (from GNOME gnome-settings-daemon, vino, etc.) to implement the fallbacks === slank is now known as slank_away === slank_away is now known as slank === ia_ is now known as hallyn === ximion is now known as ximion-afk === ximion-afk is now known as ximion === fisted_ is now known as fisted === jono is now known as Guest10241 [16:30] ev, the bug in question is bug 1018117 [16:30] bug 1018117 in Apport "No design for crashes handled long after they happened" [Medium,In progress] https://launchpad.net/bugs/1018117 === sil2100_ is now known as sil2100 [16:49] mlankhorst: It'd be good if somebody could verify bug 927424 [16:49] bug 927424 in plymouth (Ubuntu Precise) "Please backport commit to enable building without irrelevant drm libs on some arches" [High,Fix committed] https://launchpad.net/bugs/927424 [16:49] cjwatson: could try on panda in a bit [17:00] mlankhorst: Checking the build log from the buildds should do the trick. [17:02] well it no longer links against libdrm-intel1 [17:02] Right, I just checked that. [17:03] was just hoping to get it to show splash screen too, but just realized it would probably not do that on omap anyway through drm [17:03] Not a hope. libdrm-omap depends on kernel features that aren't in precise. [17:05] oops, also had to onew libdrm from my own ppa [17:06] it overwrote the ti one [17:10] ah well good enough for now :) [17:15] On 12.10, after eglibc (2.15-0ubuntu20.1) update I cannot install libc6:i386 and I get unmet dep. libc6:i386 : Depends: tzdata:i386 error. Is it normal? [17:15] you have -proposed by any chance? [17:16] if so just wait a few hours, or disable -proposed :) [17:16] mlankhorst, yeah I use proposed. Ah so, libc6:i386 not compiled yet? [17:17] all my i386 packages are gone with libc6:i386 package : ( [17:18] It'll sort itself out soon enough [17:18] Just don't let it remove things for now [17:18] cjwatson, eheh too late but thanks for the info [17:19] That was daft of you :) [17:19] Don't ever let apt remove packages without checking [17:19] considering it was a screen full of deps for wine removal, hard to not notice :-) [17:19] It's built on i386 now, so it's probably just an out-of-date mirror [17:22] if I wouldn't use an out-of-date mirror, is there still a chance to update at some point that libc6 update is published but libc6:i386 is not? [17:23] gkcn: Yes [17:23] gkcn: -proposed is not guaranteed to be multiarch-safe; it's fine for users who don't use -proposed [17:24] cjwatson: clearly we need -proposed-proposed or not publish until fully build....... [17:24] * xnox hides [17:24] ... or not [17:24] cjwatson, I see. [17:24] (archive complex enough) [17:25] cjwatson, is it hard to make it multiarch-safe or is it a deliberate decision to make testers suffer :) [17:26] gkcn: haha. possibly we should not ask people to test stuff until build & published. [17:26] It is hard [17:26] gkcn: it's the same as arch:all (part of i386 build) finishing before arch:any (!i386 builds) packages [17:27] such that anything that depends on -common gets broken. [17:27] And in any case I tend to think that apt should behave a bit better, rather than further complexifying the archive just for this [17:27] In the case xnox mentions it generally just holds things back, rather than removing lots of stuff [17:28] holding multi-arch world back would be nice as well. === deryck is now known as deryck[lunch] === Ursinha is now known as Ursinha-afk === henrix is now known as henrix_ === henrix_ is now known as henrix [18:32] Hello. How would you package a new software? Should I create a bazar repo on sf.net, for example? Or just locally? [18:52] barry: i got the MP created for you [18:54] stokachu: cool. i'm piloting tomorrow so i'll take a look then [18:54] sounds good, thanks man === deryck[lunch] is now known as deryck [19:35] If a package compiles with boost1.49 & boost1.50, which one should I choose for dependency? [19:37] Phonequer: I believe 1.49 is default still === funkyHat_ is now known as funkyHat [19:47] Phonequer: use the one that is installed and works. === Ursinha-afk is now known as Ursinha [20:02] how do i go about replacing an ubuntu package that was introduced directly into ubuntu, with the same package that has since been released into debian? anything special or will a standard debdiff work? [20:03] adam_g: treat it like a merge [20:08] micahg: how so? i can 'bzr import-dsc' from debian and merge that, but future merges from debian via bzr branches woudln't have any common ancestor. or is that workflow not expected to work? [20:09] adam_g: I'm not sure, I don't use the bzr workflow, can we not sync whoelsale? [20:09] *wholesale [20:10] yeah, I'd debdiff the two and review the differences [20:10] the difference between this and a merge is that the deviation wasn't intentional. So one gets to decide how important each difference is... [20:11] micahg: yeah, i believe a direct sync would be fine here. i guess thats my real question: how to get rid of the original ubuntu package in favor of a direct sync ? [20:11] if they have the same name, you just sync [20:12] dobey: I can block some other package that relies on 1.49 this way, can I ? [20:13] Phonequer: i don't understand what you're asking [20:13] pitti: hi, do you have any comment on bug 1103022 ? [20:13] bug 1103022 in udev (Ubuntu) "70-udev-acl.rules needs to put g+rw on /dev/kvm" [High,Confirmed] https://launchpad.net/bugs/1103022 [20:13] dobey: It's about targeting boost 1.49/default or 1.50 [20:14] i'd like to know whehter the workaround for that is going to need to stay in qemu for awhile or not [20:14] Phonequer: aren't they parallel installable? isn't that why they have the version numbers in the names for the -dev packages? [20:14] or is it just a transitional thing? [20:15] hallyn: Hey, speaking of qemu. The /etc/kvm/*if* scripts are dangling symlinks on my machine (or, were until I aimed them at /usr/bin/qemu-*) [20:17] infinity: interesting. those should get fixed with the next merge from debian though [20:17] hallyn: Kay, cool. [20:17] though that one scares me, and i should probably talk to you about it anyway: they're splitting up qemu-system into per-arch [20:17] tumbleweed: thanks [20:17] infinity: so qemu-system-x86 (for instance) will presumably start in universe [20:17] dobey: you might be right. I listed my installed libboost* packages and I have 1.50 & 1.49. The problem was when I was installing libboost-filesystem1.49 -- it reported an impossible situation. However libboost-filesystem1.49.0 (i.e. +".0") works [20:17] (and i can only pray i get all the new breaks/repalces/provides right) [20:18] on the bright side, i do think this will be the last big reworking for awhile [20:18] infinity: anyway i'm working on that merge right now, but i'll jot down a note to check that when i'm done, thanks [20:19] hallyn: Will there not still be a qemu-system and qemu-user metapackage that pulls in all the tiny ones for smooth upgrades? [20:19]