[00:51] <diwic> Hello,
[00:52] <diwic> while trying to build a package with pbuilder it seems like it can't satisfy the libjack-dev dependency
[00:52] <diwic> how can that be?
[00:54] <RainCT_> Out of curiosity, how often are apt's Translation-X files updated?
[00:54] <RainCT_> diwic: Try updating your pbuilder.
[00:55] <diwic> "pbuilder update"? Tried that.
[00:59] <diwic> RainCT_: pbuilder-satisfy-depends-dummy: Depends: libjack-dev which is a virtual package.
[01:00] <diwic> AFAIK, libjack-dev is not a virtual package...?
[01:02] <c_korn> http://packages.ubuntu.com/search?keywords=libjack-dev&searchon=names&suite=all&section=all
[01:02] <c_korn> diwic: you are not running dapper by chance ? :)
[01:02] <diwic> c_kom: I hope not :-) Freshly installed karmic
[01:03] <diwic> c_korn: sorry I misspelled your name
[01:20] <diwic> gaah...found it...forgot to enable universe
[02:01] <LordMetroid> What is Ubuntu doing for so long after one has logged in to one's user?
[02:01] <LordMetroid> It is annoying as hell to wait after one has logged in
[02:02] <LordMetroid> Cause in the time it takes to come to the login field, you can go and take a cup of coffee
[02:02] <LordMetroid> In jaunty when you logged in you got the system served to you
[02:02] <LordMetroid> Now I have to wait
[02:32] <billybigrigger> anyone tried vnc sessions in karmic?
[06:03] <TheMuso> Do such packages as xsplash, indicator-session, and libdbusmenu require feature freeze exceptions to be updated? Yes I know Canonical works on them, but they are new upstream releases after all. (I am looking into sponsoring uploads, and want to be sure an FFE is not required before I do so.)
[06:07] <ScottK> TheMuso: My understanding was they were to be treated like any other upstream.
[06:08] <ScottK> Certainly that's what we're doing in Kubuntu.  For Ubuntu I don't know if it's different.
[06:12] <dholbach> good morning
[06:13] <superm1> TheMuso, keep in mind new upstream release != new features though
[06:13] <superm1> (necessarily)
[06:13] <TheMuso> superm1: I am aware of that.
[06:32] <dholbach> vorian: can you please please please take a look at bug 386428?
[06:51] <dholbach> ArneGoetje: will scim-anthy stay in main?
[06:52] <dholbach> if it should go to universe, we wouldn't need a MIR
[06:52] <dholbach> (for kasumi)
[06:53] <dholbach> pitti: ^ do you know what the state of the discussion is there?
[06:53] <dholbach> scim vs ibus?
[06:53] <ArneGoetje> dholbach: stay in main
[06:55] <dholbach> ok
[06:55] <ArneGoetje> dholbach: we may need to switch back to scim if ibus appears to be too buggy and we cannot fix the issues in time
[06:55] <dholbach> alright
[06:56] <dholbach> ArneGoetje: there were a bunch of ITPs filed in Debian for new ibus plugins
[06:56] <ArneGoetje> dholbach: yeah, saw them
[06:59] <ArneGoetje> dholbach: but it's more important to get the current code into a good shape
[06:59] <dholbach> right
[07:03] <dholbach> I was just excited to see things moving so quickly in ibus land
[07:04]  * nixternal hugs dholbach 
[07:05]  * dholbach hugs nixternal back :)
[07:05] <nixternal> good morning sir
[07:19] <StevenK> ArneGoetje: In regards to the bug, if the upstream doesn't want to remove the .desktop file, we can just NoDisplay=true it
[07:19] <ArneGoetje> StevenK: yeah
[07:22] <StevenK> ArneGoetje: But however you want to deal with it is fine
[07:23] <ArneGoetje> StevenK: I'll poke the package maintainer again
[07:24] <ArneGoetje> StevenK: I really don't want to carry a delta around
[07:33] <StevenK> ArneGoetje: Even if it's a one-line delta? :-)
[07:34] <ArneGoetje> lidaobing: what about bug #420282 ?
[07:35] <lidaobing> ArneGoetje, I'll fix that in today or tomorrow
[07:35] <ArneGoetje> lidaobing: thanks
[07:35] <ArneGoetje> StevenK: ^
[07:37] <StevenK> Fix it how, though? :-)
[08:17] <pitti> Good morning
[08:18] <pitti> dholbach: no, from what I know scim should move to universe, we only keep ibus
[08:20] <dholbach> pitti: ArneGoetje seems to think otherwise
[08:20] <pitti> oh really? I thought we discussed that
[08:20] <pitti> ArneGoetje: we still need scim?
[08:21]  * StevenK waves to pitti, throwing him a gummy bear
[08:22] <dholbach> hey seb128
[08:22] <seb128> hello dholbach
[08:22] <pitti> hey StevenK!
[08:24] <ogra> hmm, did pidgin finally move to universe ?
[08:24] <StevenK> I thought it was supposed to stay?
[08:24]  * ogra wonders why nautilus-sendto doesnt find it at build time
[08:25] <ogra> well, n-s ftbfs on armel
[08:25] <ogra>  pidgin-dev: Depends: pidgin (>= 1:2.6.1-2ubuntu1) but it is not going to be installed
[08:25] <ogra>               Depends: libpurple-dev but it is not going to be installed
[08:25] <seb128> arch all-any mismatch there?
[08:25] <seb128> the new version has just been uploaded yesterday
[08:26] <ogra> yeah, i missed there was a pidgin upload yesterday
[08:26] <ogra> given back
[08:26] <ArneGoetje> pitti: if ibus is too buggy and we cannot fix the issues in time, we'll switch back to scim... that's what we discussed.
[08:27] <pitti> ArneGoetje: right, but why do we need to keep both in main?
[08:27] <ArneGoetje> pitti: you want to move scim back and forth?
[08:28] <pitti> well, I want to make sure that we fix all dependencies, so that it is ready to go to universe
[08:29] <pitti> ArneGoetje: ATM, something still keeps it in main through a dependency
[09:21] <slangasek> TheMuso: why is paprefs now pulling in packagekit-gnome?
[09:23] <slangasek> TheMuso: I now have an extra (and buggy) update notification icon on my taskbar thanks to this; I think I'm going to remove paprefs from my system to get rid of it, but the dependency looks wrong to me anyway
[09:27] <Ryan52> dholbach, asac, didrocks: could one of you please look at this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-web-photo/+bug/423822
[09:27] <Ryan52> dholbach, asac, didrocks: that ugly hack of a wrapper script around gnome-web-photo instead of linking properly to libxul was probably a bad idea...
[09:28] <dholbach> asac: can you take a look at it? I don't know enough about it
[09:31] <mvo> slangasek: I filed a bug about this
[09:33] <asac> Ryan52: using libxul is no answer for sure either. i cant remember exactly what i did, but most likely i tried to avoid porting it to use the real "standalone glue"
[09:34] <Ryan52> yes, by "properly linking" I meant using the xpcom glue.
[09:34] <asac> i dont know for sure how to use gnome-web-photo. please drop instructions how to reproduce in the bug
[09:34] <Ryan52> honestly, I don't know how to use it either.
[09:34] <Ryan52> for that, I'm sure dholbach can explain tho :)
[09:34] <asac> ah thats not your bug ;)
[09:35] <asac> Ryan52: want to work on it ;)`
[09:35] <asac> ?
[09:35] <Ryan52> I'm not an Ubuntu user, and we don't have gnome-web-photo in Debian. I'm just taking care of my shutter users. :)
[09:35] <asac> what does shutter do then?
[09:36] <Ryan52> takes screenshots from various places, one of those places being the web, for which it uses gnome-web-photo.
[09:36] <asac> how
[09:36] <asac> ?
[09:36] <dholbach> daniel@miyazaki:~$ gnome-web-photo.real --mode=thumbnail https://daniel.holba.ch/blog bla.png
[09:36] <dholbach> gnome-web-photo.real: error while loading shared libraries: libxul.so: cannot open shared object file: No such file or directory
[09:36] <dholbach> daniel@miyazaki:~$
[09:36] <asac> do you run a command? or link against a lib?
[09:36] <asac> dont call .real
[09:36] <dholbach> I guess that's what the problem is right now
[09:36] <asac> why do you do that?
[09:37] <dholbach> asac: the other one didn't work either :)
[09:37] <dholbach> but basically that's how you'd run it
[09:37] <Ryan52> asac: once gnome-web-photo works, shutter will too, so fix dholbach's problem :)
[09:37] <asac> Ryan52: .real is not supposed to work
[09:37] <Ryan52> asac: he said the other one doesn't work either.
[09:37] <asac> but no hint how
[09:37] <asac> from what i know the non-real thing sets the LD_LIBRARY_PATH
[09:38] <dholbach> daniel@miyazaki:~$ gnome-web-photo --mode=thumbnail https://daniel.holba.ch/blog bla.png
[09:38] <dholbach> Registering '@mozilla.org/module-loader/python;1' (libpyloader.so)
[09:38] <dholbach> Registering '@mozilla.org/network/protocol/about;1?what=python' (pyabout.py)

[09:38] <asac> so thats different ;)
[09:38] <asac> and has nothing to do with libxul
[09:38] <dholbach> I have no idea what happens there tbh
[09:38] <asac> Ryan52: ^^ dont call .real ;)
[09:38] <Ryan52> ./share/shutter/resources/modules/Shutter/Screenshot/Web.pm:    system("gnome-web-photo --timeout=$self->{_timeout} --mode=photo --format=$self->{_format} -q $self->{_quality} '$self->{_url}' '$self->{_dest_filename}'");
[09:38] <Ryan52> from shutter's source code.
[09:38] <Ryan52> so it doesn't look like shutter is calling .real
[09:38] <asac> but http://launchpadlibrarian.net/31278228/screenshot_006.png
[09:39] <asac> dholbach: can you paste the non-real script?
[09:39] <dholbach> just a sec
[09:40] <Ryan52> asac: I dunno, I'm just telling you what I know :)
[09:40] <dholbach> http://paste.ubuntu.com/264842/
[09:40] <mat_t> pitti: hey
[09:40]  * Ryan52 thinks there should be a 1.9.1 there..
[09:42] <asac> yes
[09:49] <pitti> hi mat_t
[09:53] <Ryan52> asac, dholbach: am I correct in assuming that neither of you are going to look further into it?
[09:53] <Ryan52> I guess tomorrow I'll install Ubuntu, meh. -.-
[09:54] <asac> Ryan52: any help would be appreciated. eventually i hope i would look at it
[09:54] <dholbach> Ryan52: I'm too busy at the moment to look into it, I'm sorry
[09:55] <asac> Ryan52: if you cannot do it, just remember to assign the bug to me
[09:55] <Ryan52> okay, thanks.
[09:59] <mat_t> pitti: I'm preparing the usplash assets now
[10:08] <TheMuso> slangasek: Because upstream told me that it required packagekit-gnome. Unfrotunately I don't know much about packagekit, so I added a dep on the package that provided the needed executable that paprefs needs.
[10:12] <pitti> TheMuso: eww, can we do without PK-gnome, please?
[10:12] <pitti> we really don't want to propose it as general interface for installing packages
[10:13] <pitti> PK is not suitable to be a general package installer on Debianish systems
[10:13] <pitti> and it's painfully slow, too
[10:15] <mvo> we should discuss this at next UDS, but if we can not get debconf support for PK I guess we need to bite the bullet and provide a PK compatible dbus session interface
[10:15] <mvo> we have a debconf frontend for aptdaemon, so its not a technical problem (anymore)
[10:15] <cjwatson> I think upstream said that if we want the former it should be done using the latter
[10:15] <mvo> oh well
[10:16] <pitti> mvo: that, and conffiles
[10:16] <mvo> right
[10:16] <cjwatson> Joey and I talked with Guillem at DebConf about moving bits of debconf into dpkg; it's still not out of the question that we might be able to get conffile prompts implemented using debconf
[10:17] <cjwatson> which really does need to happen ultimately
[10:30] <james_w> for conffiles, would there be an issue with doing the prompting at the end of the run?
[10:31] <james_w> i.e. are there good reasons why the prompt is done when it is?
[10:33] <cjwatson> the package isn't configured properly until the conffile is replaced; for instance you often need to replace the conffile before starting a daemon
[10:33] <cjwatson> this can be pretty importance
[10:33] <cjwatson> important
[10:34] <pitti> but debconf is also done at preinst time, so wrt. conffiles this should DTRT?
[10:35] <pitti> seb128: ah, retracers didn't upgrade yet, so they failed again; upgrading manually and restarting
[10:35] <seb128> pitti, thanks
[10:36] <seb128> sorry I've been not very helping on those this week
[10:36] <pitti> seb128: no problem, just to let you know why you got another set of spam mails
[10:37] <dholbach> mok0: great session yesterday!
[10:40] <cjwatson> pitti: yes; but conffiles are postinst-time anyway
[10:46] <TheMuso> pitti: Right will look Monday, but I guess we have to disable the install feature in paprefs then, or patch it to use apt...
[10:48] <pitti> TheMuso: what does it want to install?
[10:55] <TheMuso> pitti: afaik to install things like the bits needed to talk over the network via upnp/zeroconf etc I suspect.
[10:56] <pitti> TheMuso: we could replace that with a call to gksu synaptics...? (there's a standard invocation for this to install a particular package; let me know if you need it)
[10:56] <TheMuso> pitti: ok thanks
[10:57] <seb128> TheMuso, hey, there is a new libcanberra version available in case you didn't notice
[10:57] <seb128> not sure if you want to do the update
[10:59] <TheMuso> seb128: Known, and wasn't sure if it was under the GNOME upstrea version umbrella, so just pulled important fixes from it for now.
[10:59] <seb128> TheMuso, ah ok, I would just do the update it seems mostly bug fix changes
[11:23] <pitti> does anyone happen to know if latest karmic now enables KMS by default on ATI?
[11:25] <pitti> tkamppeter: do you have some time to look at bug 422930?
[11:26] <jderose> pitti: I believe KMS is still only enabled for Intel chipsets
[11:26] <pitti> jderose: ok, thanks
[11:26] <jderose> pitti: but i haven't tried it, just read it from http://www.ubuntu.com/testing/karmic/alpha5
[11:26] <pitti> bryce, tjaalton: is it still the plan to enable ati kms by default, as said on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus ?
[11:33] <tjaalton> pitti: I'm not sure, bryce has been testing it. AIUI there are performance regressions when it's used
[12:15] <Riddell> asac: this would be nice to look at, probably for karmic+1 http://lists.opensuse.org/opensuse-kde/2009-09/msg00006.html
[12:17] <asac> Riddell: yeah. but it has to land upstream first ;)
[12:17] <asac> in the past suses hacks against ffox were regularly rejected
[12:18] <asac> but right. i should check and see if i can helkp them with upstreaming this
[12:21] <tkamppeter> pitti, bug 422930 is most likely called by the USB backend problems of CUPS. Please also upload the current BZR state of CUPS to assure that all fixes are in.
[12:56] <pitti> tkamppeter: current bzr head is already in karmic (I uploaded a bzr snapshot for alpha-5)
[12:57] <tkamppeter> pitti, OK, thanks.
[13:23] <taavikko> pitti: I accidentally may have selected "ignore future crashes" in apport, I just can't find the right place to nullify this decision... any help?
[13:24] <pitti> taavikko: rm ~/.apport-ignore.xml
[13:24] <pitti> taavikko: or wait until a new version of that program arrives :)
[13:25] <taavikko> thanks a punch pitti :)
[13:25] <ogra> dont punch pitti, we need him ;)
[13:27] <taavikko> hold the thanks then, "no .apport-ignore.xml here..."
[13:48] <blackxored> greetings
[13:50] <pitti> taavikko: then you don't have an ignore list
[13:52] <taavikko> pitti: then apport fails somehow to collect crash (it used to work few times today already, but not anymore? )
[13:53] <taavikko> arora keeps crashing ( bug 420474 ) and the .crash file kept growing...
[13:54] <taavikko> todays first crash report was 1GiB in size, removed it, next crash, resulted in 276MiB size, now it is 42Mib so little "funny behaviour"
[13:59] <pitti> taavikko: if it already crashed three times today, it will ignore further crashes today; remove the file in /var/crash if you want to get new ones
[13:59] <taavikko> pitti: doh, the max-report thingy :)
[14:00] <taavikko> is there any limitations how big the crash report can be? didn't felt comfotable sending 1GiB
[14:00] <pitti> taavikko: it's meant to prevent eternal crash loops with programs which restart themselves but crash (e. g. nautilus or devkit-disks)
[14:00] <ogra> pitti, are you the one making decisions about usplash staying/going etc ?
[14:00]  * ogra would like what the status is for live images ... do we keep it there ? 
[14:01] <ogra> *like to know
[14:01] <pitti> taavikko: it's by and large capped on half of your memory size uncompressed core dump
[14:01] <pitti> taavikko: but yes, you shouldn't bother sending a 1GB dump..
[14:01] <pitti> ogra: I thought it was collectively decided at UDS already
[14:02] <pitti> ogra: since usplash kicks in after a (short) timeout, it should automatically come up on the live CDs AFAIUI
[14:02] <ogra> i wasnt there
[14:02] <ogra> ah, cool
[14:02] <pitti> usplash should start (1) on interactivity (boot password), (2) on fsck, (3) when X takes too long to start
[14:02] <ogra> pitti, that concept means if my armel system takes 45sec to boot i will have usplash anyway ?
[14:03] <pitti> ogra: yes; my laptop takes a similar time, so I should see it, too
[14:03] <ogra> cool
[14:03] <ogra> so my work wasnte throw away stuff to make usplash work on imx51 :)
[14:03] <ogra> *wasnt
[14:03] <Notch-11> hi, i'm trying to "beep" during the boot process, but i can't ear anything... must i load some modules or something else to get beep to work?
[14:04] <ogra> probably the pcspkr module ?
[14:05] <ogra> (just a guess)
[14:05] <pitti> Notch-11: pcspkr is blacklisted, you probably need that
[14:05] <Notch-11> ogra: yes, my first guess too, but still can't ear the beep
[14:07] <Notch-11> pitti: with "modprobe pcsprk" should work even if blacklisted, right?
[14:07] <pitti> Notch-11: yes
[14:08] <pitti> Notch-11: if you spell pcspkr right, that is :)
[14:09] <Notch-11> pitti: hehe, both tried :P
[14:10] <Notch-11> mm pcspkr is not in the initrd, maybe this
[14:16] <Notch-11> ubuntu pcspkr
[14:16] <Notch-11> ups
[14:17] <highvoltage> http://www.urbandictionary.com/define.php?term=jonathan
[14:17] <highvoltage> (sorry wrong channel)
[14:23] <Notch-11> nothing, even with the module loaded..
[14:30] <Notch-11> so what is missing for beep to beep ?
[14:30] <RainCT> Keybuk: Hey. Does D-Bus on Karmic have some limitation (as in the size of the answer to a call or something like that) impossed which wasn't there  in Jaunty?
[14:50] <Keybuk> RainCT: not that I know of
[14:50] <Keybuk> there *are* limits to such things
[14:50] <Keybuk> but I don't think they have changed
[14:50] <Keybuk> in fact, the primary limit of D-Bus used to be the length of time a receiver of a message was permitted to take to reply to it until it timed out
[14:50] <Keybuk> and that's been entirely removed
[14:51] <ogra> Keybuk, did you see my ping before ?
[14:51] <Keybuk> ogra: no
[14:51] <ogra> Keybuk, did you notice that the boot slows down with every apparmor profile thats being adeed (additional reads ... i see a massive impact on armel but suspect it happens on other areches as well, just not as noticeable)
[14:51] <jdstrand> ogra, Keybuk: that is not accurate any more
[14:51] <Keybuk> ograyes
[14:51] <ogra> jdstrand, since when ?
[14:51] <ogra> i see it on A5
[14:51] <jdstrand> ogra, Keybuk: or at least not noticably accuate
[14:52] <Keybuk> though that should be largely fixed in karmic aiui
[14:52] <Keybuk> I've certainly not noticed apparmor take that long
[14:52] <Keybuk> (and I made it largely background anyway in my prototype - so services depend on it but not X)
[14:52] <ogra> for me it's enough to make usplash time out
[14:52] <RainCT> Keybuk: Weird. We are having problems with Zeitgeist, always getting the generic error message ("may have timeout/disconnected/etc") when fetching more than 140 items in Karmic, but this works fine on Jaunty (and is actually pretty fast). Anyway, thanks for the info :)
[14:52] <jdstrand> ogra: kees implemented binary caching for the profiles
[14:52] <ogra> (on armel)
[14:53] <ogra> jdstrand, after usplash timed out i can slowly count to 5 to see the [ok] appear
[14:53] <jdstrand> ogra: this is very fast loading, assuming that the cache file exists. if it doesn't already exist, it the cache file must be compiled (done automatically)
[14:53] <ogra> if it was added after A5 i havent probably tried it yet
[14:53] <jdstrand> (or if the profile changed)
[14:53] <ogra> but it is surely noticeable in my A5 installs
[14:54] <jdstrand> subsequent boots will use the cache then
[14:54] <ogra> ok, i'll keep an eye on it ...
[14:54] <jdstrand> ogra: that is certainly odd-- it shouldn't take that long. kees did the implementation so you'd want to follow up with him for problems you are having with it
[14:54] <ogra> i guess usplash needs a bigger timeout anyway on arm
[14:55] <ogra> will do ...
[14:55] <jdstrand> ogra: this feature was added way before A5, so I'm not sure what is going on
[14:55] <Keybuk> the usplash timeout thing is interesting
[14:55] <ogra> i'm currently busy with other stuff and will ping him if i have time for tests and measurements
[14:55] <Keybuk> I just noticed yesterday that there's no support for it in the upstart-based boot
[14:55] <Keybuk> so technically we need to disable the timeout entirely ;)
[14:55] <ogra> meaning ?
[14:55] <ogra> it cant time out at all ?
[14:56] <Keybuk> right
[14:56] <ogra> or we just lose ability to change it
[14:56] <ogra> ah, cool
[14:56]  * ogra loves that
[14:56] <Keybuk> no timeout, upstart already knows to kill usplash itself
[14:57] <Keybuk> (and there's nothing on the console to timeout *to* anyway)
[14:58] <ogra> heh
[15:10] <Ryan52> asac_: ya that wrapper script is crap.
[15:10] <Ryan52> asac_: it thinks it'll find libxul is /usr/lib/xulrunner-addons/
[15:10] <Ryan52> asac_: changing the 1.9.0 to 1.9.1 in it fixes the problem.
[15:13]  * Ryan52 will get a package made later, gotta go now
[15:26] <asac_> Ryan52: thx.
[15:26] <asac_> Ryan52: if you want you can fix it to use standalone glue ;)
[16:10] <tkamppeter> pitti: Your nre udev rules (bug 420015) work.
[16:10] <pitti> tkamppeter: \o/
[16:10] <pitti> tkamppeter: thanks for testing; committing then
[16:14] <kees> ogra: hrm, you're sure it's in apparmor it's stalling?  can you check if /etc/apparmor.d/cache has files?
[16:15] <ogra> kees, on monday ...
[16:17] <seb128> slangasek, are you going to upload your empathy fix or should I do it?
[16:21] <slangasek> seb128: not in the next hour or so; if you don't beat me to it, I'll have a look after the meeting :)
[16:21] <seb128> slangasek, I do it now
[16:23] <kees> ogra: okay (i'm out on monday, US holiday...)
[16:24] <ogra> kees, tue. then, my schedule is full today
[16:24] <kees> ogra: okay
[16:24] <ogra> i want to do some measuring first so i can come up with some numbers
[16:44] <dholbach> Ubuntu Developer Week - last day, starting in 16 minutes in #ubuntu-classroom - https://wiki.ubuntu.com/UbuntuDeveloperWeek
[16:44] <Daviey> \o/
[16:52] <dholbach> hey Daviey!
[16:54] <dholbach> waaaah, I have a half-installed grub-common (/usr/sbin/grub-set-default in package grub too) - am I going to die?!?!?!
[16:58] <cjwatson> bleh
[16:58] <cjwatson> --force-overwrite it for now
[16:59] <dholbach> thanks cjwatson
[17:29] <jdstrand> cjwatson: hmm, bug #423485 doesn't seem to be fixed by the rebuild
[17:29] <jdstrand>  *** 1:3.4.1-1ubuntu2 0
[17:29] <jdstrand> valgrind /bin/echo hello
[17:29] <jdstrand> (very noisy)
[17:30] <cjwatson> jdstrand: it worked for me - can you try to track it down? does /usr/lib/valgrind/default.supp have 2.10 suppressions?
[17:31] <jdstrand> # Errors to suppress by default with glibc 2.10.x
[17:32] <jdstrand> cjwatson: seems to, but I've never looked at this file before
[18:24] <nh2> hi, how to get an app into that "easy-going" gnome app installer (add/remove software)?
[18:52] <cjwatson> kirkland,soren: would appreciate it if you could once-over lp:~cjwatson/eucalyptus/discover-nodes
[19:05] <slangasek> TheMuso: I see nothing in the paprefs package description that explains why it needs to install packages; it's definitely not getting back on my system as long as it has that dep, though
[19:33] <Lutin> I there anything needed to get the flash plugin to output audio with pulseaudio on karmic ? doesn't seem to work here
[19:48] <ebroder> Is it OK for package-a to depend on package-b, and package-b to depend on a >= version of package-a?
[19:48] <ebroder> I don't know whether apt will do the right thing with that or not
[19:48] <cyber_666_uk> hey - can anyone submit software to the repositories?
[19:49] <cyber_666_uk> how does that work, do you need to give out your source code?
[19:55] <slangasek> ebroder: it's generally inadvisable; the package manager has provisions for breaking dependency loops, but it's better to not have them in the first place (e.g., by putting everything in a single binary package instead of splitting it)
[19:56] <ebroder> Hmm...that might actually be an option. This used to be a one-way dependency pointer until the change I just made, so it was less of an issue :)
[19:57] <ebroder> It should be fine if apt wants to temporarily break the loop, though. Thanks
[19:57] <cyber_666_uk> is there a page you can point me to?
[20:07] <kirkland> cjwatson: looking ...
[20:12] <kirkland> cjwatson: looks okay by me
[20:12] <kirkland> cjwatson: i had added the avahi-utils recommends locally here
[20:12] <kirkland> cjwatson: so i can fix that up on merge
[20:12] <kirkland> cjwatson: would you like me to merge, and push that to our working tree?
[20:25] <sgallagh> mathiaz: ping
[20:25] <mathiaz> sgallagh: hi
[20:26] <sgallagh> mathiaz: I don't know if you caught the bug update, but I fixed that hang you were seeing in the proxy provider.
[20:26] <mathiaz> sgallagh: right - I saw something going through
[20:27] <mathiaz> sgallagh: do you plan to maintain a 0.5.X branch?
[20:27] <sgallagh> I figured you'd probably want to pull that and the D-BUS fix in and roll another package
[20:27] <sgallagh> mathiaz: Not at this time, mainly because we're targeting 0.6.0 for Sept. 24th
[20:28] <mathiaz> sgallagh: understood
[20:28] <mathiaz> sgallagh: thanks for letting me know
[20:28] <sgallagh> mathiaz: I wanted to ask something else
[20:28] <sgallagh> mathiaz: Does the Ubuntu development process have anything like concerted feature test days?
[20:28] <sgallagh> I'd like to try and get one scheduled for the SSSD if so
[20:29] <mathiaz> marjo: bdmurray: ^^?
[20:30] <mathiaz> sgallagh: so yes - we're running TestingDays
[20:30] <mathiaz> sgallagh: https://wiki.ubuntu.com/Testing/
[20:30] <mathiaz> sgallagh: https://wiki.ubuntu.com/Testing/UbuntuTestingDay/
[20:30] <mathiaz> sgallagh: hm - there hasn't be one run for a while now
[20:31] <sgallagh> mathiaz: Can you possibly look into scheduling one for us?
[20:31] <mathiaz> sgallagh: we could organize such a day though
[20:32] <mathiaz> sgallagh: sure - I'll get in touch with the QA team
[20:33] <sgallagh> mathiaz: Great, thank you!
[20:53] <sistpoty> hey, congrats bryce!
[20:53] <bryce> sistpoty, thanks
[20:54] <sistpoty> bryce: before you leave, any opinion on bug #424354? if testing confirms that my patch works, ok to upload it?
[21:01] <bryce> sistpoty, wow that's an oddball bug
[21:01] <bryce> sistpoty, but if that patch solves it, yeah I wouldn't have a problem seeing that go in for -cirrus.  Looks properly conditionalized to only affect the specific chip
[21:02] <sistpoty> bryce: ok, thanks... I'll take care to forward it upstream as well then
[21:02] <bryce> sistpoty, so yes, if testing confirms it works, feel free to upload, but please be sure to check launchpad after a couple weeks in case there are any regression bugs reported
[21:02] <bryce> great
[21:03] <sistpoty> bryce: sure, iirc I'm still subscribed to -cirrus bugs (iirc there aren't many people with real cirrus cards out there *g*)
[21:03] <bryce> hehe
[21:04] <sistpoty> and the 4 mb versions seem to be extremely rare, still haven't managed to get one via ebay :(
[21:16] <cjwatson> kirkland: I think it's awaiting an FFE (there's a bug), but otherwise yes please
[21:16] <cjwatson> unless somebody wants to process that :)
[21:19] <kirkland> cjwatson: i was just going to commit to the upstream project for now, and wait for soren to push a package upload
[21:20] <cjwatson> ok, if that's cool with upstream
[22:46] <moldy> hi
[22:47] <moldy> can i safely delete/bzr ignore the .upload files dput creates, or is the information in them important for something?
[22:47] <cjwatson> you can safely delete them; the log file causes dput not to upload the same thing again should you run it again on the same .changes
[22:48] <moldy> cjwatson: ok, thank you
[22:54] <moldy> i just created my first ppa and tried to upload some packages
[22:54] <moldy> i got an error e-mail saying "Unable to find distroseries: unstable"
[22:54] <moldy> what's the right way to correct this?
[22:55] <cjwatson> don't put "unstable" in the top line of your changelog - use "karmic" or whatever
[22:55] <sistpoty> moldy: use one of ubuntu (karmic, jaunty, intrepid, ...) in debian/changelog
[22:56] <moldy> sistpoty: ah, ok, thank you
[22:56] <sistpoty> np
[22:56] <moldy> and you too, cjwatson :)
[22:56] <cjwatson> that should really be in https://help.launchpad.net/Packaging/UploadErrors
[22:56] <cjwatson> (it isn't)
[22:56] <cjwatson> maybe you could suggest that to them
[22:58] <sistpoty> imho a ppa should accept $whatever except releases
[22:59] <cjwatson> the top line of the changelog tells it which release to build for and against
[22:59] <cjwatson> so that could only work if you reinvented the wheel to tell it some other way
[23:00]  * sistpoty thought that was the distribution field in the changes file
[23:00] <moldy> what's the right way to suggest that, cjwatson?
[23:01] <cjwatson> moldy: there's a link at the bottom of the page for giving feedback
[23:01] <cjwatson> sistpoty: which is generated from the top line of the changelog
[23:02] <moldy> cjwatson: ah, right
[23:02] <sistpoty> cjwatson: yep, but changing that wouldn't mean I'd hand out a ticket to upload a ppa package to ubuntu :)
[23:02] <sistpoty> would mean that I wouldn't even
[23:02] <cjwatson> oh, you mean that it should accept something that is not the same as Ubuntu release names
[23:03] <sistpoty> yes
[23:03] <cjwatson> I thought you meant it should accept *anything*
[23:03] <cjwatson> yes, I agree - there's a pretty old bug about the replay attack there
[23:03] <sistpoty> iirc it's fixed nowadays (I filed it after siretart discovered it)... but you never now ;)
[23:03] <sistpoty> know even
[23:03] <moldy> it might also be nice if dput would check this client-side
[23:04] <sistpoty> same is true for revu. the .changes file is there for the pleasure of revu admins but gets stripped for storage purposes (iirc)
[23:06] <sistpoty> moldy: partially agree... otoh I couldn't upload to unstable then (ok, agreed I can't right now myself, and even if I could, I should test the package really on unstable)
[23:08] <cjwatson> I can upload to unstable and occasionally do so from Ubuntu (after testing on unstable, of course)
[23:09] <cjwatson> usually due to forgetting which window I'm in but ...
[23:10] <moldy> ok, one should make it configureable if one did it
[23:11] <cjwatson> it doesn't really bother me, in order to actually break something in unstable you have to upload to the wrong place as well as having the wrong distribution target
[23:12] <cjwatson> so there's no real safety reason for a client-side check
[23:19]  * sistpoty wonders what would happen if he'd put multiple values in the Distribution field of a .changes file and would upload that
[23:20] <Daviey> the intertubes would melt.
[23:22] <sistpoty> Daviey: let's see, I'm just testing revu with it :)
[23:22] <Daviey> *BOOM* :)
[23:24] <cjwatson> sistpoty: there's a bug about that ;-)
[23:24] <cjwatson> "it gets complicated"
[23:24] <sistpoty> heh
[23:24] <cjwatson> https://bugs.launchpad.net/soyuz/+bug/235064
[23:26] <sistpoty> nice, thanks for the pointer cjwatson