[00:01] <geser> let's see where this discussion will lead to once all devs are back from weekend
[00:31] <amikrop> Hello, where can I find the PPA version of gnome-screensaver?
[00:31] <amikrop> Because I have the problem with screensaver coming on when watching fullscreen in VLC.
[00:32] <amikrop> And as I read in LP, the PPA version is the only solution yet.
[00:33] <MsMaco> whose ppa do you want it from?
[00:33] <MsMaco> i'm sure more than one prson has packaged gnome-screensaver somewhere. whatever but report you're reading should specify
[00:33] <MsMaco> *bug
[00:34] <amikrop> ok
[00:34]  * ajmitch would guess from the gnome-screensaver page on LP that it's the version in the motumedia PPA
[00:34] <amikrop> I found it on LP
[00:34] <MsMaco> https://launchpad.net/+search?field.text=gnome-screensaver+ppa says the 3rd result has versions of gnome-screensaver for gutsy, hardy, and intrepid...
[00:34] <amikrop> ajmitch: yeah, where can I find that?
[00:34] <MsMaco> probably launchpad.net/~motumedia?
[00:34] <amikrop> I need the motumedia one
[00:35] <ajmitch> https://launchpad.net/~motumedia/+archive/ppa
[00:38] <amikrop> ajmitch: so, I should add the PPA to the software sources of mine? can't I just download the specific package?
[00:39] <amikrop> ok, found it
[00:39] <amikrop> hope it helps
[00:40] <amikrop> also, hope the patched package gets into the main repos
[00:40] <amikrop> thanks
[00:40] <lifeless> *blink*
[00:40]  * ajmitch shrugs
[00:40] <ajmitch> it should be aa fairly trustable PPA anyway :)
[01:20] <jgoppert> hey guys, so i want to get libjsw up and running by disabling jscalibrator directory from being called in the debian/rules and eliminating the binary from debian/control, what is the best way to do this, extract the orig tarball, apply the patch, edit, and the diff with the orignal to get an updated patch?
[01:33] <jgoppert> hey guys trying to package libjsw with jscalibrator disabled on karmic, got debuild to run finally, so now when uploading to my ppa do i need to upload the original tarball since it isn't in karmic yet, or do i need to use debuild -S or what?
[01:35] <ajmitch> looks like it's not in karmic due to probable removal
[01:35] <ajmitch> -S is always required, -sa will include the orig tarball
[01:39] <jgoppert> its not in karmic yet because it ties into gtk 1.2 but they are working on repackaging it with gtk 2.0, -sa will include the tarball in the changes file?
[01:41] <ajmitch> yes it will
[01:41] <jgoppert> thanks
[01:41] <ajmitch> I expect you'll probably have to edit more than debian/rules to disable the gtk+ app in there
[01:41] <ajmitch> like removing it from debian/control, various .install files, etc
[01:42] <ScottK> jgoppert: A better bet then is to get it into Debian and sync it into Ubuntu from there.
[01:43] <ajmitch> ScottK: it's still in sid, not quite removed yet
[01:44] <ScottK> ajmitch: Ah, even better.
[01:44] <ScottK> jgoppert: Work on getting it fixed in Debian and then have it sync'ed it Ubuntu.
[01:44] <ajmitch> if you're really keen, offer to adopt the package in debian if you want to maintain it :)
[01:45] <ScottK> Personally, with still 5% of the existing Ubuntu archive unable to be built from source, I'm not particularly excited about the prospect of adding more stuff we need to maintain to an LTS release.
[01:46] <jgoppert> well i'm really just a beginner, i just disabled jscalibrator which was the only really gtk dependency
[01:46] <jgoppert> only 5%, wow i didn't know that
[01:46] <ajmitch> looks like persia was offering to help maintain it in the debian games SVN repository
[01:47] <ajmitch> 5% is still too high
[01:47] <jgoppert> oh i read that backward, lol
[01:47] <ajmitch> everything in a release should be buildable on that release, IMO
[01:47] <ajmitch> but that's a lot of work for stuff carried forward over a few years :)
[01:48] <jgoppert> i was relying on checkinstall for the longest time, finally took the plunge into real packaging
[01:48] <ScottK> ajmitch: My proposal is another rebuild test and remove the binaries for anything that FTBFS.  That way we know everything was at least buildable at some point during the cycle.
[01:48] <ajmitch> ScottK: debian has it slightly easier in that stuff can be ejected from testing without being removed altogether
[01:48] <ScottK> Yep.
[01:49] <ScottK> We could at least not deliver binaries we don't have a hope of building.
[01:49] <ScottK> ajmitch: I got one package removed in Karmic that hadn't been touched since Warty.
[01:49] <ajmitch> that's probably worthwhile
[01:49] <ajmitch> was this one of the ones imported from apt-get.org that we were discussing?
[01:49] <ScottK> I think so
[01:50] <ScottK> It was never in Debian.
[01:50] <ajmitch> LTS is a good time for a cleanup
[01:50] <wgrant> You can check the old -changes archives to see where something came from.
[01:51] <jgoppert> when is the next lts release?
[01:51] <wgrant> jgoppert: 10.04
[01:51] <ajmitch> in april 2010, the development of it is just starting
[01:52] <jgoppert> nice, hopefully i'll be able to contribute by then to the packaging effort
[01:54] <jgoppert> so basically debuild -S just doesn't produce the .deb files
[01:55] <ajmitch> yes, -S means source-only, which is what's required for uploading to launchpad
[01:55] <jgoppert> ok and it looks like it appends source instead of the dist, so i'm assuming thats how apt-get source works?
[01:56] <ajmitch> apt-get source just grabs the .orig.tar.gz, .dsc & .diff.gz files listed in the repository's Sources index
[01:56] <ajmitch> basically just what you upload
[01:57] <jgoppert> ok, so this is a typical name to upload libjsw_1.5.6-0ubuntu3~hsl1_source.changes
[01:57] <ajmitch> with dput, yes
[01:58] <jgoppert> cool, how do i get files off there, because i uploaded a whole set with amd64 instead of source in the name
[01:58] <ajmitch> if you uploaded them to a PPA, they would have been rejected
[01:59] <jgoppert> ok, the command line didn't say anything, i guess i have to wait for launchpad to process it?
[02:00] <ajmitch> yes
[02:01] <jgoppert> ok, so if i started to maintain libjsw, what do i need to do, do i just upload to a different ppa?
[02:02] <ajmitch> maintenance would preferably be done in debian, because the maintainer has offered the package for adoption there
[02:03] <ajmitch> either way, you'd need to start off by getting the package upload sponsored
[02:03] <ajmitch> that is, someone with upload rights would need to upload it to debian or ubuntu
[02:04] <jgoppert> yeah, i tried to upload to my personal ppa and i got this? Rejected:
[02:04] <jgoppert> The signer of this package has no upload rights to this distribution's primary archive.  Did you mean to upload to a PPA?
[02:04] <jgoppert> Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.
[02:04] <jgoppert> libjsw (1:1.5.6-0ubuntu3~hsl1) karmic; urgency=low
[02:04] <jgoppert>   * Disabled jscalibrator due to gtk 1.2 dependency.
[02:04] <ajmitch> how did you try & upload to a PPA?
[02:05]  * ajmitch can't remember the relevant dput option to automatically pick your ppa
[02:05] <jgoppert> oh wow i didn't specify my ppa, guess thats how i upload to the real ubntu?
[02:05] <wgrant> That is the real Ubuntu, yes.
[02:05] <wgrant> dput ppa:user/ppa blah.changes
[02:05] <ajmitch> thanks wgrant
[02:05] <jgoppert> cool, yeah i think i got it now
[02:06] <ajmitch> saves me digging around for it
[02:07] <jgoppert> thanks for your help guys, has really helped me figure this out
[02:07]  * wgrant stabs Soyuz sample data in the face a few times.
[02:08] <ajmitch> wgrant: make some better sample data
[02:09] <ajmitch> how goes the great overhaul for new-style source packages?
[02:09] <wgrant> Nearly there. Nearly there.
[02:09] <lifeless> ajmitch: sample data *is the problem*
[02:10] <wgrant> sample data is useful.
[02:10] <ajmitch> lifeless: I'd believe it, I hate trying to test some of the stuff I do at work due to having to create sample data for the weird corner cases
[02:10] <jgoppert> success, 2 pending builds
[02:10] <jgoppert> :-)
[02:13] <jgoppert> what is lpia, is that like the atom processor?
[02:14] <ScottK> jgoppert: It is, but technically it's just like i386 now
[02:14] <ScottK> Up through Jaunty there was some attempt at optimization for Atom, but it was dropped in Karmic.
[02:15] <jgoppert> oh ok, thanks, yeah i've got a little dell mini 9
[02:15] <wgrant> Is it kept in karmic for the lpia-specific functionality patches, or just for the upgrade path?
[02:17] <jgoppert> how long do personal ppa builds take?
[02:17] <lifeless> depends
[02:18] <wgrant> jgoppert: If you click on the architecture label in the appropriate row of your PPA table, it will give you an estimate of the start time.
[02:18] <wgrant> Although in two days that will be wildly inaccurate :(
[02:18] <jgoppert> why is that?
[02:18] <wgrant> Internal build queueing changes.
[02:18] <wgrant> Without corresponding queue length calculation changes.
[02:19] <jgoppert> 5 hours.. ouch
[02:19] <ajmitch> inaccurate as in a few hours/days?
[02:19] <lifeless> wgrant: :(
[02:19] <wgrant> ajmitch: Depends on the length of the queue.
[02:19] <wgrant> Basically, build will become a lot more serial from Thursday.
[02:19] <wgrant> *builds
[02:20] <wgrant> So the estimate will be lower than it should be.
[02:20] <ajmitch> do any of the PPA buildds get repurposed for the flood of autosyncs for lucid?
[02:21] <wgrant> No.
[02:21]  * ScottK thinks the flood won't be so great if they sync from testing.
[02:21] <jdong> that kinda was a surprise :)
[02:21] <ajmitch> there'll be enough updates
[02:21] <ajmitch> jdong: yes, for many people
[02:21] <ajmitch> I noticed it a few days before release when looking at the lucid schedule
[02:22] <jdong> heh I personally think it's slightly ironic to try something this drastically new for a LTS
[02:22] <ScottK> It was discussed at the last UDS, but for continuing to sync from testing after Debian freezes, not for the whole cycle.
[02:22] <wgrant> ScottK: There are still approximately far too many.
[02:22] <wgrant> ScottK: The page is still loading...
[02:22] <lifeless> ScottK: didn't you hear, its more stable.
[02:22] <wgrant> 2432 syncs fro
[02:22] <wgrant> ... from Squeeze
[02:22] <ajmitch> lifeless: sure, and how many people run testing compared to unstable?
[02:22] <wgrant> 1117 merges.
[02:22] <jdong> it'll be even more stable if we swap out the init daemon after feature freeze again!
[02:22] <jdong> oh wait *cough*
[02:23] <jdong> *goes back to his corner*
[02:23] <ScottK> Well it makes "get it into Debian so we don't maintain it" a lot harder to sell.
[02:23] <lifeless> ajmitch: turn up the gain on your sarcasm detector
[02:23] <ScottK> jdong: If it was insanity, it was at least planned insanity.
[02:23] <lifeless> ajmitch: going to pyconnz?
[02:23] <wgrant> ScottK: It's not much of a problem; I don't imagine that Squeeze will freeze before Lucid.
[02:23] <ajmitch> lifeless: don't worry, I knew it was sarcasm :)
[02:23] <ajmitch> and yes, I'm heading up on friday
[02:23] <ScottK> wgrant: It's scheduled for March.
[02:23] <wgrant> ScottK: Ha ha ha.
[02:24] <ajmitch> wgrant: you sound like you don't believe that
[02:24] <ScottK> wgrant: No, freeze schedules are reasonably reliable.  It's release schedules that are unbelievable.
[02:25] <jgoppert> hey guys i tested my packaged in pbuilder and had this error? The following packages have unmet dependencies:
[02:25] <jgoppert>   pbuilder-satisfydepends-dummy: Depends: libgtk1.2-dev which is a virtual package.
[02:25] <jgoppert> The following actions will resolve these dependencies:
[02:25] <jgoppert> Remove the following packages:
[02:25] <jgoppert> pbuilder-satisfydepends-dummy
[02:26] <jgoppert> I grepped for libgtk and got nothing left after i wiped it out.
[02:27] <jdong> gtk1 is poof, is it not?
[02:27] <wgrant> Does anybody recall if all the buildds are running Hardy yet?
[02:27] <ajmitch> jdong: it is
[02:27] <jgoppert> yeah it is, i'm repackaging libjsw from jaunty
[02:27] <ajmitch> jgoppert: make sure you're building your revision of the package
[02:27] <jgoppert> oh, good call, let me check
[02:27] <ajmitch> since I can see on LP that you removed the libgtk1.2-dev from build-depends
[02:29] <jgoppert> the dangers of wildcard, lol *.dsc.. oops
[02:30] <jdong> indeed
[02:30] <jdong> it's certainly caused directhex to accidentally shove 2 or 20 packages into the Ubuntu queue
[02:30] <jgoppert> good thing i did that forgot a -f on a rm command
[02:30] <jdong> *ducks* :)
[02:30] <jgoppert> lol wow
[02:30] <jdong> lazy typing FTW :)
[02:30] <ajmitch> jdong: I'm sure he'd never ever do such a mistake
[02:31] <jdong> lol he fixed his overzealous dput by now :)
[02:31] <ajmitch> besides, he's probably not awake at the moment to hassle about it
[02:32] <jdong> lol I'm sure I'll be slapped by the time I wake up tomorrow morning
[02:32] <ajmitch> we can only hope
[02:33] <serialorder> jgoppert: you are still applying patches in debian/patches that  modify files in jscalibrator/ which seems a little bit silly since you arent building that package. It wont prevent it from building correctly though
[02:35] <jgoppert> serialorder, to my knowledge i didn't modify anything in jscalibrator, i just removed the statements dealing with it and eliminated the gtk dependency?
[02:35] <jgoppert> ok so i jacked up and submitted a package on my ppa without checking it with pbuilder, how best to delete the old one and submit the new one?
[02:38] <kklimonda> jgoppert, upload a new one with a newer version
[02:38] <kklimonda> jgoppert, you cn try deleting it from ppa but I've had mixed results with that :)
[02:38] <jgoppert> ok thanks
[02:39] <ScottK> Even if you've deleted it, you still need to increment the revision
[02:39] <serialorder> jgoppert: if i were packaging this I would split those patches into two sets of files. Those that patch files in jscalibrator and those that don't. Then you can enable to non-jscalibrator patches in 00list and leave the others out. It just seems wrong to patch files you aren't going to use.
[02:40] <wgrant> You can never upload the same version again.
[02:40] <wgrant> You can sometimes upload an older version if you really know what you're doing.
[02:40] <wgrant> But it should not be relied upon.
[02:41] <jgoppert> oh i see, yeah those were from the old package, i didn't modify those, i figure i might get around to fixing the gtk stuff in jscalibrator eventually and don't want to mess up what was done there
[02:42] <jgoppert> warning: the current version (1:1.5.6-0ubuntu3~hsl1) is smaller than the previous one (1:1.5.6-0ubuntu3)
[02:42] <wgrant> That's true.
[02:42] <jgoppert> what should i do about this, take ubuntu back down to 3?
[02:42] <jgoppert> i mean zero?
[02:42] <wgrant> What's the current version?
[02:42] <wgrant> In Ubuntu, that is.
[02:42] <jgoppert> well in jaunty 0ubuntu3
[02:42] <jgoppert> nothing in karmic
[02:42] <wgrant> Perhaps make it 3+hsl1
[02:43] <wgrant> Since your package is not less than the old version.
[02:44] <jgoppert> what if i went to 0ubuntu4~hsl1 so if some other packager releases a new one it will overtake mine?
[02:44] <syn-ack> hrm
[02:44] <jgoppert> is that what they would do typically going from jaunty 0ubuntu3 to karmic?
[02:44] <wgrant> jgoppert: -0ubuntu3+blah has that same property. -0ubuntu4 is greater than it.
[02:45] <wgrant> The next official version will be at least -0ubuntu4.
[02:45] <jgoppert> ok, thanks
[02:45] <syn-ack> there was a link in the topic... I think in here wrt open week? anyone happen to know what it is?
[02:45] <jgoppert> i'll go with the + then
[02:48] <syn-ack> neeeever mind... Sorry to bug yall it was in yet another ubuntu related channel.
[04:12] <eboyjr> Can I get my patch sponsored? https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/470008
[04:25] <Amaranth> eboyjr: that's in main and the desktop team handles it so you'll want to talk to the folks in #ubuntu-desktop
[04:25] <Amaranth> eboyjr: but they won't be around for at least 3 more hours
[04:25] <Amaranth> and it's too early to upload anything to lucid
[04:26] <Amaranth> eboyjr: and it can't go into karmic because it's not a critical issue and it's sort of a UI change
[04:26] <eboyjr> Okay and why won't they be around?
[04:26] <eboyjr> Ah
[04:26] <Amaranth> eboyjr: they're all in europe :)
[04:26] <Amaranth> oh, and you need to attach a diff of the diff
[04:26] <JanC> reading https://wiki.ubuntu.com/Bugs/HowToFix & https://wiki.ubuntu.com/SponsorshipProcess might be useful too
[04:26] <Amaranth> or a debdiff would be even better
[04:28] <eboyjr> Those are the pages I read and okay I'll try to make a debdiff somehow whatever that it
[04:28] <eboyjr> s/it/is
[04:28] <JanC> they'll probably want a patch against the lucid version too, by the time it's ready
[04:28] <JanC> ;)
[04:28] <jgoppert> hey if i have a package on my ppa thats not yet in ubuntu would the version be opencv-2.0.0-0hsl1 or 0ubuntu0+hsl1
[04:29] <eboyjr> LOL I'll just leave my patch out there in cyberspace then...
[04:30]  * Amaranth really wants to redo that whole tab anyway
[04:30] <Amaranth> or at least the code behind it, the UI is fine
[04:33] <eboyjr> Ah I like my feature though so please let me implement it (or have it implemented for me). But can I have a bug to fix then? I'm in a code-y mood
[04:35] <jgoppert> hey any way to get autotools to dump library dependencies to control file
[04:36] <Amaranth> eboyjr: there are something like 80,000 bugs open
[04:36] <Amaranth> finding one to fix should not be a problem :)
[04:37] <eboyjr> Haha I'm looking for a juicy bug thanks =)
[04:37] <lifeless> eboyjr: do a sort byb importance, pick one
[04:37] <lifeless> jgoppert: not currently
[04:38] <jgoppert> lifeless: thanks, that too bad
[04:40] <Amaranth> lifeless: all the critical bugs are hard
[04:40] <Amaranth> although some of the High ones can be pretty easy
[04:40] <jgoppert> so is my only option to add one library at a time using pbuilder to find the missing ones until it is all done?
[04:40] <eboyjr> By importance, I get bug from Edgy and stuff :P
[04:40] <lifeless> jgoppert: yes, or read the configure script
[04:40] <jgoppert> thanks
[04:40] <lifeless> (.in or .ac I mean)
[04:44] <jgoppert> if you have a really long list of dependencies in a control file is there a line continuation or do you just keep typing?
[04:45] <lifeless> theres a continuation
[04:45] <jgoppert> \ ?
[04:45] <lifeless> see policy for file format information
[04:45] <lifeless> [I could just tell you, but then you'd not know how to find the answer to the next question :)]
[04:45] <jgoppert> true .. lol
[04:46] <jgoppert> well where is the policy file ?
[04:46] <lifeless> apt-get install debian-policy
[04:46] <jgoppert> thanks
[04:46] <lifeless> dpkg -L debian-policy
[04:51] <jgoppert> got it :-)
[05:08] <jgoppert> how often do you guys update your pbuilder, roughly speaking
[05:11] <lifeless> jgoppert: every build, precisely speaking
[05:12] <jgoppert> yeah i guess you are right, no reason to risk it
[05:31] <jmarsden> Why might I be seeing idle builders at http://launchpad.net/builders, but LP tells me my PPA builds will start in 4 hours... ?
[05:32] <hellothere1> time constraints.....
[05:32] <micahg> Archive builders are empty, PPA builders are busy
[05:34] <jmarsden> Ah, OK... and we can't use empty archive builders for PPA work... because a PPA build might take a long time and a new urgent archive build *might* come along in the meantime?  Or are they really configured very differently?
[05:35] <micahg> different build farm
[05:36] <jmarsden> It would be more efficient to have a single queue, at least in theory... oh well.  I can attempt to be patient :)
[05:37] <ScottK> For something that's urgent you can ping a buildd admin to get a build rescored.
[05:38] <jmarsden> My stiff is not urgent, it just seems sad to have build hardware waiting idle and a multi hour backlog of builds...
[05:38] <jmarsden> *stuff
[05:38]  * eboyjr didn't know Launchpad had a build farm that is crazy cool
[05:41] <jmarsden> eboyjr: Yes.  When you upload a package to your PPA it gets built on multiple architechures automatically... that what the (PPA) build farm does.  See https://help.launchpad.net/Packaging/PPA
[05:42] <ScottK> jmarsden: I'd tend to go the other way.  The Ubuntu toolchain maintainers are working on getting the toolchain for Lucid ready right now.  I think the notion that a PPA upload might be allowed to block progress on getting Lucid open for development quite odd.
[05:43] <eboyjr> O I C it uses Xen
[05:44] <jmarsden> ScottK: Well, sure, if they need the hardware they should be able to grab it.  Even kill a PPA build in progress and requeue it, if necessary.  But that's surely doable with mimimal delay and would thus allow idle hardware to be used when toolchain maintainers *don't* have need of it.
[05:45] <micahg> Maybe make a feature request in soyuz
[05:46] <ScottK> jmarsden: It takes a buildd admin to kill a build, so it's not always doable with minimal delay
[05:47] <ScottK> There is work in progress to pool the buildd's, but I don't know the details.
[05:47] <jmarsden> ScottK: OK.  I had assumed they already *were* a single pool, basically.
[05:48] <ScottK> No.  One of the big differences is that PPA buildds are virtualized and the distro buildd's aren't.
[05:49] <jmarsden> OK.  Just for curiosity... is that for "historical" reasons, or do distro buildd's actually *need* to be real physical machines?
[05:55] <eboyjr> I would assume that PPAs are only virtualized for security reasons
[05:55] <JanC> I guess one reason is that virtualization helps a bit with security (everybody can try to abuse a PPA builder)
[05:55] <JanC> heh  :P
[05:55] <eboyjr> lol..
[05:56] <eboyjr> And that distro builds need to be able to be built on physical machines for e.g. testing
[05:56] <eboyjr> testing as in other people can fixs bugs and compile on their own system
[05:56] <JanC> well, it also helps that you can use a pre-made image to boot a builder, so that would be useful for the distro builders too
[06:40] <jgoppert> can anyone help me, i've got zlib as a dependency in my control file but when i use pbuilder its getting undefined references to symbols in the zlib library, what could be going on?
[06:41] <micahg> jgoppert: do you have the -dev version as the build-dep?
[06:42] <jgoppert> for opencv-dev i have zlib1g-dev, for opencv2 i have zlib1g
[06:44] <jgoppert> micahg: for opencv-dev i have zlib1g-dev, for opencv2 i have zlib1g
[06:45] <micahg1> can you pastebin your contorl file?
[06:45] <micahg1> *control
[06:46] <lifeless> jgoppert: you shouldn't manually list the binary library
[06:46] <lifeless> jgoppert: shlib-deps will get that for you\
[06:46] <jgoppert> thats what i thought but i was getting that error so i thought it missed it, what could be wrong then
[06:47] <jgoppert> Source: opencv
[06:47] <jgoppert> Priority: extra
[06:47] <jgoppert> Maintainer: James Goppert <jgoppert@users.sourceforge.net>
[06:47] <jgoppert> Build-Depends: debhelper (>= 7), autotools-dev
[06:47] <jgoppert> Standards-Version: 3.8.1
[06:47] <jmarsden> jgoppert: use pastebin please :)
[06:47] <jgoppert> what's pastebin?
[06:48] <jgoppert> is it an irc command?
[06:48] <jmarsden> !pastebin
[06:48] <StevenK> !pastebin
[06:48] <StevenK> jmarsden: Sorry :-)
[06:48] <jgoppert> !pastebinit
[06:49] <jgoppert> !pastebin
[06:49] <jgoppert> http://paste.ubuntu.com/307295/
[06:51] <micahg1> jgoppert: you probably need to add zlib1g-dev to the source build-depends on line 4
[06:53] <jgoppert> so build depends is everything needed to build the package then, and the others are just for package management?
[06:53] <micahg> yes, anything that needs to be installed alongside the package in question
[06:53] <jgoppert> so i'm assuming all of my -dev's need to go up there?
[06:53] <micahg> most likely, if they're needed for building
[06:53] <jgoppert> i see
[06:54] <jgoppert> thanks
[06:55] <micahg> np
[06:55] <jgoppert> so should i remove the -dev's from the opencv-dev ?
[06:55] <jgoppert> and i definetly should remove the libs opencv2 right?
[06:56] <micahg> yes, shlibs should take care of that as lifeless said
[06:56] <jgoppert> ok , what about on opencv-dev leave the -dev packages?
[06:57] <micahg> jgoppert: I don't know
[06:57] <micahg> maybe someone else can answer :)
[06:59] <jgoppert> hope so :-), i'll go ahead and launch my pbuilder and cross my fingers
[06:59] <hyperair> hmm packaging libraries here?
[07:10] <dholbach> good morning
[09:14] <\sh> moins
[09:16] <eboyjr> MoinMoin
[09:31] <DexterLB> hello
[09:31] <DexterLB> in which channel can I ask about packaging and debuild errors etc?
[09:32] <jmarsden> DexterLB: This one.
[09:32] <DexterLB> ah ok
[09:33] <DexterLB> I've made my first cmake app and it works! now I want to make a debian package
[09:33] <DexterLB> I use cdbs and when I do 'debuild -S -sa -k<my key>' it creates and signs the source-only package as expected but if I do 'debuild -sa -k<my key>' to create a binary package it does build it and puts the binaries in the right place in the debian folders, but I get an error. http://pastebin.com/m1253c568
[09:33] <DexterLB> what list file is dpkg-buildpackage referring to?
[09:34] <DexterLB> actually dpkg-genchanges
[09:35] <jmarsden> I think one it uses itself.  Does a straight     debuild    (with no options) work?
[09:35] <DexterLB> I'll try now
[09:37] <DexterLB> same error
[09:37] <DexterLB> :(
[09:38] <DexterLB> should I pastebin my rules, changelog and control files?
[09:39] <jmarsden> Hmmm.  Sounds to me like a cmake-specific thing.  I'm no expert at all on cmake and it is 1:38am here... I'd suggest you see if someone else has better ideas than mine :)
[09:40] <DexterLB> it's 11:38am here
[09:41] <DexterLB> I'll ask google (again) :D
[09:41] <slytherin> DexterLB: Do you have a install file in debian/ directory?
[09:43] <DexterLB> no
[09:43] <DexterLB> cd debian && ls: http://pastebin.com/m578e5eb7
[09:44] <jmarsden> DexterLB: One thought before I sleep: you are using a -1ubuntu1 version number, is there really a -1 package of this software already in Debian?  If not, use -0ubuntu1 .. I wonder if that is confusing anything related to the error you are seeing??
[09:44] <DexterLB> oops
[09:44] <DexterLB> wait, I'll try
[09:44] <DexterLB> good night btw
[09:45] <jmarsden> Goodnight.
[09:46] <DexterLB> I removed all .ex files from debian and fixed 1ubuntu1 to 0ubuntu1
[09:46] <DexterLB> now building...
[09:47] <DexterLB> and same error
[09:50] <DexterLB> slytherin: here are the contents of debian/ :  changelog compat control copyright dirs docs README.Debian rules
[09:51] <slytherin> DexterLB: that is your problem. You need to have install file specifying what all files should go into the resulting .deb package.
[09:51] <DexterLB> BUT
[09:52] <DexterLB> cdbs executes make install
[09:52] <DexterLB> and after the debuild, despite the error, there is a folder debian/timelapse/usr/bin which contains the executable
[09:53] <jmarsden> DexterLB: Yes, but I think what slytherin is saying is that debuild doesn't know it should package those files, until you tell it to do so.
[09:54] <jmarsden> By listing usr/bin/whatever in a file named debian/install
[09:54] <DexterLB> aaah
[09:56] <DexterLB> so I create a file debian/install containing "debian/timelapse ."
[09:57] <DexterLB> or "debian/timelapse/usr/bin/timelapse usr/bin/timelapse" for file-specific
[09:57] <jmarsden> DexterLB: No, containing   the one line   /usr/bin/timelapse        if that is the file you are packaging.
[09:57] <DexterLB> I'll try
[09:57] <jmarsden> Sorry, make that usr/bin/timelapse, no leading / if I remember rightly.
[09:57] <DexterLB> yeah
[09:57] <DexterLB> ok
[09:58] <gaspa> dholbach: around? have you a moment?
[10:00] <DexterLB> did it, built, same error :(
[10:07] <dholbach> gaspa: yep
[10:08] <gaspa> warp10 and I have a question for you ;)
[10:08] <dholbach> sure
[10:12] <gaspa> dholbach: we're in #6had, just to not bother this channel... k?
[10:13] <DexterLB> rules: http://pastebin.com/m772a1040
[10:13] <DexterLB> control: http://pastebin.com/mbebecd0
[10:13] <DexterLB> changelog: http://pastebin.com/m42a68215
[11:52] <Rocha> good morning
[11:54] <Rocha> i want to file a bug report for rhythmbox and i can't because i'm behind a proxy server
[11:54] <Rocha> how should i file the bug?
[11:54] <Rocha> the "report a problem" from the help menu doesn't support proxy
[11:58] <micahg> Rocha: ubuntu-bug?
[11:59] <Rocha> i suppose ubuntu-bug uses apport
[11:59] <Rocha> and apport doesn't support proxy
[11:59] <Rocha> but i'll try anyway
[12:00] <Rocha> micahg: yes, i'm correct, it doens't work
[12:01] <Rocha> i filed the bug to rhythmbox's bugzilla
[12:01] <micahg> Rocha: instructions for manually filing are here: https://help.ubuntu.com/community/ReportingBugs
[12:02] <Rocha> i just wanted to report that rhythmbox can't get track names if you're behind a proxy
[12:02] <Rocha> micahg: i've already read that
[12:02] <micahg> obviously not
[12:02] <micahg> https://help.ubuntu.com/community/ReportingBugs#Filing%20bugs%20at%20Launchpad.net
[12:03] <Rocha> sorry, i really missed that
[12:03] <micahg> :)
[12:04] <slytherin> Rocha: may be the problem is with your proxy
[12:04] <Rocha> i'll get the source for rhythmbox to see if i can fix the bug
[12:05] <Rocha> slytherin: i suppose the protocol is the same for all proxies
[12:05] <Rocha> if other applications work, rhythmbox should work too
[12:05] <Rocha> i'm using a web based chat client throught proxy using firefox
[12:07] <Rocha> i've just found a bug in gnome-panel also
[12:23] <Rocha> i hope this bug is easy to fix
[12:24] <Rocha> unfortunately rhythmbox is coded in C
[12:24] <Rocha> i don't know why people insist on using C for desktop applications
[12:27] <Rocha> slytherin: i just installed banshee and it gets the track names, so it's really lack of proxy support in rhythmbox
[13:22] <serialorder> I am looking at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html and I am wondering why there are FTBFS for superseded packages, anyone care to explain?
[13:23] <wgrant> serialorder: Those are packages that failed to build in the rebuild archive, but were subsequently superseded by packages in the primary archive.
[13:23] <wgrant> serialorder: Most likely making the results unuseful.
[13:25] <serialorder> i guess i am trying to figure out why we would care that they FTBFS if they have been superseded by a newer version? Unless I misunderstand supersede?
[13:26] <Laney> That was the archive as at 09/09/09
[13:26] <Laney> things may have changed since then
[13:27] <serialorder> oh so its not the package that has been superseded its the build?
[13:28] <serialorder> its not that a new upstream version has come out but that there has been a new build process
[14:22] <jdong> ugh
[14:22] <jdong> I'm a bit upset with bug 216398
[14:23] <jdong> did we really SRU dosemu to set mmap_min_addr back to 0 for the *entire system*?
[14:23] <jdong> maybe I should SRU a firegpg package to rm /etc/init/apparmor.conf because it prevents accessing my GnuPG keys.
[14:25] <jdstrand> jdong: /etc/init/apparmor.conf... I don't have that file?
[14:25] <jdong> whatever file stops apparmor from loading at boot.
[14:26] <jdstrand> jdong: you are referring to mmap_min_addr still? that is a sysctl value and nothing to do with apparmor
[14:26] <jdong> it would've at least been nice to have a postinst warning dialog that installing dosemu will defeat a security feature
[14:26] <jdong> jdstrand: apparmor was just an example for another security feature on by default
[14:27] <jdstrand> jdong: firegpg is for firefox?
[14:27] <jdstrand> jdong: the firefox apparmor profile is not enabled by default
[14:27] <jdong> ok forget that example
[14:28] <jdong> I also do not see a motu-sru ACK on the bug
[14:29] <falktx> i've something to ask to you, motu guys
[14:30]  * jdstrand finally gets jdong's point
[14:30] <falktx> i've written a software some time ago
[14:30] <falktx> what do I need to do to make it go to Lucid universe?
[14:31] <jdong> it would seem like wine does the same
[14:31] <jdstrand> jdong: so, I think kees had some ideas for mmap_min_addr on a per application basis (dosemu and wine are the two I know of)
[14:31] <jdong> jdstrand: yeah, that's what I would've expected to be the solution in the first place...
[14:31] <jdstrand> jdong: I don't recall off-hand what he had in mind, but it requires changes to the system iirc
[14:32] <jdstrand> jdong: it isn't possible atm
[14:32] <jdong> understood
[14:32] <jdstrand> but there might be a way to do it
[14:32] <jdong> I think particularly for something like dosemu, should a user be told "Installing this will defeat a security feature put in place to prevent a recent class of root exploits from reoccuring"....
[14:32] <jdstrand> jdong: for some reason, I want to say it actually *does* have something to do with apparmor...
[14:32] <jdong> the user might not want the package anymore
[14:32] <jdstrand> it is starting to come back now
[14:33] <jdstrand> I think jj and kees thought we might be able to add a feature to AA that would allow you to specify the mmap_min_addr in the profile somehow
[14:33] <jdstrand> and override the system default
[14:33] <jdong> ah cool
[14:33] <jdong> SELinux currently has this capability, right?
[14:34] <jdstrand> so dosemu and wine could conceivably have a very lenient profile that changes the mmap_min_addr
[14:34] <jasonix> hi all - just getting started here - excited about ubuntu - checked out the contributing wiki - so, first, do I simply start with BugSquad???
[14:34] <jdstrand> jdong: it has something like this, but it caused them some grief not too long ago
[14:35] <falktx> no one cares about me?
[14:35] <kklimonda> btw, why was apparmor chosen over selinux? I can't seem find a good rationale anywhere
[14:35] <jdstrand> jdong: it would obviously have to be done right so that it didn't introduce any holes and couldn't be circumvented
[14:35] <Pici> !newpackage | falktx
[14:35] <jdstrand> kklimonda: wiki.ubuntu.com/AppArmor
[14:35] <jdong> ah, right
[14:35] <jdong> they had SELinux and mmap_min_addr patches fighting over the LSM hook
[14:35] <jdong> lol that's actually a bit morbidly funny :)
[14:36] <Pici> falktx: That should get you started. (I'm not a developer, so if you have any more specific questions, I'm afraid I probably can't help)
[14:37] <jdong> falktx: NewPackages has a good procedure for this. As a developer, I'll say that packaging it yourself is probably the fastest way to get it done
[14:37] <Rocha> i think ubuntu should come with banshee as the default music player
[14:37] <jdong> sitting around and/or filing "please package my cool app" bugs might have a very slow turnaround
[14:37] <micahg> jaytheblogger: depends what you want to do
[14:38] <jaytheblogger> well, I'm interested in getting more games packaged into Ubuntu - possibly becoming a MOTU developer as well
[14:38] <micahg> Rocha: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-default-media-player-choice
[14:38] <kklimonda> Rocha, there are still bugs in banshee that have to be fixed before it can be used as a default player
[14:39] <jaytheblogger> I read about the Debian games team, is that where most of that development work is done ?
[14:39] <falktx> I'm filling a bug report needs-packaging now
[14:40] <falktx> https://bugs.launchpad.net/ubuntu/+bug/471081
[14:41] <Rocha> kklimonda: rhythmbox doesn't work in my environment so i have to use banshee
[14:41] <jaytheblogger> micahg: the games team seems to be more of a marketing and promotion team than development
[14:41] <micahg> jaytheblogger: in Ubuntu, yes
[14:42] <jaytheblogger> micahg: so who decides what games get included with ubuntu ? is it that team ?
[14:43] <micahg> jaytheblogger: idk, I would think whatever is in Debian + whatever people package here
[14:44] <jaytheblogger> micahg: so as a newbie, can I package a game for Ubuntu that hasn't been packaged before ?
[14:44] <micahg> yes
[14:45] <micahg> but there's a process
[14:45] <falktx> changed description - https://bugs.launchpad.net/ubuntu/+bug/471081
[14:45] <jaytheblogger> micahg, right, I'm sure - there's a certain way to do it, a review process, etc.
[14:45] <micahg> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[14:47] <falktx> i already have a valid debian source package (used in my PPA)
[14:47] <falktx> what should be my next move?
[14:47] <falktx> wait for approval?
[14:47] <jaytheblogger> micahg: OK, I will take a look at that - and packaging new stuff counts towards me eventually becoming a MOTU developer ?
[14:47] <falktx> or is there something I can do to speed-up?
[14:53] <falktx> i'm seeing REVU
[14:54] <falktx> I think I'm close...
[14:55] <jaytheblogger> micahg: OK, I will take a look at that - and packaging new stuff counts towards me eventually becoming a MOTU developer ?
[14:55] <directhex> yes
[14:55] <micahg> jaytheblogger: idk, I'm not a MOTU, I just try to answer what questions I can
[14:56] <jaytheblogger> OK, sorry - thanks for your help
[14:57] <falktx> I already uploaded to REVU
[14:59] <dholbach> https://wiki.ubuntu.com/UbuntuOpenWeek kicking off in 1 minute in #ubuntu-classroom
[15:00] <kklimonda> thanks for reminding :)
[15:01] <bddebian> Heya folks
[15:09] <falktx> REVU page - http://revu.ubuntuwire.com/p/qtsixa
[15:09] <falktx> can someone review it?
[15:09] <falktx> I'm not with high hopes for this, but I though I should try
[15:11] <iulian> Hello bddebian.
[15:11] <bddebian> Hi iulian
[15:13] <falktx> is there a motu that can help me, please....'
[15:13] <falktx> ?
[15:14] <falktx> patience is a virtude
[15:16] <mok0> falktx: you can start by fixing the warning/notices given on revu's page
[15:20] <falktx> "This package has no debian/watch file or get-orig-source rule"
[15:20] <falktx> what does that mean?
[15:20] <mok0> falktx: you need a debian/watch file
[15:21] <mok0> falktx: "man uscan"
[15:31] <falktx> still don't get it
[15:31] <falktx> what does the watch file does?
[15:33] <joaopinto> falktx, http://wiki.debian.org/debian/watch
[15:34] <gaspa> quadrispro: double personality?
[15:34] <quadrispro> lol
[15:35] <mok0> falktx: the watch file enables an automatic check to see if a new version of the tarball has appeared
[15:35] <mok0> falktx: ... it is used by uscan, that can also initiate a download of the new version
[15:36] <mok0> falktx: To test, do: uscan --report-status
[15:40] <falktx> the debian wiki page was very useful, thanks
[15:40] <falktx> fixed now
[15:45] <falktx> everything fixed now
[15:45] <falktx> http://revu.ubuntuwire.com/p/qtsixa
[15:46] <mok0> falktx: thx, now it's ready for review :-)
[15:46] <falktx> what do I need to do next?
[15:46] <falktx> just wait?
[15:46] <mok0> Yes
[15:47] <mok0> falktx: I will review it now
[15:48] <falktx> thanks
[15:57] <mok0> falktx: I'm having problems with my sbuilder that I need to work out first :-(
[16:01] <falktx> no prob
[16:01] <falktx> how much time do you think you'll take?
[16:01] <falktx> 1 hour is enough?
[16:03] <mok0> falktx: yeah, I'll post the review later tonight
[16:03] <falktx> i'll check tomorrow
[16:03] <falktx> thanks for helping me
[16:03] <mok0> falktx: that'll be fine!
[16:04] <mok0> falktx: np
[16:04] <falktx> see ya
[16:32] <kklimonda> james_w, have a moment for another question? Why aren't svn tags imported to launchpad repository? for example when I check out transmission bzr repository I only get trunk and bzr tags returns nothing.
[16:32] <james_w> lp:transmission?
[16:32] <kklimonda> yes
[16:34] <james_w> I'm not sure why
[16:37] <kklimonda> should I ask on #launchpad ?
[16:43] <jpds> kklimonda: I don't think bzr supports svn tags.
[16:44] <jpds> kklimonda: Try #bzr.
[16:45] <mok0> Arggh, I need some help... I had problems with dbus not being configured in my karmic schroot environment, so I logged in and removed it (didn't think dbus was relevant in the schroot) but now it has bricked my _workstation_?!!? The LVM logical volume has gone
[16:46] <mok0> When I boot I end up in the initramfs
[18:12] <highvoltage> good evening
[18:15] <ari-tczew> hello highvoltage
[18:18] <highvoltage> heya ari-tczew
[18:19] <MsMaco> jdong: ping last comment on bug 415766
[18:19]  * MsMaco smacks ubottu 
[18:32] <jdong> MsMaco: haha look in #ubuntu-devel? :)
[19:29] <stevecrozz> I'm trying to build a php package and I'm getting an error I don't understand libtool: 6624: cannot create sapi/apache2handler/mod_php5.loT: Directory nonexistent
[19:30] <stevecrozz> I get this after apt-get source php5, then dpkg-buildpackage
[19:36] <soren> ScottK: When I upload python-mhash, I think you mentioned someone to talk to if I wanted it sponsored into Debian.. Who might that have been?
[19:37] <ScottK> soren: POX on #debian-python on OFTC
[19:37] <soren> ScottK: Thanks.
[19:38] <ScottK> No problem.
[19:39] <MsMaco> win 23
[20:09] <fabrice_sp> Hi. For SRU, even if the package is in Universe, according to the wiki page, we subscribe ubuntu-sru. Is that new?
[20:09] <fabrice_sp> wasn't is motu-sru before?
[20:10] <jdong> fabrice_sp: it's eventually a part of the archive reorg that the two SRU teams harmonize into one big happy family...
[20:10] <jdong> was unaware it was happening so soon
[20:10] <fabrice_sp> oh: the archive reorg. You're right
[20:10] <DktrKranz> no more motu-sru?
[20:11] <fabrice_sp> according to https://wiki.ubuntu.com/StableReleaseUpdates, no
[20:14] <DktrKranz> https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev2=137&rev1=136
[20:18] <ari-tczew> 65  active members
[20:18] <ari-tczew> All members shows 4 users
[20:18] <ari-tczew> https://launchpad.net/~ubuntu-sru/+members
[20:18] <jdong> ari-tczew: from registry administrators
[20:19] <jdong> either that or colin and martin count as 30 people each
[20:19] <jdong> I'd believe that as well!
[20:35] <ari-tczew> if this change will improve better SRU's management, it's ok
[20:35] <ari-tczew> SRU process so far has been a long and complicated
[20:35] <jdong> ari-tczew: the change only makes sense when the archive reorg happens
[20:36] <jdong> ari-tczew: well, in what way is it long and complicated?
[20:36] <jdong> unfortunately given the previous lessons we've had to learn the hard and bad way... the current procedure is the minimum required complexity for thoroughness
[20:41] <ari-tczew> previous SRU's procedure looked such as: file a bug (request for SRU), complete information (OK), subscribe one team, add tag, subscribe second team, remove tag, etc...
[20:41] <ari-tczew> and in result I need spamming motu-sru's members on their private mails to any move for my request
[20:42] <jdong> ari-tczew: we don't really mind the "spam" -- in fact I'd rather at any point in time know exactly what's going on with regards to SRU's and potential SRU's.
[21:21] <soren> How long does it usually take before a bug submitted to the Debian BTS turns up in the web interface or I get a confirmation e-mail?
[21:22] <av`> ~1 hour or more
[21:22] <DktrKranz> soren: it took longer these days because of some spam backlog, it should be quicker now
[21:23] <soren> Oh, ok. Lovely. It's only been 20 minutes so far, so everything is probably fine. Thanks!
[21:23] <DktrKranz> it took ~ 20 min to me
[21:23] <ajmitch> soren: did you attach with the mail the required food for the hamsters to process it?
[21:34] <soren> ajmitch: Is that what normal people call a GPG signature? :)
[21:37] <ajmitch> no, the hamsters that run the mail servers
[21:37] <ajmitch> poor little things get tired out so eaily :)
[21:37] <ajmitch> s/eaily/easily/
[21:40] <DktrKranz> soren: if you need a sponsor for your python-mhash ITP, feel free to ping.
[21:43]  * POX considers turning fast mode on (in order to collect another sponsoree ;)
[21:43]  * DktrKranz sits down and let POX to rule :)
[21:44] <POX> DktrKranz: well, even fast mode will not help as I have to change one of mine packages in order to upload one of packages
[21:44] <DktrKranz> heh
[21:45]  * ajmitch needs to catch up with whatever the current rules are on python packaging 
[21:45] <POX> (sponsoree already tested my patch, so using fast mode will be hard)
[21:45] <soren> POX: Oh, you're in here as well :) That's convenient.
[21:46] <ajmitch> 'fast mode'?
[21:46] <POX> 'fast mode' == find one serious bug and reply to the RFS mail
[21:46] <ajmitch> aha :)
[21:46] <Darxus> So, some people on the motu list are upset that Canonical made an arbitrary decision reguarding Ubuntu?
[21:47] <soren> POX: Which e-mail should I send the RFS e-mail to?
[21:47] <soren> Darxus: Which decision?
[21:47] <POX> soren: piotr@debian.org
[21:47] <Darxus> Subject: Re: Søren Hansen and Michael Bienia
[21:47] <soren> POX: Cool. On its way.
[21:47] <ajmitch> soren: I'm guessing the discussion over the MC extension
[21:47] <ajmitch> which turned into more of a discussion about communication
[21:48] <soren> Darxus: That was not CAnonical. It was the CC and DMB.
[21:48] <Darxus> Oh, what are CC and DMB?
[21:49] <soren> Darxus: Community Council and Developer Membership Board.
[21:49] <Darxus> Ah.
[21:50] <soren> POX: Sent. Thanks in advance.
[21:50] <Darxus> Really sounds like people mistook Ubuntu for a democracy.
[21:56] <joaopinto> Darxus, you should re-read that thread, producing incorrect statements on the channel does not improve communication
[21:58] <joaopinto> Darxus, oh sorry, that was question, no, that is not correct, if you seek further clarification read the thread
[22:07] <randomaction> It's a pity, looks like sistpoty was really disappointed :(
[22:17] <JontheEchidna> oh, so that's why I was getting so many ubuntu-motu digests
[23:01] <KurtKraut> I've made a rather complex shell script that I want to distribute to Ubuntu users. Making a .deb package is quite a rocket science, a thing more complex then my script itself. Autopackage.org seems to be abadoned. Any suggestion on ways to distribute software to Linux?
[23:02] <RAOF> KurtKraut: How many files is the shell script?
[23:03] <KurtKraut> RAOF, currently 2.
[23:03] <Darxus> That's not "a shell script" :P
[23:04] <joaopinto> KurtKraut, list it somewhere and provide instructions how to get it with wget ?
[23:04] <jdong> eh a simple deb file doesn't have to be rocket science here
[23:04] <jdong> as long as you don't care for packaging policy it should be a 5 minute job
[23:04]  * jdong watches the MOTU police swarm his dorm
[23:05] <RAOF> Agreed.  You're in the wrong channel for a simple deb file to be rocket science :)
[23:05] <KurtKraut> joaopinto, it is not a stand alone script. It has many dependencies. Distributing with a simple wget would force me to implement in the script all dependency check and upgrade system.
[23:05] <Darxus> KurtKraut: https://wiki.ubuntu.com/PackagingGuide
[23:05] <RAOF> jdong: Surely you've got a better work flow than that!  It wouldn't take me more than 5 minutes to make a policy-conformant package of a simple shell script! :P
[23:05] <joaopinto> KurtKraut, just add: sudo apt-get install blah blah, to your instructions ;)
[23:06] <KurtKraut> Darxus, I've read this guide and tried to use the examples provided, even copy & pasting it and it never works. I always get stuck to something.
[23:06] <jdong> KurtKraut: well asking a specific question will likely help you get un-stuck
[23:06] <jdong> I do think a simple deb is the proper way to do this
[23:06] <jdong> RAOF: well you're all magical :)
[23:06] <RAOF> Possibly because all the examples are going to include lots of steps that your shell script won't need at all.
[23:06] <Darxus> You could make a 1 line install script and run it through checkconfig :)
[23:07] <jdong> RAOF: I was thinking more of someone in KurtKraut's situation
[23:07] <KurtKraut> RAOF, that's one problem indeed but I skip all steps that aimed to compiling.
[23:07] <KurtKraut> I'll try making a .deb again and I'll ask a specific question when I get stuck.
[23:08] <jdong> sounds like a good way to go :)
[23:08] <Darxus> Yeah.
[23:12] <KurtKraut> A first problem: dh_make -e your.maintainer@address (as shown in https://wiki.ubuntu.com/PackagingGuide/Complete)
[23:12] <KurtKraut> It is asking me:
[23:12] <KurtKraut> Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch or cdbs?
[23:12] <KurtKraut>  [s/i/m/l/k/n/b]
[23:12] <KurtKraut> -
[23:12] <KurtKraut> The last attempt I did I picked up 'indep binary'. Is that right for a shell script?
[23:14] <joaopinto> KurtKraut, just: dh_make -c gpl -b  , it will be more simple for what you need
[23:21] <KurtKraut> joaopinto, ok. Proceeding.
[23:22] <KurtKraut> dh_make generated me a ../debian/control. Should I edit the 'Depends:' value manually?
[23:22] <azeem> KurtKraut: maybe
[23:23] <KurtKraut> azeem, it is already filled with 'Depends: ${shlibs:Depends}, ${misc:Depends}'
[23:23] <azeem> what else do you need?
[23:23] <KurtKraut> azeem, should I keep it and add the dependecies I know at the end?
[23:23] <azeem> which are?
[23:23] <KurtKraut> azeem, libnotify-bin, fping, dash, curl
[23:24] <azeem> yes
[23:25] <joaopinto> KurtKraut, change the binary package archicture from Any to All, since it's a shell script
[23:25] <joaopinto> it's arch independent
[23:25] <KurtKraut> joaopinto, okay
[23:26] <KurtKraut> One of my dependencies are libnotify-bin. It's current version is 0.4.5-1ubuntu1. How should I place it in 'Depends:' on contro file? libnotify-bin (>=0.4.5-1ubuntu1) ?
[23:27] <joaopinto> KurtKraut, versions are not mandatory, if you are not sure it works with previous version, yes, set whatever it was tested with
[23:28] <KurtKraut> joaopinto, that's the approach I want to do: put the minimum tested versions
[23:30] <KurtKraut> Ok, control file done. Now the rules file... what should I put on it since it is a shell script?
[23:31] <joaopinto> KurtKraut, you just need
[23:31] <joaopinto> #!/usr/bin/make -f
[23:31] <joaopinto> include /usr/share/cdbs/1/rules/debhelper.mk
[23:32] <KurtKraut> joaopinto, there is a 'include /usr/share/cdbs/1/class/makefile.mk' also, added by dh_make. Should I remove this line?
[23:32] <joaopinto> the debhelper.mk rules will call dh_install,dh_installdirs which is all you need
[23:32] <joaopinto> yes, that one is to use with "Makefile"
[23:32] <joaopinto> which you don't have :)
[23:34] <KurtKraut> joaopinto, ok. My package will contain two files: pomamonitor.sh and pomamonitor.conf - I'd like pomamonitor.conf to be kept in ~/.pomamonitor. What place should pomamonitor.sh be installed? /usr/bin?
[23:35] <joaopinto> KurtKraut, you don't install files into user's home dir from a .deb package
[23:36] <joaopinto> creating config files is a role for the app/script, not for the install process
[23:36] <KurtKraut> joaopinto, hm, ok.
[23:36] <KurtKraut> joaopinto, So where do I place pomamonitor.sh?
[23:36] <joaopinto> as for pomamonitor.sh, yes, usr/bin is fine
[23:37] <KurtKraut> joaopinto, and how I ser /usr/bin as its place?
[23:37] <KurtKraut> *how do I set
[23:37] <joaopinto> first edit your debian/dirs
[23:37] <joaopinto> those are the dirs that the package should create, keep only or add the one you need
[23:37] <joaopinto> then create a debian/install
[23:37] <joaopinto> there you list the files that will be intalled by the dh_install command
[23:38] <joaopinto> the format is: source destination
[23:38] <KurtKraut> joaopinto, https://wiki.ubuntu.com/PackagingGuide/Complete told me to delete the dirs file and: 'At this point, you should have only changelog, compat, control, copyright, and rules files in the debian directory.'
[23:38] <joaopinto> example:  src/pomamonitor.sh usr/bin
[23:38] <joaopinto> KurtKraut, well, we are not following the guide are we :) ?
[23:39] <KurtKraut> joaopinto, I was trying to but you're right.
[23:39] <joaopinto> anyway for usr/bin you can rm debian/dirs, it's created on the existing system for sure :P
[23:39] <joaopinto> it could be helpful for usr/share/myscripts :P
[23:41] <KurtKraut> joaopinto, so now I have a dirs file that contains only one line: src/pomamonitor.sh usr/bin
[23:41] <KurtKraut> joaopinto, is that right?
[23:42] <joaopinto> no, that was for debian/install
[23:42] <joaopinto> on debian/dirs you have a single dir per line
[23:43] <KurtKraut> joaopinto, and in my case, I don't need to have content in debian/dirs because I'll place pomamonitor.sh in /usr/bin, wich certainly already exists, right?
[23:43] <joaopinto> right
[23:43] <KurtKraut> okay
[23:44] <joaopinto> KurtKraut, about  ~/.pomamonitor, you could install an /etc/default/pomamonitor.conf
[23:44] <joaopinto> however, it would be up to your script, to copy it to the user's home dir on the first run
[23:45] <joaopinto> and you should use ~/.config/ to be XDG compliant
[23:46] <RAOF> joaopinto, KurtKraut: Actually, you should use $XDG_CONFIG_DIR to be XDG compliant.
[23:47] <joaopinto> RAOF, right, I was just describing the default :P
[23:50] <KurtKraut> joaopinto, I'm thinking of not distributing a .conf file inside the .deb and then use dialog/zenity to ask for user's data on first run and then generate a conf on ~/.pomamonitor on the fly
[23:50] <joaopinto> ok, that would be another option
[23:51] <KurtKraut> joaopinto,  so my debian/install file has a single line: src/pomamonitor.sh usr/bin
[23:51] <KurtKraut> joaopinto, is that right?
[23:51] <joaopinto> yes
[23:51] <KurtKraut> joaopinto, ok. So what is the next step?
[23:51] <joaopinto> KurtKraut, debian/copyright
[23:53] <joaopinto> KurtKraut, rm debian/{*.ex,*.EX,README.*}  (not sure you did it already)
[23:53] <KurtKraut> joaopinto, yes, I did it already
[23:53] <KurtKraut> joaopinto, and I finished editing debian/copyright
[23:53] <joaopinto> ok, now, assuming tour DEB* environment varialbles are properly set
[23:53] <joaopinto> just: debuild
[23:54] <Darxus> Somebody should document this :P
[23:54] <KurtKraut> joaopinto, ... I guess I didn't set any sort of variables. What variables are you talking about?
[23:55] <joaopinto> DEBEMAIL, DEBFULLNAME
[23:55] <joaopinto> I believe they are mentioned on the wiki example
[23:55] <joaopinto> erm wait
[23:55] <joaopinto> the most importante one was missed
[23:55] <joaopinto> debian/changelog
[23:55] <joaopinto> use dci -i/-a to edit it
[23:56] <joaopinto> ops, dch
[23:59] <KurtKraut> joaopinto, ok, done
[23:59] <KurtKraut> joaopinto, and how do I set DEBEMAIL and DEBFULLNAME?
[23:59] <joaopinto> KurtKraut, export DEBEMAIL=your_email
[23:59] <joaopinto> those ones should be on your shell profile