[12:17] <crimsun> geser: of course, that's why I asked if he planned on filing an M.I.R. to have it in gutsy/main.
[12:19] <mohammad> ScottK, crimsun: Thank you. this package will be my first contribution in ubuntu reps :)
[12:21] <ScottK> mohammad: Uploaded.  Thank you for contributing.  Everyone having access to Ubuntu in their own language is an important value in Ubuntu, so this contribution is particularly appreciated.
[12:22] <superm1> thx crimsun.
[12:22] <crimsun> whew, thank goodness my ttf- upload failed ;)
[12:22] <ScottK> What, you uploaded it too?
[12:22] <crimsun> (this caf's wifi is wonky)
[12:22] <crimsun> no, I attempted, but it failed
[12:23] <crimsun> rsync error: unexplained error (code 130) at rsync.c(271) [sender=2.6.9] 
[12:23] <crimsun> your upload is [or should be]  the accepted one
[12:23] <ScottK> I got an accepted message, so we're good.
[12:23] <shawarma> crimsun: You rsync your uploads?
[12:24] <ScottK> mohammad: It has to be manually accepted by the archive admins, so it will be a while before it's actually published.  
[12:24] <crimsun> shawarma: to a trusted remote host.
[12:24] <shawarma> crimsun: Ah, from which you do the actual upload?
[12:24] <crimsun> I dput from there.  Yes.
[12:25] <shawarma> That's pretty much what I do when on a questionable connection, too.
[12:26] <mohammad> ScottK, crimsun:  thanks
[12:27] <ScottK> mohammad: No, thank you.  You did the hard work here.  Welcome to the club....
[12:28] <superm1> ScottK, I need one more on mythbuntu-default-settings yet, would you be able to look that over as well?
[12:28] <crimsun> err?
[12:28] <crimsun> you already have 2 +1s on mythbuntu-default-settings
[12:28] <superm1> crimsun, did you upload?
[12:28] <superm1> oh whoops :)
[12:28] <crimsun> I'm working on that
[12:28] <ScottK> superm1: No.  Unfortunately I have to be on the road in roughtly 120 seconds.
[12:29] <ScottK> Ah.  Looks like you're OK anyway.
[12:29] <ScottK> roughtly/roughly
[12:31] <ScottK> See you all later.  Have a good $TIME_OF_DAY.
[12:31] <crimsun> l8r
[12:34] <crimsun> *headdesk*
[12:35] <crimsun> `sudo ifconfig eth0 mtu 1300`, and voila, we're in business again.
[12:47] <crimsun> reviewing ubuntustudio* source packages on REVU now.
[12:48] <icf7> Could someone nuke http://revu.tauware.de/details.py?upid=5888 ?
[12:49] <crimsun> why for?
[12:49] <icf7> crimsun: Has been renamed and will enter through Debian.
[12:50] <crimsun> archived for now.
[12:50] <icf7> crimsun: Thanks
[12:54] <_16aR_> has anyone know how to register env variable in debian package ?
[01:05] <_MMA_> crimsun: Thanx.
[01:14] <crimsun> _16aR_: more precisely, please?
[01:19] <gnomefreak> when you use nautilus to connect to ftp server and it prompts you for password and user name even though you always hit always remember, what app is that a problem with?
[01:21] <crimsun> gnome-keyring.gnome-keyring-manager |   2.18.0-2 |         gutsy | source, amd64, i386, powerpc
[01:21] <crimsun> argh
[01:21] <crimsun> gnome-keyring-manager  <--
[01:21] <gnomefreak> thats what i was afraid of
[01:25] <gnomefreak> crimsun: ty trying to file bug but LP isnt playing nicely
[02:27] <_16aR_> crimsun: for example, my soft checks a custom env var to look for medias 
[02:29] <_16aR_> at runtime, it checks the DELTA_DATA env to prepend it before each media needed by the game (texture sounds, models)
[02:30] <_16aR_> so that it can load them
[02:46] <crimsun> _16aR_: that sounds like a runtime executable thing, not a packaging thing - or am I missing something?
[02:48] <_16aR_> crimsun:  yes, but without this env var , every launch of the prog and further developped programs will fail loading the media. quite annoying
[02:49] <crimsun> _16aR_: ok, confirm if I understand your statements.  You'd like a user-specific or global environment variable to be seeded at user login for your package?
[02:51] <_16aR_> crimsun: since every user could launch or develop an app, I think a global env would be cool
[02:51] <persia> _16aR_: perhaps the software could supply a default value for this variable in a global configuration script, which could be patched (if required) in packaging, and use the default variable if the environment variable is not configured?
[02:52] <_16aR_> but i may not know every aspect of packaging a distrib, so...
[02:52] <_16aR_> persia: yes. It's a kind of $PATH var
[02:53] <_16aR_> in fact, it is
[02:53] <_16aR_> it is a path where to look for files to load in the app
[02:57] <crimsun> persia's suggestion is worth investigating.
[02:58] <crimsun> e.g., conditionally source [well, '.' /etc/foo/bar]  and modify $PATH as appropriate
[03:00] <_16aR_> so it should be included in the libraries ?
[03:01] <_16aR_> by default, it looks in the . dir
[03:02] <_16aR_> otherwise it looks in the DELTA_DATA dir
[03:02] <crimsun> is this environment variable something you _want_ the user to set?
[03:03] <crimsun> i.e., if you're providing files that will be in $DELTA_DIR and hence will be needed, why not simply look there?
[03:07] <LaserJock> evening all
[03:34] <antioxid> i will compile email-claws, in repository is libetpan 0.48 , but 0.49 is needed
[03:34] <LaserJock> crimsun: all moved?
[03:34] <crimsun> mostly.
[03:38] <LaserJock> crimsun: is it nice so far?
[03:39] <crimsun> quite.  Had lunch with Scott(K) earlier this afternoon.  Finding all the free wifi spots in D.C.
[03:39] <LaserJock> awesome
[03:39] <LaserJock> what area of D.C. are you in?
[03:40] <crimsun> I live in MD, but I commute to NW D.C. and Baltimore.
[03:40] <ajmitch> hello crimsun, LaserJock 
[03:40] <crimsun> 'lo ajmitch 
[03:41] <LaserJock> I got to ride the subway a fair amount for the National American Chemical Society meeting last fall
[03:41] <ajmitch> I bet that was exciting ;)
[03:41] <LaserJock> I found a motel 6 out by the pentagon
[03:42] <LaserJock> and had to ride 20 min each way to the conference center in the middle of DC
[03:42] <crimsun> hehe
[03:42] <crimsun> yeah, I'm on Green/Yellow and Orange daily.
[03:42] <LaserJock> that motel 6 was $105/night
[03:44] <zul> hey
[03:44] <LaserJock> hi zul 
[03:45] <crimsun> hey zul, how's the young one?
[03:45] <LaserJock> well, I really can't imagine living in the DC area but it was fun riding around the subway for a week
[03:46] <zul> crimsun: good kind of cranky right now because he pulled out his feeding tube
[03:47] <LaserJock> yikes, is that easy to get back in?
[03:47] <zul> i cant do it, have to wait until my wife gets home
[03:47] <ajmitch> ouch
[03:48] <zul> yeah so he is crying every 2 minutes..
[03:48] <zul> its not like we dont feed him
[03:51] <LaserJock> but of course he thinks it's been days since you fed him last
[03:51] <zul> yeppers
[03:53] <crimsun> zul: ah.  And how are his folks doing?
[03:54] <zul> very tired...
[03:54] <crimsun> :-)
[03:55] <LaserJock> darn, my swap/resume is still messed up
[03:56] <LaserJock> my swap partition has a new UUID every time I reboot it seems
[03:57] <LaserJock> I hope somebody gets some use out of the switch to UUIDs because it's been nothing but trouble for me
[04:02] <luisbg> hey Jordan
[04:03] <luisbg> I see no purpose for UUID
[04:04] <crimsun> it works for a few limited use cases of mine
[04:04] <luisbg> using the location /dev/sda3 is much cleaner, and gives much more less problems
[04:04] <crimsun> e.g., I have a bunch of external usb drives
[04:06] <ajmitch> luisbg: just because it gives less problems for you, doesn't mean that it is better
[04:06] <ajmitch> I have SATA drives where the BIOS order is quite different from the kernel detection order
[04:06] <luisbg> ajmitch, it seams to give problems to LaserJock but I guess that if it's more problems for him, it doesn't mean it's worse
[04:06] <ajmitch> though I do use RAID on top of LVM for them (and so I can use the /dev/mapper/... syntax for filesystems)
[04:07] <ajmitch> the main reason was the switch from hdX to sdX
[04:07] <ajmitch> which really could get confusing when you have a mix of SATA & PATA devices
[04:08] <LaserJock> it does seem useful for often changing things, like USB sticks
[04:08] <luisbg> if I place the UUID in my laptop the kernel panics, just changing it to sdX location fixes it
[04:08] <luisbg> it's nice both things can be used
[04:08] <LaserJock> but I think it was Keybuk that was saying people shouldn't us /dev/sdX anymore
[04:09] <LaserJock> I'm not sure what else we're supposed to use, I'm not sure if LABEL= works everywhere UUID does and I'm not sure how I'm supposed to find what the LABEL is
[04:09] <ajmitch> vol_id?
[04:09] <LaserJock> so what if it doesn't have a label?
[04:10] <luisbg> gotta leave
[04:10] <luisbg> LaserJock, talk to you soon =)
[04:10] <luisbg> ciao ajmitch 
[04:10] <LaserJock> cya lucas 
[04:10] <LaserJock> luisbg rather
[04:11] <luisbg> ;) cya
[04:12] <ajmitch> LaserJock: I do confess to only using UUID for /boot
[04:13] <LaserJock> well, it *was* working for swap so I must have done something
[04:13] <ajmitch> cryptoswap? :)
[04:13] <LaserJock> but it's kinda difficult to know what all I need to change
[04:14] <ajmitch> the only reason the swap UUID shoudl change would be if mkswap was being run on startup
[04:14] <LaserJock> hmm
[04:14] <ajmitch> again, on my laptop I use the lvm name for swap
[04:14] <LaserJock> well, yes, that makes sense to me
[04:14] <LaserJock> but I don't understand why it would be running mkswap
[04:15] <LaserJock> I"m still afraid of LVM, I don't know that I'd be all that happy with lvm-by-default :-)
[04:16] <superm1> LaserJock, i'm joining in this conv a bit late, but is LVM supported in ubiquity's partman yet?
[04:16] <ajmitch> there's nothing to be afraid of :)
[04:16] <ajmitch> superm1: no
[04:16] <superm1> okay thats what i thought...
[04:17] <persia> LaserJock: LVM is tasty and good for you.
[04:17] <superm1> so any lvm-by-default spec would be a few releases away anyhow
[04:17] <ajmitch> yes
[04:18] <ajmitch> all this is in a spec somewhere
[04:22] <LaserJock> well, it seems too easy to make a mess with LVM
[04:22] <StevenK> How? I've not managed to tie myself in a knot with it.
[04:23] <superm1> my biggest worry is that its too easy to lose data when you start spanning it across multiple drives
[04:23] <superm1> whereas with mount points instead, you only lose a little
[04:23] <persia> superm1: No reason you can't use mount points AND LVM.
[04:23] <crimsun> that's a false sense of security, really.
[04:24] <StevenK> superm1: In servers, we use RAID 1 and LVM on top of that.
[04:24] <superm1> that would be the smarter way to go, but at that point why not RAID 0+1?
[04:24] <StevenK> With only 2 disks?
[04:25] <StevenK> These are 1RU rackmount servers.
[04:25] <superm1> ah right
[04:26] <StevenK> Then again, even with more than 2 drives, I can't see why to use RAID0+1.
[04:27] <LaserJock> well, I don't have much of a need for LVM
[04:27] <persia> StevenK: Depends on your IO and uptime requirements.  If you've large IO, and have high uptime requirements, it's useful (although most of the time RAID5+spare is a better allocation of 4 drives).
[04:28] <LaserJock> and I've blown away partitions and volume groups, etc. trying to figure things out
[04:28] <StevenK> LaserJock: Then your method of figuring stuff out is too destructive. :-P
[04:28] <LaserJock> StevenK: exactly
[04:28] <crimsun> he plays with lasers.  It's probably normal. ;)
[04:29] <LaserJock> so my cost/benefit hasn't really gone in favor of LVM
[04:29] <persia> LaserJock: With lvm-by-default, that would become somebody else's problem, and it would just work.
[04:29] <StevenK> Except when it breaks.
[04:29] <persia> right
[04:29] <ajmitch> the only time I've had issues with LVM like that, was due to my own stupidity & not checking before rm -rf 
[04:29] <LaserJock> well, it's lvm-by-default on Fedora/openSUSE that usually messes me up
[04:29] <ajmitch> ie, completely unrelated to LVM
[04:30] <chillywilly> hi
[04:30] <ajmitch> hello
[04:31] <LaserJock> if I had a real reason to use LVM I suppose I'd go ahead an figure it out
[04:32] <LaserJock> but I don't have multiple linux drive, or big drives
[04:33] <LaserJock> I think mostly I'm just an idiot with those kinds of things
[04:33] <ajmitch> hello Hobbsee 
[04:34] <LaserJock> since I seem to be the only one that has problems with it
[04:34] <persia> LaserJock: I doubt that: it's a different way of thinking about drives and data, and it really helps to have either several drives or a really big one that need management to learn.
[04:35] <Hobbsee> hi LaserJock!
[04:35] <Hobbsee> hi ajmitch!
[04:42] <LaserJock> hi Hobbsee 
[04:45] <nixternal> howdy
[04:45] <nixternal> I had to stop with the hola cuz LaserJock stole it from me :)
[04:45] <LaserJock> hola nixternal 
[04:45] <LaserJock> ;-)
[04:45] <nixternal> hehe
[04:47] <ajmitch> nixternal!!!
[04:48] <nixternal> ajmitch!!!
[04:48] <Hobbsee> it's the vista lover!
[04:48] <Hobbsee> !nixternal
[04:48] <ubotu> Oh no!  The pointy-clicky Vista lover has arrived!  He's rumoured to be giving out free money, too!
[04:48] <nixternal> I need to figure out how to afford some RDRAM and a new hard drive for this free p4 server I got
[04:49] <ajmitch> RDRAM? throw out that motherboard
[04:49] <LaserJock> I've got 3 computers at work with RDRAM
[04:51] <StevenK> Rambus, isn't it?
[04:52] <LaserJock> yeah, that's why my machines at work only have 256MB of it
[04:52] <ajmitch> expensive stuff
[05:05] <gpocentek> morning
[05:05] <LaserJock> tritium!
[05:05] <LaserJock> gpocentek!
[05:05] <tritium> Hi LaserJock :)
[05:05] <Hobbsee> hiya gpocentek!
[05:05] <gpocentek> hi LaserJock :)
[05:05] <gpocentek> hi Hobbsee, hi tritium 
[05:05] <tritium> LaserJock: congratulations are in order, yes?
[05:06] <tritium> hi gpocentek 
[05:06] <LaserJock> tritium: maybe ;-)
[05:06] <tritium> That's awesome, LaserJock.  Way to go :)
[05:06] <LaserJock> thanks
[05:08] <jsgotangco> what happened?
[05:08] <jsgotangco> --> still trying to wake up
[05:08] <tritium> Hey there, jsgotangco 
[05:09] <jsgotangco> hi!
[05:09] <ajmitch> hello jsgotangco, tritium 
[05:09] <tritium> ajmitch!
[05:16] <tritium> Buenas noches, amigos.
[05:16] <ajmitch> tritium: bye
[05:16] <tritium> Talk to you soon.
[05:16] <LaserJock> Treenaks: cya
[05:16] <LaserJock> blah
[05:16] <LaserJock> stupid xchat ;-)
[05:16] <LaserJock> tritium: cya
[05:16] <LaserJock> ajmitch: core-dev
[05:16] <tritium> ajmitch: late congrats for core-dev
[05:17] <ajmitch> rather late, I'm sure you've been around since he became core-dev :)
[05:18] <ajmitch> aw
[05:18] <tritium> No worries, ajmitch.  /me heads to bed...
[05:21] <ajmitch> bye!
[05:36] <persia> I'm filing removal bugs for packages removed from Debian.  Can anyone think of a reason we might want to keep these?  The only thing that's coming to mind for me is patent-related stuff for multiverse, but any other reasons I shouldn't file bugs would be welcome.
[05:36] <ceros> anyone here familiar with the freedesktop menu-spec and if debian supports it?
[05:37] <persia> ceros: Somewhat, and not officially, but most of the time.
[05:38] <ceros> persia: will it work for KDE and Gnome?
[05:39] <ceros> persia: should rephrase that, is it supported in KDE and Gnome?
[05:39] <persia> ceros: It should, but there may be some customisations to the menus (as we have in Ubuntu) that may cause some confusion.
[05:39] <persia> ceros: I think both upstreams strive for compatibility, but it's been a moving target until recently.
[05:40] <ceros> do you happen to know how kdevelop and kdesdk installs the submenus?
[05:40] <ceros> that's what I've been trying to figure out
[05:42] <persia> ceros: Not at all, sorry.  I'd guess that the contents of /etc/xdg/menus may be helpful, but I can't be sure.  Also, you might find something useful in /usr/share/desktop-directories/
[05:45] <ceros> thanks persia
[05:45] <ceros> i think i've  figured it out now
[05:46] <persia> ceros: Great!  How does it work?  (I mostly use GNOME or xfce menus, so I'm curious about KDE).
[05:46] <nixternal> persia: they tend to work with kde as well
[05:47] <LaserJock> it's basically the same
[05:47] <LaserJock> KDE just implements submenus
[05:47] <persia> nixternal: Right.  For .desktop files I'm confident about KDE: it's more the mechansim for building menus, default search paths, etc.
[05:47] <persia> LaserJock: Dynamically when the menu gets too large?  Is this in /etc/xdg/?
[05:48] <LaserJock> no
[05:48] <LaserJock> well, they aren't on until there is something in them
[05:48] <LaserJock> if I remember right
[05:48] <ceros> persia: let me make sure before i explain
[05:48] <persia> ceros: Thanks.
[05:48] <LaserJock> but like there is an Education/Science menu
[05:49] <persia> LaserJock: That sounds like an improvement.  My menus are a little crowded.
[05:49] <LaserJock> gnome specifically doesn't do that
[05:52] <ScottK> persia: About the removal bugs...  What would you think about sending the list to devel-discuss to see if anyone objects.
[05:52] <LaserJock> yeah
[05:52] <LaserJock> there has always been a bit of a philosophical element to that
[05:53] <persia> ScottK: I'd think it was a waste of time.  Things like exim (replaced by exim4) or 3ddesktop (dead upstream, no ubuntu uploads, beryl is better) are obvious.  When I trim a bit, a mail might be more useful.
[05:53] <LaserJock> i.e. Universe is the place where *everything* in free software can live
[05:53] <ScottK> persia: What is gained by removing them?
[05:53] <StevenK> Less archive space, for one.
[05:53] <LaserJock> I think some people in the past haven't wanted any packages removed
[05:53] <Hobbsee> ScottK: less bugs in the archive, less space
[05:54] <Hobbsee> er, more space
[05:54] <persia> LaserJock: I completely agree with *everything* in free software, but leftovers from package transitions (exim), things that just don't work in ubuntu (modutils), things that were renamed ages ago (laptop-mode), etc.  are just cruft.
[05:54] <ScottK> If it's buggy and broken, sure, but hard drive space is pretty cheap.
[05:54] <Hobbsee> ScottK: bandwidth is not
[05:54] <ScottK> True.
[05:54] <LaserJock> if nobody is using them and there aren't many of them than both arguments are somewhat mute
[05:54] <persia> ScottK: But triage time to chase bugs for things that we can't or don't care to support isn't cheap.
[05:55] <ScottK> Sure.
[05:55] <StevenK> ScottK: And when you're mirroring a complete shedload, it isn't fair for Ubuntu to turn around and say "You now need twice the space to mirror Ubuntu, sorry."
[05:55] <LaserJock> that is to say, if people are using them enough that there are bug reports you can hardly say "this package is dead"
[05:55] <ScottK> I think there is probably some stuff that's obvious cruft and should go, but if people still find stuff useful, just because Debian dumped it, doesn't mean we should.
[05:56] <ScottK> They sometimes remove stuff for reasons that would be irrelevant in Ubuntu.
[05:56] <persia> LaserJock: But they shouldn't be.  There were about 25 open bugs being ignored against "laptop-mode" a month or so ago.  About 5 of them applied to "laptop-mode-tools", and the rest were because the user installed the wrong package.
[05:57] <LaserJock> well, I don't know that we should be avoiding triage work by removing packages
[05:57] <persia> ScottK: Right.  Anything not obviously cruft or illegal to distribute (freecraft comes to mind), I'll not ask for removal without seeking a wider opinion.
[05:57] <persia> LaserJock: Not "avoiding triage work", but rather rendering it unnecessary by reducing user confusion.
[05:57] <ScottK> Sounds good to me.
[05:57] <LaserJock> note that I'm not opposed to removals, I'm just saying that some people (including Mark) think Universe should be a vast playground of all FLOSS
[05:58] <persia> LaserJock: Right.  As mentioned before, I agree with that :)
[05:58] <LaserJock> hence why we have apt-get.org stuff
[05:58] <persia> (and open REVU)
[05:58] <StevenK> Wah. ScottK, think about it. If Debian don't maintain it, we have to.
[05:58] <Hobbsee> of course...are we willing to maintain this stuff, which debian has removed?
[05:58] <LaserJock> even though that is largely dead/unmaintainable/uncool stuff
[05:58] <persia> Hobbsee: As long as there is an upstream, why not?
[05:59] <Hobbsee> persia: because upstream dont package it, and who's going to go and make sure they're all updated
[05:59] <LaserJock> Hobbsee: and the question is if we *have* to maintain it
[05:59] <persia> Hobbsee: cruft checkers :)
[05:59] <Hobbsee> LaserJock: well, someone has to, else it rots
[05:59] <LaserJock> that's the point
[05:59] <Hobbsee> and if debian isnt, then it becomes our problem
[05:59] <LaserJock> I've heard some people pretty much say that was fine
[06:00] <LaserJock> somebody might pick it up, who knows :-)
[06:00] <persia> LaserJock: Now there's where we differ.  Rotting is bad - either we should get it up to date (on a best-effort basis), or we don't want it.
[06:00] <LaserJock> that's were it would be nice to get a general opinion on Universe
[06:01] <LaserJock> or some direction at least
[06:01] <ScottK> Actually I think our quality problems are more with new stuff than old bitrot stuff.
[06:01] <StevenK> I agree with persia, for what it's worth.
[06:02] <ScottK> There's a balance here and there is no exact right answer.
[06:02] <ScottK> I think what persia said about removal of obvious cruft and ask about the rest is reasonable.
[06:02] <LaserJock> I just don't want there to be a big difference in expectation
[06:03] <ScottK> Not to mention Exim4...
[06:03] <StevenK> And all three are well maintained, so why kill them?
[06:04] <StevenK> Which means vi, kate, gedit and every other editor should be killed because emacs exists?
[06:04] <StevenK> There is the point of choice, and also one of where do we draw the line?
[06:05] <ScottK> Speaking of removals....
[06:06] <Hobbsee> LaserJock: as to whether it's the place for everything, or it's something that has some level of QA?
[06:06] <Hobbsee> LaserJock: afaics, canonical doesnt care about it to a great extent - as in, they dont support it
[06:06] <Hobbsee> of course, the quality of it does make a large part of the quality of ubuntu, by sheer package count
[06:09] <ajmitch> ScottK: and your testbuild of pypy worked?
[06:12] <Hobbsee> haha
[06:14] <ScottK> That's on the list for after I convince Hobbsee to upload my gnupg update (which will be after I make it work right).
[06:15] <Hobbsee> hah
[06:18] <ScottK> You laugh, but that one wasn't a joke.
[06:19] <Hobbsee> well, i realise that - but you're asking someoen to sponsor an upload, right after you admit to not test building..
[06:20] <ScottK> Sure.  I realize the theory isn't perfect, but I figured there was no downside risk on that one.
[06:21] <ceros> persia: the reason why there's submenus installed for kdevelop is because there are entries already specified for kdevelop under /etc/xdg/menus/kde-applications.menu
[06:21] <ceros> oh
[06:22] <ceros> persia:
[06:22] <ceros> persia: the reason why there's submenus installed for kdevelop is because there are entries already specified for kdevelop under /etc/xdg/menus/kde-applications.menu
[06:22] <Hobbsee> ScottK: :)
[06:23] <persia> ceros: Ah.  That makes sense.  Thanks.
[06:23] <ceros> persia: yep, they have an extra category which is X-KDE-KDevelopIDE
[06:24] <ceros> which is used with the kdevelop .desktop files
[06:24] <ceros> read up on http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html
[06:24] <ceros> and read the section titled "Merging"
[06:24] <persia> ceros: Right.  I know how it's supposed to work, just didn't know how KDE did it.  I'm glad to hear it's the sensible way.
[06:25] <ceros> one thing though, the spec says to put custom menu files under $XDG_CONFIG_DIRS/menus/applications-merged/
[06:25] <ceros> yet kde only offers /etc/xdg/menus/kde-applications-merged
[06:25] <ceros> is it the same for gnome?
[06:27] <ceros> by the way, this announcement was made on the fourth
[06:27] <ceros> this one: http://lists.debian.org/debian-devel-announce/2007/07/msg00000.html
[06:37] <LaserJock> bah, does anybody know of any good places to get clipart for linux?
[06:42] <ceros> i see that gutsy will use /etc/xdg/menus/applications-merged as far as kdebase-data is concerned
[06:42] <ceros> http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=kdebase-data&version=gutsy&arch=all
[06:43] <ceros> anyone here know if gnome will do the same
[06:43] <ceros> ?
[06:44] <LaserJock> ceros: what do you mean exactly?
[06:45] <ceros> LaserJock: what i'm trying to do with some packages i'm making is to provide a custom submenu for them
[06:45] <LaserJock> ok
[06:45] <ceros> for instance if a game has a gui configuration window and the main game launcher
[06:45] <ceros> i want to create a subment and add the appropriate links in that submenu
[06:46] <LaserJock> won't happen in Gnome
[06:46] <ceros> not even with gnome-menu?
[06:46] <LaserJock> no
[06:46] <ceros> why?
[06:46] <LaserJock> because Gnome doesn't like submenus
[06:47] <ceros> i take it you mean the Gnome developers, right?
[06:47] <LaserJock> and that's not really the way the XDG spec is designed
[06:47] <LaserJock> it has categories
[06:47] <LaserJock> and menu items fall into those categories
[06:48] <ceros> but the spec says "By convention, third parties may add new <Menu> files in this location to create their own sub-menus."
[06:49] <LaserJock> right, but that doesn't me Gnome has to honor that
[06:49] <LaserJock> *mean
[06:50] <LaserJock> hmm, it might work
[06:50] <ceros> so this means that gnome won't have custom submenus
[06:50] <ceros> huh?
[06:51] <LaserJock> in general Gnome doesn't do that
[06:51] <LaserJock> but I just tried some stuff locally
[06:51] <LaserJock> dropping something in ~/.config/menus/applications-merged
[06:52] <LaserJock> so I guess it's doable, I'm just not sure that Gnome likes people doing that
[06:53] <ceros> well, i would like to create packages that doesn't mess with a user's home path
[06:53] <LaserJock> exactly
[06:53] <ceros> when you say Gnome, are you referring to the developers or the program?
[06:54] <LaserJock> developers
[06:54] <LaserJock> that's why I said it appears to be doable (the programs work)
[06:54] <ceros> ok, well isn't this about Ubuntu and Debian
[06:54] <ceros> ?
[06:55] <LaserJock> why?
[06:55] <LaserJock> I thought it was about Gnome's implementation of XDG
[06:56] <calc> perhaps i should have stuck around and gotten bill to get rid of the debian spec and transition to xdg completely :\ oh well too late now
[06:57] <LaserJock> I'm really not sure why it's kept
[06:57] <ceros> what i'm after is finding a standard way to support custom submenus through different desktop environments
[06:57] <ceros> whether it be Gnome, KDE, Enlightenment, XFCE, etc
[06:58] <calc> LaserJock: well the main reason is not very many window managers supported and probably still don't support the fdo standard one
[06:58] <LaserJock> calc: but in general you can convert an xdg menu into many window manager's menus
[06:58] <calc> LaserJock: however it shouldn't be that hard to write a parser to convert from fdo standard to their window manager format
[06:59] <calc> LaserJock: true and that is the reason against there still being a debian format instead of just using fdo one
[06:59] <LaserJock> I think you can do it with openbox, enlightenment, fluxbox I'm pretty sure
[06:59] <LaserJock> and XFCE4, KDE, and Gnome have XDG support out of the box
[07:00] <LaserJock> so you're left with not that many you'd need to support
[07:00] <LaserJock> it'd be at least nice to see debian menu backseated for a failback
[07:00] <LaserJock> *fallback
[07:01] <LaserJock> ceros: just try it out, drop a .menu into /etc/xdg/menus/applications-merged/
[07:01] <LaserJock> and provide .directory files
[07:01] <ceros> k
[07:01] <calc> LaserJock: if you are a DD you could get the ball rolling :)
[07:01] <ajmitch> if you're not, you could just flame until it gets done!
[07:01] <calc> LaserJock: even if you aren't you could work on it ubuntu and get someone to apply it to debian packages :)
[07:01] <LaserJock> calc: unfortunately (or is that fortunately?) I'm not
[07:01] <calc> ajmitch: that doesn't work so well ;)
[07:02] <LaserJock> well, it doesn't require anything really
[07:02] <LaserJock> that's my point
[07:02] <LaserJock> other than DDs not saying "eww, we use debian menu not .desktops" when we give them one
[07:02] <LaserJock> :-)
[07:02] <ajmitch> calc: it could be entertaining though
[07:02] <LaserJock> mhm
[07:03] <ajmitch> debian doesn't have enough good-quality flamewars
[07:03] <LaserJock> I suppose I could do a blog/email debian-devel blitz
[07:03] <LaserJock> ;-)
[07:03] <calc> LaserJock: i doubt many would complain since most people use modern desktops
[07:03] <LaserJock> debian-menu is the suXor!!!
[07:03] <calc> LaserJock: i think its just bill that is stuck in < 2000 ;)
[07:03] <LaserJock> that should go over well, don't you think?
[07:04] <calc> to be fair i think that KDE didn't support fdo menu until 3.x
[07:04] <calc> so it wasn't able to be used until like 3-4 years ago ;)
[07:04] <ceros> calc: 3.2 actually
[07:04] <LaserJock> we've pushed a fair number of .desktops to Debian
[07:04] <calc> ceros: ah yea i thought it was after 3.
[07:04] <calc> er 3.0
[07:04] <LaserJock> I think mostly the Debian maintainers have responded well
[07:04] <calc> 3-4 years in debian time is a drop in the bucket ;)
[07:04] <calc> like 2 release cycles ;)
[07:04] <LaserJock> yeah
[07:05] <LaserJock> it's hard to turn the ship ;-)
[07:05] <calc> they didn't even officially ship amd64 port until ~ 3 years after its existence
[07:06] <ajmitch> it could be worse - it could be the windows release cycle
[07:06] <calc> debian was getting close
[07:06] <calc> they seemed to have figured out how to get it down to ~ 2 year cycles
[07:06] <calc> for a while the cycles were getting longer every release
[07:06] <ajmitch> 2 years is pretty good for those of us that like it on servers
[07:07] <calc> i like 6mo cycles
[07:07] <ajmitch> so do I
[07:07] <StevenK> LTS for servers, and new shiny bling on the desktop every 6 months.
[07:07] <ajmitch> but for server stuff, LTS
[07:07] <calc> i usually run dev version anyway, but i think i am going to stick with stable after all the problems with gutsy
[07:07] <calc> just do my dev work in a vm or chroot
[07:07] <LaserJock> I think I'd like 1 year cycles, but 6 months is ok too
[07:07] <ajmitch> unless I need specifically need something that's newer
[07:08] <StevenK> LaserJock: You don't have to upgrade ...
[07:08] <LaserJock> StevenK: development cycles, not upgrade cycles
[07:08] <LaserJock> it's constant deadlines, for me anyway
[07:08] <calc> ajmitch: i have to reinstall my box now apt-get dist-upgrade keeps oopsen my box
[07:08] <ScottK> Good night all.  I'm out of juice for the day.
[07:10] <LaserJock> cya ScottK 
[07:10] <ajmitch> calc: that's exciting
[07:11] <ajmitch> I generally find that *if* there's a problem like that, it can be worked around
[07:11] <ajmitch> but I tend not to upgrade as often as others
[07:12] <LaserJock> lol
[07:12] <calc> ajmitch: well i probably could mark the packages it happens on to hold but if apt-get oops my box something is very wrong with the kernel
[07:12] <LaserJock> look at what you did ajmitch 
[07:12] <ajmitch> haha
[07:12] <calc> ajmitch: or my system perhaps
[07:12] <calc> i think its something in the kernel though since it is reproducible
[07:12] <ajmitch> calc: generally, yes
[07:13] <calc> i'll probably know something more tomorrow I emailed BenC with the oops log
[07:14] <calc> it oops in do_utimes if i read the trace right
[07:15] <calc> i did a fsck -f on the fs to see if it was ok and it reported good
[08:24] <Fujitsu> calc: My kernel reproducably oopses when configuring various things like mysql-server-5.0. There are a number of bugs on it.
[08:24] <Fujitsu> I don't think reinstalling is likely to fix a kernel bug.
[08:35] <man-di> can somebody tell me how to force orig tarball inclusion with pbuilder? -sa doesnt seem to work no matter what I try.
[08:36] <DarkMageZ> man-di, in the .dsc file is the .orig.tar.gz listed?
[08:36] <man-di> DarkMageZ: no, but thats what I need
[08:36] <DarkMageZ> man-di, how are you creating the .dsc?
[08:36] <man-di> DarkMageZ: my last idea would be to vi *.dsc
[08:37] <man-di> DarkMageZ: pdebuild does that by calling dpkg-buildpackage
[08:37] <man-di> DarkMageZ: (this is with a binary+source upload)
[08:39] <man-di> I think I will just edit the .dsc manually
[08:39] <DarkMageZ> man-di, have you been poking around with the changelog file too much?
[08:40] <DarkMageZ> if you edit the .dsc manually then it will fail the gpg verification (only matters if you intend to get package to anywhere official)
[08:40] <man-di> aeh,
[08:40] <man-di> I meant .changes, not .dsc
[08:40] <DarkMageZ> what is the name of the orig.tar.gz and what is the line @ the top of the debian/changelog ?
[08:40] <man-di> DarkMageZ: the package is not signed yet, I will sign it afterwards
[08:41] <man-di> This is for a libapache-mod-jk backport for www.backports.org
[08:41] <man-di> and I need to do a source+binary+orig tarball upload
[08:42] <man-di> the problem is, the revision is -3~bpo.1
[08:42] <man-di> and pdebuild refuses to include the orig tarball in the resulting .changes file
[08:43] <DarkMageZ> hmm. backup what you've done and try debuild -S within the root of the altered source tree
[08:43] <mohammad> Hello, Is it possible for liblucene2-java which needs accepting java-sun license be merged to mutliverse instead of universe?
[08:43] <mohammad> http://packages.debian.org/unstable/text/liblucene2-java
[08:44] <man-di> DarkMageZ: the debdiff is really minimal, thats not the problem
[08:44] <gpocentek> Hobbsee: could you tell me how I could make KDE use ~/.bash_logout, or if there's something similar I could use?
[08:45] <man-di> DarkMageZ: I just dont wanna build the package in my normal system. I dont want to install Apache1 and Apache2 at once in my system
[08:45] <Hobbsee> gpocentek: thought it did, btw
[08:45] <Hobbsee> *tbh
[08:45] <man-di> mohammad: port it to java-gcj-compat-dev
[08:45] <gpocentek> looks like it doesn't (for me at least :p)
[08:45] <man-di> mohammad: thats the best thing for all
[08:46] <Hobbsee> gpocentek: then i have no idea :)
[08:46] <mohammad> man-di: I tested it with java-gcj-compat-dev. build failed.
[08:46] <gpocentek> Hobbsee: ok, thanks anyway
[08:46] <DarkMageZ> man-di, debuild -S doesn't cause the package to be built in the system. it just looks for the orig.tar.gz (to see if it is named right :P). then compares it to the changes and creates the .diff.gz & .dsc and signs it.
[08:46] <man-di> mohammad: how? log?
[08:47] <man-di> DarkMageZ: I know what it does, I use that since several years. The problem is that it doesnt build the package
[08:48] <DarkMageZ> then if you want to build the package within the pbuilder just run pbuilder build whatever.dsc
[08:48] <man-di> DarkMageZ: and I disabled signing with debuild long ago, I perfer to explicitely call debsign
[08:48] <man-di> DarkMageZ: thats waht I did, the problem is that pbuilder misses to include the orig.tarball in the .changes file
[08:48] <man-di> DarkMageZ: and yes I tried serveral usages with -sa
[08:49] <man-di> pbuilder seems to just ignore it, or I dont found the right way to tell it to pbuilder
[08:49] <dholbach> good morning
[08:50] <DarkMageZ> pbuilder will pull the orig.tar.gz if it's in the .dsc. so something is up with how that's being created
[08:50] <man-di> DarkMageZ: hmmm
[08:50] <mohammad> man-di: I tested it once and it failed, but I donot have the log right now. if you want to see the log file let me know I will run gutsy pbuilder locally again
[08:50] <man-di> thats good to know, thanks, DarkMageZ 
[08:51] <man-di> mohammad: it would be nice why it fails, then we can fix it
[08:51] <mohammad> man-di: ok i will build it again :)
[08:51] <DarkMageZ> man-di, what is the top line of the debian/changelog? and the name of the orig.tar.gz?
[08:53] <man-di> DarkMageZ: "libapache-mod-jk (1:1.2.23-3~bpo.1) etch-backports; urgency=low" and libapache-mod-jk_1.2.23.orig.tar.gz
[08:54] <DarkMageZ> hmm, that looks fine. hmm.
[08:54] <man-di> I edited the .changes file now manually, signed the package and uploaded and it seems to work too
[08:54] <man-di> DarkMageZ: I think my problem was that the initial .dsc dont included .orig.tar.gz
[08:55] <man-di> DarkMageZ: and pdebuild ignored -sa
[08:55] <man-di> I try debuild -S -sa ; pbuilder-etch build libapache-mod-jk_1.2.23-3~bpo.1.dsc now
[08:55] <mohammad> man-di: is there a simple way to log pbuilder output?
[08:56] <nixternal> pbuilder --buildlog logfile.tx
[08:56] <mohammad> thanks
[08:57] <nixternal> err, --logfile
[08:57] <nixternal> sorry about that
[08:58] <nixternal> that is how I run my pbuild script, that way there I can watch it and also have it logged
[09:01] <man-di> DarkMageZ: even the trick with "debuild -S -sa" doesnt work
[09:01] <man-di> DarkMageZ: I think its just a feature pbuilder doesnt have
[09:03] <man-di> persia: my hero
[09:04] <man-di> persia: you surely know this
[09:04] <persia> man-di: Warning: I've gone through 3 montors today, so I may stop being able to see you without warning :)
[09:04] <jekil> someone can review please? http://revu.tauware.de/details.py?upid=5896
[09:05] <man-di> persia: I want to build a package and upload source+binary+orig.tarball, version is -3. How do I force inclusion of .orig.tar.gz in the resulting .changes file?
[09:05] <man-di> persia: my current solution is: vi *.changes ; debsign; dput
[09:06] <persia> man-di: debuild -S -sa?  (also, use -v if the version changed significantly since the last upload).
[09:07] <man-di> persia: debuild -S -sa doesnt include the *.debs in the .changes
[09:07] <man-di> and I need to build it pbuilder to do big dependencies on apache1 and apache2
[09:07] <persia> man-di: Ah.  You're uploading to Debian then :)  Does debuild -sa work?
[09:08] <man-di> persia: in this case to www.backports.org
[09:08] <persia> man-di: Ah.  I'm not a pbuilder expert, but I'd suggest something like unrolling the tarball, using it as a chroot, and running debuild therein.
[09:09] <man-di> persia: pbuilder ignores -sa and I tried serveral ways to tell it to pbuilder
[09:09] <man-di> persia: you mean like pbuilder login
[09:09] <man-di> hmmm
[09:09] <man-di> not really nice but would work too
[09:09] <persia> man-di: Exactly.  (I use schroot / sbuilder, so I do schroot -c release & run debuild when the options I want don't pass well).
[09:09] <man-di> I think I will stay with the solution with editing .changes manually, its the smallest effort for me
[09:10] <persia> man-di: Makes sense.  That's why there's debsign :)
[09:11] <man-di> persia: I never sign with debuild
[09:11] <man-di> I like to have some control when I sign something
[09:11] <man-di> and I do debuild too often
[09:16] <DarkMageZ> oh, there's something that's been bothering me for a while. how do i do something equal to debuild -S without the signing?
[09:17] <persia> DarkMageZ: debuild -S -us -uc
[09:17] <persia> DarkMageZ: Or perhaps, rather, only -us (-uc is no changes, which may not also be what you want, although it often is for me).
[09:18] <DarkMageZ> that'll make it easier to remember. :)
[09:19] <man-di> DarkMageZ: or put this into ~/.devscripts
[09:19] <man-di> DarkMageZ: mkoch@lappi ~> grep uc .devscripts
[09:19] <man-di> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -uc -us -I.svn"
[09:20] <DarkMageZ> i like to decide just before running debuild. but thanks anyways.
[09:25] <jekil> why some packages like http://ftp.debian.org/debian/pool/main/s/snort/snort_2.3.3-14.diff.gz  make modification outside /debian ?
[09:26] <Hobbsee> becuase they were bad, and didnt use a patch system, probably
[09:27] <persia> jekil: Alternately, they may be very old.
[09:27] <persia> jekil: If you're patching an update, please try to maintain the maintainers patch system (even when it's bad).
[09:27] <StevenK> Hobbsee: Meh. Patch systems aren't required.
[09:27] <jekil> yeah, i am repackaging it with new version 2.6
[09:28] <jekil> persia: i thinks that because the package i very is very old its better if i remake it
[09:28] <jekil> current snort version is 2.6
[09:28] <persia> jekil: I only recommend that if Debian has no maintainer.  Otherwise you may annoy someone, which might make it harder to work with them later.
[09:29] <jekil> persia: debian dont accept the policy of new 2.6
[09:29] <jekil> persia: so.. tha package is very old
[09:30] <jekil> (and bugged)
[09:31] <persia> jekil: Still, you might want to get in touch with Javier before changing the patch system.
[09:33] <jekil> persia: but this isn't a new package? outside patch system. because debian package now is 2.3 and current snort is 2.6
[09:35] <persia> jekil: New version of an existing package.  If the Debian maintainer chooses to update the package, and you've changed the patch system, merging is hard.  Also, if you've added a useful patch, and the Debian maintainer doesn't want to switch to your patch system, it may be difficult for them to extract it.
[09:37] <jekil> persia: actually in debian cannot be updated
[09:37] <persia> jekil: Why is that?  Also, if it cannot be updated in Debian, why can it be updated in Ubuntu?
[09:38] <jekil> persia: because snort is GPL but  rules license is proprietary
[09:38] <jekil> persia: debian want to ship snort with rules
[09:38] <jekil> but it's not needed
[09:38] <mohammad> man-di: the log file of lucene2 is ready: http://www.iqc.ca/~mderakhshani/transfer/lucene2-log.txt
[09:38] <persia> jekil: OK.  So, ubuntu should ship snort without rules?
[09:39] <jekil> persia: yes, because they are like antivirus rules, changes are frequently, the people manage thet ourself
[09:41] <persia> jekil: That sounds like a significant change.  Given the policy differences, it may be slightly more acceptable to adjust the patch system (but I'd still be against it).  Separately, you might want to ask for feedback from ubuntu-motu@l.u.c regarding such a change, as users will now be expected to generate their own rules, rather than having  default set (which may require additional documentation, etc.).
[09:43] <jekil> persia: thanks
[09:45] <persia> jekil: Alternately, you might consider having a snort team in ubuntu, and generating a standard set of GPL'd 2.6 rules as a bzr branch in LP, and including that in your package.  This might also allow Debian to adopt it.
[09:47] <mohammad> I am going to sleep. anyone who is interested to know why build of lucene2 using java-gcj-compat-dev fails , please take a look at http://www.iqc.ca/~mderakhshani/transfer/lucene2-log.txt
[10:00] <man-di> eeak, I remember that issue of mohammed with lucene2
[10:02] <jekil> i have a great problem with a software that i am packaging
[10:02] <jekil> 1) the tar.gz contains .svn directory
[10:03] <jekil> 2) the name of tar.gz and the directory inside isn't the package name
[10:04] <Hobbsee> jekil: rename the .tar.gz
[10:04] <Hobbsee> and probably remove the .svn directory from the tarball
[10:05] <tsmithe> so, my source package wired provides a couple of global libraries in /usr/lib, and i would like to create a libwired? package for them. however, they are not built with a SONAME version, which makes this tricky (and scary ABI-wise)... what do you folks suggest i do?
[10:05] <jekil> Hobbsee: this can be done? i read that i can't modify the tar.gz
[10:06] <Hobbsee> jekil: you can in some circumstances
[10:06] <Hobbsee> jekil: see the packaging guide
[10:06] <jekil> Hobbsee: ok, thanks
[10:06] <man-di> tsmithe: put them into /usr/lib/wired
[10:07] <man-di> tsmithe: and tell people not to link them 
[10:07] <Hobbsee> jekil: but you dont need to rename the directory inside - dpkg already does that, whenever it extracts the source
[10:07] <RAOF> Such as when upstream is stupid or forgetful :).  Hey Hobbsee!
[10:07] <tsmithe> ok. but then wouldn't i have to add /usr/lib/wired to ld.so.cache? how would i tell wired where to find them?
[10:08] <man-di> tsmithe: depends on how they are loaded
[10:08] <Hobbsee> hiya RAOF!
[10:08] <jekil> Hobbsee: great, thanks
[10:08] <tsmithe> man-di, hmm?
[10:08] <tsmithe> if i tell configure to put all libraries into /usr/lib/wired, the wired-specific files get put into /usr/lib/wired/wired, which is ugly.
[10:08] <man-di> tsmithe: are they directly linked or loaded at runtime?
[10:08] <tsmithe> directly linked
[10:09] <man-di> tsmithe: take a big stick and hit upstream hard
[10:09] <tsmithe> trust me, i've tried
[10:09] <man-di> hehe
[10:09] <tsmithe> it's so hard to get to them - as far as i can see they don't have a mailing list, the irc channel is always dead, the guy i sent an email to never got back to me. but development still continues... somehow.
[10:09] <man-di> tsmithe: this means you need to handle this in the package
[10:09] <tsmithe> yea
[10:10] <tsmithe> (for the 0.4 release, they were quite amenable)
[10:10] <man-di> by libwired1 .. 2 .. 3 ... etc
[10:10] <man-di> and always conflicting with the older ones
[10:10] <tsmithe> lovely
[10:10] <man-di> and put them into /usr/lib
[10:10] <tsmithe> yep
[10:11] <man-di> so when you are at libwired20 you will conflict with 19 other libwiredX packages
[10:11] <man-di> isnt that funny?
[10:11] <tsmithe> not really
[10:11] <man-di> :-)
[10:11] <tsmithe> hehe
[10:11] <man-di> tsmithe: so try the big stick again
[10:11] <tsmithe> that conflict line will get pretty large...
[10:11] <tsmithe> yeah... i just want it done!
[10:12] <man-di> tsmithe: and you will need to do a lot of testing to see if you need to increment the X or not
[10:12] <tsmithe> of course, i'm aware abi changes are tricky to spot
[10:12] <man-di> yes
[10:13] <man-di> thats why C/C++ libs are such bitches
[10:13] <man-di> well, Java jar are too
[10:13] <man-di> and probably other formats too
[10:13] <tsmithe> heh
[10:13] <tsmithe> yay
[10:15] <tsmithe> persia, hi. i notice you weren't able to find the source package. i think joejaxx had the web structure non-browsable, for reasons of his own. looks like crimsun found it, though, so it's all good. what's the process now?
[10:15] <tsmithe> *source package for ubuntustudio-screensaver
[10:15] <man-di> hmm, I know the solution for lucene2/mohammed: build the package on a single core machine
[10:16] <tsmithe> man-di, is it not possible to restrict a process to one core?
[10:16] <tsmithe> (or is that not the issue?)
[10:16] <persia> tsmithe: Wait ;)  An archive admin should look at it in the next couple days.
[10:16] <tsmithe> ahh that's super :)
[10:18] <man-di> tsmithe: when you know a way to tell GCJ to put all his threads on the same cpu/core
[10:18] <persia> tsmithe: You can check the queue from https://bugs.launchpad.net/~ubuntu-archive/+subscribedbugs, but my experience is that the archive admins don't respond well to poking.
[10:18] <man-di> tsmithe: I dont think thats possible whithout configuring the kernel in a special way
[10:18] <tsmithe> persia, yeah. i'll just wait :)
[10:18] <tsmithe> man-di, oh right ok. yay again
[10:28] <tsmithe> what are .la files for? do i need them?
[10:28] <tsmithe> i heard they were obsolete
[10:29] <man-di> tsmithe: libtool needs them when you wanna load libs at runtime
[10:30] <man-di> libltdl to be more clear
[10:30] <tsmithe> ok. so i'll include them
[10:30] <man-di> tsmithe: for plugins thats useful
[10:30] <tsmithe> yes
[10:30] <man-di> and tsmithe for linking with libtool when compiling
[10:30] <tsmithe> yeah.
[10:30] <persia> tsmithe: Contraily, I'd recommend removing them unless you really need them (your application doesn't work otherwise)
[10:31] <tsmithe> hmm
[10:31] <tsmithe> i'll see if it works without
[10:31] <persia> tsmithe: Be sure to check plugins: as man-di said, sometimes you need it.
[10:32] <tsmithe> yes
[10:35] <tsmithe> man-di, if i'm doing libwired1, would i have libwired-dev or libwired1-dev?
[10:36] <man-di> tsmithe: I would go for libwired-dev as long as the API is stable at least
[10:36] <tsmithe> ok
[10:36] <man-di> libwired1 is about ABI compatibility, libwired-dev about API compatibility
[10:37] <man-di> thats a bit simplified but mainly it
[10:37] <man-di> and libwired-dev makes your work a bit easier
[10:38] <man-di> libwired1-dev only really makes sense when you wanna have different version of wired in the archive to compile against
[10:38] <tsmithe> makes sense
[10:38] <man-di> e.g. when you wanna have 2 API-incompatible version of wired in the archive
[10:38] <tsmithe> yes
[10:38] <tsmithe> i don't think that's going to happen
[10:38] <man-di> as I dont think you will need that. stay with libwired-dev
[10:38] <tsmithe> excellent
[10:39] <jekil> someone can review please? http://revu.tauware.de/details.py?upid=5896
[10:39] <tsmithe> the debian library packaging guide recommends for plugins a lib*-runtime package. would a libwired-runtime or libwired-plugins package be useful in this case, considering there are plugins?
[10:40] <persia> tsmithe: Are the plugins for wired, or libwired?
[10:41] <tsmithe> hmm. i think just for wired. how could i check?
[10:41] <persia> More generally, libfoo-runtime is a good place for utility code that people may want, but don't need, libfoo-plugins is a good place for library extensions, and foo-plugins is a good place for general application plugins
[10:42] <tsmithe> ok. i think i'll put them in wired-plugins
[10:42] <persia> tsmithe: Are the plugins useful with libwired installed, but not wired?  If yes, then you might want libwired-plugins.  If no, just wired-plugins (this is *much* more common)
[10:43] <tsmithe> i think they are useful with just libwired installed, looking mainly at the file names: "libWiredReverb.so", for example. so i guess libwired-plugins
[10:44] <persia> tsmithe: Ummm..  the filenames are probably not a good indication.  Where is the plugin-loading code?  Do the plugins extend the API, or extend the interface?
[10:45] <persia> s/interface/user interface/
[10:45] <tsmithe> hehe ok. i'm gonna go check out the sources, and get back to you
[10:46] <persia> tsmithe: Another way to ask the question is: would an application developer working on something that linked against libwired (but not wired) use the plugins?
[10:49] <tsmithe> well, having looked at the sources, most seem to extend the api, and i could see a developer wanting to link against them
[10:49] <persia> tsmithe: OK.  libwired-plugins might be right.  Thanks for checking carefully.
[10:49] <tsmithe> no problem :)
[10:49] <tsmithe> but now, as they have no versioning again, do i want libwired1-plugins?
[10:49] <persia> tsmithe: Yes (because they provide .so files)
[10:49] <tsmithe> yes
[10:49] <tsmithe> cool
[10:49] <tsmithe> i just really don't like the idea of having a package in the archive depend on libwired1, and then for me to come along and upload a new wired source package... what happens to the old libwired1, if i have libwired2 in the new sources?
[10:50] <tsmithe> it doesn't disappear, does it?
[10:51] <persia> tsmithe: That's the reason for the versioning: the old binary libwired1 stays around.  New builds get libwired2 (because of libwired-dev depending on libwired2 and providing a libwired2 interface).  When everything is rebuilt, libwired1 will be removed as cruft.
[10:51] <tsmithe> aha thanks
[10:51] <RAOF> Hey, how come gst-plugins-farsight got syncd without a sync bug on LP?
[10:51] <persia> tsmithe: Just remember, only do libwired1 -> libwired2 if you really need it: as long as it's compatible, stay with libwired1.
[10:52] <persia> RAOF: Poor record keeping?  The archive-admins aren't perfect :)
[10:52] <tsmithe> persia, of course
[10:53] <RAOF> Also, I thought it would be a merge...
[10:53] <persia> RAOF: If something important was dropped, we can always restore with ubuntu1 :)
[10:55] <RAOF> Yeah.  Hey, I wonder if that fixes my bug against debian's -farsight :)
[11:01] <tsmithe> hmm... now i look at them again, they all seem to provide functionality and extend the UI. so wired-plugins after all, i guess
[11:30] <jussi01> good morning all
[11:30] <tsmithe> morning jussi01 
[11:31] <jussi01> heya tsmithe
[11:31] <tsmithe> yo
[11:50] <tsmithe> should i have my libwired1 package provide libwired?
[11:50] <tsmithe> if it conflicts against all older versions in future, but api stays the same, then that would seem ok. but then again, if api changes...
[11:50] <tsmithe> maybe it's safer not to
[11:54] <persia> tsmithe: Safer not to: that's more useful when transitioning from libwired to libwired0 (or the like).  Also, what's the upstream soname?  Do you want libwired1?  libwired0?  libwired47?  It's nice to use something with some relation (although many maintainers don't: this is not a requirement in any way).
[11:56] <tsmithe> well, there are two libraries shipped, so the sonames don't necessarily reflect upon the package name, although both contain libWired. i don't think i need to provide libwired, in this case.
[12:06] <persia> Do we still have php4 on purpose, or is it just leftovers?  (note: I'm not filing a removal, just looking for a pointer to any documentation for someone else's removal plans)
[12:08] <bigon> RAOF: about gst-plugin-farsight I've already made a package
[12:09] <bigon> RAOF: http://revu.tauware.de/details.py?upid=5890
[12:10] <persia> bigon: Does this represent a new upstream, or just a merge from Debian?
[12:10] <bigon> persia: merge from debian
[12:11] <persia> bigon: Ah.  Merges sent to REVU sometimes get lost.  Next time, please consider submitting a merge bug against the package in Ubuntu and attaching a debdiff against debian to process the merge.
[12:12] <tsmithe> does my library package need to call ldconfig? i've seen others that don't
[12:12] <persia> More generally, REVU should be used when 1) the package is not in Debian or Ubuntu, or 2) this is a new upstream version not yet in Debian or Ubuntu
[12:12] <man-di> tsmithe: that should be autimatically added by some debhelper tool
[12:13] <tsmithe> oh right ok
[12:13] <tsmithe> hmm
[12:13] <bigon> persia: ok :)
[12:13] <persia> bigon: Thanks.  Sorry for the confusion.
[12:20] <persia> Anyone here familiar with cipe & openvpn?  If so, would you mind taking a look at debian bug 428977 to see if we are similarly affected?
[12:20] <ubotu> Debian bug 428977 in ftp.debian.org "RM: cipe -- RoQA; orphaned; abandoned upstream; incompatible with all Debian kernels; obsoleted by openvpn" [Normal,Open]  http://bugs.debian.org/428977
[12:23] <Fujitsu> persia: Why wouldn't we be? We have a newer kernel than Debian, and I don't see how the others issues wouldn't be relevant to us.
[12:23] <persia> Fujitsu: That's my thought, but I'm not great with kernel interfaces, so I wanted a second opinion.
[12:24] <persia> Fujitsu: Separately, based on conversation about 6 hours ago (if I remember correctly), it was suggested that packages only be removed when they were truly broken, rather than just useless.
[12:25] <Fujitsu> That sounds a little odd.
[12:27] <persia> Fujitsu: The idea is that maybe there is a user somewhere, and maybe someone will want to become a new upstream.
[12:27] <Fujitsu> After 5 years? Hm...
[12:28] <persia> Fujitsu: This spring I updated a dead upstream package that hadn't been touched in 3 years, so it's not outside the realm of possibility.
[12:29] <Fujitsu> persia: I guess... But what counts as broken?
[12:29] <Fujitsu> cipe won't work. Is that broken?
[12:30] <persia> Fujitsu: Yep.  Thanks.  I'll go request removal then :)
[12:30] <Fujitsu> Good idea. Removal of useless/broken stuff is good.
[12:30] <persia> Fujitsu: On the other hand, if it installed, worked, and was just full of security holes and not recommended, we should keep it.
[12:30] <Fujitsu> I suppose so!
[12:35] <persia> Fujitsu: Just to repeat some of the earlier discussion, and explain why: imagine the result of discussions regarding which text editors could be considered useless...
[12:36] <persia> Fujitsu: Why stop there: nobody really needs a CLI editor, when we have so many good GUI editors :)
[12:36] <Fujitsu> Ah yes, definitely.
[12:38] <persia> man-di: It's a joke.  I could count the number of times I've used a GUI text editor on my fingers (well, I might need a toe or two).
[12:38] <Fujitsu> One of the other techs at school is most irritated that we don't have a GUI for managing the firewall rules on the Internet gateway. That CLI is just so evil.
[12:38] <tsmithe> in not totally sure what to do about lintian "E: libwired1: no-shlibs-control-file" errors. i've gone through the library guide, and the policy manual as referenced, but i don't really see what i'm doing wrong
[12:38] <tsmithe> what do i need to do to fix it?
[12:38] <persia> tsmithe: Does using the -iIv flags give you any useful guidance?
[12:39] <coNP> Is it possible to fix a "please sync" bug for a non-MOTU (e.g., bug 122018)?
[12:39] <ubotu> Launchpad bug 122018 in wajig "please sync wajig 2.0.37 from debian" [Unknown,Fix released]  https://launchpad.net/bugs/122018
[12:39] <man-di> persia: I guessed that, but even some jokes need some kicks :-)
[12:39] <tsmithe> persia, not really, i've tried as suggested in the manual, section 8.6
[12:40] <luisbg> hey tsmithe 
[12:40] <persia> coNP: Yes.  Just subscribe U-U-S rather than U-A to get MOTU approval.
[12:40] <luisbg> hey persia 
[12:40] <persia> luisbg: Hi
[12:40] <tsmithe> hi luisbg 
[12:40] <luisbg> =)
[12:40] <luisbg> are you guys talking about the uploaded packages (waiting for archive admin approval)
[12:40] <tsmithe> nope
[12:40] <coNP> persia: what is U-A? :) By the way to fix a bug (debian -> ubuntu) it should be patched.
[12:40] <luisbg> and the screensaver is pending of tsmithe giving the url
[12:40] <coNP> So in fact this should be a merge I guess.
[12:40] <tsmithe> luisbg, no crimsun found it :)
[12:41] <persia> luisbg: coNP U-A: ~ubuntu-archive: The Ubuntu Archive Administrators
[12:41] <tsmithe> we're talking about libwired1's shlibs files
[12:41] <luisbg> tsmithe, but I don't see it uploaded
[12:41] <tsmithe> luisbg, the archive admins check it out :)
[12:41] <luisbg> tsmithe, the archive admins are very busy
[12:41] <luisbg> let's see how that goes
[12:42] <luisbg> it can take weeks if they don't see it as priority
[12:42] <persia> coNP: If there are no Ubuntu changes, and we want all the Debian changes, a sync is good.  If there are Ubuntu changes, we'd need to merge.
[12:42] <tsmithe> luisbg, it's ok - i'm on it :)
[12:42] <coNP> persia: we need to introduce ubuntu changed, because ubuntu differs from debian  (to fix a bug)
[12:42] <luisbg> tsmithe, good to know =)
[12:42] <luisbg> persia, you on it too :P
[12:42] <tsmithe> he doesn't need to be
[12:42] <luisbg> persia, did joejaxx granted you access to the ubuntu studio devel channel?
[12:42] <persia> coNP: That's a merge then :)
[12:43] <persia> luisbg: I can't do anything else at this point, so I'm not important.
[12:43] <persia> luisbg: grant access?  It's just /join, no?
[12:43] <luisbg> persia, you still are important :P not because of this, because of the rest
[12:43] <luisbg> persia, yes, try to join
[12:44] <persia> luisbg: My client says I'm joined.
[12:45] <luisbg> LOL, I don't see you there
[12:45] <luisbg> tsmithe, how is wired going?
[12:45] <luisbg> persia, are you in the ubuntu devel mailing list?
[12:45] <persia> luisbg: Not sure.  Probably.  Why?
[12:46] <tsmithe> luisbg, fine. just wondering about "no-shlibs-control-file" errors
[12:46] <luisbg> persia, since it's moderated I don't know if a reply I've sent has gone through or not 
[12:47] <luisbg> tsmithe, ahhh
[12:47] <persia> luisbg: Check the archives: https://lists.ubuntu.com/archives/ubuntu-devel/2007-July/thread.html
[12:49] <luisbg> hasn't been aproved and through
[12:50] <luisbg> :(
[12:50] <luisbg> it makes a discussion go slow if everybody statements must be approved
[12:51] <persia> luisbg: use ubuntu-devel-discuss to discuss the discussion on ubuntu-devel - the moderation is considerably lighter
[12:51] <Fujitsu> luisbg: That's what IRC's for!
[12:53] <luisbg> Fujitsu, LOL not when you need the big guys participate
[12:53] <luisbg> to participate*
[12:54] <persia> luisbg: They also use IRC
[12:54] <Fujitsu> luisbg: I see them more often on IRC.
[12:54] <luisbg> persia, yes but is harder to grab them and get them all together in the same discussion
[12:55] <StevenK> I didn't think devel-discuss was moderated.
[12:55] <persia> StevenK: subscribers only
[12:56] <StevenK> Ah
[12:56] <persia> (non-subscribers are subject to moderation - usually takes 2-3 days)
[12:58] <luisbg> there have been ubuntu members waiting for approval for a month now :S
[01:01] <coNP> Hey, StevenK, do you have some time now to review my openbox package? I don't want to annoy you, if you have it somewhere at the end of your TODO list, is fine for me... :)
[01:03] <StevenK> coNP: Yup, sure.
[01:04] <luisbg> when is the next community council meeting?
[01:04] <coNP> luisbg: still TBA, I'm afraid
[01:05] <luisbg> TBA?
[01:06] <luisbg> to be assigned?
[01:06] <coNP> to be announced
[01:06] <persia> luisbg: There are sometimes delays or missed meetings around the sprint - things should get back to normal thereafter.
[01:07] <luisbg> cool
[01:07] <luisbg> meanwhile it's not this weekend
[01:07] <luisbg> I can make it
[01:07] <luisbg> =)
[01:07] <coNP> luisbg: the later you get approved as a member, the later it expires... :)
[01:08] <tsmithe> heh
[01:08] <luisbg> coNP, it expires?
[01:08] <tsmithe> after a year
[01:08] <coNP> in two years, yea
[01:08] <tsmithe> o i thought it was one
[01:09] <coNP> maybe one
[01:09] <luisbg> LOL, didn't knew that
[01:09] <tsmithe> well, you can get it renewed
[01:09] <luisbg> but you can become a candidate again after it expires right?
[01:09] <coNP> it was two years last time
[01:09] <luisbg> if they approved you the first time, unless you quit your projects
[01:09] <luisbg> you will continue being accepted
[01:09] <seb128> hi
[01:10] <luisbg> hey seb128 
[01:10] <luisbg> persia and tsmithe, you coming to the next community council meeting to say I deserve being a member?
[01:10] <seb128> could anybody do an emerald and a heliodor rebuild, they still use libwnck18
[01:10] <luisbg> LOL
[01:10] <tsmithe> luisbg, sure
[01:10] <luisbg> tsmithe, awesome
[01:10] <luisbg> seb128, have you reported a bug in launchpad?
[01:10] <persia> seb128: Do we not like bug 124385?
[01:10] <ubotu> Launchpad bug 124385 in emerald "Packages to remove from Gutsy" [Wishlist,Confirmed]  https://launchpad.net/bugs/124385
[01:11] <luisbg> bbl guys
[01:11] <seb128> persia: I've not looked at bug, just to http://people.ubuntu.com/~ubuntu-archive/NBS/libwnck18
[01:11] <luisbg> persia, you haven't said yes to talking good about me btw
[01:11] <seb128> persia: 12 minutes ago, ok ;)
[01:11] <StevenK> That was the bug I just filed.
[01:12] <persia> luisbg: Sorry - hunting a bug :)  Depends on when it's scheduled.
[01:13] <seb128> persia, StevenK: thanks
[01:20] <seb128> could you rebuild sear also so libatlas-cpp-0.6-0c2a can be cleaned
[01:21] <StevenK> seb128: Waiting on the Debian maintainer for that.
[01:21] <seb128> and gnome-chemistry-utils gchempaint?
[01:22] <StevenK> I think they both failed to build.
[01:23] <StevenK> seb128: Are you going on a purging run?
[01:23] <seb128> StevenK: trying to cleaning the NBS list
[01:24] <StevenK> I've been doing that for days. :-)
[01:24] <seb128> StevenK: good ;)
[01:24] <seb128> StevenK: why do you wait for the Debian maintainer to rebuild sear?
[01:24] <seb128> StevenK: nothing prevent to upload a build1 version now and sync when there is a new revision
[01:25] <StevenK> seb128: Because I thought he would be quicker than this. :-)
[01:25] <persia> seb128: the DM is usually in this channel, and just as likely to rebuild as any of the rest of us :)
[01:26] <man-di> seb128: sear is a bitch, I'm debian maintainer of it
[01:27] <man-di> seb128: I'm waiting for two library transitions in Debian to be able to update it.
[01:27] <seb128> ok
[01:34] <persia> nevermind: it's in multiverse after all...
[01:35] <dholbach> motus can do multiverse no problem
[01:35] <persia> dholbach: Yep :)
[01:35] <dholbach> :-)
[01:36] <persia> I just didn't think the source for vmware-player was actually open.
[01:40] <persia> Hmm..  OK.  Any suggestions on rebuilding a package in multiverse to update the library dependencies when there's no source in the source package?
[01:48] <Fujitsu> persia: Run away screaming.
[01:49] <persia> Fujitsu: Perhaps, but I'd prefer not to carry libssl097 without debian support, especially as we've got libssl098 for almost everything else...
[01:49] <persia> Fujitsu: Someone built it, and someone allowed it in multiverse, so there should be some way to maintain it.
[01:50] <Fujitsu> persia: Ask upstream?
[01:50] <persia> Fujitsu: Maybe.  There's a lot of static libs that come with the package - perhaps I can work out something with those...
[01:51] <Fujitsu> persia: They don't have to have source.
[01:51] <persia> Fujitsu: Really?  Do we have any other examples of these monstrosities?
[01:51] <tsmithe> flashplugin-nonfree?
[01:52] <Fujitsu> persia: eagle comes to mind.
[01:53] <Fujitsu> tsmithe: That's a rather different case.
[01:53] <tsmithe> oh ok
[01:53] <persia> tsmithe: That's just an installer - not a problem.
[01:53] <tsmithe> right
[01:53] <persia> Fujitsu: Hrm.  I still don't like it, but if it's not only one package, I'm less motivated to complain
[01:54] <tsmithe> man-di, i uploaded wired 0.5+dfsg1-1 to mentors. i don't know what to do about the shlibs error, having tried a number of things, but the package works as it is, builds ok over here, and seems to be quite clean apart from that.
[01:54] <man-di> tsmithe: please mail me the link of the dsc file and I will look over the weekend into it and probably sponsor it
[01:55] <persia> tsmithe: If you're pushing wired to Debian, may I archive the REVU upload?
[01:55] <tsmithe> persia, there's a revu upload? sure! go ahead :)
[01:55] <persia> tsmithe: Thanks.
[01:55] <tsmithe> man-di, thank you - what was the e-mail address again?
[01:56] <persia> tsmithe: Done (also, everyone's email address is in LP)
[01:56] <tsmithe> ahh good point
[01:58] <StevenK> seb128: gchempaint uploaded, looking at gnome-chemistry-utils now
[01:58] <seb128> StevenK: thanks
[02:03] <man-di> tsmithe: konqueror@gmx.de
[02:03] <tsmithe> man-di, sent :)
[02:03] <tsmithe> thanks
[02:04] <ScottK> Good morning all.
[02:04] <tsmithe> morning ScottK 
[02:05] <DarkSun88> Hi all
[02:06] <persia> ScottK: Hi.  The only package I wasn't sure of for removals was newlib (removed from Debian as it has no reverse-depends and was not useful for a system with an installed kernel).  I'm not sure it's worth a mail for one package, so perhaps we can just leave it?
[02:08] <ScottK> persia: I'm fine with leaving it.
[02:18] <xxxxx1> morning all!
[02:32] <ScottK> jdong: Ping
[02:33] <DarkSun88> Tha package texmaker is fakesync?
[02:40] <persia> DarkSun88: It looks to me like a merge (needs dh_iconcache).  Separately, what does 1.6 get us that 1.5 doesn't have?  At this point, we don't need to merge non-bugfix updates unless we so desire.
[02:41] <DarkSun88> Ok
[02:45] <Hobbsee> persia: it's still way before feature freeze though
[02:46] <persia> Hobbsee: Sure, but are merges still mandatory?  I thought we considered at this point, to make sure nothing broke, and we got useful features.  I'm against a flood, but don't see any reason not to grab most of it.
[02:47] <Hobbsee> uh, yes they are
[02:47] <persia> ("this point" being between DebianImportFreeze" and "UpstreamVersionFreeze")
[02:47] <Hobbsee> it's only when it hits upstream version freeze and such that it's bug fixes only
[02:48] <persia> Hobbsee: Ah.  Hmm.  That's annoying.  I'll go file another couple hundred sync bugs then...
[02:48] <Hobbsee> i'm not sure why DIF is so early
[02:48] <Hobbsee> heh
[02:48] <Hobbsee> well, if there's reason to, then that's probably a good idea
[02:49] <persia> Hobbsee: There must be some reason for DIF: I thought it was to give us time to finish the transitions, clean up unmetdeps, do coding for the features we wanted, etc.  I'm not yet completely convinced (unless you'd be processing all the syncs :) )
[02:50] <Hobbsee> persia: may well be
[02:50] <persia> Hobbsee: Who might have an authoritative answer?
[02:50] <Hobbsee> persia: wlel, yeah, i think it is to do with the unmet deps and that kind of stuff - and to be able to bring new packages to fix such things
[02:50] <Hobbsee> ask in #ubuntu-devel
[02:50] <Hobbsee> probably pitti or someone
[02:50] <persia> Hmm..
[02:53] <guardian> hi, i have a noob question related to alsa: where to start if i want to compile 1.0.14 from source, targetting feisty ?
[02:53] <guardian> please
[02:56] <persia> Hobbsee: OK,  Now I'm sure I'm not convinced :)
[02:58] <ScottK> persia: Sounds to me like "Ooohhh.  That new release looks shiny and wonderful." is sufficient reason at this point.
[02:59] <persia> ScottK: I'd agree with that, but someone should look at it to decide it's shiny and wonderful, rather than just reviewing the MoM output.
[03:07] <Hobbsee> persia: since when are debian uploads reflective?
[03:07] <Hobbsee> "ooh, shiny..."
[03:07] <persia> Hobbsee: :)
[03:08] <Hobbsee> :)
[03:25] <crimsun> guardian: err...
[03:25] <crimsun> guardian: do you mean simply compiling it, or do you mean creating a Debian package of it?
[03:26] <guardian> running it on my own box
[03:26] <guardian> went to the alsa web site yesterday but doc links were outdated or gave 404
[03:26] <guardian> or i did not search well :/
[03:29] <crimsun> guardian: it's literally as straightforward as `sudo aptitude install pbuilder devscripts && dget http://archive.ubuntu.com/ubuntu/pool/main/a/alsa-driver/alsa-driver_1.0.14-1ubuntu1.dsc && cp /usr/share/doc/pbuilder/examples/pbuilder-distribution.sh ~/pbuilder-feisty && mkdir -p ~/pbuilder/result && ~/pbuilder-feisty create && ~/pbuilder-feisty build alsa-driver_1.0.14-1ubuntu1.dsc
[03:30] <crimsun> the two debs you need end up in ~/pbuilder/result/
[03:31] <crimsun> if you're quite lazy, you can simply grab the 1.0.14-1ubuntu1 debs that were built this morning
[03:32] <crimsun> you'll also need do to similarly for the alsa-lib and alsa-utils source packages.
[03:38] <guardian> well gonna save this command line
[03:39] <guardian> i was afraid of having to look for kernel patches corresponding to my exact kernel version or such
[03:39] <guardian> i don't know alsa at all: i don't know how it integrates with the kernel and what are the roles of the various libs
[03:40] <crimsun> well, do you want an overview of it generally or an overview of Ubuntu-specific packaging of it?
[03:40] <guardian> crimsun: you mentioned .debs built this morning, will they work on feisty ? i thought ubuntu would start supporting 1.0.14 in gusty
[03:41] <guardian> both would be nice :)
[03:41] <guardian> both overviews that is
[03:41] <crimsun> guardian: the alsa-base and linux-sound-base debs for gutsy will work unmodified in feisty, yes.
[03:41] <guardian> ok
[03:41] <guardian> good to know
[03:43] <crimsun> ALSA's actually fairly straightforward.  There are kernelspace and userspace portions.  The Ubuntu alsa-driver source package (derived from Debian's source package of the same) builds three binary packages: alsa-source, alsa-base, and linux-sound-base.  You only need the latter two, because our kernel (linux-image-2.6foo) provides the equivalent of what is generated from the first binary package, alsa-source.
[03:44] <crimsun> Thus, linux-image-2.6foo and alsa-source both provide the kernelspace portion, which pokes your audio hardware.
[03:45] <crimsun> The Ubuntu alsa-lib source package (again, derived from Debian's) builds numerous binary packages, most important of which are libasound2 and libasound2-dev.  The former is the critical userspace library that all native ALSA apps use at runtime; the latter is used during compilation of said native ALSA apps.
[03:47] <crimsun> Very generally, a native ALSA app is written against the [newest]  alsa-lib API.  When you use an ALSA app, it speaks to this library, which hooks into the driver (the kernelspace portion).
[03:48] <crimsun> In this light, the Ubuntu alsa-utils source package (also derived from Debian's) is simply another set of ALSA applications, since it needs libasound2-dev to build (thus needing libasound2 to run).
[03:49] <crimsun> Same applies for the alsa-tools source package.
[03:49] <jekil> someone can suggest me a good rtfm for build meta packages?
[03:51] <persia> jekil: it's just a package with no meaningful content: /usr/share/doc/package/ and a control file.  Towards what end are you developing a meta-package?
[03:52] <jekil> persia: i dont known how to write the rules file, i am building a series of package in ubuntu stuio style
[03:54] <persia> jekil: Ah.  For rules, I'd suggest CDBS, but you could probably get away with just using dh_installdocs if you want to do it manually.  Take a look at your sample package.  Also, I'd suggest putting all the meta-packages you need in a single source, to save effort.
[03:55] <jekil> persia: thanks, yes i use a single source
[04:03] <porthose> could you point me to a good CDBS guide
[04:04] <persia> porthose: google for CDBS Documentation, and use the duckcorp link.
[04:04] <ScottK> porthose: Google cdbs documentation and click on the first link.
[04:04] <ScottK> ;-)
[04:04] <porthose> thanks
[04:06] <dholbach> did everybody add a license notice to their scripts in the ubuntu-dev-tools branch?
[04:06] <dholbach> if so, it'd be nice if somebody checked it out and uploaded it
[04:21] <shawarma> dholbach: motu-sru are people who decide if an sru is ok or not, or does it involve actual work? :)
[04:21] <persia> shawarma: I can't speak for him, but some people willing to actually process uploads would be great :)
[04:22] <dholbach> shawarma: I meant -uvf
[04:22] <dholbach> oh my god
[04:22] <shawarma> I see..
[04:22] <persia> dholbach: No, it's all good.  The sru team needs help too :)
[04:22] <shawarma> dholbach: motu-uvf are people who decide if an sru is ok or not, or does it involve actual work? :)
[04:22] <shawarma> Er..
[04:22] <shawarma> "if an uvf is ok or not" of course.
[04:23] <dholbach> . o O { I'm glad I'm not the only one }
[04:23] <shawarma> heh.
[04:23] <dholbach> yes, we have a procedure for that, where we check the changelog diff and a diffstat
[04:23] <persia> Doesn't the last member of the UVF team to approve need to upload as well?
[04:23] <dholbach> to get a rough idea what the changes are about and how big they are
[04:24] <dholbach> and if we can have LP bugs that get fixed by that upload we prefer it even more :)
[04:24] <dholbach> shawarma: thanks for letting me know
[04:24] <shawarma> dholbach: I think I understand the evaulation process involved. I'm just curious if that is all that's needed.
[04:25] <dholbach> yes, that's all that's needed
[04:25] <dholbach> https://wiki.ubuntu.com/FreezeExceptionProcess#head-9c768217b322f8567d24d91647eaf0a256a73046
[04:25] <shawarma> Wicked.
[04:27] <dholbach> can you follow up on the thread and say that you'd be interested?
[04:27] <dholbach> we want to have a few people nominated, so we can set up a poll on LP
[04:28] <shawarma> dholbach: Sure. I also just applied for the team on lp..
[04:28] <dholbach> right, saw that :)
[04:28] <dholbach> thanks for offering to help out
[04:32] <zul__> dholbach: how much time do you have to put into the uvf stuff?
[04:33] <dholbach> quite a bit
[04:33] <dholbach> but in the end - with 5 members of the team it went much quicker and better
[04:33] <dholbach> I think we agreed on 2 ACKs in a 5 member team, so that was fine
[04:37] <jekil> how i can create control file for a meta package that give me this error?http://rafb.net/p/toKqzH30.html
[04:37] <jekil> this is the rules http://rafb.net/p/ttRBY242.html
[04:38] <StevenK> dholbach: Nominate oneself how?
[04:38] <dholbach> just follow up on the list
[04:38] <dholbach> and we'll add you to the poll
[04:39] <dholbach> thanks a lot StevenK
[04:41] <Hobbsee> we have a poll about that now?
[04:41] <pochu> StevenK: or maybe apply to the team too (since it's moderated...)
[04:41] <Hobbsee> oh neat
[04:42] <pochu> Hobbsee: not yet. There's a week for people to step up.
[04:42] <Hobbsee> sorry, as in, we have nominations for it
[04:47] <guardian> crimsun: many thanks for the detailed explanation, sorry i was afk
[05:05] <yamal> I uploaded sabnzbd to revu, but the *_source.changes was put in incoming/rejected. What to do?
[05:06] <axxo> bribe higher placed officials
[05:07] <Hobbsee> !revu
[05:07] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[05:07] <Hobbsee> yamal: are you in the group listed in that link?
[05:10] <yamal> Hobbsee: if you mean the "Contributors of packages for ubuntu universe" then yes. Joined few days ago
[05:10] <Hobbsee> right
[05:10] <jekil> anyone can review please? http://revu.tauware.de/details.py?upid=5896
[05:11] <yamal> axxo: who to bribe ;)
[05:13] <Hobbsee> yamal: er, me, i guess
[05:15] <yamal> thanks... any clue/reason why it ended up there in the first place?
[05:18] <Hobbsee> nope
[05:18] <Hobbsee> just that it's a bit strange at times
[05:41] <coNP> Can bug 90120 be solved by uploading the package that is provided on the website of pgadmin3 to ubuntu? Is something else needed?
[05:41] <ubotu> Launchpad bug 90120 in pgadmin3 "New version of pgadmin3 available" [Wishlist,Confirmed]  https://launchpad.net/bugs/90120
[05:45] <Kano> hi, is it known that the feisty package for beryl lacks the beryl-xgl binary?
[05:46] <geser> coNP: have you tried if the source builds in a gutsy pbuilder?
[05:47] <coNP> I'm trying it right now
[05:47] <coNP> I was going to ask first if it is possible at all
[05:48] <geser> Kano: yes
[05:48] <Kano> geser: and is it too complicated to add it?!
[05:48] <geser> coNP: do you know if the packaging is based on the Debian one?
[05:49] <coNP> seems so
[05:50] <geser> Kano: I don't remember the reason exactly, but AFAIR it didn't get packaged because one was in hurry and possible also get beryl into main and beryl-xgl would stay in universe anyway
[05:51] <Kano> it is in universe
[05:51] <Kano> it is kinda stupid to have xgl and no beryl-xgl binary
[05:52] <geser> yes, it didn't get promoted into main at the end and stayed in universe
[05:52] <Kano> could nobody fix that issue
[05:53] <Hobbsee> now?  no.
[05:57] <geser> has beryl any future? I know that there is some merging between beryl and compiz but don't know how the result will look like
[05:57] <Hobbsee> geser: compiz fusion is the merge, i think
[06:15] <bmm> Any MOTU: ccbuild is looking for it's second advocate, if you have time please take a look at http://revu.tauware.de/details.py?upid=5889 and post your comments
[06:55] <elektranox> can somebody review my package? :)
[07:01] <xxxxx1> elektranox, paste the revu link
[07:02] <xxxxx1> :)
[07:02] <elektranox> http://revu.tauware.de/details.py?upid=5256
[07:09] <cbx33> hey all
[07:10] <nixternal> howdy
[07:10] <cbx33> hey nixternal 
[07:10] <cbx33> long time dude
[07:10] <cbx33> how ya been?
[07:10] <nixternal> busy busy busy
[07:10] <nixternal> and you?
[07:11] <cbx33> yeh more of the same
[07:11] <nixternal> trying to learn Python, which is going OK right now, and doing the KDE 4 packaging..fun stuff
[07:20] <ScottK> nixternal: There's an O'reilly book by that title that I recommend.
[07:20] <ScottK> err....
[07:21] <ScottK> almost that title
[07:21] <ScottK> "Learning Python"
[07:21] <nixternal> I don't have that one...I got the one cbx33 recommended me though "Beginning Python"
[07:22] <cbx33> nixternal, how are you finding it
[07:22] <cbx33> I'm gonna be running those lessons soon :p
[07:22] <nixternal> I can't wait for those...the book is good because it teaches...I also have Python in a Nutshell and Programming Python as backups
[07:23] <nixternal> I am going to get the Learning Python one right now on Amazon, as I also want to get the O'Reilly Regular Expressions book
[07:23] <cbx33> cool
[07:23] <cbx33> well if anyone can help with setting up the environment
[07:24] <cbx33> I can start them earlier
[07:24] <nixternal> there is another book I wanted to get, and now I can't remember what it was
[07:25] <ScottK> nixternal: Dive Into Python is also decent and Free (in fact I think it may already be installed in your Ubuntu system).
[07:25] <geser> I've "Core Python Programming" here
[07:25] <nixternal> I have dive into python electronically
[07:25] <cbx33> geser any good
[07:25] <cbx33> ?
[07:25] <ScottK> That's a good one to start with although somewhat dated in some respects now.
[07:25] <ScottK> That was to nixternal
[07:25] <nixternal> ScottK: I noticed that it is dated
[07:26] <nixternal> I find the most difficult stuff, for some reason, iterations..I am used to C/C++/Java iterations
[07:26] <geser> cbx33: I've got time to read it yet, but it has a good review, over 1000 pages and covers also Python 2.5
[07:26] <cbx33> awesome
[07:27] <geser> I haven't *
[07:27] <ScottK> nixternal: It takes some getting used to.
[07:27] <geser> but the parts which I already looked at are quite good
[07:27] <geser> there is also a free chapter of it
[07:27] <cbx33> geser link?
[07:29] <geser> cbx33: http://corepython.com/ and then "Sample chapter" on the left side
[07:29] <cbx33> cool
[08:08] <AnAnt> can anyone review this package: http://revu.tauware.de/details.py?upid=5901
[08:11] <icf7> AnAnt: Using patches instead of modifying the Makefile directly would simply maintaining
[08:12] <icf7> AnAnt: Same with the .desktop file
[08:12] <AnAnt> ok
[08:12] <AnAnt> will work on that
[08:17] <icf7> AnAnt: I like your comment in line 2 of debian/rules ;)
[08:19] <AnAnt> icf7: I didn't put that comment, it comes by default 
[08:20] <AnAnt> icf7: should it be removed ?
[08:21] <icf7> AnAnt: No, no problem at all, just funny
[08:21] <AnAnt> doh I forgot how to make patches for dpatch system !
[08:22] <ScottK> AnAnt: man dpatch-edit-patch
[08:23] <icf7> AnAnt: I'm not a MOTU, but except direct editing instead of patches, I only miss an icon
[08:24] <AnAnt> icf7: huh ?
[08:24] <AnAnt> icf7: I get the icon in Applications
[08:26] <icf7> AnAnt: sorry, my bad. It's alright, but not scalable
[08:26] <AnAnt> icf7: cannot cure that
[08:27] <icf7> AnAnt: No problem, shouldn't hinder anything. You may want to ask the icon's creator for a scalable version later, but that's unimportant
[08:31] <ScottK> bmm: Uploaded and archived with one trivial adjustment.  Thank you for your contribution.
[08:35] <eagles0513875> do we have any debuggers here
[08:35] <eagles0513875> cuz i have a really cool debugging program i just found out about in a magazine
[08:41] <icf7> eagles0513875: This channel's members are the best debuggers I know of. They even find all the errors, fully automated ;)
[08:41] <eagles0513875> really thats kool but what if ur an ordinary programmer that helps debug these programs and doesnt have the automation
[08:42] <ScottK> Same thing here too, really.
[08:43] <eagles0513875> ok im just trying to make peoples lives easier scott
[08:43] <ScottK> OK.  Then do it with Free/Open software.  The last thing we need it more proprietary tools.
[08:45] <eagles0513875> ScottK: it is free if not for commercial use
[08:46] <icf7> eagles0513875: He meant free as in freedom.
[08:46] <ScottK> That's not Free Software
[08:46] <ScottK> what icf7 said.
[08:46] <eagles0513875> ok
[08:46] <eagles0513875> ill just stop trying to push it
[08:47] <ScottK> Good plan.
[08:47] <eagles0513875> lol
[08:48] <bmm> ScottK: thanks for uploading ccbuild, I'll fix the tabs->spaces thing locally without an upload, so it's fixed the next time I do something with it. Thanks!
[08:49] <ScottK> No problem.  Thank you for your contribution.
[09:15] <jekil> hello
[09:39] <AnAnt> Hello, can someone please REVU: http://revu.tauware.de/details.py?upid=5903 , I've modified it to use the dpatch system.
[09:40] <ScottK> AnAnt: Was thwab-lib (1.0-1) uploaded to Debian?
[09:41] <AnAnt> ScottK: no
[09:41] <AnAnt> ScottK: thwab-lib doesn't exist in Debian yet
[09:42] <ScottK> Then your changelog entry for the current version in debian/changelog should be the only one.  What you have now looks like an Ubuntu update to a Debian package.
[09:42] <AnAnt> ok
[09:48] <AnAnt> ScottK: ok, new upload is on http://revu.tauware.de/details.py?upid=5904
[09:50] <ScottK> AnAnt: I don't have a lot of time at the moment.  Given your interests, I thought you might be interested in a new Arabic font that was just uploaded for Gutsy: https://launchpad.net/ubuntu/+source/ttf-scheherazade
[09:50] <geser> is this the first package for Ubuntu (or Debian)?
[09:51] <AnAnt> ScottK: I know about it
[09:51] <ScottK> AnAnt: OK.
[09:51] <AnAnt> geser: yes first package
[09:51] <AnAnt> ScottK: the packager contacted me
[09:51] <AnAnt> ScottK: and I tried it
[09:51] <ScottK> AnAnt: How is it?
[09:51] <AnAnt> ScottK: he has another package that will depend on that font
[09:51] <ScottK> I see.
[09:52] <AnAnt> ScottK: well, I dunno Urdu or so, but I was interested in its abilities to display Qur'an (as it has special font requirements) and it was alright (there is no complete solution so far anyways)
[09:53] <ScottK> I see.  Is it oriented towards Urdu then?  
[09:53] <AnAnt> ScottK: no, it is not oriented towards Urdu (it was just an example)
[09:53] <ScottK> Ah.
[09:54] <AnAnt> ScottK: it is an arabic fonts , but Urdu, arabic, pushto, farsi have a lot of common characters
[09:54] <ScottK> Right.  Pakistani Punjabi too.
[09:54] <AnAnt> ScottK: the author says that this font can display all those fonts
[09:54] <AnAnt> ScottK: oops sorry, the author says that this font can display characters for all those languages
[09:55] <ScottK> Right.
[09:55] <AnAnt> ScottK: err, Pakistani is Urdu, it's their formal language at least
[09:55] <ScottK> Not what I meant.
[09:56] <ScottK> Punjabi is used both in India and Pakistan, but in India they use a different alphabet entirely even though it's the same spoken.
[09:56] <AnAnt> oh
[09:56] <ScottK> Sometimes it's called Western Punjabi and Eastern Punjabi too.
[09:59] <AnAnt> well, what I know is that in each of Pakistan and India, they have too many languages
[09:59] <AnAnt> ScottK: so ppl from different areas would talk to each other in English !!!!
[10:00] <AnAnt> ScottK: I saw that myself
[10:00] <ScottK> They can speak to each other just fine.  It's written communication that's the problem.  The switch has come since the partition in 1947.  I don't recall which changed.
[10:01] <ScottK> Of course English is the common language there for most anyway.
[10:02] <AnAnt> I mean, I saw 2 indians who were from India, but from different areas within India, they talked to each other in english, so when I asked, I was told that India has too many languages, and they don't understand each other
[10:02] <geser> AnAnt: you should add perl to the Depends for the binary package
[10:03] <AnAnt> geser: oh, because of the other scripts ?
[10:03] <AnAnt> geser: thanks for pointing that out !
[10:03] <geser> yes
[10:04] <geser> you will find perl installed on nearly all systems but it's only important
[10:04] <AnAnt> yeah, you're right, I missed that 
[10:05] <AnAnt> geser: uploading now
[10:09] <cbx33> hey all
[10:09] <cbx33> what's the smallest linux device people know of....hand held that you can still do things like create python programs actually on the device?
[10:10] <ScottK> Specifically Python or just create programs?
[10:11] <cbx33> well
[10:11] <cbx33> install stuff
[10:11] <cbx33> and hack around on it
[10:11] <cbx33> not it plugged into a pc
[10:11] <AnAnt> geser: ok, it's on http://revu.tauware.de/details.py?upid=5906
[10:11] <man-di> cbx33: there are some mobile phones with linux inside
[10:15] <ScottK> cbx33: http://www.nokiausa.com/770
[10:16] <cbx33> yeh saw that
[10:16] <cbx33> can you code actually on the thing
[10:16] <cbx33> or just outside of it?
[10:17] <ScottK> Dunno as I haven't actually tried.  You can get to a root shell with effort and from there you can do anything I would assume.
[10:43] <imbrandon> cbx33, you cxan actualy code on it( 770 ) and the 800
[10:43] <imbrandon> s/cxan/can
[10:43] <imbrandon> they are nice actualy, based on debian even too
[10:43] <cbx33> imbrandon, W000000000000000000000000T
[10:43] <cbx33> dude
[10:43] <cbx33> where have you been?
[10:43] <cbx33> cool
[10:43] <cbx33> I may get one 
[10:43] <cbx33> battery life seems a bit bad though?
[10:44] <cbx33> 3 hours?
[10:44] <imbrandon> nah, its better than advertised, ask seveas about his, he seems to lvoe it
[10:44] <imbrandon> love*
[10:44] <cbx33> oooh
[10:44] <cbx33> maybe I'll get one
[10:44] <cbx33> replace my aging dell axim x3i
[10:44] <cbx33> which is win2003
[10:44] <cbx33> imbrandon, you still up for helping me out?
[10:44] <imbrandon> he has a 770, and the 800 seem to be even better as far as screen and proc power and bat life
[10:44] <cbx33> or are you super busy
[10:44] <cbx33> not today obviously
[10:45] <cbx33> wow
[10:45] <cbx33> awesome
[10:45] <imbrandon> yea i can, just not this weekend
[10:45] <cbx33> cool
[10:45] <cbx33> oh dude
[10:45] <cbx33> I've been like frantic
[10:45] <cbx33> had soooo many people interested
[10:45] <imbrandon> on my way to an amusement park with my gf and kids
[10:45] <cbx33> in the lessons
[10:45] <imbrandon> in a few minutes ;)
[10:45] <cbx33> awww cool
[10:45] <imbrandon> but yea i'm definately still down to help out when i have a moment to get with you
[10:46] <cbx33> awesome
[10:46] <imbrandon> what times gmt are good for you generaly?
[10:46] <cbx33> we'll have to schedule a time
[10:46] <cbx33> tell ya waht
[10:46] <cbx33> mail me your availability next week
[10:46] <cbx33> and I'll try to work into that
[10:46] <imbrandon> kk sounds good\
[10:46] <imbrandon> kk , they are here, got to run, ttyl
[10:46] <cbx33> np
[10:49] <xxxxx1> bye all
[11:24] <jikanter> \quit
[11:48] <sacater> pochu: /me waves
[11:54] <siretart> mwolson: hey there
[11:55] <mwolson> hi siretart
[11:55] <siretart> mwolson: see your inbox :)
[11:55] <siretart> just hit C-c C-c
[11:56] <mwolson> sweet!
[11:57] <mwolson> siretart: can that branch be set up to send commit notifications?  since Romain asked for commit messages of my initial git repo for emacs22, I image he'd like them for this one as well
[11:57] <mwolson> s/image/imagine/
[11:59] <siretart> mwolson: yes
[11:59] <siretart> mwolson: on https://code.launchpad.net/~ubuntu-elisp/emacs/ubuntu, there is a tab on the left side, where you can subscribe
[12:00] <siretart> you can even specify if you want just notifications, or diff of the changes
[12:01] <siretart> mwolson: IIRC, you wanted to remove yourself from the CC of the bugs?
[12:02] <mwolson> siretart: right
[12:03] <siretart> mwolson: ok, I'll upload to gutsy after your push, ok?
[12:03] <mwolson> alright, i'll get on that right away
[12:04] <mwolson> it looks like emacs21 didn't add the Cc, so perhaps it should just be removed; sending to ubuntu-motu might make people mad at us :^)
[12:04] <siretart> right
[12:05] <siretart> we'd rather want to point ppl to visit https://launchpad.net/ubuntu/+source/emacs22/+filebug
[12:05] <siretart> which will work as soon as the package enters gutsy
[12:09] <persia> Is there a timeframe for emacs22 inclusion?  There's a heap of updates in the U-U-S queue related to emacs22, but I'm not sure about uploading them before we actually have an emacs22 package.