[01:02] <SolarWar2> Hi, I am looking for someone to review (or advocate) my package here: (http://revu.ubuntuwire.com/details.py?package=qlix) :)
[01:02] <RainCT> good night
[02:42] <j-b> hello
[03:33] <tbielawa> Is it a requirement to be a full fledged MOTU to join the motu launchpad group? Or just an interest in becoming one?
[03:34] <StevenK> tbielawa: The former
[03:34] <tbielawa> Thanks
[03:37]  * wgrant woiuld have thought that being a fully fledged MOTU and being a member of ~motu were the same thing.
[03:48] <ScottK> NCommander: Do you have anything to do with armel?
[03:48] <NCommander> ScottK, I'm bootstrapping Ubuntu-armel ...
[03:48] <NCommander> Does that count?
[03:48] <wgrant> Isn't Nokia already doing that?
[03:49] <wgrant> And wasn't Canonical considering it?
[03:49] <NCommander> I haven't heard on either count
[03:49] <ScottK> No, I want a Debian armel porter.  My klamav problem on arm got solved by someone queing it for a retry (that succeeded without me asking).  Now it's stuck 'building' for 3 days on armel.
[03:49] <NCommander> I'm at the point that I'm just about fire up buildd and start building the base system
[03:49] <wgrant> NCommander: There is a Nokia ARM port of Ubuntu available, I'm sure.
[03:49] <ScottK> I've seen public mention that Ubuntu will support armel.
[03:49]  * NCommander shrugs
[03:49] <NCommander> I still have a MIPS board ...
[03:51] <wgrant> m68k!
[03:51] <wgrant> There must be something even more obscure.
[03:52] <NCommander> sh4
[03:53] <wgrant> That works.
[03:53] <NCommander> wgrant, while I would consider an m68k port, we'll be +2 past intrepid by time it compiles
[03:54]  * NCommander would consider kfreebsd-i386
[03:54] <NCommander> or if anyone has some alpha hardware lying around ;-)
[03:54] <StevenK> Why?
[03:54] <NCommander> I actually perfer the freebsd system over LInux, but I hate their packaging
[03:55] <ScottK> I've got an old Mac LC III with 68030 (and the 68040 add-in board) that last I checked still worked.
[03:55] <NCommander> You seriously want Ubuntu for m68k?
[03:55] <NCommander> (considering its glibc is stalled at 2.5, it would probably be ugly)
[03:56] <ScottK> No.  Just mentioning obscure hardware.
[03:56] <NCommander> heh
[03:56] <awmcclain> Is there a better tool than pbuilder for testing a package that's a daemon?
[03:56] <NCommander> awmcclain, what are you trying tod o?
[03:57] <awmcclain> I'm repackaging a web service, and I just want to make sure that everything is working properly.
[03:57] <NCommander> awmcclain, use a normal chroot
[03:57] <awmcclain> (this is for a ppa)
[03:57] <awmcclain> rather than pbuilder login?
[03:58] <NCommander> I'm too tired to give you a well thought out and reasonable answer ;-)
[03:58] <NCommander> ScottK, maybe if I can fix my alpha box, I'll use that as my weekend project
[03:59]  * NCommander would use Debian alpha as a base, then just selectively build enough packages to create an ubuntu chroot and work from there
[05:45] <Awsoonn> Is there a method of updating man pages that I might want to know?
[05:46] <j-b> anyone maintaining VLC around here ?
[05:47] <wgrant> j-b: I touch it sometimes.
[05:59] <j-b> wgrant: ok, VLC is in 0.9.0-test3 and should be release during august, any hope of getting in Intrepid or should we package it oursleves ?
[06:00] <wgrant> j-b: I plan to get 0.9.0 into Intrepid.
[06:00] <wgrant> Although I thought it was meant to be out by now.
[06:00] <j-b> we are in feature freeze
[06:00] <j-b> and we are in test3
[06:00] <j-b> planning is to release on mid-august
[06:01] <wgrant> OK, that should work.
[06:01] <j-b> but, we might shift a bit
[06:01] <j-b> but, I think that from test4, it should be quite usable (kind of RC1)
[06:01] <wgrant> It will be out before ~October?
[06:01] <j-b> wgrant: I am asking since debian has frozen VLC (Lenny has 0.8.6)
[06:01] <j-b> wgrant: oh, yes
[06:02] <j-b> wgrant: october should be 0.9.1-alpha1
[06:02] <coppro> there should totally be a package for the Windows version of Mono, under Wine
[06:02] <NCommander> coppro, there is, its called the mono installer ;-)
[06:02] <wgrant> j-b: Famous last words... but yes, I intend to look at 0.9.0 at some point, probably talking to Debian about it.
[06:03] <j-b> wgrant: we have some Nightly builds for HH
[06:03] <j-b> but I am asking since there is a big shift from VLC 0.8.6 to 0.9.0, especially since the new default GUI is Qt
[06:04] <wgrant> Oh.
[06:04] <j-b> not all the distro are doing it the same way
[06:04] <j-b> SuSE is doing vlc-noX, vlc, qvlc and wxvlc
[06:05] <wgrant> I presume Debian will throw it into experimental or at least their svn at some point soon.
[06:05] <j-b> since interface are just some modules (.so)
[06:05] <j-b> wgrant: ok, so I should see with xtophe and sam, I guess (debian maintainers)
[06:06] <j-b> wgrant: other question, what is the Ubuntu policy for mp3lame, x264 and mp4-encoder ?
[06:07] <wgrant> They're in multiverse.
[06:07] <wgrant> I have x264 enabled in Ubuntu VLC, while Debian doesn't.
[06:08] <j-b> multiverse, ok. Where is VLC  ?
[06:08] <wgrant> VLC, as it needs x264.
[06:08] <wgrant> Er.
[06:08] <j-b> it doesn't need it
[06:08] <wgrant> Multiverse, as it needs x264.
[06:08] <wgrant> Doing too many things.
[06:08] <wgrant> It does if I want to have x264 enabled...
[06:08] <j-b> yes :D
[06:09] <j-b> is it possible to have one package in multiverse depending on one in universe ?
[06:11] <j-b> wgrant: what are our deadlines if we want to be in Intreid ?
[06:12] <wgrant> j-b: Packages in multiverse can depend on packages in any component. The opposite is not true.
[06:13] <wgrant> 2008/08/28 is the deadline for new upstream versions, but if we have a RC before that we could probably get it in later.
[06:13] <wgrant> And it's easier to get exceptions if the project has an abysmal security record.
[06:13] <j-b> wgrant: ok, so in theory, we could have a vlc in universe and the plugins in multiverse
[06:14] <j-b> do we have a "abysmal security record" ?
[06:14] <wgrant> j-b: If the plugins can be built from a separate source package, yes.
[06:14] <wgrant> You do.
[06:14] <j-b> :'(
[06:14] <wgrant> Not quite as bad as things like WordPress and phpMyAdmin, though.
[06:15] <j-b> well, we have less security updates than FFx, but yes, demuxers are very likely security borken
[06:15] <wgrant> Fortunately your patches are generally fairly easy to locate.
[06:15] <j-b> wgrant: well, for sure, we won't fix security in 0.8.6 branch
[06:15] <wgrant> Um, even though it's in Hardy and Lenny?
[06:16] <wgrant> That seems very short-sighted and distro-hostile.
[06:16] <j-b> yes
[06:16] <j-b> no, that seem s very unstaffed
[06:17] <wgrant> It's a lot easier for the upstream devs to backport fixes than tiny distro security teams that don't know the code...
[06:17] <j-b> wgrant: give us more than 5 devs
[06:17] <j-b> :)
[06:17] <wgrant> More than our security team, at least.
[06:18] <j-b> wgrant: we will try to provide patches for security
[06:18] <j-b> since the code is very separated in plugins, and usually the seucrity is one plugin not the application
[06:19] <j-b> but it is not sure that we will make actual release for it
[06:19] <wgrant> Right, that's fine.
[06:19] <wgrant> As long as we have patches.
[06:19] <wgrant> We don't upload new upstream releases to old suites anyway.
[06:19] <j-b> wgrant: all security issues in the last 2 years where not more than a few lines of patches in some plugins
[06:20] <wgrant> j-b: I noticed. I've dealt with most of them.
[06:20] <j-b> wgrant: but yes, 0.8.6 has much diverted from 0.9.0
[06:20] <j-b> wgrant: that is also why some distro broken vlc in more packages
[06:20] <wgrant> It would be much easier if you would note which commit fixes each vulnerability, though.
[06:21] <j-b> wgrant: yet another boring question: do you have patches that we (upstream) could use ?
[06:21] <wgrant> j-b: I think the only major one that we now carry is PulseAudio, but I believe that's in 0.9.0 anyway.
[06:22]  * wgrant checks for others.
[06:22] <j-b> wgrant: yes, PA...
[06:23] <j-b> wgrant: do you know where I can find the ubuntu Qt4 packaging team ?
[06:23] <wgrant> j-b: Of that I'm not quite sure.
[06:23] <j-b> too bad
[06:24] <j-b> wgrant: anyway, thx a lot for your time.
[06:24] <wgrant> j-b: You can see all of our patches at http://patches.ubuntu.com/v/vlc/extracted/. That includes those we inherit from Debian.
[06:24] <j-b> if needed, mail me
@videolan.org :D
[06:24] <j-b> my g/f uses ubuntu, so I want a good VLC there :D
[06:25] <wgrant> Thanks for talking to us. Communication with upstream is always a good thing, and generally makes things easier for all involved.
[06:25] <j-b> thanks for your work :D
[06:26] <j-b> and I'll see what I can do to help debianers to make some good debian/rules
[06:26] <ScottK> j-b: If you're looking for people working on QT, then #kubuntu-devel
[06:26] <j-b> not writen a .deb in years...
[06:26] <j-b> ScottK: thx
[06:27] <j-b> arf, sorry, yet another question: how long do you keep bugs for old release in launchpad ?
[06:27] <wgrant> j-b: They're there forever, but they are hidden from the default view once they are closed.
[06:27] <wgrant> They will remain open until fixed or the old release loses support, which is usually 18 months after release.
[06:28] <j-b> wgrant: ok
[06:28] <j-b> muchas gracias...
[06:28] <j-b> mail me if needed :D
[09:11] <huats> morning everyone
[09:12] <huats> whois sirestart
[09:12] <huats> sorry for the noise...
[09:12] <huats> raphink: hey
[09:12] <huats> any lluck on your investigation on REVU ?
[09:12] <raphink> hi huats
[09:33] <stefanlsd> can anyone help me with a pbuilder error - trying to do the pbuilder create
[09:34] <stefanlsd> ends like this - http://pastebin.com/d3d5301e4  (essentially W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/intrepid/Release  Unable to find expected entry  restriced/binary-i386/Packages in Meta-index file (malformed Release file?)
[09:37] <slytherin> vorian: need to discuss the bug you logged
[09:37] <slytherin> about jboss
[09:37] <slytherin> slangasek: ﻿need to discuss the bug you logged. ﻿about jboss
[09:39] <laga> can i get some motu-sru love for bug #241402?
[10:01] <geser> stefanlsd: I've no idea, the typo in the file it missed looks strange. Perhaps mvo in #ubuntu-devel has an idea what went wrong.
[10:18] <stefanlsd> geser: thanks. in the .pbuilderrc i had a type of restricted
[10:27] <Wubbbi> Hello :)
[10:27] <Wubbbi> Can a MOTU take a look at here please? http://revu.ubuntuwire.com/details.py?package=kio-sysinfo
[10:29] <slangasek> slytherin: why in the world does jboss have circular build-dependencies?  that's just madness :/
[10:30] <slytherin> slangasek: that you will have to ask Debian packagers.
[10:30] <slangasek> as opposed to upstream?
[10:32] <slytherin> slangasek: frankly, I don't know if it is upstream problem or packaging problem.
[10:35] <geser> slangasek: have you a better idea to resolve the bootstrapping problem with jbossas4?
[10:39] <Sikon> What's with all the motu-sru members resigning?
[10:39] <Sikon> A flashmob?
[10:40] <\sh> Sikon: nope...just a matter of time
[10:41] <wgrant> Who is left?
[10:41]  * \sh resigned from motu-sru...see mail
[10:41] <\sh> there's not much time left of my day to do the duties for this job....and I really want to see another member of motu to fulfill this position..
[10:41] <wgrant> \sh: Who *is* left, not who *has* left.
[10:41] <Sikon> \sh> ScottK resigned before you
[10:42] <geser> wgrant: apparently nobody. I'm waiting over a week already for a comment from ~motu-sru
[10:42] <Sikon> And before that, Hobbsee resigned from MOTU and MOTU Release Team
[10:43] <huats> geser: i think TheMuso is still there...
[10:44] <huats> and pitti is also there I think
[10:44] <huats> (but I might be wrong)
[10:45] <\sh> well, regarding me, it hasn't to do with Launchpad...but it has to do with time spend on RL, RL work and Leonov (in this particular order) and it's really important that this team is running at a good speed...and I can't achieve that speed (everybody can see that, that I don't do upload a lot of packages this cycle)
[10:45] <geser> huats: afaik pitti was never in motu-sru, just ubuntu-sru
[10:50] <huats> geser: oh sorry I mixed both
[10:50] <huats> :(
[10:51] <DktrKranz> huats: pitti does archive-admin tasks and provides guidance in case of doubt.
[10:57] <Wubbbi> DktrKranz: do you have time?
[11:00] <DktrKranz> Wubbbi: not much right now, what can I do for you?
[11:01] <Wubbbi> Can you take a look at this please? http://revu.ubuntuwire.com/details.py?package=kio-sysinfo
[11:05] <DktrKranz> Wubbbi: not right now, but I could have a look later this afternoon
[11:06] <Wubbbi> DktrKranz: ok no problem. thank you very much :)
[11:47] <sistpoty|work> hi folks
[12:05] <cody-somerville> persia, I wrote the minutes for the meeting.
[12:05] <persia> cody-somerville: I saw them.  Thanks.  Usually I send them to the mailing list as well, just to let everyone know (as not everyone is subscribed to that wiki page).
[12:07] <cody-somerville> Okay.
[12:07] <cody-somerville> I'll do that now.
[12:11] <StevenK> nhandler: I've uploaded your hildon-t-m-b debdiff, thanks!
[12:12] <nhandler> Thank you StevenK :)
[12:20] <huats> hey sistpoty|work
[12:20] <huats> glad to see you
[12:20] <sistpoty|work> hi huats
[12:21] <huats> I have a pb with revu
[12:21] <huats> I cannot upload anymore
[12:21] <huats> :(
[12:21] <huats> i have started to look at this pb with raphink
[12:21] <huats> apparently my key disapeared from the kearing
[12:21] <huats> keyring
[12:21] <raphink> mine aswell ;)
[12:21] <huats> sorry
[12:21] <huats> that is true :)
[12:22] <sistpoty|work> NCommander: around? ^^ :)
[12:22] <persia> huats: Are you still a member of the uploaders team?
[12:22] <sistpoty|work> huats: revu has gone through quite a bit of code changes in regards to keys and stuff... NCommander should know best ;)
[12:23] <sistpoty|work> (and RainCT) ;)
[12:23] <huats> persia: I think... I was last week
[12:23] <huats> hey persia btw
[12:23] <huats> :)
[12:25] <huats> persia: LP says that I am a member of the team
[12:25] <huats> sistpoty|work: ok
[12:25] <huats> so NCommander please help us :)
[12:32] <Adri2000> huats and raphink: have you both logged in revu once before uploading?
[12:33] <raphink> sure
[12:33] <huats> hum
[12:33] <huats> I think so too
[12:33] <norsetto> please don't let huats upload to revu, please!
[12:33] <huats> norsetto: hello :)
[12:33] <raphink> haha
[12:34] <norsetto> huats: oh hi, you are here too :-)?
[12:34] <huats> ;)
[12:34] <Adri2000> as far as I understand the changes that have been made, the revu-uploaders team is no longer used. your key is imported into revu when you first login to revu using launchpad openid
[12:34] <huats> I'll try to upload again now that I am loggued in
[12:34] <huats> ....
[12:34] <raphink> Adri2000: ah, this is new
[12:35] <jpds> raphink: Might want to "merge accounts" after login.
[12:36] <raphink> I see
[12:36] <norsetto> jpds: you are with the backporters team, right? Care to give a look to bug 252037 ?
[12:37] <huats> Adri2000: raphink and sistpoty|work it works !
[12:37] <huats> I might not have loggued since...
[12:38] <norsetto> oh no ....
[12:38] <huats> that was the reason...
[12:38] <huats> sorry norsetto...
[12:38] <huats> ;)
[12:38]  * norsetto goes to have lunch ...
[12:38] <jpds> norsetto: Looks like sauerbraten-data, recommends and conflicts on sauerbraten.
[12:38] <huats> norsetto: enjoy your pasteque
[12:38] <huats> ;)
[12:40] <norsetto> jpds: yes, that would also
[12:40] <norsetto> need to be updated
[12:40] <jpds> norsetto: Looks like: sauerbraten-data (>= 0.0.20071227-1) is the biter where -1~hardy1 is less than the required dependency
[12:42] <norsetto> jpds: there are two things, sauerbraten needs to have a suitably versioned dep on sauerbratem-data, and sauerbraten-data needs to have a suitable versioned conflict with sauerbraten
[12:43] <jpds> Right,
[12:44] <norsetto> jpds: can you take care of that? I don't think I'm allowed to upload to -backports/
[12:44] <jpds> norsetto: Me neither :) Only core-dev can upload directly.
[12:44] <norsetto> jpds: ah!
[12:45]  * norsetto looks around to see if there is any core-dev lurking in the corners
[12:45] <jpds> I have to file a backport request on LP with ubuntu-archive subscribed
[12:46]  * norsetto seems to remember that sistpoty|work has super cow powers
[12:46] <sistpoty|work> norsetto: /me can't even login to lp right now :P
[12:46] <norsetto> sistpoty|work: thats a good one, have to remember it :-)
[12:47] <huats> :)
[12:47] <sistpoty|work> sad but true... the recover password page says that I'm not authenticated *g*... so obviously I need to be logged in to recover my password *g*
[12:47] <norsetto> lol
[12:48]  * norsetto really goes to have lunch
[12:48] <sistpoty|work> have a good meal, norsetto
[12:48] <jpds> sistpoty|work: I think they logged everyone out yesterday.
[12:49] <wgrant> jpds: That matches my experience.
[12:49] <jpds> wgrant: Hobbsee had the same and me too.
[12:49] <sistpoty|work> well, that alone wouldn't be too much of a problem *g*
[12:50] <Hobbsee> sistpoty|work: that's...special.
[12:50] <Hobbsee> sistpoty|work: go complain in #launchpad, if you haven't already
[12:50] <sistpoty|work> Hobbsee: I already have :)
[12:50]  * Hobbsee hasn't looked there yet
[13:14]  * cody-somerville tackles Hobbsee.
[13:15] <Hobbsee> hey cody-somerville!
[13:16] <cody-somerville> How are ya? :)
[13:17] <huats> If anybody want to give a review of http://revu.ubuntuwire.com/details.py?package=tktreectrl
[13:17] <huats> :)
[13:20] <Hobbsee> cody-somerville: doing OK.  home from work.  yay!
[13:21] <cody-somerville> \o/
[13:23]  * norsetto is not here
[13:23] <StevenK> Evidently
[13:24] <StevenK> Otherwise cody-somerville might tackle you as well.
[13:24]  * cody-somerville grins.
[13:24] <norsetto> StevenK: tackling is ok, is tickling which isn't
[13:25]  * Hobbsee tickles norsetto with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™
[13:26]  * norsetto laugh his err, bottom, off
[13:26] <persia> It tickles too?  Next you'll claim it juliennes fries...
[13:26] <Hobbsee> it does many things.
[13:26] <cody-somerville> Amen!
[13:35] <norsetto> huats: small typo: "This package contains the development file" should be "This package contains the development files"
[13:36] <huats> norsetto: ok
[13:37] <norsetto> huats: also, some blank spaces here and there to be cleaned out
[13:38] <huats> norsetto: in the control file right ? (I have just removed some)
[13:39] <norsetto> huats: also rules and copyright
[13:39] <huats> ok ok
[13:39] <norsetto> huats: I see you have decided not to use make distclean
[13:39] <huats> norsetto: no
[13:39] <huats> I am using it,
[13:40] <norsetto> huats: there is no make (dist)clean in the clean target of rules
[13:40] <huats> there is a clean target
[13:41] <norsetto> huats: thats not what I'm saying
[13:41] <huats> and in it I test if the Makefile exists or not, if it does, I am using distclean
[13:41] <huats> ok
[13:41] <huats> so I mistunderstand :)
[13:42] <norsetto> huats: my fault, was looking at the old rules *cough*
[13:42] <huats> I am listening :)
[13:42] <huats> ah ok :)
[13:43] <huats> no pb
[13:43] <huats> ::)
[13:44] <norsetto> huats: but then this comment "We need to clean by hand since there is no clean target in Makefile" should go ;-)
[13:44] <huats> yep
[13:44] <huats> :)
[13:45] <AnAnt> doko: ping
[13:46] <huats> norsetto: ok
[13:46] <huats> I have corrected all that
[13:46] <huats> :)
[13:46] <huats> thanks !
[13:50] <norsetto> huats: hmmmm, I guess the examples should really go in the -dev package
[13:51] <huats> they are not ?
[13:51] <huats> oups
[13:51] <Wubbbi> DktrKranz: 1) Upstream tarball does not provide a full copy of the license used, this will cause archive-admin to reject the package.  that does that mean?
[13:52] <huats> norsetto: it is the case right now in my new local package :)
[13:53] <norsetto> Wubbbi: that your package will likely be rejected if submitted
[13:54] <Wubbbi> why?
[13:55] <norsetto> huats: how can I check some of the examples? For instance, tclsh8.4 bitmaps.tcl does nothing
[13:55] <huats> norsetto: the example is just one big example
[13:55] <norsetto> Wubbbi: because upstream tarball doesn't contain sufficient license information
[13:55] <tacone> are suggested installed by default in intrepid ?
[13:55] <norsetto> huats: hmmm, I see
[13:58] <norsetto> huats: perhaps we should say something to that effect in the -dev README.Debian
[13:59] <huats> ok
[14:01] <persia> Wubbbi: Essentially, as the packager, it is your responsibility to work with upstream to ensure that their code release includes all the necessary licensing information for redistribution.
[14:01] <persia> Some upstreams only include that required for distribution, but may not complete all requirements to allow others to redistribute.
[14:03] <Wubbbi> persia: and what I have to do now?
[14:03] <AnAnt_> doko: ping
[14:04] <norsetto> huats: do we care that TREECTRL_LIBRARY is undefined?
[14:05] <Wubbbi> persia: why not? ... Its under the GPL. And the GPL allowed me to do anything I want with. oO
[14:05] <huats> regarding the example
[14:05] <AnAnt_> doko: Hello, can you help me with Martin Pitt's question on bug 249158 ?
[14:05] <huats> the way to test it is to gunzip eveything
[14:05] <AnAnt_> doko: eclipse version is still at 3.2 while swt-gtk is currently  at 3.4 on Debian
[14:06] <huats> and then tclsh8.4 demo.tcl
[14:06] <huats> :)
[14:06] <norsetto> huats: yes, I did that, thats why I've seen that warning
[14:06] <huats> norsetto: TREECTRL_LIBRARY undefined ?
[14:06] <huats> norsetto: let me check
[14:06] <persia> Wubbbi: The GPL very much does *not* let you do anything you want with it.
[14:07] <slytherin> tacone: 'Suggests' are never installed. I think you means 'Recommends'. AFAIK, they will be installed by default in intrepid
[14:07] <persia> Anyway, https://wiki.ubuntu.com/UpstreamGuide has some information that might help to determine what is required.
[14:07] <bddebian> Heya folks
[14:07] <sistpoty|work> hi bddebian
[14:07] <cody-somerville> Heya bddebian
[14:08] <Wubbbi> persia: why? :
[14:08] <Wubbbi>   This package is free software; you can redistribute it and/or modify
[14:08] <Wubbbi>   it under the terms of the GNU General Public License as published by
[14:08] <Wubbbi>   the Free Software Foundation; either version 2 of the License, or
[14:08] <Wubbbi>   (at your option) any later version.
[14:08] <bddebian> Hi sistpoty|work, cody-somerville
[14:08] <Wubbbi> !!!you can redistribute it and/or modify!!!
[14:09] <slytherin> Wubbbi: GPL insists that your modifications should also be released under same license
[14:09] <directhex> Wubbbi, the gpl doesn't allow me to use gpl source code in a closed product. even if i want to!
[14:09] <bddebian> And the the source goes with it
[14:09] <bddebian> and
[14:09] <bddebian> and
[14:09] <bddebian>  :)
[14:09] <directhex> Wubbbi, that's not "anything i want"
[14:09] <directhex> Wubbbi, you want the WTFPL
[14:09] <persia> Wubbbi: redistribute *under the terms of the GPL*, which as some restrictions.
[14:10] <directhex> the WTFPL is a 1-clause copyleft license, with the following term:
[14:10] <broonie> slytherin: Well, you don't need to use the *same* license. You just need to grant at least the rights the GPL grants (so, eg, public domain is fine)
[14:10] <directhex>   0. You just DO WHAT THE FUCK YOU WANT TO.
[14:10] <Wubbbi> persia:  I want to releas it under the GPL! where is the problem?
[14:10] <slytherin> broonie: yes, I means no additional restrictions
[14:11] <Wubbbi> I dont understand what you all mean. The Programm is under the GPL ... I have redistribute and modify it ( I'm allowed to ;) ) ... now I want to release it again under the GPL ... whats the problem?
[14:12] <sistpoty|work> Wubbbi: does the orig.tar.gz contain a copy of the GPL?
[14:13] <directhex> Wubbbi, are all contents, e.g. artwork or sounds or fonts, covered under the same license?
[14:14] <DktrKranz> Wubbbi: basically there's no way to tell becaus .orig.tar.gz does not ship a full copy of the license, this leads to uncertainty when looking at files without license headers (such as .po files for instance). Ubuntu/Debian can't rely on the informations listed in a web page to determine license, but for information shipped together with source code.
[14:14] <Wubbbi> directhex: I have removed the unfree ATI/NVIDIA/INTEL/AMD Pictures and replaced them with some Oxygen ( GPL ) Icons. And all of these things are under the GPL or LGPL ..
[14:15] <Wubbbi> ohhhh ... the po files dont have any Licens comment :/
[14:16] <directhex> see?
[14:16] <DktrKranz> I think upstream would provide a full copy of the licenses if asked, it's not a big issue, IMO
[14:16] <Wubbbi> but on the Homepage, it shows me GPL http://kde-apps.org/content/show.php/New+sysinfo+1.0?content=85668
[14:16] <sistpoty|work> DktrKranz: ahem... a missing gpl in the source code doesn't really have any impact in regards to files w.o. license headers. the problem is rather that it's a requirement of the gpl itself which is not met then.
[14:17] <DktrKranz> sistpoty|work: doesn't GLP imply we ship a full copy of the license?
[14:17] <DktrKranz> *GPL
[14:18] <directhex> yes
[14:18] <sistpoty|work> DktrKranz: yes, it does. just your argument is flawed ;)
[14:18] <sistpoty|work> DktrKranz: or my understanding of it ;)
[14:18] <DktrKranz> sistpoty|work: my bad words :)
[14:18] <sistpoty|work> heh
[14:18] <SolarWar> I'm looking for some packaging experts to comment on my package thats up for review: http://revu.ubuntuwire.com/details.py?package=qlix
[14:18] <Wubbbi> DktrKranz: ok ... how to fix that issue now?
[14:19] <sistpoty|work> Wubbbi: 1) tell upstream. 2) repack the orig.tar.gz and put in a copy of the gpl
[14:19] <nhandler> SolarWar: You don't need to ask in this channel every day for people to review qlix. People will review it when they get a chance.
[14:19] <SolarWar> okay :)
[14:20] <Wubbbi> sistpoty|work: the complet GPL? oO
[14:20] <persia> SolarWar: On the other hand, you are welcome to advertise your cool package once a day if you wish.  You may get more interest if your advertisement includes a little more information about the package.
[14:21] <sistpoty|work> Wubbbi: yep
[14:21] <NCommander> me wakes up
[14:22] <norsetto> SolarWar: feel also free to make offers, we accept cash, major credit cards and used stamps
[14:22] <AnAnt> persia: can you help out with this bug 249158 ?
[14:22] <sistpoty|work> Wubbbi: the source package must be complete on its own, as it can be used on its own (iirc some distribution even have used debian sources as "upstream" sources in the past)
[14:22] <persia> norsetto: No soliciting bribes in public :p
[14:23] <SolarWar> norsetto, haha :)
[14:23] <norsetto> persia: bribes? Thats good honest work ;-)
[14:24] <persia> AnAnt: From the buglog, I suspect you'll want to verify that the new swt-gtk supercedes eclipse.  If you're not sure, you might try confirming with doko.
[14:24] <Wubbbi> sistpoty|work: ok just copy in the orig.tar.gz?
[14:24] <AnAnt> persia: what does supercede mean ?
[14:25] <sistpoty|work> Wubbbi: exactly
[14:25] <persia> AnAnt: roughly: both is newer than and replaces
[14:26] <Wubbbi> sistpoty|work: GPL, GPL-2 or GPL-3?
[14:26] <AnAnt> persia: swt-gtk does not replace eclipse, maybe only the swt libs that eclipse provide
[14:26] <sistpoty|work> Wubbbi: whatever license matches (I'm quite sure upstream put a note under which license the software is supposed to be released)
[14:27] <Wubbbi> sistpoty|work: and there are 2 files with the LGPL Lincense ... should I copy the LGPL License too?
[14:28] <sistpoty|work> Wubbbi: yes (even though it's legally not necessary, since LGPL allows files to be relicensed under the GPL)
[14:28] <Wubbbi> ok
[14:29] <persia> AnAnt: right.  Historically, swt-gtk was no longer used, as the libraries from eclipse were used instead.  It may be that now swt-gtk is good again, and we should not use the eclipse libraries.
[14:30] <persia> The archive admin reviewing the update would like someone to investigate this, and update the bug with further information as to whether we should be using swt-gtk or the swt libraries from eclipse.
[14:30] <Wubbbi> sistpoty|work: ok done ... now thats all?
[14:31] <sistpoty|work> Wubbbi: no idea actually... I haven't looked at the source package in the first place ;)
[14:31] <Wubbbi> DktrKranz: thats all? Or do we need more License changes?
[14:32] <DktrKranz> Wubbbi: I think it's all
[14:33] <Wubbbi> DktrKranz: 4) This shouldn’t be a native package (you haven’t .diff.gz file).  ... how to fix that?
[14:34] <DktrKranz> Wubbbi: ah... it's not LGPL, it's GNU Library.  GNU Library has been replaced by LGPL, though...
[14:35] <Wubbbi> DktrKranz: ???
[14:35] <Wubbbi> that mean?
[14:35] <DktrKranz> Wubbbi: two files are licensed under GNU Library Public License.
[14:36] <DktrKranz> it's an obsolete license, though. I'm unsure if you can provide LGPL text or old GNU Library GPL one
[14:38]  * persia recommends providing both, and specifying which files are under which license: it may be taht GLPL stuff is not GPL3.0 compatible (one would need to check the FSF compatibility graph)
[14:40] <Wubbbi> DktrKranz: are what license is that?
[14:40] <Wubbbi> LGPL or what?
[14:41] <Wubbbi> are = and
[14:41] <DRebellion> Could someone explain *exactly* what a get-orig-source debian/rules target should do? I'm slightly confused at the moment...
[14:42] <DktrKranz> Wubbbi: http://www.gnu.org/licenses/old-licenses/library.html
[14:42] <Wubbbi> and what do i need to change now?
[14:45] <DRebellion> Or, could somebody suggest an existing package that uses a get-orig-source target to update svn that I could take a look at?
[14:45] <laga> DRebellion: mythtv and mythplugins
[14:45] <DRebellion> laga, thanks
[14:47] <Wubbbi> DktrKranz: what to do now?
[14:54] <DktrKranz> Wubbbi: mh... sorry. I'll be off due to work now. If you want, let's talk about it this evening or tomorrow
[14:54] <persia> A get-orig-source target should download the *latest* source from upstream, and adjust the tarball to make it DFSG free if required, and store it in the current direction.  It should work from any directory.
[14:54] <norsetto> DktrKranz: that mean?
[14:55] <DRebellion> persia, dfsg?
[14:55] <persia> I should be able to call `cd /tmp; /home/persia/src/myprogram/myprogram-0.1/debian/rules get-orig-source` and end up with an orig.tar.gz in /tmp.
[14:55] <persia> DRebellion: Debian Free Software Guidelines
[14:55] <DktrKranz> norsetto: my boss is committing tons of paper ;)
[14:56] <DRebellion> persia, ok, so. I download the latest svn, rename the directory appropriately, tarball it, and dump it in the cwd?
[14:56] <norsetto> DktrKranz: a good job is not finsihed until all the paperwork is done
[14:56] <Wubbbi> DktrKranz: ok
[14:56] <persia> DRebellion: Generally not, as the latest svn is often not something that works.  Better to use the latest revision with a release tag, or something similar.
[14:57] <ivoks> hi motus
[14:57] <DRebellion> persia, this is an svn release though.
[14:57] <persia> DRebellion: Then yes, but be prepared for something to go wrong.
[14:57] <DRebellion> ok, thanks for your help
[14:57] <sistpoty|work> hey ivoks
[14:58] <DRebellion> persia, you should write that up on the ubuntu wiki. There are plenty of guides on when you should include a get-orig-source target, but nothing explaining exactly what it should o.
[14:58] <norsetto> sistpoty|work: you traitor, you are only an honorary motu now ;-)
[14:58] <DRebellion> s/o/do.
[14:59] <sistpoty|work> norsetto: he
[14:59] <sistpoty|work> heh even
[14:59] <slytherin> DRebellion: svn export is the command you should use.
[14:59] <DRebellion> slytherin, ok
[15:00] <persia> DRebellion: apt-get install debian-policy; sensible-browser /usr/share/doc/debian-policy/policy.html/ch-source.html
[15:00] <DRebellion> persia, that sounds useful.
[15:01]  * DRebellion installs
[15:01] <slytherin> Is there anyway to discourage such mis-identifications - https://edge.launchpad.net/~abedzaben-89
[15:02] <persia> slytherin: Not as long as we have user-editable short names.
[15:02] <laga> slytherin: maybe his name is Kyle Mitnick?
[15:03] <slytherin> laga: hen he should have used it.
[15:14] <jmehdi>  I've uploaded a new package for Webstrict (http://revu.ubuntuwire.com/details.py?package=webstrict) but I don't see it... Could someone help me?
[15:18] <AnAnt> doko: ping
[15:18] <DRebellion> =(
[15:19] <DRebellion> My get-orig source target is failing. I think it has to do with me not using variables correctly.
[15:19] <kdubois> i'm using pbuilder and pdebuild to make my package. What is the path that I should tell the makefile to install its libraries/binaries/etc. to? my package gets made, but has nothing in it
[15:19] <DRebellion> Can I paste 7 lines here?
[15:19] <DRebellion> kdubois, $(CURDIR)/debian/${DEB_SOURCE_PACKAGE}
[15:22] <norsetto> !pastebin | DRebellion
[15:23] <DRebellion> http://paste.ubuntu.com/31740/
[15:23] <DRebellion> just as i suspected :P
[15:24] <geser> DRebellion: don't fortget this is a Makefile and not a sh-script
[15:24] <norsetto> DRebellion: in a Makefile each line spawns its own shell, so, if you write it like that, its not gonna work ;-)
[15:25] <DRebellion> geser, norsetto, so, do it all on one line?
[15:25] <norsetto> DRebellion: yes, use \ wisely
[15:25] <DRebellion> thanks
[15:26] <kdubois> i have it installing to debian/tmp, should it be installing to debian/extra-animations (extra-animations is name of package)
[15:27] <kdubois> that seems weird to me
[15:29] <persia> DRebellion: You may find that instead of using \ you would do well with $(SVN_REPO).  Also, be aware that make has three different ways to set variables.  "=" is almost certainly not what you want, except in special cases.  Generally you want either ":=" or "?=", and likely := in this case.
[15:31] <DRebellion> persia, what do := and ?= do
[15:31] <DRebellion> ?
[15:32] <persia> := sets the variable at parse time, ?= sets the variable at execution time, = sets the variable when it is used.
[15:32] <persia> One uses the first for static variables (or variables that only depend on previously defined variables)
[15:32] <norsetto> persia: I thought =? sets it if it is not set already?
[15:33] <persia> One uses the second for variables where setting has a sde effect, and they should only be set once, and that value used thereafter.
[15:33] <persia> One uses the last only where one needs the variable value to depend on a constantly changing value (or one that is only known at runtime (e.g. $<))
[15:34] <DRebellion> 0.0
[15:34] <persia> Yes, that is one way of interpreting the meaning of ?=, although not precise.  Specifically, it sets the variable the first time it is used, which may be parse time or runtime depending on how it is used.
[15:35] <DRebellion> persia, so.. I'm going to use := for SVN_REPO and ?= for SVN_REVISION?
[15:37] <persia> DRebellion: That seems right.  You know the repo in advance, but you want to calculate the revision when you do the svn call (and not update it later if there is a commit while you are processing it).  For safety, I recommend only using $(SVN_REVISION) in a runtime context with that choice, as tempting as it might be to use it in a parse-time context to save line length.
[15:38]  * persia notes that using = for variables that depend on the value of a ?= variable is one trick that allows one to delay interpreation of the ?= variable until runtime, although it should not be abused.
[15:38] <DRebellion> This is just painful
[15:38] <persia> DRebellion: Also, be careful that you don't make any svn call during a normal build: it should only happen when calling get-orig-source
[15:39] <DRebellion> What does += mean?
[15:40] <persia> DRebellion: It appends anything after the += to the list identified by the lvalue.
[15:41] <DRebellion> persia, ok
[15:42] <persia> Note that += inherits the execution time of the original list definition, so if your list was defined with =, += will just add that at the time of use.  If your list was defined with :=, += will add it at parse time.  Don't use += for things defined with ?= as it will cause make to be confused.
[15:43] <DRebellion> Ok, here's what I've got (still failing): http://paste.ubuntu.com/31749/
[15:44] <persia> make is not a shell script
[15:44] <DRebellion> But, it has a shebang!
[15:44] <DRebellion> #!
[15:44] <Wubbbi> 4) This shouldn’t be a native package (you haven’t .diff.gz file). ... what does that mean?
[15:44] <persia> Yes, as does python, perl, ruby, etc.
[15:44] <DRebellion> persia, so, what should I do?
[15:45] <persia> Wubbbi: You want to have the debian/ directory outside the orig.tar.gz, and have an orig.tar.gz in the base directory when you build the source.
[15:45] <persia> DRebellion: First, define SVN_REPO aboce get-orig-source
[15:45] <DRebellion> aboce?
[15:45] <persia> Second, drop all the "&& \" entries
[15:45] <persia> s/c/v/
[15:46] <DRebellion> persia, with export?
[15:46] <Wubbbi> persia: ??? I dont understand ... should I Put the debian Folder to orig.tar.gz?
[15:46] <persia> Oh, define SVN_REVISION up there too: it won't actually get called until it gets used (?=)
[15:46] <persia> Wubbbi: precisely the opposite.
[15:48] <Wubbbi> persia: aha ... so I have to put the debian folder out of the orig.tar.gz?
[15:48] <persia> DRebellion: http://paste.ubuntu.com/31751/ is significantly closer to what you seek.
[15:49] <persia> Wubbbi: Indeed.
[15:49] <persia> Wubbbi: Create the orig.tar.gz as suitable for any distribution.
[15:49] <persia> Unpack it, add debian/ and call `debuild -S -sa` to generate your source.
[15:49] <norsetto> DRebellion: there is a complete example of how to make a get-orig-source in gnome-pkg-tools, you may find it enlightening
[15:49] <Wubbbi> persia: ok
[15:50] <persia> norsetto: For SVN snapshots?
[15:50] <DRebellion> norsetto, I will take a look, thanks.
[15:50] <norsetto> persia: for both
[15:50] <persia> norsetto: Interesting.  Does it suffer from the common doesn't-work-from-any-directory bug?
[15:50] <norsetto> persia: no idea, I'm just looking at it, but seems pretty complete
[15:51] <Wubbbi> persia: but there was no debian folder in the orig.tar.gz ... so what could this mean? I have never done a debian folder to orig.tar.gz.
[15:52] <DRebellion> persia, then this happens: mv trunk -1.8.2.2+
[15:52] <DRebellion> (after export)
[15:52] <DRebellion> how should I be running this agian?
[15:53] <persia> norsetto: It has the doesn't-work-from-any-directory bug and the doesn't-get-source-from-upstream-location bug.
[15:53] <persia> (in other words, it's completely useless for the intended purpose)
[15:53] <DRebellion> It also suffers from the homepage-in-description bug
[15:54] <persia> DRebellion: the gnome-pkg-tools get-orig-source stub?
[15:54] <persia> DRebellion: I see the problem.  You need SVN_REVISION to use $(shell ...)
[15:55] <asisak> Hey MOTUs!
[15:55] <DRebellion> persia, shell?
[15:55] <persia> Wubbbi: You don't want the debian folder in the orig.tar.gz.  You do want the orig.tar.gz in the parent folder from where you have the debian/ folder.
[15:55] <asisak> Is it possible to do a backport if it involves a new source dependency?
[15:56] <persia> DRebellion: Well, I presume that svn info ... is a shell command, right?  You need to tell that to make.
[15:56] <DRebellion> persia, what does make think it is?
[15:56] <persia> asisak: I've seen cases of that before, as long as there is low potential for regression.
[15:56] <DRebellion> persia, makes no difference - same error
[15:56] <persia> DRebellion: a list.
[15:56] <persia> paste?
[15:56] <asisak> persia: in this case first the source needs a backport, right?
[15:57] <asisak> I mean the source dependency
[15:57] <persia> asisak: As I understand it, although I'm not a backporter.  Sometimes there is someone in #ubuntu-backports who knows, but sometimes there isn't.
[15:57] <asisak> it seems to be quite empty :(
[15:59] <Wubbbi> persia: ok ... I have to Put the orig.tar.gz in the same folder, where the /debian was? done
[16:00] <persia> Wubbbi: One folder up from there.
[16:00] <DRebellion> persia, http://paste.ubuntu.com/31759/
[16:05] <persia> DRebellion: You don't have DEB_SOURCE_PACKAGE defined.  Also you probably want +svn2198 rather than just +2198.
[16:06] <DRebellion> persia, it was used in the wiki.ubuntu.com examples without being defined. Oh well.
[16:07] <persia> DRebellion: Probably pulled from a package that used CDBS, which defines it.  Without CDBS, you have to define it manually.  Anyway, all the examples in the wiki assume a basic understanding of make.
[16:08] <DRebellion> persia, it works!
[16:08] <DRebellion> persia, thanks.
[16:08] <DRebellion> :)
[16:09] <persia> DRebellion: Now next time someone is having trouble with variable assignment in make, or just decides to write a shell script instead of using make, you have all the tools to help them fix it :)
[16:10] <DRebellion> persia, great!
[16:14] <Wubbbi> persia: ok thx worked
[16:14] <Wubbbi> :)
[16:15] <DRebellion> erm... how can I turn '2198' into 'svn2198' on the command line?
[16:16] <directhex> sed 's/^/svn/' ?
[16:16] <persia> DRebellion: Just add it in your string : -1.8.2.2+svn$(...
[16:16] <DRebellion> grr
[16:16]  * DRebellion facepalm
[16:16] <DRebellion> persia, you've worn out my brain :P
[16:16] <persia> Also, you might want to pull the version from somewhere (perhaps the changelog, perhaps with dpkg-parsechangelog)
[16:20] <Wubbbi> persia: 4) This shouldn’t be a native package (you haven’t .diff.gz file). ... but right now I didn't get a .diff.gz too oO and I have builded it with orig.tar.gu
[16:20] <Wubbbi> gz
[16:21] <persia> Wubbbi: OK  What is the version in the changelog?
[16:21] <Wubbbi> 1.0-0ubuntu1
[16:22] <persia> And you've whatever_1.0.orig.tar.gz in the parent directory when you build the source?
[16:22] <persia> And you've the debian directory in the source directory, and not in the orig.tar.gz?
[16:23] <Wubbbi> persia: yes yes
[16:24] <persia> Wubbbi: I'm baffled: maybe someone else could look at it?
[16:31] <DRebellion> persia, how can I get dpkg-parsechangelog to run from anywhere and still find the changelog?
[16:32] <slytherin> DRebellion: IIRC, ${CURDIR} will always give you root of the package being built.
[16:33] <DRebellion> slytherin, of course!
[16:34] <DRebellion> slytherin, no, actually it's only giving me the current working directory
[16:35] <sistpoty|work> DRebellion: why do you want to look at the changelog in the first place?
[16:35] <DRebellion> sistpoty|work, to get the version
[16:35] <sistpoty|work> DRebellion: for what use?
[16:35] <DRebellion> sistpoty|work, for the get-orig-source target in debian/rules
[16:36] <sistpoty|work> DRebellion: then you're doing s.th. wrong... get-orig-source should get the latest upstream version, not the current one of the package
[16:36] <persia> DRebellion: You may find the construction $(dir $(_)) useful
[16:37] <DRebellion> sistpoty|work, it's an svn snapshot, so the naming must be correct:   VERSION+svnREVISION
[16:37] <persia> sistpoty|work: It's a SNV snapshot.  I suggested it might be interesting to use the changelog upstream version rather than hardcoding it in debian/rules
[16:37] <DRebellion> I must post this in wiki.ubuntu.com when I am done.
[16:38] <DRebellion> persia, can you expand on that?
[16:38] <DRebellion> (dir)
[16:38] <persia> DRebellion: $(dir /foo/ ) selects the directory path of argument /foo/
[16:38] <sistpoty|work> DRebellion: but you can't detect VERSION from the debian/changelog. just consider that upstream released a new version in the meantime.
[16:39] <persia> $(_) is the path of the currently executing process (or the makefile in the case of executable makefiles)
[16:39] <persia> sistpoty|work: Good point.
[16:40] <persia> DRebellion: You'll want to pull the version from a watch file then.  That ought accurately track upstream.
[16:40] <DRebellion> persia,
[16:40] <DRebellion> ok
[16:41] <persia> Note that you'll want something like $(shell uscan --dehs --report-status --package $(PACKAGE) --upstream-version 0 --watchfile $(dir $(_))/watch --no-symlink | grep upstream-version | sed 's/\(.*\)/\1/g')
[16:42] <DRebellion> wait, this won't work for this particular upstream
[16:42] <persia> Mind you, that sed call looks wrong to me offhand, but it might not be (I wrote that a long time ago)
[16:42] <DRebellion> they increment their version numbers inside their svn trunk
[16:42] <DRebellion> ie
[16:43] <DRebellion> their latest release is 1.8.2.0 but in the svn trunk, it's reported as 1.8.2.2
[16:43] <DRebellion> I will parse it from their config files!
[16:44] <huats> norsetto: just to let you know, the new release with ALL your comment of tktreectrl has been put on revu :D
[16:44] <persia> DRebellion: Just be careful to parse at runtime: that will be a somwhat tricky use of ?=
[16:47] <DRebellion> persia you mean := ?
[16:48] <persia> Very much not.  := will be called at build time, and break the build as the buildd doesn't have internet access or a local copy of the svn snapshot.  You want ?= because A) you only want to run your parser once, and B) you only want to run it after you've grabbed the latest snapshot to be sure you are using the right version for that snapshot.
[16:49] <DRebellion> persia, you are talking about SOURCE_VERSION (1.8.2.2), right?
[16:50] <persia> DRebellion: Yes.
[16:50] <DRebellion> ok, i think i understand
[16:54] <norsetto> huats: ah thanks, I was really looking for that
[16:55] <huats> norsetto: i know...
[16:55] <huats> and since I don't want to let you down with nothing to do...
[16:55] <huats> it is my pleasure you know :)
[16:56] <DRebellion> persia, it's working perfectly now. Thanks once more ;)
[17:10]  * sistpoty|work heads home... cya
[17:13] <DRebellion> "sistpoty|work heads home... cya"... "has quit ("Back to work")" 0.o
[17:23] <DktrKranz> dendrobates: re bug 217254, open-vm-tools has been reimported into Intrepid. Do you still think it should be removed from the archives or current version is better?
[17:44] <slangasek> geser: I haven't looked closely enough to get any better ideas; but the fact that jboss should need bootstrapping at all is still madness
[18:22] <DRebellion> If any MOTUs are in the mood, monkeystudio is up for REVU: http://revu.ubuntuwire.com/details.py?package=monkeystudio
[18:25] <squarebracket> i'm trying to build a driver, but it's giving me a linux/config.h not found error, and i have build-essential and the appropriate headers installed
[18:27] <NCommander> squarebracket, try using /lib/modules/*kernel*/build as the kernel include path
[18:27] <AnAnt> doko: ping
[18:28] <DRebellion> NCommander, what do you think of bug 253025 ?
[18:29] <NCommander> DRebellion, there is a lag between the crontab, and the updates getting installed, but it would be pretty cool
[18:30] <NCommander> (I'm hoping though there may be a way we can remove the dinstall lag though)
[18:34] <squarebracket> NCommander, i don't see a config.h where in /include/linux, just configfs.h ... is that what it wants?
[18:34] <NCommander> squarebracket, no. What module are you trying to compile?
[18:34] <squarebracket> NCommander, intel 536EP
[18:35] <squarebracket> (modem chipset)
[18:36] <kdubois> i'm still having problems with figuring out where pbuilder wants the rootlike fs installation to go http://pastebin.ca/1086264
[18:38] <NCommander> squarebracket, its possible it wants compiled sources and the headers aren't enough, but that would suprise me
[18:41] <squarebracket> NCommander, it only lists the kernel source headers under the prerequisites..
[18:45] <NCommander> squarebracket, the source is different from the headers. Are you sure its not packaged (or available through module-assistant?)
[18:48] <squarebracket> NCommander, lsmod doesn't list it. unless i'm mistaken, that should list it? i don't know what module-assistant is, though.
[18:56] <NCommander> squarebracket, apt-get install module-assistant; m-a
[18:56] <NCommander> (as root)
[18:56] <squarebracket> already did that =]
[18:57] <squarebracket> "Couldn't create the /usr/src/linux symlink!
[18:57] <squarebracket> ??
[19:10] <kdubois> can anyone tell me the path that pbuilder makes it package out of?
[19:17] <Kopfgeldjaeger> /var/cache/pbuilder/result
[19:17] <Kopfgeldjaeger> or sth. like /var/cache/pbuilder/intrepid-i386/result
[19:21] <slytherin> kdubois: check your /etc/pbuilderrc or ~/.pbuilderrc
[19:25] <kdubois> slytherin: it doesnt say what directory it runs dpkg-deb on to create the debian
[19:26] <slytherin> kdubois: I think I misunderstood your question. Can you please make it clear for me?
[19:27] <kdubois> alright, what i'm trying to build has a makefile which requires a hardcoded installation path. i run pdebuild, and it sucessfully builds
[19:27] <kdubois> but i think its installing to the wrong path, because the deb produced is empty
[19:27] <kdubois> except for the control files, etc
[19:29] <slytherin> kdubois: When you use pbuilder you have to do 'sudo pbuilder --build packagename.dsc' But then your problem is not related to pbuilder. Check debian/install files or debian/rules file of your package.
[19:30] <kdubois> my understanding is that pbuilder creates a staging area in tmp. it then compiles my package, and plucks out the binaries and libraries that result and shoves them into a deb
[19:31] <kdubois> as i understand it, pbuilder has a designated area to look for the what is produced in compilation. i need to know where that area is
[19:31] <kdubois> i know the problem lies in an incorrect path specified for installation
[19:32] <slytherin> kdubois: You are not entirely correct. pbuilder creates a chroot and builds the package inside it, not in /tmp. It will be good if you can paste rules file in pastebin.
[19:34] <kdubois> the install part of my rules is just "make install". i have a straight, hand-generated makefile for this package with a hardcoded installation path
[19:35] <geser> kdubois: does your Makefile respect $DESTDIR?
[19:35] <slytherin> kdubois: then that is the problem. Can't help much as I have not dealt with many apps using make.
[19:35] <kdubois> no, i'd have to modify it to respect DESTDIR
[19:36] <geser> kdubois: usually make install is passed DESTDIR=$(CURDIR)/debian/tmp
[19:37] <geser> kdubois: don't rely on a fixed path as someone might want to build it in his home for some reason and not with a pbuilder/sbuild/etc.
[19:37] <kdubois> so i should probably modify the makefile then?
[19:41] <slytherin> geser: I have come to conclusion that the packaging of libjboss-* packages is very wrong. There are more circular build dependencies that I first thought.
[19:59] <kdubois> geser: i modified the makefile to respect DESTDIR, but its still making empty packages. i'm telling it to install to $(CURDIR)/debian/tmp
[20:02] <kdubois> geser: nevermind, i think i got it working! yay
[20:05] <geser> slytherin: :( Do you have the impression that we get all libjboss-* build someday?
[20:06] <slytherin> geser: yes, they will. But I am not really favour of doing it the way we are doing. Anyway, I will work on rest of the packages tomorrow.
[20:07] <geser> I hope we don't need to do it on every new upstream version
[20:08] <slytherin> geser: Once we have all the packages built, I don't we will need to do it for every release. But as slangasek said, it is better to work on eliminating circular build deps
[20:11] <ember> apachelogger: amarok-kde4 doesn't segfault on your side?
[20:17] <apachelogger> ember: nope
[20:17] <RichW> theres a debian/patches directory, will it apply the patches when the package is built?
[20:17] <apachelogger> ember: maybe we need to recompile against kde 4.1.0
[20:21] <RichW> that was a easy q :)
[20:28] <RichW> nvm i got answer for my Q
[20:28] <RichW> I got another one though.. can I make pbuilder use -j4 with make?
[20:29] <tacone> RichW: I'd be interested in know that as well.
[20:32] <RichW> I got a dualcore and I cant use both cores because of pbuilder :(
[20:32] <tacone> me too :)
[20:33] <tacone> 3 processors out of 4 are sleeping
[20:33] <RichW> I guess i could read the source code to pbuilder.
[20:34] <ember> apachelogger: i've open a bug a couple of days ago (the only in amarok-kde i think) it segfaults on starting
[20:34] <tacone> RichW: guess make has some way to set a default.
[20:34] <RichW> pbuilder is just a bunch of bash scripts.
[20:35] <RichW> quite impressive
[20:35] <tacone> RichW: this guy feels the same of us: http://ducksarepeople.com/blog/node/21
[20:36] <stefanlsd> Anyone help me with a prob silly question. I'm following the https://wiki.ubuntu.com/PackagingGuide/HandsOn and in step 2 he uses a dget to get the package source dsc file.  How do you know what the URL should be?
[20:38] <tacone> stefanlsd: if you're trying to get a package in the hardy repositories apt-get source <packagename> would do.
[20:39] <stefanlsd> tacone: oh ok. thanks.  guess i dont need the dget then.
[20:39] <tacone> stefanlsd: otherwise launchpad has a package search
[20:39] <tacone> err. ubuntu.com
[20:40] <tacone> stefanlsd: http://packages.ubuntu.com/
[20:40] <stefanlsd> tacone: thanks thanks
[20:41] <tacone> stefanlsd: http://packages.ubuntu.com/source/intrepid/rapache
[20:41] <RichW> tacone, FOUND IT! pbuilder-buildpackage, line 119 -     DPKG_COMMANDLINE="cd tmp/buildd/*/; dpkg-buildpackage -us -uc <add -j4 here> $DEBBUILDOPTS"
[20:42] <RichW> I should build a packages version of pbuilder for my ppa :)
[20:42] <tacone> nice RichW. now there's nothing left between you and ruling the world.
[20:42] <RichW> patched*
[20:42] <RainCT> stefanlsd: Daniel wrote dget there so that it points always the same version; in the "real world" you would use "apt-get source" to get the latest version, if you have a deb-src entry for Intrepid in your /etc/apt/sources.list. dget is used to get packages from Debian (looking at packages.debian.org for the URL) or Ubuntu (packages.ubuntu.com or launchpad.net) versions which you don't have in your sources.list, from REVU (http://revu.tauware.de) 
[20:42] <RichW> tacone, Thanks, wish i was smart enough to be a motu myself :)
[20:42] <tacone> RichW: try to interact with motus or core-dev and see if you can get the patch incorporated
[20:43] <tacone> RichW: I wish I was smart enough to be a motu too :-D
[20:43] <RichW> tacone, Im working on that though. Im starting out with rebuilding ready made ones.
[20:43] <stefanlsd> RainCT: Thanks - got it :)
[20:44] <stefanlsd> One thing i cant find on the wiki is the latest standardsversion and what it entails...
[20:44] <geser> some months ago someone did rebuild the Debian archive with -j2 (or more, I don't remember anymore) and some packages failed to build
[20:44] <kdubois> more problems now, dpkg-shlibdeps complains that one of my libs shouldn't be linked with things (uses none of its symbols)
[20:47] <geser> RichW: see also http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options and look at parallel in DEB_BUILD_OPTIONS
[20:48] <geser> kdubois: patch the source to not link against the mentioned lib
[20:49] <kdubois> geser: i want it to link to that library though
[20:49] <RichW> geser, Ahhh! Thanks.
[20:50] <geser> kdubois: why do you want/need to link the library when the binary doesn't use it?
[20:52] <kdubois> the binary does use it though. i have no idea why its having symbol mismatch.
[20:53] <kdubois> and i'm actually not packaging a binary, i'm packaging a library
[20:53] <slangasek> kdubois: dpkg-shlibdeps is much more often right than wrong.  which lib is it complaining about?
[20:53] <slangasek> this is just a warning, though; lots of other packages in the archive get similar warnings
[20:54] <kdubois> this is a compiz plugin i wrote, and its complaining about everything, the compiz libraries, the opengl libraries, things it needs.
[20:55] <kdubois> and the library doesnt work once i install my package, so i'm pretty sure that dpkg-shlibs is correct in this case
[20:55] <slangasek> where could I see this plugin?
[20:58] <kdubois> http://gitweb.compiz-fusion.org/?p=users/kdubois/extra-animations;a=summary
[21:00] <stefanlsd> Where would i find  the latest standardsversion and what it entails?
[21:01] <DRebellion> stefanlsd, the latest standards-version is 3.8.0 iirc
[21:01] <stefanlsd> DRebellion: isnt it documented somewhere? The latest version and what it should include?
[21:01] <DRebellion> stefanlsd, probably ;)
[21:02] <norsetto> stefanlsd: check out the debian-policy package
[21:02] <kdubois> slangasek: the problem is probably still the static makefile it uses...
[21:03] <norsetto> stefanlsd: in there, there is also upgrading-checklist.txt.gz which helps for upgrading
[21:03] <kdubois> i wish i could just throw the working library made the regular way into dpkg-deb --build and be done with it. :D
[21:05] <stefanlsd> norsetto: thanks. i got it
[21:06] <norsetto> stefanlsd: be carefull that if you take the hardy one won't be the latest
[21:07] <stefanlsd> norsetto: got the intrepid one - 3.8.0.1
[21:07] <norsetto> stefanlsd: thats the good one
[21:11] <slangasek> kdubois: the problem probably has to do with compiz desp
[21:11] <slangasek> desp
[21:12] <slangasek> deps, gar
[21:14] <kdubois> slangasek: so just add related libraries to control until it works then?
[21:14] <slangasek> sorry, what?
[21:14] <slangasek> I thought we were talking about the dpkg-shlibdeps warning?
[21:15] <kdubois> yeah, i am. i guess that suggestion doesnt make sense then :P
[21:17] <slangasek> dpkg-shlibdeps is issuing a warning because your binary is directly linked against libraries that it doesn't use
[21:18] <slangasek> so if you're going to worry about the warning at all (which isn't required), you have to fix it by taking things /out/ of the upstream build process, not by adding things to debian/control
[21:18] <slangasek> dpkg-shlibdeps is calculating the package dependencies correct in any case - so this really is just a warning
[21:19] <kdubois> does it calculate it against the build deps or the install deps?
[21:19] <slangasek> it calculates it against what is actually contained in your binary
[21:20] <slangasek> i.e., it examines your library, sees what libraries it needs in order to be usable, and looks up the correct package dependencies for those
[21:20] <slangasek> and then it warns you if some of those library dependencies aren't actually used by your binary
[21:25] <kdubois> i'm gonna have to think about that for a bit
[21:25] <kdubois> ive had all the packaging i can handle for today
[21:25] <slangasek> fwiw, here's what 'pkg-config --libs compiz' spits out:
[21:25] <slangasek> -lX11-xcb -lXcomposite -lXdamage -lXrandr -lXinerama -lXcursor -lSM -lxslt -lstartup-notification-1 -lX11 -lxcb -lXfixes -lICE -lxml2
[21:26] <slangasek> you're certainly not using symbols from most of those libraries directly :)
[21:26] <slangasek> so this is really a compiz "bug", in that its .pc file tells people to link against libs they don't use
[21:26] <Wubbbi> DktrKranz: do you know How to Replace Icons in a Package? I mean you cant replace it with a patch. so how to do that?
[21:27] <slangasek> Wubbbi: convert the icon into a form that can be stored in a patch (i.e., uuencode it)
[21:27] <Wubbbi> slangasek: how to do that
[21:27] <slangasek> using the 'uuencode' command
[21:28] <slangasek> then use 'uudecode' somewhere in your debian/rules to convert it back to binary
[21:28] <slangasek> and be sure to remove that binary again in your 'clean' target, since otherwise dpkg-dev will give errors about unrepresentable changes to binary files
[21:29] <Wubbbi> slangasek: ok ... I have never done this befor ( with replacing Icons ) what is my first step?
[21:29] <kdubois> slangasek: i think i just got it working with debuild. cant seem to get pdebuild to do it
[21:30] <slangasek> kdubois: well, that sounds like a separate problem from the dpkg-shlibdeps warning, then. :)
[21:31] <slangasek> Wubbbi: looking at the uuencode manpage, I think :)
[21:32] <kdubois> yeah, thanks for the help everyone
[21:33] <Wubbbi> I found a wikipage https://wiki.ubuntu.com/PackagingGuide/Howtos/BinaryFilesInDiff ... But they just told me how to add ... not how to replace
[21:33] <Wubbbi> is that the same?
[21:34] <slangasek> Wubbbi: yes
[21:35] <Wubbbi> ok
[22:46] <nhandler> Are packages in main able to Depend on a package in Universe?
[22:46] <jpds> They can Suggest: not depend, as that package would then require a main inclusion report.
[22:47] <ScottK> Aren't suppose to recommend either.
[22:49] <Laney> protonchris: Hey, I see you've done a lot of updates to glom in the past. I assigned the update bug to myself, but just wanted to check whether you'd rather do it before I do anything.
[23:06] <mrayzenoss> I have a few possibly basic questions about getting a Zope application added as a package, any takers?
[23:07] <Jazzva> mrayzenoss, just ask. If someone knows, you will get your answers :).
[23:07] <mrayzenoss> Well, I'm the Community Manager for Zenoss and we use Zope 2.8.8, which is rather old
[23:07] <mrayzenoss> but we're stuck on it for now
[23:07] <mrayzenoss> and it requires Python 2.4, which I do see packaged
[23:08] <mrayzenoss> https://launchpad.net/ubuntu/+source/python2.4
[23:08] <mrayzenoss> other distros don't support Python 2.4, so that's where the discussion has usually stopped about getting Zenoss into a distro
[23:09] <mrayzenoss> basically I want to start seeing what kind of traction I can get with https://bugs.launchpad.net/ubuntu/+bug/251404
[23:10] <mrayzenoss> plus there are questions about our use of Google Maps, is that allowed as a restricted package?
[23:12] <mrayzenoss> and is Flash allowed?
[23:14] <Jazzva> flash should be allowed, I think. But it would get into multiverse.
[23:15] <Jazzva> I'm not sure what are the terms of use for Google Maps, you should wait for someone more competent to answer
[23:15] <mrayzenoss> so we could pull that out and make it a non-free Deb (I'm a Debian user myself)
[23:15] <mrayzenoss> still coming around to Ubuntu's layout :)
[23:15] <Jazzva> :)
[23:16] <directhex> multiverse is pretty much non-free + contrib - canonical support
[23:16] <Jazzva> Well, I suppose it could qualify for multiverse
[23:16] <mrayzenoss> well, Zenoss is GPL
[23:16] <mrayzenoss> it's just we use Flash and Google Maps
[23:16] <directhex> so are most apps in contrib
[23:16] <mrayzenoss> but I could pull those out potentially
[23:16] <directhex> that's the point of contrib - free apps depending on non-free
[23:17] <directhex> in ubuntu, both live in multiverse
[23:17] <mrayzenoss> understood
[23:17] <Jazzva> mrayzenoss, I haven't worked a lot with Flash. I suppose that if there is a way to pass the source of the Flash file in the package, then it should be ok
[23:17] <mrayzenoss> the source is all available
[23:18] <mrayzenoss> the Debian folks didn't want anything to do with Flash
[23:18] <mrayzenoss> or Google
[23:18] <Jazzva> mrayzenoss, and as for Google Maps, I don't know if it's allowed. It might be...
[23:18] <mrayzenoss> I have a potential replacement for that
[23:18] <mrayzenoss> OpenLayers
[23:20] <mrayzenoss> so is there a proper channel to work through to help me tackle all the dependencies issues?  Like someone I can approach to handle all my questions individually?  Not that IRC isn't great and all :)
[23:21] <mrayzenoss> it's just we're a large application with a lot of potential blockers
[23:22] <mrayzenoss> but if I can get a roadmap in place, I can get working on proper Ubuntu packaging
[23:22] <mrayzenoss> as opposed to our .bin most Ubuntu users have been using
[23:22] <directhex> mrayzenoss, i think there's a MOTU mailing list, but this is probably the best place on IRC
[23:23] <directhex> mrayzenoss, usual timezone irc caveats apply
[23:23] <mrayzenoss> yeah, I didn't want to spam up the MOTU mailing lists
[23:23] <mrayzenoss> but I'll look for the right one to post to
[23:27] <mrayzenoss> I guess the ubuntu-motu mailing list will be a good place for my big email.  Thanks
[23:30] <Jazzva> mrayzenoss, no problem. Good luck :)
[23:34] <emgent> evening
[23:37] <nhandler> Good evening emgent
[23:42] <emgent> nhandler: :)
[23:46] <bdrung> is here someone from the mozilla team?
[23:47] <Jazzva> bdrung, I am.