[00:09]  * mneptok checks his pants
[00:09] <mneptok> sjoerd: you lie.
[00:10] <maco> O_o
[00:11] <maco> thats an interesting conversation to walk in on
[00:12] <mneptok> maco: if i had a nickel ...
[00:13] <jdong> maco: considering that it's mneptok, you could've walked in on far worse....
[00:13] <jdong> *hides*
[00:14] <maco> jdong: thats probably true
[00:15] <jdong> just like with xinetd services, knock and wait a couple seconds before entering?
[00:15] <jdong> (heh actually launchd on the iPhone is the worst at playing this game)
[00:15] <Amaranth> wow my notify-osd just went into a debug mode or something
[00:16] <jdong> the first time you SSH into an iPhone it literally spends a minute generating SSH host keys.
[00:16] <Amaranth> everything was all framed out and at the top it said "normal - report incorrect urgency?"
[00:16] <Amaranth> oh, maybe a lucid thing
[00:18] <dtchen_> okay, I know I'm dense, but do we officially document how to navigate to browseable online source for source packages?
[00:19] <dtchen_> I'm going through similar pain to fix an alsa bug in openSUSE 11.2, and uh, no documentation is *bad*
[00:20] <dtchen_> maybe https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource ?
[00:20] <maco> there's browsable online source?
[00:20] <maco> you mean aside from the handful of packages in bzr?
[00:20] <dtchen_> maco: that's very much what I'm hoping
[00:21] <dtchen_> otherwise it's going to be a very long night :/
[00:22] <dtchen_> ...I think this is one stellar argument for having all source, not just /debian, in bzr
[00:22] <dtchen_> err, in bzr branches on LP
[00:22] <maco> agreed
[00:34] <wgrant> maco: All packages are available in bzr now.
[00:35] <maco> wgrant: i thought it was a few thousand?
[00:35] <wgrant> maco: The entire archive (except perhaps for a few that failed) has been imported.
[00:36] <maco> with full source, not just debian/?
[00:36] <wgrant> Correct.
[00:38] <dtchen_> wgrant: code.launchpad.net/foo ?
[00:38] <dtchen_> (where foo is the source package name)
[00:39] <maco> wouldnt it be /ubuntu/+source/foo?
[00:39] <dtchen_> maco: doesn't seem to be a loggerhead link anywhere
[00:39] <maco> *shrug*
[00:40] <wgrant> dtchen_: code.launchpad.net/ubuntu/SERIES/+source/PACKAGE
[00:40] <wgrant> dtchen_: Or drop the SERIES/ to get a list of all.
[00:41] <dtchen_> man, either I fail, or I can't get them for linux, alsa-*, pulseaudio -- probably because none of them have upstream series set?
[00:41] <dtchen_> e.g., I can see eglibc's fine
[00:41] <wgrant> That's not necessary.
[00:41]  * wgrant checks.
[00:42] <ccheney`> dtchen_: coming to UDS? :)
[00:42] <dtchen_> ccheney`: no.
[00:42] <ccheney`> dtchen_: oh :(
[00:43] <wgrant> dtchen_: you appear to be cursed in your package selection.
[00:43] <dtchen_> yeah, go figure.
[00:47] <jdong> maybe dumb question
[00:47] <jdong> but how do you get an orig.tar.gz+diff.gz out of a LP branched bzr package?
[00:48] <jdong> that's the last piece of the bzr-kept-packages thing that I don't understand
[00:50] <maco> i think, theoretically, youre not sposed to need those
[00:50] <jdong> errr
[00:50] <jdong> suppose I want to make a change to znc then upload it back.
[00:50] <jdong> what would be the workflow?
[00:51] <maco> uhhh i guess one of those bzr/deb commands would be necessary...
[00:52] <jdong> naturally, bzr branch lp:ubuntu/lucid/znc
[00:52] <maco> branch, change, debcommit, push to somewhere....?
[00:52] <jdong> then cd into znc and edit whatever I want.
[00:52] <maco> i dont think lp will auto-build it when you debcommit & push though
[00:52] <jdong> right
[00:52] <jdong> it seems like you need to dput *something*
[00:53] <maco> is james_w in a US timezone yet?
[00:53] <jdong> debcommit just performs a bzr commit using debian/changelog
[00:54] <jdong> and I just tried bzr builddeb -S and it generated one native znc debian package
[00:54] <maco> right but it makes it so that when you push that branch to lp, it is automatically marked as being with that bug
[00:56] <ion> When i do bzr branch lp:ubuntu/lucid/foo, i don’t get a branch for the original tarball and the pristine-tar, data, right?
[00:56] <jdong> ion: from what I can see you only get the branch representing the fully unpacked debian source package.
[00:57] <jdong> the history seems to encode Debian changes as merges
[00:57] <jdong> which is why I asked if there were some bzr-builddeb magic for reconstructing pristine-tar
[00:58] <ccheney`> maco: iirc i heard you recently became a motu?
[00:58] <maco> ccheney`: aye, yesterday
[00:59] <ccheney`> maco: congratulations :)
[00:59] <maco> ccheney`: thanks :)
[00:59] <ion> I wish bzr allowed multiple branches in a single repository in a single directory with a single working tree.
[01:00]  * ccheney` hopes we have a powermgmt session at UDS, karmic seemed to be a bad regression :-\
[01:00] <ion> One could get the upstream, debian, ubuntu and pristine-tar branches with a single ‘bzr get lp:ubuntu/lucid/foo’ command.
[01:01] <jdong> ccheney`: what nonsense! Karmic dims my screen if I don't touch my mouse in 2 seconds!
[01:01] <jdong> ;-)
[01:01] <ccheney`> jdong: heh, and mine takes 10s+ to wake up now
[01:01] <ccheney`> if it does decide to wakeup at all
[01:02] <jdong> haha ouch
[01:02] <jdong> my wakeup is still okay
[01:02] <jdong> just networking literally takes 2 orders of magnitude longer to come up compared to its stock OS.
[01:03] <ccheney`> nice
[01:03] <maco> jdong: which will remain unnamed? :P
[01:03] <ajmitch> ccheney`: 5 minutes to wake up from hibernate isn't bad, is it?
[01:03] <ccheney`> ajmitch: hahaha
[01:03] <ajmitch> on a good day
[01:03] <ccheney`> ajmitch: if you have a slow drive i suppose
[01:03] <jdong> maco: yup :)
[01:03] <ccheney`> 10-20s from sleep though is pretty slow
[01:03] <ajmitch> yeah I think it's a 5400 RPM drive
[01:03] <jdong> ajmitch: I couldn't tell if you were being sarcastic!
[01:04] <ajmitch> I usually just suspend & it wakes up from that pretty fast
[01:04] <jdong> heh even Win2k got out of hibernate in 30-ish seconds
[01:04] <ajmitch> my problem is more the occasional severe slowdown once woken up
[01:04] <ajmitch> I can't remember the bug #
[01:04] <jdong> ah
[01:05] <maco> ccheney`: 10-20s for resume from s2ram sounds like my laptop back on hardy
[01:05] <jdong> the loveliness of swsusp sending everything to  swap
[01:05] <ccheney`> assuming you have a swap partition and less than 4GB of ram hibernate doesn't really need to take more than 1min to work
[01:05] <maco> ccheney`: also sounds like a cold boot on jaunty (but not on karmic)
[01:05]  * ajmitch has a swap partition & 4GB of RAM
[01:05] <ccheney`> maco: heh, yea mine was working fine on jaunty not sure what happened with karmic
[01:06] <maco> i think i had a 15s boot on hardy. 35s on karmic (shouldnt say this too loud in front of ke yb uk, eh?)
[01:06]  * ccheney` hasn't tested to see how slow hibernate is for him, but his drive does ~ 100MB/s with hdparm test
[01:06] <ccheney`> maco: there is a ppa that is supposed to help a large amount
[01:06] <ccheney`> maco: haven't tested it myself, but yea jaunty->karmic boot did get noticably slower with stock setup
[01:07] <maco> i think thats hat the ureadahead sru was for
[01:07] <ajmitch> I was pleasantly surprised at how well suspend/resume mostly works though :)
[01:07] <maco> i havent rebooted yet though
[01:08] <maco> hrm i should do laundry so i can pack for uds
[01:09] <ccheney`> maco: hmm that is what i should be doing now as well, i blew it off for irc :)
[01:09] <maco> my excuse was dinner
[01:09] <maco> but i finished eating now
[01:09]  * ccheney` will be driving up tomorrow afternoon, takes ~ 3.5hr by car
[01:10]  * ajmitch would like to be there :)
[01:13]  * jdong loves how maco used ureadahead and sru in the same sentence ;-)
[01:14] <maco> jdong: what?
[01:15] <maco> didnt something like that just happen?
[01:15] <maco> or am i very confused?
[01:16] <maco> yeah is in -proposed
[01:16]  * ccheney` is done :)
[01:16] <jdong> yes it did happen
[01:16] <maco> this laundry thing is making me discover i have much better t-shirts than the men's black-t-shirt-with-band-name-on-front ive been wearing
[01:16] <jdong> but that doens't stop me from commenting on that.
[01:17] <jdong> I'm quite sure if I SRU'ed Azureus with transmission I'd get into trouble ;-)
[01:17] <maco> hahahaha
[01:17] <ScottK> Nah, it'd be "It's jdong, what did you expect".
[01:18] <jdong> lol
[01:18] <jdong> haha speaking of azureus
[01:18] <jdong> had someone else recently bicker to me about the beg screen.
[01:19] <jdong> err that's plural. beg screens.
[01:19] <maco> beg screens?
[01:20] <ScottK> jdong: Canonical supports putting adverts for their proprietary serverices in the default install, so I can't see how it would be different.
[01:20] <jdong> I think the difference is if you say no, they don't tell you how many Canonical employees poured their hearts into it, and that you're a bad person and won't get any christmas gifts from Santa.
[01:20] <jdong> maco: see bug 434979
[01:21] <jdong> and attached screenshots
[01:21] <maco> haha ok
[01:22]  * ccheney` reminds him of the hans copyright message
[01:25] <ScottK> jdong: OK.  I just argued against an SRU.
[01:25] <jdong> :)
[01:30] <ScottK> jdong: I was restrained.  I could have marked it invalid since arguable although annoying, it's not a bug at all.
[02:30] <ebroder> system-config-printer isn't using polkit, is it?
[02:30] <ebroder> how is it escalating privileges?
[02:36] <dtchen_> not that I see, but there's system-config-printer-udev.
[02:37] <ebroder> Yeah - it looks like Fedora and/or SUSE (can't tell which) wrote cups-pk-helper, which relatively recent versions of s-c-p can use to escalate themselves
[02:37] <ebroder> I find myself wanting cups-pk-helper for an unrelated project at the moment :)
[02:38] <ebroder> Google is not helping me find this cups-pk-helper project, though
[02:39] <ebroder> Looks like the Fedora spec file points at http://www.vuntz.net/download/cups-pk-helper/ ?
[02:41] <dtchen_> ebroder: Till Kamppeter would be your best POC, I think
[02:44] <ebroder> dtchen_: Ok, I'll touch base before doing anything
[02:45] <dtchen_> ebroder: (or pitti, but I don't know if he still touches the printing bits)
[02:57] <ebroder> Can I not have a .orig.tar.bz2? Does it have to be a .tar.gz?
[03:00] <wgrant> ebroder: The new 3.0 (quilt) format permits bzip2 compression, but is not yet supported in Ubuntu.
[03:00]  * ebroder nods
[03:00] <ebroder> I thought you could do that with old-style packages, too
[03:00] <wgrant> Sort of, but no archive software will accept it.
[03:00] <wgrant> And I'm not sure if dpkg supports it any more.
[03:00] <ebroder> Sure
[03:01] <ebroder> It's been a while since I created a package from scratch - I'm shaky on the details
[03:13] <jdong> since when did Phoronix start reviewing computer cases?
[03:13] <jdong> and not even a timed MAFFT benchmark for the case.
[12:11] <yofel> hi, would it be possible to SRU bug 402188? The upstream patch has been tested in a ppa and works fine. I could supply a debdiff myself.
[13:35] <pitti> ebroder, dtchen_: s-c-p relies on "lpadmim" membership; I think it shold also ask you for user/pwd if you aren't in that group, but I'm not sure (the cups web UI does)
[14:05] <dtchen_> pitti: ok, thanks
[15:06] <qense> What is the prefered way of installed GConf schemas? gconftool-2 or gconf-schemas?
[15:10] <KArtinka> Hey ;)
[15:10] <Kartinka> I have some Questions about DevKit and udev Rules, is here anybody who knows something about them in connection with hiding unmounted partitions
[16:30] <TheMuso> c
[16:45] <fcuk112> i get this pbuilder error: dpkg-shlibdeps: error: couldn't find library  avg.so.0 needed by                         debian/python-libavg/usr/lib/libColorNode.so.0.0.0 (ELF format:  'elf32-i386'; RPATH: '').
[16:45] <fcuk112> i setup a pbuilder hook and when i try to grep for the file i get this: http://www.pastie.org/699559.  the debian/rules looks like this: http://www.pastie.org/699485.  can anybody help?
[17:14] <ebroder> pitti: Do you know if anybody has done work on cups-pk-helper yet?
[18:36] <dtchen_> hmph, I broke PA in Lucid.
[18:39] <ion> naurun
[18:46] <Kartinka> I have some Questions about DevKit and udev Rules, is here anybody who knows something about them in connection with hiding unmounted partitions
[19:05] <dtchen_> there, PA fixed and pushed
[19:58] <RetDude> Who here is experienced with PCI 2.1 add-in video cards and Ubuntu?  (Ben Stein:  Anyone?  anyone?  anyone?)
[20:02] <yml> hello
[20:03] <yml> I would be interested to package an new software called uwsgi and to create a PPA
[20:03] <yml> I have read quite some documentation up to now and I have a couple of questions
[20:04] <yml> the first one is how to integrate this operation in a dvcs workflow ?
[20:08] <Kartinka> I have some Questions about DevKit and udev Rules, is here anybody who knows something about them in connection with hiding unmounted partitions
[20:09] <ebroder> Kartinka: It looks like there isn't. Your best bet may be to send mail to ubuntu-devel-discuss
[20:11] <ebroder> Kartinka: But in general, it's better etiquette to just ask your question instead of asking to ask
[20:21] <yml> uwsgi (the application I would like to debianized is in a mercurial  repository. My idea was to create the debian folder directly inside the repository. Is there anything wrong with this approach ? dh_make refuse to run because the repository is called uwsgi and does not have yet a version.
[20:21] <yml> the application is available here : http://projects.unbit.it/uwsgi
[20:56] <RAOF> yml: Yes and no.  We like to have a clean separation between upstream & the packaging.  This is normally done by taking the upstream tarball and adding a debian directory to the source package only (so it goes in the .diff.gz).
[20:56] <RAOF> You could also do this by having a separate mercurial branch, if hg-buildpackage exists.
[20:57] <RAOF> (Which it does)
[20:57] <yml> RAOF: the idea is to contribute the debian  directory to upstream
[20:58] <RAOF> Well, we (as in Ubuntu & Debian) really prefer it if upstream _doesn't_ have a debian directory, at least in their releases.
[20:58] <yml> so that it is part of the repository and evolve together
[20:58] <yml> where is  this file managed in revision ?
[20:58] <gigabytes> yml: the problem is that sometimes debian and ubuntu have different packages and the debian directory can't be the same.
[20:59] <maxb> And the problem is more that the debian/ directory needs changing outside the package's upstream release cycle
[20:59] <yml> gigabytes: for now it has none  :-)
[21:00] <yml> ok I understand the principle
[21:00] <yml> but I would prefer to be able to use mercurial to manage this file at least locally
[21:01] <RAOF> Take a branch of trunk and add the debian directory.
[21:02] <yml> RAOF: I installing hg-buildpackage
[21:02] <RAOF> That's perfectly acceptable.
[21:02] <ScottK> yml: You can, just don't include it in the tarball for a release.
[21:02] <yml> this make sense
[21:03] <yml> for now I plan to use MQ
[21:21] <Kartinka> For my Problem specially look here: http://ubuntuforums.org/showthread.php?p=8323565#post8323565 i hope anyone can help
[21:25] <maxb> Kartinka: This is a development channel, for support, please see #ubuntu
[21:26] <Kartinka> there they said i should write my problem here
[21:26] <Kartinka> sorry but when everybody said another shit to me what can i do :(
[21:26] <ScottK> They are wrong.
[21:26] <ScottK> There is also an ubuntu-users mailing list.  Maybe more luck there
[21:29] <dtchen_> Kartinka: wrong channel, as stated previously.
[21:30] <dtchen_> Kartinka: to answer your questions, however, they are not hidden from the system, only from devicekit-disks, which means the partitions won't appear in GNOME
[21:30] <Kartinka> can i ask you, is there any way to hide them completely from the system?
[21:30] <dtchen_> Kartinka: as for the syntax, please see /usr/share/doc/udev/writing_udev_rules/index.html
[21:32] <ScottK> Time to board.  See you later.
[21:32] <Kartinka> mh okay is there any declaration about how to know that i have to use for example KERNEL=="loop*|ram*", GOTO="hide_partitions_end"<--- loop*|ram* in this part and so on?!
[21:32] <Kartinka> because i would like to understand what i do not only copy and paste cause of that i ask...
[21:32] <dtchen_> Kartinka: see the file I referenced.
[21:33] <Kartinka> okay i will take a look about when i switched system! sorry for nerding...^^
[21:33] <Kartinka> cause can you give me last answer on the question above
[21:34] <Kartinka> cause of hiding them from the whole system is it in any way possible to do or not?
[21:35] <dtchen_> Kartinka: yes, of course it's possible
[21:35] <dtchen_> Kartinka: if you really don't want to reboot, use http://bazaar.launchpad.net/~ubuntu-core-dev/udev/ubuntu/files/head%3A/docs/writing_udev_rules/
[21:37] <Kartinka> oh thats really nice from you thank you!
[21:43] <Kartinka> dtchen_ can i ask you, in which method is it possible to hide the partitions completely? :/ i hope i distrb you not to much but i found nobody before
[21:43] <dtchen_> Kartinka: please, this channel is not appropriate for general support questions.
[21:44] <Kartinka> can i talk to you in query?
[21:44] <Kartinka> i don't want to write without asking you for it...
[21:44] <dtchen_> sorry, but I'm fairly busy at the moment
[21:44] <Kartinka> mh okay sorry... :(
[21:52] <pitti> ebroder: first time I hear about cups-pk-helper, I'm afraid
[23:28] <andersk> Why hasn’t libmoose-perl synced from Debian yet?  It’s currently uninstallable in lucid.
[23:29] <ebroder> Huh? squeeze and lucid both have 0.92-1
[23:30] <andersk> Lucid has 0.82-1 unless that’s changed very very recently.
[23:30] <ebroder> Ah - looks like it's in depwait
[23:30] <ebroder> https://launchpad.net/ubuntu/+source/libmoose-perl/0.92-1/+build/1325365
[23:32] <andersk> Looks like it’s waiting on libtest-simple-perl >= 0.88?  That should be satisfiable now.
[23:32] <ebroder> No, it's in depwait for libtry-tiny-perl
[23:32] <ebroder> Which is a new package. Don't archive admins have to approve new packages?
[23:33] <andersk> I thought they don’t (before DebianImportFreeze).
[23:34] <ebroder> The process described on https://wiki.ubuntu.com/ArchiveAdministration#Syncs sounds like they have to be manually ACKed
[23:34] <ScottK> If there's an existing Ubuntu diff, it takes a manual sync
[23:34] <ebroder> ScottK: this is a package that was previously not in Ubuntu
[23:35] <ScottK> Ah.
[23:35] <ebroder> (s/previously/currently/, really)
[23:35] <andersk> https://wiki.ubuntu.com/DebianImportFreeze says it should be automatic.
[23:36] <ScottK> Even auto sync needs a manual push.
[23:37] <andersk> Hmm, but https://wiki.ubuntu.com/LTSDebianImportFreeze does not.