[06:55] <dupondje> http://launchpadlibrarian.net/49420291/buildlog_ubuntu-maverick-armel.loop-aes-utils_2.16.2-1_FAILEDTOBUILD.txt.gz => somebody has any clue ? :)
[06:55] <dupondje> ../../../fdisk/fdisk.c:2142: error: unable to find a register to spill in class 'GENERAL_REGS'
[07:02] <RAOF> That's generally some inline assembly being munted.
[07:03] <RAOF> If there isn't some inline assembly involved then it's probably a compiler bug.
[07:07] <dupondje> no assembly code in the function it seems ...
[07:09] <dupondje> and it did build on debian armel ...
[07:09] <RAOF> With the same gcc? :)
[07:11] <dupondje> prolly not :P
[07:14] <dupondje> gcc-4.4 4.4.4-3ubuntu3 vs gcc-4.4_4.4.3-3
[07:17] <dupondje> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../../fdisk -I..  -include ../config.h -I../../../include -DLOCALEDIR=\"/usr/share/locale\"  -fsigned-char -Wall -g -O2 -MT fdisk.o -MD -MP -MF .deps/fdisk.Tpo -c -o fdisk.o ../../../fdisk/fdisk.c
[07:17] <dupondje> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../../fdisk -I..  -include ../config.h -I../../../include -DLOCALEDIR=\"/usr/share/locale\"  -fsigned-char -Wall -g -Os -MT fdisk.o -MD -MP -MF .deps/fdisk.Tpo -c -o fdisk.o ../../../fdisk/fdisk.c
[07:17] <dupondje> -O2 in debian
[07:17] <dupondje> -Os in ubuntu
[07:17] <dupondje> could that be the reason ?
[07:18] <micahg> dupondje: we also have a different libc6
[07:19] <dupondje> but its not really a bug in loop-aes then? but more in libc or gcc ?
[07:21] <RAOF> Without the additional constraints of inline assembly, I think that any time the compiler is unable to find enough registers is a bug in the compiler.
[07:29] <Rhonda> What does the tag canonical-losa-lp mean? Or are they arbitrary?
[07:32] <lifeless> the universe is arbitrary
[07:34] <Rhonda> lifeless: If that was meant to be a joking comment, I didn't get it. :)
[07:34] <lifeless> what is your question about the tag
[07:35] <Rhonda> It was added to a bug and I wonder what it means.
[07:35] <Rhonda> The question about the tag is exactly what I wrote - what does it mean/imply. :)
[07:35] <lifeless> it means that the canonical losa team have some interest in the bug
[07:36] <Rhonda> What's the "losa" team?
[07:36] <lifeless> launchpad/landscape operational system administrator
[07:36] <lifeless> though they do U1 too, but the abbreviation has been kept
[07:37] <Rhonda> It was added to the bug about that one isn't able to unsubscribe from individual bugs with implicit subscriptions on launchpad.
[07:38] <lifeless> yes
[08:31] <dholbach> good morning
[08:44] <ricotz> hello, recently we had a packaging change of docky in result of the major upstream change, therefore the package python-docky got obsolete, so my question is what is the best way to do this transition? i added a "Replaces" and "Conflicts" for python-docky to the docky package. is this the proper way?
[08:46] <RAOF> ricotz: This depends on precisely what happens.  Having python-docky Conflicts/replaces the docky package is unlikely to be the right option, unless python-docky provides the full docky experience now :)
[08:47] <RAOF> What's the actual situation?
[08:48] <RAOF> I'd guess that some files that used to be in the docky package are now being provided by the python-docky package?  In that case, Replaces: docky (<= $LAST_BROKEN_VERSION) is appropriate.  That tells dpkg that python-docky will replace some files in a docky package older than $LAST_BROKEN_VERSION
[08:48] <ricotz> RAOF, this only affects the ppa, we splitted out the helpers to a new project which is compatible with awn
[08:48] <ricotz> RAOF, the docky ppa package is python free now
[08:49] <ricotz> the goal was to get python-docky removed when installing the new docky
[08:49] <lifeless> probably want breaks
[08:49] <RAOF> Ok.  Why?  Is there a packaging conflict, or is python-docky now simply obsolete?
[08:49] <lifeless> not conflicts
[08:50] <lifeless> RAOF: ^ ricotz:
[08:50] <ricotz> RAOF, it is obsolete
[08:50] <RAOF> If python-docky is simply obsolete, why not rely on apt-get/aptitude to do the right thing?
[08:51] <RAOF> Few people are going to have manually installed python-docky, so when docky stops depending on it it'll fall under “unused packages”.
[08:51] <ricotz> RAOF, this could leave python-docky installed
[08:51] <lifeless> ricotz: set breaks:python-docky
[08:51] <lifeless> ricotz: thats all you need
[08:51] <ricotz> http://bazaar.launchpad.net/~docky-core/docky/packaging/annotate/head:/ubuntu-lucid/control
[08:51] <ricotz> lifeless, ok
[08:52] <RAOF> python-docky will be automatically uninstalled once nothing depends on it.
[08:52] <lifeless> never ever use conflicts unless a) the two packages cannot *unpack* on disk (see the debian packaging policy for details on what that means) or b) breaks won't work, and you understand how both work in detail to be able to make that assertion
[08:52] <lifeless> RAOF: depends on policy
[08:52] <RAOF> lifeless: Is there any particular reason to use breaks, though?  One package doesn't actually break or conflict with the other.
[08:53] <lifeless> ricotz: but let me also say, if python-docky won't cause *harm*, don't interfere.
[08:53] <lifeless> RAOF: ^ :P
[08:54] <ricotz> lifeless, it doesnt do harm, but could lead to problem when using the included python interface which isnt working anymore after docky is updated
[08:54] <AnAnt> Hello, I think I was accepted as MOTU last week, but I still didn't get an email about it
[08:54] <lifeless> ricotz: so, installing the new docky breaks python-docky ?
[08:54] <AnAnt> how much time does it normally take ?
[08:55] <ricotz> lifeless, yes, the included dbus interface definitions are not valid anymore
[08:55] <lifeless> then breaks: is absolutely the right thing to do
[08:55] <lifeless> RAOF: ^
[08:56] <ricotz> lifeless, ok
[08:58] <dupondje> 5 sync requests open :p
[08:58] <dupondje> héhé :)
[09:02] <AnAnt> geser: ^
[09:04] <dupondje> https://merges.ubuntu.com/universe.html => when is this list refreshed ?
[09:04] <geser> AnAnt: usually the chair processes the outcome of the meetings short after the meeting. fixing it now.
[09:04] <AnAnt> geser: thanks
[09:07] <geser> AnAnt: done
[09:10] <AnAnt> so the question is, what can I do as a MOTU (besides continuing what I've been doing before) ?
[09:10] <AnAnt> any tools I should know about ?
[09:11] <geser> AnAnt: the main difference now is that you don't need a sponsor anymore and can sponsor others
[09:11] <AnAnt> geser: that's on REVU, right ?
[09:12] <AnAnt> geser: how about if I do a merge or sync
[09:12] <geser> AnAnt: not only, but also merges and syncs
[09:12] <AnAnt> geser: how do I get it actually done ?
[09:13] <AnAnt> how do I actually do the merge or sync now, is just setting the bug status (of my merge/sync request) to confirmed enough ?
[09:14] <AnAnt> or I should do an eupload somewhere ? for example in Debian, after becomming a DM, I would upload to ftp.upload.debian.org instead of mentors
[09:14] <geser> sync -> subscribe ubuntu-archive directly, merges -> upload directly (you don't even need to file a bug for it)
[09:14] <AnAnt> ah, upload.ubuntu.com ?
[09:14] <geser> yes
[09:15] <AnAnt> ok, I  just found it now /etc/dput.cf
[09:15] <AnAnt> ok, thanks
[09:16] <dupondje> you can use requestsync also if u have upload rights right ?
[09:16] <geser> yes
[09:17] <AnAnt> oh, yes, just drop the -s
[09:17] <geser> instead of the sponsoring team it subscribes ubuntu-archive instead
[09:18] <dupondje> got some syncs open to be ack'ed if you need some practice ;)
[09:22] <AnAnt> ok, bye
[09:50] <Laney> ricotz: if you want to do a stable release update, you need to get it fixed in the development release first
[09:50] <Laney> ...so please get the new docky version updated there
[09:50] <Laney> ...and for that please get it updated in Debian
[09:50] <Laney> ...and for that please come to #debian-cli @ oftc
[09:50] <Laney> that is all!
[09:50]  * Laney out
[10:12] <dupondje> http://dupondje.be/fxload.debdiff => this looks like a good debdiff ?
[10:13] <dupondje> for merge of https://launchpad.net/ubuntu/+source/fxload
[10:23] <slytherin> dupondje: looks fine except you should give a proper name to the patch instead of debian-changes-0.0.20081013-1ubuntu1
[10:28] <dupondje> slytherin: the name is automatictly given when builded ... :s
[10:30] <slytherin> dupondje: You can rename it can't you?
[10:32] <dupondje> yepp ! :)
[10:36] <dupondje> https://bugs.launchpad.net/ubuntu/+source/fxload/+bug/587824
[10:36] <dupondje> feel free to comment :)
[10:36] <dupondje> gtg now :)
[12:49]  * DktrKranz cheers quadrispro as newly appointed DD, please give him something to sponsor :)
[12:56] <dupondje> https://bugs.launchpad.net/ubuntu/+source/fxload/+bug/587824 => this looks good ?
[13:27] <jetienne> q. native question: i got a source package with .dsc, .tgz, .source_build, .source_changes... how can i build it ?
[13:29] <dupondje> pbuilder --build file.dsc
[13:30] <jetienne> dupondje: anything easier ? apparently pbuilder need a lot of config to work
[13:31] <dupondje> alot of config ?
[13:31] <dupondje> should be working out of the box :)
[13:31] <jetienne>  /var/cache/pbuilder <- apparently this dir need to be created
[13:31] <jetienne> it is complaining about other things too
[13:34] <ricotz> Laney, ping
[13:35] <jetienne> dupondje: ok apparently i can "dpkg-source -x file.dsc" and then "debuild -b"
[13:38] <sommer> morning
[13:42] <ricotz> sebner, can you take care of this? https://bugs.edge.launchpad.net/docky/+bug/574003
[13:45] <sebner> ricotz: still needs a SRU ack? /me investigating
[13:46] <ricotz> sebner, i just asked RAOF
[13:46] <sebner> ricotz: oh, did he upload?
[13:46] <ricotz> sebner, he is updating it in debian now
[13:47] <sebner> ricotz: ah ^^
[13:57] <sebner> ricotz: ok, I'm going to upload it to lucid-proposed now
[13:58] <ricotz> sebner, ok
[14:05] <arand> If I take someone elses debian packaging and update it slightly, should I add "And updated by $ME" after "This package was debianized by.." ? Or just ignore it? (I'm taking a debianization from getdeb and using it for my PPA)
[14:06] <arand> (Ignore, meaning just put info in changelog)
[15:51] <ScottK> ara: Just ignore it and put the info in the changelog
[15:51] <ScottK> oops.
[15:51] <ScottK> arand: ^^^
[15:51] <ara> ScottK, ;-)
[15:52] <arand> ScottK: Ok, cheers
[16:36] <ripps> Can someone here help me figure out why my mplayer-build package won't build in maverick? http://launchpadlibrarian.net/49425944/buildlog_ubuntu-maverick-i386.mplayer-build_3:1.0~rc3%2Bgit20100531.c690323-0ubuntu1~ripps1_FAILEDTOBUILD.txt.gz
[16:36] <ripps> It seems to fail at override_dh_auto_build
[16:53] <ogra> ripps, ERROR: libxvid not found
[16:57] <jetienne> i think i will reach buildability today! :)
[17:13] <ripps> ogra: oh, I think I figured it out, I forgot to carry over some custom package dependencies in my drobotik configs
[17:39] <ari-tczew> lfaraone: : I've answered, check bug 587627
[18:42] <dupondje> 773 jobs (three days)
[18:42] <dupondje> omg :)
[18:58] <geser> dupondje: sparc is constantly busy for 3 days since the auto-sync started
[19:00] <ScottK> And that's with a substantial fraction of the packages failing to build.
[19:00] <ScottK> If everything built it would be a lot more behind.
[19:08] <ricotz> ScottK, hello, do you mind approving an upload to lucid-proposed?
[19:09] <ScottK> ricotz: Did ubuntu-sru approve it already?
[19:09] <sebner> ScottK: pitti did
[19:09] <ricotz> ScottK, yes, pitti dod
[19:09] <ricotz> did
[19:09] <ScottK> OK.  What bug?
[19:09] <sebner> ricotz: you know how to bypass the queue, hmm? ^^
[19:09] <ricotz> ScottK, https://bugs.edge.launchpad.net/docky/+bug/574003
[19:10] <ricotz> sebner, i am waiting for a long time for this
[19:10] <sebner> ricotz: sure
[19:14] <ScottK> ricotz and sebner: Done.
[19:14] <ricotz> ScottK, thank you!
[19:15] <ScottK> You're welcome.
[19:15] <sebner> ScottK: cool, thx. mind approving another one (mine)?
[19:15] <ScottK> sebner: As long as it's ubuntu-sru approve, no problem.  What bug?
[19:16] <sebner> ScottK: pitti told me to upload it anyways if it's importat (I consider startup crash important) and you (archive) will approve anyways
[19:17] <ScottK> sebner: It needs an ubuntu-sru ack.  I'm not on ubuntu-sru, so I can't do that.  My advice is pester jdong.
[19:18] <sebner> ScottK: right, never could catch him yet!
[19:18] <sebner> jdong: ^
[19:18] <ari-tczew> please sponsor this bug 368855
[19:19] <ScottK> ari-tczew: Is that fix in Debian too?
[19:20] <ari-tczew> ScottK: I don't know, I just saw that patch has got ACK for SRU and waiting in queue to sponsor
[19:20] <ScottK> I see.
[19:20]  * ScottK looks
[19:22] <ScottK> ari-tczew: What release are you fixing this for?
[19:24] <ari-tczew> ScottK: I don't fix it. kklimonda is author of patch. I just poke sponsors there. The release is jaunty.
[19:25] <ScottK> ari-tczew: It's not uploaded yet, so nothing for me to accept.
[19:25] <ari-tczew> ScottK: I didn't ask you for accept. I'm looking for sponsor only.
[19:26] <ScottK> Oh, I misunderstood.  That I don't have time for.  Sorry.
[19:26] <ari-tczew> no problem
[19:44] <fred_and_me> evning guys
[19:44] <ari-tczew> hello
[19:44] <fred_and_me> i was wandering if someone could shed some light on a packaging related problem i'm having
[19:45] <fred_and_me> i'm trying to build myself a small build service using rebuildd and reprepro
[19:45] <fred_and_me> the buildd gets the source file from the reprepro, builds it and puts the binarys into the repo
[19:46] <fred_and_me> except it rejects the pbuilder build source files because it doesn't have the same checksums than the source from the repo
[19:47] <fred_and_me> but when i inspect the contents of the two packages, the content is identical
[19:47] <fred_and_me> why does that happeß
[19:47] <fred_and_me> ?
[19:47] <jdong> sebner: looks like you've gotten your ACK?
[19:47]  * jdong has been settling down in California for his summer job
[19:48] <ScottK> fred_and_me: That's a bit off topic here.  You might try #ubuntu-packaging.
[19:49] <fred_and_me> thanks ScottK, i will
[19:51] <sebner> jdong: hmm, no?
[19:51] <jdong> sebner: bug number?
[19:51] <jdong> must've misaligned my scrollback then
[19:51] <sebner> jdong: https://bugs.launchpad.net/ubuntu/+source/themonospot/+bug/533747
[19:52] <jdong> oh
[19:52] <ari-tczew> jdong: ping on private message
[19:52] <jdong> ari-tczew: can you please retransmit? My bouncer is a bit glitchy with privmsg handling
[19:53] <jdong> sebner: you're okay now :)
[19:53] <sebner> jdong: take my thanks! :)
[19:53] <sebner> ScottK: would you mind? =)
[19:53]  * ScottK looks
[19:55] <ScottK> sebner: Is it fixed in Maverick already?
[19:55] <sebner> ScottK: nope, it the fix I intend to do a upload in Debian
[19:55] <sebner> *it = if
[19:55] <sebner> *fix works
[19:55] <sebner> -.-
[19:57] <ScottK> If we're at the "if it works" stage, it's really not ready for SRU.
[19:57] <dupondje> https://bugs.launchpad.net/ubuntu/+source/fxload/+bug/587824 => does this merge look nice ? :)
[19:57] <ScottK> Not sure if I understood your substitutions correctly.
[19:57] <dupondje> ScottK: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/544910 => this is an SRU also imo :) could you give it a shot ?
[19:58] <ScottK> dupondje: Is it already uploaded and approved by ubuntu-sru?
[19:58] <sebner> ScottK: My can't reproduce the error but others have reported to be fixed
[19:58] <ScottK> sebner: Done.
[19:58] <ScottK> OK.
[19:59] <sebner> ScottK: th
[19:59] <sebner> x
[19:59] <ScottK> You're welcome.
[20:01]  * sebner shouldn't write anything while using the mobile phone at the same time -.-
[20:38] <dupondje> ScottK: no, how do I get it approved ? :D
[20:39] <ScottK> dupondje: Subscribe ubuntu-sru and someone on the team will review it.
[20:39] <arand> dupondje: Well, subscribe ubuntu-sru, and wait.
[20:40] <dupondje> anyway, change got into debian .. isn't it better to wait for sync and then sru ?
[20:42] <arand> Well, it's often the case that a sru won't happen if the change isn't in ubuntu+1 yet, so yea.
[20:44] <dupondje> well the change is already in ubuntu+1, but the changed debian package not
[20:47] <micahg> JontheEchidna: what do you think about renaming/add dummy package kmozillahelper to firefox-kde-support so that it's easier to find
[20:49] <JontheEchidna> debfx: ^?
[20:49] <JontheEchidna> I don't know if upstream plans to stick with just providing Firefox integration, but debfx might know more
[20:49] <JontheEchidna> a dummy package or provides: field entry couldn't hurt, at any rate
[20:50] <micahg> JontheEchidna: is it maintained upstream or in Ubuntu?
[20:50] <debfx> micahg: that's what I suggested in bug #559154
[20:50] <JontheEchidna> micahg: openSUSE hosts/maintains the code in gitorious
[20:50] <micahg> debfx: I know, I was asking if we're going to do it :)
[20:51] <debfx> oh, +1 from me obviously :D
[20:51] <ScottK> Does firefox suggest kmozillahelper?
[20:52] <micahg> ScottK: ye
[20:52] <micahg> s
[20:52] <ScottK> Then I think the question is answered.
[20:52] <ScottK> If users don't know about it, it's a package manager issue.
[20:52] <micahg> ScottK: how many regular users look at suggests?
[20:53] <ScottK> micahg: Are they presented by the package management software to them?
[20:53] <ScottK> I don't think changing the name will help.
[20:53] <JontheEchidna> Is there any way to recommend firefox-gnome-support || firefox-kde-support and have apt be smart enough to choose the one that would install less new stuff?
[20:53] <ScottK> No.
[20:53] <JontheEchidna> :(
[20:53] <micahg> ScottK: it'll show up in a search for firefox
[20:54] <ScottK> I see.
[20:54] <ScottK> That's a good point.
[20:54] <micahg> ScottK: it also makes it more obvious what it does
[20:55] <ScottK> JontheEchidna: Maybe we should directly seed kmozillahelper in kubuntu-common and then if a Kubuntu users installs Firefox, they already have the addon?
[20:55] <JontheEchidna> ScottK: that would work, but we'd have to remove kmozillahelper's dependency on firefox
[20:55] <ScottK> JontheEchidna: Agreed.
[20:55] <JontheEchidna> not a big deal imo, but would have to be done
[20:55] <ScottK> It's a bit of a hack, but it should work.
[20:56] <JontheEchidna> do we want to care about the name if we go this route?
[20:56] <micahg> JontheEchidna: I don't think so
[20:56] <debfx> renaming kmozillahelper would also make the name consistent with firefox-gnome-support
[20:56] <micahg> JontheEchidna: actually, wait, maybe we would
[20:56] <micahg> JontheEchidna: if users only install kde w/out kubuntu, they still wouldn't find it
[20:57] <JontheEchidna> good point
[20:58] <ScottK> micahg: That's true, but I'm not sure we care that much.
[20:58] <JontheEchidna> The question is: "do we want to carry a transitional package for 2 years for this?"
[20:58] <micahg> JontheEchidna: well, I think it would just be a permanent dummy package unless upstream renames
[20:59] <dupondje> http://packages.debian.org/changelogs/pool/main/m/mplayer/current/changelog => a debian changelog that contains ubuntu changelog items ?!
[20:59] <micahg> JontheEchidna: I could also throw the dummy package in firefox in theory
[21:00] <JontheEchidna> well, it's not too big of a deal to have a dummy package around
[21:00] <JontheEchidna> So the plan is:
[21:00] <JontheEchidna> - Change kmozillahelper's name to firefox-support-kde
[21:01] <JontheEchidna> -Provide a dummy package for kmozillahelper that depends on firefox-support-kde
[21:01] <JontheEchidna> - Remove firefox-kde-support's dependency on firefox
[21:01] <JontheEchidna> - Seed firefox-kde-support in kubuntu-common
[21:01] <JontheEchidna> sound good?
[21:01] <micahg> JontheEchidna: the thing I'm wondering is about actually changing the name since upstream calls it something diferent
[21:02] <JontheEchidna> So, kmozillahelper could stay the main package, but firefox-kde-support be the dummy?
[21:02] <micahg> JontheEchidna: that's what I was thinking
[21:02] <JontheEchidna> sounds fine to me
[21:02] <debfx> micahg: opensuse calls the package mozilla-kde4-integration
[21:02] <micahg> JontheEchidna: that way we're consistent with upstream and ourselves
[21:03] <micahg> debfx: oh, in that case, we can just change our name ;)
[21:03] <debfx> I'd say the source package should be called kmozillahelper and the binary firefox-support-kde
[21:04] <micahg> debfx: that's fine too
[21:04] <debfx> JontheEchidna: upstream tarballs are available from https://build.opensuse.org/package/files?package=mozilla-kde4-integration&project=mozilla%3AFactory
[21:05] <debfx> I should have documented that though at that time build.opensuse.org required a login
[21:09] <JontheEchidna> debfx: good to know
[21:10] <dupondje> guys, a debian changelog that contains ubuntu changes? is that anything special ?
[21:10] <debfx> actually I could write a watch file
[21:12] <JontheEchidna> dupondje: not common, but not unheard of
[21:13] <dupondje> http://packages.debian.org/changelogs/pool/main/m/mplayer/current/changelog :p
[21:13] <JontheEchidna> they must've done a merge with us
[21:14] <dupondje> but seems not everything is included :s
[21:25] <debfx> micahg, JontheEchidna: so are we going to do it like that?
[21:26] <micahg> debfx: sounds good to me
[21:28] <debfx> so firefox needs to change the suggests and kubuntu-firefox-install doesn't need to install kmozillahelper anymore
[21:29] <micahg> debfx: open a task/bug or just ping me when you're ready for firefox to change
[21:36] <ari-tczew> micahg: how are you doing?
[21:36] <micahg> ari-tczew: k, trying to get a lot of backports done :)
[21:37] <ari-tczew> micahg: cool, good luck !
[21:38] <ari-tczew> bdrung: hello, did you prepare script for sponsoring fakesyncs?
[21:39] <bdrung> ari-tczew: half. ack-sync & syncpackage will gain this feature. i was disrupted by a failing internet connection.
[21:40] <bdrung> ari-tczew: i will finish it soon
[21:41] <ari-tczew> bdrung: aha, ttx has sponsored my bzr diffs, but don't worry, I'll always find a fakesync, just ask me ;)
[21:41] <bdrung> ari-tczew: geronimo-jpa-3.0-spec is still there as testcase?
[21:42] <ari-tczew> bdrung: of course, you can use it for testing
[21:42] <bdrung> ari-tczew: because i saw that ttx sponsored most of bug 512430
[21:43] <ari-tczew> bdrung: yes I know, but I didn't please him
[21:53] <ari-tczew> what sposor prefer to - pack new upstream release and send to bzr or upload .diff.gz .dsc and orig. files?
[21:58] <bdrung> ari-tczew: if you are in doubt do both ;) it depends probably on the sponsor
[21:58] <bdrung> ari-tczew: is it possible to update the package in debian first and sync/merge it?
[21:59] <ari-tczew> bdrung: I've packed new upstream release (package doesn't exist in Debian) and I switched source format to 3.0 - I don't know whether bzr does like change source format
[22:00] <bdrung> ari-tczew: IIRC it should work
[22:02] <ari-tczew> bdrung: so I'll upload it tommorow to bzr.
[22:02] <bdrung> ari-tczew: is someone trying to bring this package to debian?
[22:03] <ari-tczew> bdrung: I know nothing about this
[22:04] <bdrung> ari-tczew: are you interested in maintaining it?
[22:04] <ari-tczew> bdrung: not sure, this package is: firmware-addon-dell
[22:07] <ari-tczew> bdrung: why you ask?
[22:08] <bdrung> ari-tczew: just my usual questions. i like to see all packages in debian and then synced to ubuntu (or merged if really required)
[22:09] <ari-tczew> bdrung: are you satisfied if you see in e-mail inbox a lot of sync requests?
[22:10] <bdrung> ari-tczew: yes (compared to seeing many new upstream packages or merge requests)
[22:11] <bdrung> ari-tczew: i begin with sponsoring sync requests and then doing the other stuff
[22:12] <ari-tczew> bdrung: aha, fine
[23:29] <bdrung> tumbleweed: ping
[23:30] <tumbleweed> bdrung: pong
[23:31] <bdrung> tumbleweed: do you still my endorsement or do you finished the motu application?
[23:32] <arand> rhythmbox patches are 01-05, 80, 82, 90-96. What number should my new patch be?
[23:32] <tumbleweed> bdrung: there wasn't time last week, I'm up again next week
[23:32] <micahg> arand: depends where it needs to be applied
[23:32] <tumbleweed> yes, I'd appreciate an endorsement
[23:32] <bdrung> k, will put it on my TODO
[23:32] <tumbleweed> bdrung: thanks
[23:33] <micahg> bdrung: have you sponsored enough of my stuff to give me an endorsement for mozilla package set dev?
[23:33] <bdrung> micahg: gimme a list of bugs
[23:33] <arand> micahg: which I don't really know, it's a git commit for python initialization problems.
[23:33] <micahg> bdrung: k, I guess I'll have to do that later :)
[23:34] <arand> micahg: I guess 07, incorrect?
[23:34] <bdrung> tumbleweed: in your mail you listed four bugs. are there more nows
[23:34] <bdrung> s/nows/now?
[23:35] <tumbleweed> hmm, let me see
[23:37] <lfaraone> bdrung: by the way, I am in ~ubuntu-dev as of a few weeks ago.
[23:38] <bdrung> lfaraone: context?
[23:38] <lfaraone> bdrung: in re to <1275236527.1990.38.camel@deep-thought>
?
[23:39] <lfaraone> bdrung: the reason I didn't push them directly into ~ubuntu-dev/+junk/ack-sync was because I wasn't sure whether I should commit directly.
[23:40] <lfaraone> bdrung: the messageID of your email on "Re: Updates / features for ack-sync".
[23:41] <simar> sudo echo 3 | tee -a /sys/class/backlight/nvidia_backlight/brightness  can anyone please tell me the meaning of this statement including |(or) i know what are echo ..
[23:41] <simar> plz help
[23:41] <bdrung> lfaraone: aha, the ack-sync script. your work on it is appreciate. you are allowed to commit directly. ;)
[23:42] <lfaraone> bdrung: mk, thx.
[23:42] <bdrung> mk?
[23:42] <Laney> simar: this isn't the channel for support, please try #ubuntu
[23:44] <tumbleweed> bdrung: #585329, #584125, #585014, #583899, #583999, #583106, #581511, #562272, #527982 (and a few more awaiting review, if you are keen :P )
[23:46] <tumbleweed> whoops, two of those arne't yours
[23:47] <tumbleweed> oh they are, nm