[00:07] <djsmith> I've got a patch to fix (what I consider) a bug in /etc/dhcp3/dhclient-exit-hooks.d/ntp. Is this an okay place to discuss it?
[00:10] <RAOF> djsmith: dhclient is in main, isn't it?  #ubuntu-devel might be better.  Although filing a bug on launchpad is generally the best spot to put bugs :)
[00:10] <micahg> RAOF: the file in question is in ntp, which is still in main :)
[00:11] <RAOF> micahg: Fair suck of the sav. :)
[00:11] <micahg> ?
[00:11]  * RAOF declares today “talk like an aussie” day.
[00:12] <micahg> RAOF: google translate doesn't know Aussie :)
[00:13] <RAOF> “Fair enough” is a reasonable translation :)
[00:13] <micahg> RAOF: ah, k
[00:13] <djsmith> RAOF: I'll use ubuntu-bug then. Thanks
[00:16] <guidoi> similar question
[00:16] <guidoi> I've posted a patch to fix an usability bug in compiz
[00:16] <guidoi> it's already applied upstream
[00:16] <guidoi> but till the compiz team release the new version
[00:17] <guidoi> i believe it can be applied on ubuntu's current package too, as an upgrade
[00:17] <guidoi> someone pointed me to #ubuntu-motu
[00:18] <guidoi> but i don't know if compiz is in main or what
[00:18] <guidoi> let me check
[00:19] <ajmitch> compiz is in main
[00:19] <imbrandon> guidoi: where is the patch ? /me is afk for a few minutes
[00:19] <ajmitch> RAOF: can I choose not to talk like an aussie, please? :)
[00:19] <guidoi> let me get you the url imbrandon
[00:19] <imbrandon> guidoi: attach the patch to a bug on launchpad against compiz, then subscribe ( NOT assign ) ubuntu-sponsors, when maverick opens we can grab it then
[00:20] <guidoi> https://bugs.launchpad.net/bugs/207065
[00:20] <guidoi> it's already attached
[00:20] <guidoi> uhm suscribe ubuntu-sponsors..
[00:22] <ajmitch> 'subscribe someone else' on the right-hand side, if you haven't done so
[00:22] <guidoi> yes i'm on that
[00:22] <guidoi> Ubuntu Sponsors
[00:22] <guidoi> or Ubuntu Sponsors for main
[00:22] <ajmitch> Ubuntu Sponsors
[00:23] <Laney> oh, my sponsors membership is running out
[00:23] <guidoi> Ubuntu Sponsors Team team has been subscribed to this bug.
[00:23] <Laney> persia or TheMuso: please add me to the new team
[00:23] <guidoi> great, what's ubuntu sponsors team? i mean, how do you define/become sponsor
[00:24] <Laney> any ubuntu developer with upload powers can sponsor
[00:26] <imbrandon> guidoi: any ubuntu developer that wishes to become a sponsor and spends some time reviewing patches like yours becomes one
[00:26] <imbrandon> basicly is a self selecting subset of ubuntu-developers
[00:27] <guidoi> ah, now i get it
[00:28] <imbrandon> guidoi: if someone hasent gotten to your patch by .... i'd say about a week after maverick opens you might re-ping us in here
[00:28] <imbrandon> maverick should open in 2 days ( but its not set in stone )
[00:29] <imbrandon> and by open i mean status != frozen in launchpad so we can upload
[00:29] <guidoi> sorry for being so ... un-educated , but what's maverick?
[00:29] <imbrandon> what will become the next version of ubuntu, e.g ubuntu 10.10
[00:29] <imbrandon> maverick is the "next" codename , like lucid for 10.04
[00:30] <guidoi> oh i see
[00:30] <guidoi> lucid will only receive security updates from now on
[00:30] <imbrandon> guidoi: you can see the frozenness status at http://launchpad.net/ubuntu , bout 3/4 way down on the right
[00:30] <Aquina> well lucid will also have backports, right?
[00:30] <imbrandon> guidoi: yes security updates and major bugfixes
[00:31] <imbrandon> and in come cases backports
[00:31] <imbrandon> s/come/some
[00:31] <Aquina> :-)
[01:03] <persia> Just a reminder, it's Patch Day.  Anyone with some time to review patches and help get them in the right places is encouraged to stop by #ubuntu-reviews and help out.
[02:04] <RAOF> df00z1: We don't discriminate against stupid buildsystems; your build target could probably be more succinctly specified as “$(MAKE) install DISTDIR=$(CURDIR)/debian/iscsitarget”, though.
[02:04] <lifeless> RAOF: hah
[02:04] <df00z1> oh, I didn't realize you could specify distdir on the same line like that
[02:05] <persia> make accepts variables by a stunningly diverse array of methods.
[02:05] <RAOF> Bonus points for remembering which definitions take precedence! :)
[02:06] <hyperair> RAOF: DESTDIR...
[02:06] <df00z1> the other thing is, type of package, single binary, multiple, library, etc
[02:06] <persia> hyperair: No, DISTDIR.  upstream is special.
[02:06] <df00z1> the package contains a kernel module AND a few binaries
[02:06] <RAOF> hyperair: No, DISTDIR :)
[02:06] <hyperair> ah, "special" upstreams.
[02:06]  * hyperair facepalms
[02:07] <df00z1> Would the type be "single binary" or would I need to break out the package into a kernel module and userland?
[02:07] <persia> df00z1: You want multiple, and you want to look at dkms to build the kernel modules at install-time (as you can't know which kernel is installed at package build time)
[02:08] <persia> df00z1: I'd recommend four packages: -source (for m-a users), -module (for dkms users), -docs, and -tools (some folks just use the barename for this one)
[02:08] <persia> -source is extra points, and can safely be skipped if you like :)
[02:10] <df00z1> ...hmmm
[02:10] <df00z1> there's an init.d script though
[02:10] <df00z1> which requires the kernel module be loaded
[02:11] <df00z1> the initd script actuallt does a modprobe
[02:11] <df00z1> so im not sure i can seperate userland from the kernel module...it would have to require the kernel module
[02:11] <persia> Consider starting the service based on a udev rule instead.
[02:12] <persia> So that when the module loads, it starts the daemon, etc.
[02:14] <persia> If the module isn't autoloaded based on hardware detection, consider having the module package do something to ensure it's autoloaded by another means, so it then triggers udev, which triggers the daemon, which leaves a working system.  initscripts are serialised, and slow down startup, etc.
[02:15] <psusi> bah... imageshack doesn't like .svg it seems
[02:15] <hyperair> pastebin it!
[02:16] <hyperair> svgs are text after all =D
[02:16] <df00z1> I guess I could figure out udev and make it do something like that...
[02:16] <df00z1> thats non standard
[02:16] <df00z1> so id have to document it
[02:16] <psusi> heh
[02:17] <df00z1> non standard for other distros that is
[02:17] <psusi> you don't want to view it as text though
[02:17] <df00z1> anyone who's used to using it would be kinda confused
[02:17] <df00z1> haha
[02:17] <df00z1> arnt they XML based
[02:17] <psusi> I think
[02:17] <df00z1> surely theres someone out there who can look at the text and paint you a picture of it
[02:17] <df00z1> hahaha
[02:18] <psusi> picture viewer does that just fine
[02:18] <df00z1> then they can save it as a jpg
[02:18] <df00z1> and put it on imageshack
[02:18] <jdong> web browsers also do it
[02:20] <persia> df00z1: Which distro doesn't use udev?
[02:20] <df00z1> Oh, most use udev
[02:20] <df00z1> but to start and stop services for this one specific app
[02:21] <persia> df00z1: Also note that by using udev, you skip the entire sysvinit/upstart/systemd/etc. set of questions.
[02:21] <df00z1> lol, their makefile has a series of if statements
[02:21] <persia> Any service that depends on a kernel module *should* use udev to start/stop that service, based on the presence/absence of the kernel module.
[02:21] <df00z1> that try to detect what distro you're on
[02:21] <df00z1> and installs the correct init script accordingly
[02:21] <persia> Yeah, that's just messy :)  Doing it in udev lets you have one standard method for every distro :)
[02:23] <persia> The bit to consider is that you can't know when the user boots a different kernel, so you might have an initscript that ends up failing because it can't load the module, or worse, claiming to start a service that doesn't work because it has the wrong module.
[02:23] <persia> And that's just a waste of computation when you can detect the module load, and the user *already* has N ways to ensure that a given module loads if it's available on the system.
[02:24] <psusi> ahh there we go, saved as png and it's smaller, heh...
[02:25] <psusi> before: http://img34.imageshack.us/img34/5379/befores.png
[02:26] <psusi> after: http://img248.imageshack.us/img248/4760/afterw.png
[02:27] <psusi> now I can't figure out why it isn't all in one tight ring in the middle... hrm...
[02:28] <persia> What do the colors mean?
[02:28] <psusi> apparently different color = different file
[02:31] <jdong> psusi: temugen's bzr branch has a newer revision
[02:32] <jdong> psusi: the current one scales the graph to the smallest and largest block# mentioned by ureadahead
[02:32] <jdong> e.g. before/after are NOT drawn to absolute scale
[02:32] <jdong> only to relative distance.
[02:32] <jdong> psusi: the new one has a -f parameter to draw everything
[02:32] <jdong> psusi: bzr branch http://bradmisik.com/trunk/fragraph/
[02:32] <psusi> I can't figure out why there seem to be two general rings in the after instead of everything being in a tight ring in the middle....
[02:33] <psusi> it seems like I didn't manage to get a complete list of the pack file files to defrag...
[02:33] <jdong> psusi: I just gave temugen the pngs and he asked the same :)
[02:33]  * jdong spawns temugen...
[02:33] <jdong> hey it worked!
[02:33] <psusi> lol
[02:34] <jdong> psusi: does boot feel any faster?
[02:34]  * psusi uploads bootcharts
[02:34] <jdong> damn cool though
[02:35] <jdong> I've ALWAYS wondered what a Windows-esque defragger graph of a Linux FS looked like
[02:35] <temugen> jdong: I thought the windows-esque ones were the strip type?
[02:35] <jdong> temugen: no way, if anything a rectangular array
[02:36] <jdong> temugen: Diskeeper popularized the strip thing
[02:36] <jdong> and I have highly negative opinions about diskeeper, but anyway, that's not relevant to this ;-)
[02:36] <jdong> (in short, the way they labeled fragmentation as a disease to the point that their product has a constant background process that defrags every few seconds is ABSURD)
[02:37] <jdong> psusi: can you update your fragraph to bzr and generate your after pic again with -f?
[02:37] <jdong> (which plots the entire disk)
[02:38] <psusi> before: http://img30.imageshack.us/img30/9495/faldaralucid201005041.png
[02:38] <psusi> http://img21.imageshack.us/img21/1530/faldaralucid201005045.png
[02:38] <psusi> after...
[02:39] <jdong> psusi: wow the disk is definitely used less afterwards and reaches higher peaks
[02:41] <psusi> jdong, you update the bzr in the last few minutes?  branched it about 2 hours ago
[02:42] <jdong> psusi: oh, no we didn't. pass in -f?
[02:42] <temugen> psusi: no updates; it was stable since yesterday
[02:42] <psusi> jdong, yea... it reads the files faster as they seem to be backed at the start, which is why I'm wondering why the image shows a sort of outer ring
[02:42]  * jdong giggles about the use of "stable" :)
[02:42] <psusi> I'd have to boot back off the rotational disk to do that
[02:43] <psusi> does this graph the blocks used by directories too?  or only the files themselves that are listed in the pack file?
[02:43] <jdong> psusi: only the files
[02:43] <psusi> because so far I just filtered the output of ureadahead --dump with a few greps and an ls -i to get a list of inode numbers of the files it reads, which does not include the directories those files live in
[02:43] <jdong> psusi: that's what we do too
[02:44] <psusi> the big 1.5-2 second dip of nearly zero io in the boot chart after the initial square wave is where ureadahead is looping on open() and keeps blocking to fetch one block of directory at a time
[02:45] <psusi> I need to rework ureadahead to not open() and readahead() each file, but rather call readahead() on the raw block device for all blocks used by the files, and the directories they live in
[02:45] <psusi> hrm... but yea.... all of the files in the ureadahead pack SHOULD be crammed at the start of the disk... at least after the root directory and journal
[02:46] <psusi> I need to figure out what files those blocks in the outer ring are from
[02:46] <jdong> psusi: again, graph with -f to make it to scale.
[02:47] <psusi> to scale?  I thought -f just graphed all files, not just those in the pack file?  or did I misunderstand?
[02:47] <jdong> psusi: -f makes the start block 0 and end block max_block
[02:47] <temugen> psusi: it graphs the whole span of the block device
[02:47] <psusi> what is it otherwise?
[02:47] <jdong> psusi: without -f start block is min(readahead_mentioned_block) and end block is max(readahead_mentioned_block)
[02:47] <jdong> so just the region mentioned by readahead.
[02:48] <psusi> ohh... then I'm REALLY confused
[02:48] <jdong> yeah
[02:48] <psusi> I thought the unmarked space before the inner ring was the journal and root directory
[02:48] <jdong> which is why I said the graph wasn't to scale and somewhat deceptive in that regard.
[02:48] <jdong> no no no :)
[02:48] <jdong> the way that it's by default, it ONLY graphs the region in which there's files mentioned by ureadahead
[02:48] <psusi> other than that, everything else ureadahead reads should be packed tightly followign that in the first and second block groups
[02:48] <jdong> so in that way, it preserves the betweenness relationship
[02:48] <jdong> but not "scale" of the entire disk
[02:49] <jdong> you want -f for that
[02:49] <psusi> hrm...
[02:49] <jdong> and arguably -f should be default, if not for historical reasons
[02:49] <jdong> (namely, temugen figured out how to get the size of the disk AFTER writing the initial concept) :)
[02:49] <psusi> k... guess I'll reboot and regraph... would be nice if I could tell it to use the pack file and device under /mnt ;)
[02:49] <psusi> actually, I can probably fool it with chroot
[02:49] <temugen> and like -f, you can also specify a bpm (like 1000, which would be one visible block is equal to 1000 disk sectors)
[02:50] <temugen> psusi: that would be easy to implement if you want me to :) The Ureadahead class already accepts a pack file string in its constructor, just need to get the block device to do the same
[02:50] <jdong> psusi: I'm hoping it's just the start:end range decreased by orders of magnitude before vs after
[02:51] <jdong> which I wouldn't doubt to be the case!
[02:51] <temugen> and it's clear you guys want -f to be default as well :)
[02:52] <jdong> temugen: hahaha only C/C++ gets the right to make crummy things default for historical reasons ;-)
[02:52] <psusi> hrm... /dev/252:5: No such file or directory
[02:52] <jdong> hahahaha looks like we're missing a level of indirection? XD
[02:54] <psusi> when I was booted from that drive it complained about /dev/dm-5 missing, so I had to symlink it to the correct lvm device
[02:54] <jdong> psusi: eeeep you're on a LVM device?
[02:54] <psusi> jdong, of course ;)
[02:54] <jdong> psusi: you missed keybuk's big speech about how ureadahead doesn't work on device-mapper ;-)
[02:54] <jdong> psusi: but I do admire your hack for it!
[02:54] <psusi> eh?  works just fine
[02:55] <jdong> psusi: it's not supposed to (tm)
[02:55] <psusi> why not?
[02:55] <jdong> psusi: because device mapper hides away the abstraction of physical location on disk.
[02:55] <psusi> so?  ureadahead's idea of physical location is just going to be relative to the start of the volume
[02:55] <jdong> psusi: or more concretely, stat()ing the mountpoint does not yield a major/minor that can be used to loo kup /sys/class/dev/block/major:minor/queue/rotational
[02:55] <psusi> normally it's relative to the start of the partition... same thing....
[02:56] <jdong> psusi: (I'm requiring Keybuk, argue with him, not me!)
[02:56] <psusi> actually, it does ;)
[02:57] <psusi> I was actually kind of surprised that that part worked... but ureadahead seems to judge correctly that I'm using ssd normally and rotational for this test volume I copied to the old disks
[02:57] <jdong> psusi: that's freakish that queue/rotational works on device-mapper :)
[02:58] <psusi> jdong, I assumed ureadahead was being smart enough to notice the slaves in /sys and check queue/rotational on the slave instead
[02:59] <jdong> psusi: I'm pretty sure it's not that smart
[02:59] <psusi> hell, when I first installed karmic before I got the ssd, it was on lvm on the old dmraid raid 0...  after I got the ssd, I just had lvm pick up the running root volume and migrate it on the fly while it was in use over to the ssd
[02:59] <psusi> then I made a snapshot and tried upgrading to lucid ;)
[03:00] <jdong> lol I'm confused how snapshots and ureadahead work in practice :)
[03:00] <jdong> considering logical block locations have nothing to do with physical locations in that case
[03:00] <psusi> ureadahead just works with logical block locations
[03:00] <jdong> yes, ureadahead itself works
[03:01] <jdong> but what it's DOING doesn't work that well IMO when you've got COW and other relocating going on
[03:01] <psusi> oh yea... it won't perform optimally if the files it's trying to read are split between the original disk and the cow store
[03:02] <jdong> right
[03:02] <psusi> at one point when testing lucid I actually booted using the snapshot as the root fs to perform the upgrade from karmic to lucid and if it didn't work, I was just going to delete the snapshot
[03:02] <psusi> it was kinda cool
[03:03] <psusi> then I wanted to keep lucid and merge the snapshot back into the origin, but that isn't supported just yet... think it went into 2.6.34
[03:04] <psusi> anyhow.... back to defrag.. why is fraggraph complaining about /dev/252:5? ;)
[03:04] <jdong> psusi: trace through the codepath that maps a stat to a /sys/class/block/dev
[03:04] <temugen> psusi: it checks /sys/dev/block/252:5 for a link
[03:04] <psusi> ohh, it wanted /sys and /proc --bind mounted in the chroot ;)
[03:04] <jdong> HAHAHAHAHA
[03:04] <jdong> XD
[03:05] <jdong> yes, sysfs would be nice to have :)
[03:05] <jdong> so would /dev :)
[03:05] <persia> psusi: schroot is *wonderfully* flexible at doing that sort of tricky bits, if you're just a chroot user (rather than using chroot() as an implementation detail)
[03:06] <temugen> psusi: so yea, it checks /sys/dev/block/#:# for a link and then reads the output of blockdev on /dev/xxx#
[03:08] <psusi> the -f didn't seem to make any difference
[03:08] <psusi> yea, I bound /dev, just forgot /sys ;)
[03:09] <psusi> there are still two well defined rings, an inner, and an outer, neither of which are all the way against the spindle
[03:10] <persia> Might it be possible that those are better read locations for some odd reason on that particular device?
[03:11] <psusi> no... I configured defrag to pack the files in question at the start, so they should all be crammed right around the center in the graph
[03:14] <psusi> what I need is a mouseover to tell me what file those blocks belong to when I point at them in the graph ;)
[03:21] <psusi> temugen, any chance you get can that to happen? :)
[03:33] <baddog> hi
[03:36] <persia> hey baddog
[03:37] <baddog> looks like pbuilder requires a fairly big download to set up, which isn't feasible for me. Are there any alternatives available?
[03:37] <baddog> I would like to get involved with the MOTU
[03:48] <persia> The alternatives all also require a fair bit of download, plus *using* any of the build-test tools requires download of all the build-deps for each build.
[03:48] <baddog> hm. crap :(
[03:49] <persia> Some folks use PPAs, but that tends to run into issues with changelog entries and version numbers.
[03:49] <baddog> :/
[03:49] <persia> Some folk don't test-build, but we don't approve of that much :)
[03:49] <baddog> I guess I'd better find somewhere else to contribute then :P
[03:50] <persia> Well, we'd be happy to get patches, if you have some.
[03:50] <baddog> hm. I don't :P
[03:50] <baddog> but k
[03:50] <baddog> ok*
[03:50] <persia> But yeah, if you're bandwidth-constrained, I'd strongly recommend working with one or a few specific upstream development projects.
[03:50] <baddog> yeah
[03:51] <persia> You'll have an initial load pulling the code and history, and some continuous load keeping your tree up-to-date, but you won't have the constant test-building.
[03:51] <baddog> I suppose
[03:51] <persia> Well, you will, but it won't be from arbitrary packages needing downloading all the time: you'll rather just be building the one source.
[03:51] <ScottK> That or depending on the type of constraint, one might use a local mirror.
[03:51] <baddog> nah, local mirrors won't help at all
[03:52] <baddog> bbl
[03:58] <temugen> psusi: absolutely
[03:58] <temugen> psusi: anything to help out your defrag work :)
[04:00] <jdong> temugen: please tell me SVG's have an alt= equivalent ;-)
[04:01] <temugen> jdong: it wouldn't be more than 10min of work to render it with a mouseover anyway. I've got all of that data (locations and file blocks) readily available
[04:01] <temugen> but sure, I'll look into that first :P
[04:01] <jdong> temugen: render with mouseover? it's a SVG!
[04:01] <temugen> jdong: so? pygame has an svg library!
[04:01] <jdong> temugen: I hope they add alt= support before they add onclick= javascript events :)
[04:01] <temugen> but yes, me too :)
[04:01] <jdong> ah, pygame
[04:01] <jdong> yeah let's just link everything against SDL!
[04:01] <jdong> *ducks* :)
[04:02] <temugen> sheesh, this is basically a necessary feature now. why didn't we think of that before?
[04:03] <jdong> temugen: eh because you started out making it just a slide renderer for me based on a selfish request :)
[04:04] <jdong> temugen: it appears that all the SVG tags support a <desc> subtag </desc>
[04:04] <temugen> jdong: ah, good point :) (minus the selfish request) The commenting and structure sure wouldn't lend itself to those motives, though
[04:04] <jdong> I'm not convinced what SVG renderers support that
[04:06] <ScottK> requirements creep is fun.
[04:07] <jdong> temugen: can it make extra-fragmented files blink?
[04:07] <jdong> *runs*
[04:08] <temugen> jdong: *sigh* it CAN do a lot of things. Do I need to program them is the question.
[04:18] <psusi> ahhh, being married is awesome
[04:19] <psusi> lol
[04:20] <psusi> jdong, temugen yea... I need to figure out what is causing that outlying ring of blocks... inode numbers or names, I don't care.. either way I can analyze in debugfs
[05:07] <persia> Just a reminder, it's Patch Day. Anyone with some time to review patches and help get them in the right places is encouraged to stop by #ubuntu-reviews and help out.
[05:19] <imbrandon> evening all
[05:25] <fabrice_sp> 'morning imbrandon
[06:05] <fabrice_sp> does somebody knows why the sponsoring page shows all packages as unseeded?
[06:05] <fabrice_sp> it makes hard to find the packages I can sponsor :-/
[06:34] <persia> fabrice_sp: Might be something related to the maverick transition: you could just try uploading anything listed as "unseeded" and see what happens :)  Alternately, check with rmadison.
[06:40] <mannyv> persia: hi from earlier
[06:40] <persia> hey.
[06:59] <Rhonda> persia: speaking of maverick, what needs to get done to make wesnoth-1.8 sync into there and dropping the ubuntu patch? :)
[07:00] <persia> Needs a sync bug.
[07:00] <Rhonda> Alright, will look into it.
[07:00] <persia> requestsync should do it.
[07:00] <ajmitch> Rhonda: oh hi, I did do that libsdl1.2 diff, just fetching the patches from the last 2 debian uploads :)
[07:00]  * ajmitch needs to follow up on it a bit :)
[07:01] <Rhonda> Ah, yes, please don't forget about it. Users are already pretty unhappy with the required workarounds.
[07:04] <Rhonda> Every time I stumble upon bug #56125 I have to laugh again. :)
[07:05] <ajmitch> why isn't that critical?
[07:06] <Rhonda> hihi, which brings me back to my comment in http://bugs.debian.org/271810 ;)
[07:08] <Rhonda> ajmitch: But you could test/comment in bug #570609 if you feel like it. ;)
[07:10] <imbrandon> ajmitch / Rhonda : the cow bug, i went back to go read it, and apparently i touched it 4 years ago, wow i've been arround here too long
[07:10] <imbrandon> lol
[07:13] <Rhonda> I still don't see any informations about author/license for the proposed cows so this should rather be considered invalid.
[07:14] <imbrandon> author is the original poster, but your right, no license for the patch proposed ;)
[07:14] <Rhonda> Actually I'm serious on that. I hate it to see Felix Lee's cat used all over the place with stripped out author tag.
[07:14] <imbrandon> but then again most patches arent licensed
[07:14] <Rhonda> imbrandon: I highly doubt that the original poster was the author.
[07:15] <Rhonda> Stating "gentoo's cow" doesn't make it sound like he did it himself.
[07:15] <imbrandon> sure, he/she could have made the hybrid ;)
[07:15] <imbrandon> its only a 4 char change imho
[07:15] <Rhonda> But then he did a derived work from something he might not have a license for.
[07:16] <imbrandon> ahh now THAT is a good call, but again i have a feeling apt is licensed gpl X even on gentoo
[07:16] <imbrandon> thus patches and dirivatives must be too
[07:16] <Rhonda> Does gentoo has apt?
[07:16] <imbrandon> sure, as does fedora and a few other distros
[07:17] <Rhonda> I'm not sure that the cow does appear in apt in gentoo. And even then - others can do mistake, we shouldn't just "believe" them.
[07:17] <imbrandon> there is even apt for win32 via cygwin pkg mgmt
[07:17] <Rhonda> And actually, the way ascii art is handled within the cowsay package makes me feel extremely uneasy.
[07:17] <imbrandon> Rhonda: very true, i'm inclided to agree, just giving the devils advocate :)
[07:17] <\sh> moins
[07:18] <Rhonda> http://rhonda.deb.at/ascii/unsorted.html
[07:18] <imbrandon> heya \sh
[07:20] <Rhonda> When looking at it, I still like my dust puppy and wilbert. :)
[07:20] <imbrandon> :)
[07:25] <\sh> -Etoomanyblueprints and topics ;)
[07:25] <imbrandon> lol, \sh yup, seems that way every 6 months
[07:26] <\sh> imbrandon, well, in former times it was more "ok, what sounds interesting"...now it's "heck, there are too many topics we are stumbling upon during our daily work"...the whole java stack crap falls into this category
[07:27] <imbrandon> \sh: yea, you just have to pick the ones you can contribute the most to and trust the others are handled correctly, thats some of the growing pains of being soo biug
[07:27] <imbrandon> big*
[07:28] <\sh> imbrandon, well, good thing about this uds is, I'm not alone on this one...our junior sysadmin needs to do some work too...he isn't even involved in this whole ubuntu business, but he will be in no time...
[07:28] <imbrandon> :)
[07:29] <imbrandon> food time, back in a bit
[07:29] <\sh> and this is only all about server, monitoring, puppet and java foo .. oh hell
[07:32] <ajmitch> hi \sh
[07:32] <\sh> hey ajmitch
[07:32] <ajmitch> \sh: is anything happening with leonov these days?
[07:33] <\sh> ajmitch, wanna takeover? looks like with kid, wife and work I'm totally occupied, but if I find somehow the time to do some hacking on leonov, sure...there will be progress
[07:34]  * imbrandon is curious what leonov is ...
[07:35] <\sh> leonov was the idea of a desktop launchpad client
[07:35] <imbrandon> ohhhhhhh nice
[07:35] <imbrandon> that would be awesom imho
[07:35] <\sh> imbrandon, http://www.leonov.tv/
[07:35] <ajmitch> it needs its guts replaced to use launchpadlib
[07:35]  * \sh needs to update all that
[07:35]  * imbrandon peeks
[07:35] <\sh> ajmitch, yes
[07:36] <ajmitch> I might hack on it a bit & see if I can get anywhere with that
[07:36] <imbrandon> is it python ?
[07:36] <ajmitch> it is
[07:36] <\sh> sure it's python
[07:36] <imbrandon> nice
[07:36] <ajmitch> groundcontrol has some similar ideas, but a different focus, I think
[07:36] <\sh> most of the things I do are nowadays in python
[07:36] <imbrandon> ajmitch: i might hack a bit too, but you konw my python guru-ness so i'll probably pass stuff through you ;)
[07:37] <imbrandon> isnt groundcontrol more server admin stuff like webmin on crack
[07:37] <ajmitch> no
[07:37] <ajmitch> https://edge.launchpad.net/groundcontrol
[07:38] <imbrandon> ahh i misunderstood the 3 minutes i looked at it then via someones blogpost on planet
[07:39] <ajmitch> \sh: I may as well join the team & quietly hack away on it, no promises on results soon though :)
[07:39] <\sh> ajmitch, welcome :)
[07:40] <imbrandon> ahh gc looks more like other app intergration
[07:40] <imbrandon> from a glance
[07:40] <imbrandon> ok food is done in the microwave, back again in a min
[07:40]  * \sh hacks now mostly on FAI + Puppet + Django + QooxDoo to provide a "all you can eat" app framework for companies to auto-deploy/auto-configure their datacenters
[07:41] <\sh> this I'm doing during my worktime, and the app will be released as GPLed (or whatever license I'll come up) to the public with blessing of my company
[07:41]  * imbrandon is working on a license key verification webservice server mostly the last couple of days for $work
[07:42] <\sh> ajmitch, done
[07:43] <imbrandon> \sh: hahaha Shock Me!, man you dont know how much of a KISS geek I am
[07:44] <imbrandon> \sh: i have so much KISS merchandise its not even funny, posters, guitar  and guitar picks form the members, ticket stubs, even a 1970's pinball machine
[07:44] <\sh> imbrandon, are we all KISS geeks? ;) fire, blood, masks and guitars + gene simmons == must have addiction for geeks ;)
[07:45] <imbrandon> heheh i was/am more of an ACE fan, he is the reason i started playing guitar way back in the day
[07:45] <\sh> oh well...yes...space with ace
[07:45] <imbrandon> even went as Ace for holloween a few years ;)
[07:46]  * ajmitch prefers nice gentle music, like iron maiden
[07:47] <\sh> what I like today is "gene simmons family jewels" on bio channel
[07:47] <imbrandon> you know shock me was written because Ace was comming on stage one night durring tour in Germany and he got an electrical shock from the railing from a faulty ground, had to get a stand in guitarist for the show for that night
[07:47] <\sh> ajmitch, like "gates of tomorrow" of "dance of death" (the music I'm right now listening too?)
[07:47] <imbrandon> ajmitch: :)
[07:48] <imbrandon> ajmitch: i'm more of a 60 and 70's rock guy, with a tiny bit of the 90's and really new stuff mixed in.
[07:49] <imbrandon> pantera, omg, cowboys from hell ;)
[07:50] <\sh> ah well Iron Maiden is still one of the masters of rock...on saturday I was watching a concert of 2003 (recorded in Dortmund, Germany) and even at their old age...they still rock like hell...Hail Eddie ;)
[07:51] <\sh> (but I think they are still not that old than the original Kiss Lineup)
[07:53] <imbrandon> hahah yea the original KISS lineup is what, in their early 60's now ?
[07:54] <\sh> imbrandon, yes..genes 60s birthday was last year when I remember correctly
[07:55] <\sh> but still...they rock every stadium...it's just so bombastic
[07:56] <imbrandon> Paul Daniel Frehley (born April 27, 1951), better known as "Ace"
[07:56] <imbrandon> ahh so 59
[07:57] <imbrandon> yup
[07:58] <\sh> last year around christmas, we got visitors from cameroon...one young girl (aged 14 or 15 dunno anymore) she checked my dvd collection and found the official kiss reunion story from 1996 .. she went mad and wanted to watch it directly...asked her "You know Kiss?" "sure, they're my fav band ever...they are so cute and sexy" ;)
[07:58] <imbrandon> lol, wow
[07:58] <\sh> Gene, born 1949
[08:00]  * maco guesses she hasnt seen current photos
[08:01] <imbrandon> maco: of ?
[08:01] <maco> imbrandon: the guys from KISS
[08:01] <imbrandon> maco: hehe probably, plastic surgery does wonders
[08:01] <\sh> http://www.smh.com.au/ffximage/2006/10/18/kiss_fragrance_wideweb__470x313,2.jpg <- gene unmasked
[08:01] <siretart> morning
[08:02] <imbrandon> maco: http://www.zrock.com/zforum/images/blacktooth07_5342.jpg <- Ace Unmasked
[08:02] <imbrandon> moins siretart
[08:03] <maco> wow they still have enough hair to dye
[08:03] <imbrandon> hehe
[08:03]  * siretart hifives imbrandon :-)
[08:03] <imbrandon> i actualy saw ace on that tour, it was the "rocket ride tour" of 2007ish
[08:03] <\sh> http://www.kissonline.com/media/index/singlemediaplayer/mediaId/5/type/video/ :)
[08:04] <imbrandon> \sh: wow thats old, from the 70's
[08:05] <\sh> yes...in the 70ties I wasn't allowed to watch them at all :) and when they reunited in 1995 I was the first to buy tickets for the concert in dortmund...it was great...I even had tears in my eyes :)
[08:05] <imbrandon> still a great song though
[08:06]  * imbrandon gets back to Ubuntu stuff, before i sit and watch youtube all night of KISS ;)
[08:08] <dholbach> good morning
[08:08] <imbrandon> heya dholbach
[08:08] <dholbach> hi imbrandon
[08:08] <\sh> imbrandon, lol
[11:00] <soren> I'm constructing a watch file for libcloud. I want it to look at its download page (http://incubator.apache.org/libcloud/downloads.html) and find the .bz2 there. However, the link I can find there takes me to a page where I'm supposed to choose a mirror to download from. How do I deal with that?
[11:00] <slytherin> soren: Use apache's primary distribution site in watch file
[11:01] <soren> slytherin: They ask that people don't use the main mirrors.
[11:01] <soren> "Please use the backup mirrors only to download PGP and MD5 signatures to verify your downloads or if no other mirrors are working."
[11:02] <slytherin> soren: You are not downloading anything, only checking presence of a file
[11:03] <soren> I'm certainly downloading if there's a new version.
[11:05] <soren> I guess I'm going to have to do that. I don't see a way to make uscan do a two-step thing.
[11:07] <slytherin> soren: I have always used main site in watch files. AFAIK, there is no other solution.
[11:22] <ghostcube> persia: i tested the medibuntu mplayer, and the segfault is still there. i need to check how i can get jackd downgraded cause i use the 1.96 branch from an ppa. ubuntu has an other version packaged afaik
[11:23] <ghostcube> its the first time since a bit that xine is compiled by ubuntu against jackd libs correct?
[11:25] <slytherin> ghostcube: because jack moved to main in Lucid cycle.
[11:26] <ghostcube> hmm, ok will do more bug hunting this evening :)
[11:27] <ghostcube> i think ubuntu compiled jackd "old" release cycle with xine
[11:27] <ghostcube> have to check later :)
[11:30] <ghostcube> heh yeah i use jack2 and ubuntu offers jack 1
[11:30] <ghostcube> so it will be hard to investigate my bug i think i must live with
[12:00] <soren> slytherin: Ok, thanks.
[12:01] <soren> Does anyone know how I can get uscan to understand that 1.0 is the newest version here: http://pypi.python.org/packages/source/p/python-cloudservers/
[12:02] <POX> soren: opts=uversionmangle=s/(a|rc)/~$1/
[12:03] <soren> POX: ROCK! Thanks.
[12:04] <POX> soren: your sponsor suck for not pointing this out before uploading
[12:04] <soren> POX: Heheh :)
[12:04]  * soren loves his sponsor anyway
[12:04] <slytherin> soren: Or easier would be to check only numerical versions. Expression would be ([\d\.]+)
[13:21] <diwic> Sorry for being off topic here, but can somebody help me get in touch with Marianna (about UDS-M), either on IRC or on phone?
[13:22] <Pici> diwic: You may have better luck asking in #ubuntu-community-team
[13:23] <diwic> Pici: thanks
[13:32] <ari-tczew> packages.ubuntu.com needs some love, because intrepid is EOL and maverick is current devel
[13:35] <Rhonda> ari-tczew: Looking into it, thanks for the information.
[13:35]  * Rhonda . o O ( cloning the packages.git repository right now )
[13:36] <ari-tczew> no problem, you welcome
[13:36] <Rhonda> Actually I wonder wether djpig might be the only one to be able to deploy it on Ubuntu, too.
[13:38] <jpds> Rhonda: Yes.
[13:39] <Rhonda> jpds: Thanks for the information. Actually I'm trying to convince to get added to the deployment group within Debian, maybe it might make sense to have a backup for Ubuntu, too.
[13:42] <Rhonda> Did the maverick release obsolete any other release?
[13:43] <jpds> No.
[13:43] <Rhonda> dapper?
[13:43] <jpds> No, dapper is supported until April next year.
[13:43] <Rhonda> Hmm, it's not on the wiki frontpage anymore.
[13:44] <jpds> https://wiki.ubuntu.com/Releases
[13:44] <Rhonda> Yes, it just confuses me that it isn't on http://wiki.ubuntu.com/ itself anymore.
[13:44] <jpds> Hmm, good point.
[13:48] <Rhonda> jpds, ari-tczew: http://git.debian.org/?p=webwml/packages.git;a=commit;h=736a2217 - now it only has to get deployed. :)
[13:49] <jpds> Rhonda: Might want to drop intrepid.
[13:49] <ari-tczew> +1
[13:50]  * Rhonda wonders why I asked before wether any other releases are obsoleted.  %-)
[13:50]  * Rhonda nibbles on jpds's shoulder and does another commit.
[13:51] <jpds> maverick didn't obsolete intrepid! They just happened to occur at the same time...
[13:52] <Rhonda> nitpicker! :)
[13:52] <Rhonda> Created commit b675bdf: remove intrepid
[13:54] <ari-tczew> Rhonda, thanks!
[13:54] <Rhonda> ari-tczew: Like mentioned, it seems to require djpig to deploy it, so it might take a while to become visible.
[13:55] <ari-tczew> ok ok
[13:57] <ari-tczew> Rhonda: now maverick in packages.ubuntu.com isn't importand, because debian import not yet works
[14:04] <callum1> Hi all, I have found a bug in the xdg-email command. Not sure how I would go about making a new bug
[14:04] <callum1> I also have a fix for this
[14:10] <mannyv> callum1: first check and see if it is listed here https://launchpad.net/ubuntu/+source/xdg-utils/+bugs if it is then not open a new bug report
[14:11] <mannyv> woops if it is not*
[14:11] <callum1> mannyv: thanks I have had a look and this appears to be a new bug so I have posted the problem and the fi
[14:11] <callum1> fix*
[14:14] <geser> lucas: does http://people.ubuntuwire.com/~lucas/merges.html already use Debian unstable as base?
[14:20] <hyperair> Just a reminder, it's Patch Day. Anyone with some time to review patches and help get them in the right places is encouraged to stop by #ubuntu-reviews and help out.
[14:23] <lucas> geser: fixed now to use sid, the public version will be updated in a few mins
[14:23] <geser> thanks
[14:26] <lucas> (maybe more, it's hammering the LP API when there are lots of pending merges)
[14:27] <mannyv> callum1: if you are still around you should you should grab the source package with apt-get source xdg-utils and fix the bug in there then add a patch to the bug report
[14:28] <callum1> mannyv: Yeah i was going to post the patch but  apt-get source xdg-utils
[14:28] <callum1> Reading package lists... Done
[14:28] <callum1> Building dependency tree
[14:28] <callum1> Reading state information... Done
[14:28] <callum1> E: Unable to find a source package for xdg-utils
[14:28] <callum1> sorry about paste bomb
[14:30] <geser> do you have the source repository enabled? (a deb-src line in your /etc/apt/sources.list?)
[14:32] <callum1> not sure anyway to check which source this package comes from?
[14:33] <geser> xdg-utils is the right source package
[14:33] <persia> `apt-cache show ${PACKAGE} | grep Source || echo ${PACKAGE}` tends to work.
[14:33] <soren> callum1: apt-get source takes care of that. "apt-get source <some binary package>" gives you the corresponding source package.
[14:35] <callum1> Sorry I mean which sources.list is required for a particular package
[14:35] <callum1> http://packages.ubuntu.com/search?keywords=xdg-utils&suite=default&section=all&arch=any&searchon=names usually has universe/main etc but in this case it does not
[14:36] <kklimonda> callum1: your bug is a duplicate of bug 528867 which has attached a branch with a fix.
[14:37] <callum1> kklimonda:  nice thats the fix I was going to propose :)
[14:38] <callum1> Seeing as someone has already done this i will leave this. Thanks for your help guys
[14:53] <mannyv> callum1: since you already files a bug report in LP you should go mark it as a duplicate with the link on the page labeled: "Mark as duplicate"
[14:54] <mannyv> oh already done nm
[14:58] <ScottK> nhandler: I see you were involved in the libnet-ssleay-perl update in Debian.  I was wondering if you could have a look at the 90test-fix-on-64bit-arches.patch patch in the Ubuntu package and see if you think it should be included by Debian too.
[16:12] <lfaraone> Hey, does anybody running Jaunty have a chance to do a SRU verification for me? (it's as simple as "sudo apt-get install etoys; etoys", and if it runs, you're done)
[16:31] <arand> lfaraone: I've got a virtualbox if that'll do?
[16:35] <nigelbabu> Just a reminder, it's Patch Day. Anyone with some time to review patches and help get them in the right places is encouraged to stop by  #ubuntu-reviews and help out.
[16:35] <nigelbabu> We only have about 108 bugs more to be reviewed, help us make it ZERO!
[16:36] <lfaraone> arand: that's fine.
[16:36] <lfaraone> arand: Bug 301190 is the ref
[16:38] <lfaraone> When can we start to request syncs for Maverick? (after the toolchain?)
[16:40] <proppy> Hi, is there a javascript shell available in universe ?
[16:40] <proppy> it seems that spidermonkey-bin is gone
[16:51] <ScottK> lfaraone: You can file sync requests now.  They won't be acted on for a while.
[16:52] <geser> lfaraone: I've already filed some sync requests for packages that can be synced again (don't need a merge)
[16:54] <arand> lfaraone: Noticed a random crash while testing, not able to reproduce it seems, just report the error I got printed on terminal, or disregard?
[17:10] <arand> lfaraone: Hmm, my guess is that these crashes are simply down to general instability of etoys :/
[17:24] <temugen> psusi: Alright you can bzr update and there'll be title tags placed on the blocks for you
[17:25] <temugen> psusi: Chromium renders them on mouseover, I'd imagine/hope any other browser you use would too
[18:30] <psusi> temugen: awesome... can't wait to get home and try it
[18:32] <imbrandon> happy cinco de mayo
[18:42] <lfaraone> arand: probably.
[18:44] <lfaraone> arand: can you send me the log of the crash, by the way?
[18:44] <lfaraone> (is it something like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507161 ?)
[18:56] <lfaraone> arand: (if you could, set the "verification-needed" tag to "verification-done")
[21:32] <ari-tczew> do we need to update-maintainer in SRU, if current maintainer is emailed @ubuntu.com ?
[21:34] <ScottK> No
[21:34] <geser> even if you tried to use update-maintainer, it would tell you that there is nothing to change
[21:41] <RainCT> hey
[21:41] <RainCT> What happened to GRUB in Lucid? :(
[21:42] <sebner> RainCT: hmm?
[21:42] <RainCT> sebner: there's no way I can get it to show up
[21:42] <sebner> RainCT: no problems here
[21:42] <imbrandon> rainct, its hidden ,hold shift when booting
[21:42] <RainCT> Ah. Was trying like mad with escape.
[21:42] <RainCT> Thanks
[21:43] <imbrandon> and or modify /etc/default/grub and rerun update
[21:43] <RainCT> Yeah well it's just in case I need a recovery shell
[21:45] <RainCT> Eg. yesterday after installing the nvidia driver and rebooting Ubuntu would boot up to the point where X is supposed to start and there hard freeze with a black screen. Had to look for an USB to be able to edit /etc/X11/xorg.conf because I couldn't figure out how to get a shell otherwise
[21:45] <RainCT> (although disabling the nvidia driver didn't fix it, I ended up reinstalling.. weird stuff :P)
[21:46] <RainCT> anyway, /me stops whining. Thanks for the info imbrandon, sebner
[21:46] <imbrandon> np
[21:46] <sebner> RainCT: I didn't do anything but np :P
[21:47] <RainCT> sebner: well, I guess I enjoy pinging you ^^
[21:47]  * sebner throws rotten tomatoes at RainCT :P
[21:48] <RainCT> sebner: btw, I've got 2x 24" monitors at work. they are awesome :P
[21:49] <sebner> RainCT: pfffffffffffffffffffffffffffffffffffffffffffff
[21:49] <sebner> RainCT: definately too good for you :P
[22:10] <nhandler> ScottK: I'll take a look in a little bit
[22:12] <geser> RainCT: a 3840x1200 dekstop or a 3840x1080 one?
[22:15] <ScottK> nhandler: Thanks.
[22:18]  * ajmitch only has 3360x1050 here :(
[22:18]  * ScottK tosses another ping at jdong over clamav in the lucid-proposed queue.
[22:19] <directhex> i have 3520x1200 at work
[22:19] <ajmitch> I suppose I could count my laptop at 1600x900 as well, since I use x2x to use the desktop mouse & keyboard with it
[22:20] <temugen> ScottK: I'm not sure if he can look at it for a while, he is literally buried in work right now :-/
[22:20] <geser> I've only 3200x1200 (an old 17" with 1280x1024 and a 24" with 1920x1200)
[22:20] <ScottK> temugen: I don't care if he looks at it, I just want him to approve it. ;-)
[22:20] <jdong> ScottK: LMFAO
[22:20] <jdong> ok ok before heading out for dinner, I'll take a peek
[22:20] <jdong> what's the change?
[22:21] <ScottK> jdong: Thanks the powerpc fix yesterday was incomplete.
[22:21] <jdong> oh it says it
[22:21] <ajmitch> who needs dinner when there are packages to look at?
[22:21] <ScottK> I got the commit for the fix in there, but not the one with the fix for the fix so it would compile.
[22:21] <jdong> oh okay, gotcha
[22:21] <jdong> sounds reasonable to me, doesn't really change the intent of the debdiff
[22:21] <ScottK> Thanks.
[22:21] <jdong> ACK :)
[22:21] <ScottK> jdong: Accepting.  Thank you and have a nice day.
[22:22] <Bachstelze> [23:21] < ScottK> I got the commit for the fix in there, but not the one with the fix for the fix <= yo dawg, I heard u like fixes...
[22:22] <jdong> ScottK: thank you!
[22:22] <ScottK> Done.
[22:49] <YokoZar> ScottK: I'm having a little trouble with https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/571999  it doesn't make any sense to me.  Basically apt is refusing to upgrade when wine and wine1.2 are installed and it's throwing the error that wine1.2 conflicts with wine << 1.2 (which fails because both packages are 1.1.42).
[22:49] <YokoZar> What doesn't make sense to me is that the conflicts line in debian/control doesn't say << 1.2 at all, but instead says << 1.1.36.
[22:51] <YokoZar> wine1.2-dev has a (wrong) conflicts line that says wine-dev << 1.2, but that shouldn't matter since neither wine-dev or wine1.2-dev were installed in the logs linked there.  So I have no idea where this conflicts failing condition is coming from
[22:52] <YokoZar> ScottK: anyway I could SRU the wine-dev 1.2 to 1.1.36 thing, but I don't think that would fix the actual problem (that now has 12+ duplicates)
[23:11] <ajmitch> jdong: if you're still alive, do you think temugen's patch for mutt (bug 539348) is SRU-worthy? :)
[23:12] <nigelbabu> Just a reminder, it's Patch Day. Anyone with some time to review patches and help get them in the right places is encouraged to stop by   #ubuntu-reviews and help out.
[23:12] <nigelbabu> We're down to 91 bugs and really could use some help to bring it down to 0
[23:24] <ScottK> YokoZar: You need to replace win << 1,2 also
[23:25] <ScottK> win/wine
[23:25] <YokoZar> ScottK: where?  debian/control under wine1.2 says << 1.1.36
[23:25] <ScottK> YokoZar: Replaces?
[23:27] <YokoZar> ScottK: ok you're right it needs to be higher version in Replaces
[23:27] <YokoZar> ScottK: but that shouldn't generate that error either
[23:27] <ScottK> If it doesn't replace the current wine package then it would explain exactly the error you're getting.
[23:28] <YokoZar> A conflicts line with a different version?
[23:28] <YokoZar> It's not supposed to conflict at all
[23:28] <ScottK> But it does conflict, right?
[23:29]  * ScottK quits looking and downloads.
[23:29] <ScottK> looking/guessing
[23:29] <YokoZar> Thanks by the way