[00:45] <mok0> "@antifacista45xx is a perl script with an array of pro-khamenei slogans, and @Avi0wn3d is a python script to counter it." Yay Python!
[03:19] <qiyong> does cvs have a startup script in init.d or is it startup by inetd?
[03:20] <ajmitch> I suspect inetd, but I haven't used cvs for several years (thankfully)
[03:20] <ajmitch> you should probably check in the package
[03:21] <lifeless> inetd
[03:21] <lifeless> but, don't use cvs. thanks
[03:22] <qiyong> so cvs has no standalone mode?
[03:22] <qiyong> lifeless: user insists cvs, period
[03:22] <lifeless> it doesn't.
[03:23] <lifeless> if you're writing you should use it via ssh anyway
[03:23] <qiyong> it doesn't support standalone?
[03:23] <lifeless> thats correct
[03:23] <qiyong> i have to use pserver for windows clients
[03:30] <MTecknology> Time for me to learn how to packlage... I'm going to package my own junk soon enough
[03:30] <nhandler> :)
[03:31] <MTecknology> nhandler: it's a scary road I'm about to embark upon
[03:31] <MTecknology> I tried to fix bugs in packages once and I failed horribly
[03:32] <nhandler> MTecknology: If you are interested, we do have a mentoring program you can join
[03:33]  * MTecknology is interested
[03:33] <nhandler> MTecknology: https://wiki.ubuntu.com/MOTU/Mentoring
[03:34] <MTecknology> cool
[03:35] <ryanprior> Hi there, I'm trying to build a source package to upload to REVU. When I run the suggested command, "dpkg-buildpackage -S -sa -rfakeroot", I get an error about a missing debian/changelog file -- this suggests to me that building the package really isn't so straightforward.
[03:35] <lifeless> ryanprior: you need to *have* a package to be able to build it. Upstream tarballs are not packages.
[03:35] <ryanprior> I tried to Google for a tutorial on building a Debian source package, but while there are lots of tutorials on building binary packages, I couldn't find one for building source packages.
[03:36] <RAOF> ryanprior: You'd be looking for !packagingguide
[03:36] <ryanprior> !packagingguide
[03:36] <ryanprior> I will take a look.
[03:36] <ajmitch> packages that break on python2.4 annoy me
[03:37] <lifeless> ajmitch: any particular reason?
[03:38] <ajmitch> because it interrupted my upgrading of packages to the latest karmic version :)
[03:39] <ajmitch> it's a new package in karmic that just appears to have the wrong python version info
[03:39] <ajmitch> since it relies on features from 2.5
[03:42] <MTecknology> Is this link supposed to be an empty tarball? https://wiki.ubuntu.com/PackagingGuide/Basic
[03:43] <MTecknology> this part - wget http://ftp.gnu.org/gnu/hello/hello-2.4.tar.gz
[03:43] <ajmitch> MTecknology: it's not empty when I download it
[03:44] <MTecknology> oh...
[03:44] <MTecknology> spelling error in the wiki....
[03:45] <ajmitch> what is the spelling error?
[03:46] <MTecknology> They tell you to make an empty directory and create a tarball over top of the one you just downloaded
[03:46] <ajmitch> no, it doesn't
[03:47] <ajmitch> it says to do that if there isn't a tarball
[03:47] <MTecknology> oh..
[03:47]  * MTecknology needs to learrn how to stop skimming text when not in class
[03:47] <ajmitch> it could be clearer, but it's not a spelling error
[03:52] <lifeless> what I hate is patch systems that wedge themselves
[03:54] <MTecknology> !find dh_make
[03:55] <RAOF> lifeless: What would be an example of that?
[03:55] <ajmitch> looks like we get to remove zope 2.x & plone from ubuntu
[03:57] <ajmitch> which will drop one of the big rdepends of python2.4
[04:05] <lifeless> RAOF: whatever evolution uses
[04:05] <RAOF> :(
[04:07] <lifeless> having done a build, pull from upstream, do another build, and it bitches
[04:07] <lifeless> can't undo the patch, can't redo it, can't fix it.
[04:07] <lifeless> arrgghh
[04:07] <MTecknology> you guys should remove evolution :)
[04:08] <MTecknology> it's one of the biggest reasons I build up from a cli install :P
[04:42] <persia> !ops
[04:42] <persia> Could someone please gently get RAOF to fix his connection?
[04:44] <ajmitch> A fine example of Australian telecommunications infrastructure, I'm sure :)
[04:44] <persia> Quite likely.
[04:45] <persia> But I don't know the magic codes to not only get him off the channel until he sorts it, but off the server (as it's flooding several channels)
[04:45] <ajmitch> you'd probably need to convince some freenode staff of that
[04:45] <lifeless> I'll see about ringing him
[04:45] <persia> But I think they'd prefer to hear from delegated contacts, which is why I made the call above.
[04:45] <persia> lifeless, Thanks.
[04:46] <ajmitch> now that's service
[04:47] <persia> The power of global initiatives with local implementations.
[05:30] <marnold> question a package of mine just hit Debian as import freeze is not yet in effect do i need to do anything for a sync or does it just happen?
[05:31] <ajmitch> it'll happen
[05:31] <ajmitch> the 'autosync' isn't fully automatic, it's triggered by an archive admin
[05:31] <marnold> it did
[05:31] <marnold> that was fast
[05:32] <ajmitch> so, no problem to worry about then?
[05:32] <marnold> nope just wondering
[05:33] <slytherin> can anyone please explain the meaning of << before version string when specifying dependencies?
[05:36] <ajmitch> slytherin: 'strictly earlier' is the wording that policy uses
[05:36] <slytherin> ajmitch: what does that mean in plain words?
[05:36] <ajmitch> less than
[05:37] <slytherin> and how is that different than simply <
[05:37] <ajmitch> such as conflicts: foo (<< 1.2.3)
[05:37] <ajmitch> "The deprecated forms < and > were used to mean earlier/later or equal, rather than strictly earlier/later, so they should not appear in new packages (though dpkg still supports them). "
[05:37] <ajmitch> debian policy is a good resource for that
[05:38] <ajmitch> They're effectively the same, but use << & >> where needed
[05:38] <ajmitch> in the conflicts case that I used, it'd be better to use Breaks instead
[05:39] <slytherin> ajmitch: thanks for help. I will use <<
[06:09] <MTecknology> Anyone know who Luigi Gangitano is?
[06:14] <persia> MTecknology, https://launchpad.net/people/ is a useful tool
[06:14] <MTecknology> persia: except that it's just a blank profile
[06:15] <persia> MTecknology, click on "Related Software"
[06:16] <MTecknology> persia: but that doesn't tell me if he's ever in here :P
[06:16] <MTecknology> makes me assume he is
[06:17] <persia> With no direct uploads to Ubuntu, it's unlikely that this would be a good place to find such a person.
[06:17] <persia> Of course, there are exceptions to that guideline.
[06:40] <dholbach> good morning
[07:01] <iulian> Morning dholbach.
[07:03] <dholbach> hiya iulian!
[07:08] <mok0> Anyone here know about Tor networks?
[07:10] <mok0> They've been advertised as safe for iraniasn to use but I don't think they are
[07:12] <dholbach> mok0: I have no idea
[07:12] <ttx> mok0: well it depends on definitions of "safe". Authorities should still be able to know they are going through a Tor network.
[07:13] <ttx> since first-hop would be telling them that.
[07:13] <mok0> ttx: All the gov. has to do is to operate an exit node
[07:13] <mok0> ttx: and they can perform end-to-ebd traffic analysis
[07:13] <mok0> end-to-end
[07:15] <ttx> mok0: with enough noise that should prove quite difficult
[07:17] <mok0> ttx: security through obscurity is not enough if you are in a completely  controlled society
[07:18] <persia> mok0, It's all about balancing the cost of tracking vs. the cost of the information.
[07:18] <persia> It's probably safe to use Tor for generic surfing to places popular throughout a given controlled area.
[07:18] <persia> hard to identify a specific person if there is sufficient cover.
[07:18] <ttx> mok0: also you can pick nodes
[07:18] <persia> But that gets into game theory, etc.
[07:19] <mok0> persia: in a situation where the life of the regime is threatned, I don't think cost matters
[07:19] <ttx> (at least entry and exit ones)
[07:20] <mok0> A swedish security guy was able to recover a large number of email addresses and passwords by running an exit node
[07:21] <ttx> mok0: of course, exit nodes get unencrypted traffic. So if the encapsulated traffic is not encrypted, he would sure get vereything in it
[07:21] <persia> mok0, Right.  Cost of data.  So, it may be sufficient for regular browsing.  It may not be sufficient for subversion.
[07:21] <lifeless> thats more to do with unencrypted protocols beyond tor
[07:21] <persia> For subversion, you want deep back-channel communication anyway.
[07:22] <ttx> mok0: people don't necessarily get that tor doesn't protect you froim eavesdropping on exit nodes.
[07:22] <ttx> mok0: that's what the swedish research shows.
[07:22] <persia> (e.g. Have a set of servers that check the time via ntp over the net.  have them synchronised locally before checking.  Have the pattern of times that the servers check be meaningful)
[07:22] <mok0> I am just concerned b/c iranians are told to use Tor networks on Twitter
[07:23] <ttx> tor is a powerful in experienced hands. I wouldn't recommend it as the solution to all evil since you can get it wrong if you don't understand how it works.
[07:23] <lifeless> mok0: they are also told to use http proxies, which are if anything less secure still
[07:23] <ttx> s/powerful/powerful tool/
[07:24] <mok0> lifeless: yes, but that is for surfing
[07:24] <mok0> What the regime wants is to stop people from uploading videos and pictures
[07:25] <mok0> Proxies allow peope to surf and get information INTO the country
[07:26] <persia> So, it's possible to create a model where the information can be tracked by pattern matching.
[07:26] <mok0> persia: yes
[07:26] <persia> But as long as there are collaborators, it's harder.
[07:26] <persia> For example, Alice uses tor to get her video into UbuntuOne.
[07:26] <persia> She shares it to Bob.
[07:27] <persia> Bob waits a random period of time (6-14 hours) before sending it in encrypted mail to Chris.
[07:27] <persia> Chris dumps it on a torrent server.
[07:27] <lifeless> if you want secure, freenet is better
[07:28] <lifeless> its just abysmally slow
[07:28] <persia> Malcom has a hard time matching Alice's activity to the torrent contents.
[07:29] <mok0> persia: yes, that involves several steps
[07:30] <mok0> But if the gov. is monitoring the network in general, and they have Tor exit nodes, they can find out who is sending videos to CNN for example
[07:31] <mok0> Only if the Tor network is very very large, they may not get enough packages to do it
[07:31] <persia> mok0, as does anything that is to be secure.  Any process is subject to tracking at the level of intelligence used to prepare it.  The smarter your automation, the smarter the cracking automation has to be.  Human-level automation tends to get expensive quickly (but look at Bletchley Park for a counterexample)
[07:32] <mok0> persia: yes
[07:32] <persia> Anyway, tor is a tool.  Potentially a useful tool.  Relying solely on tor is better than nothing, but perhaps not sufficient.
[07:35] <mok0> In combination with encryption Tor might be rather safe
[07:36] <mok0> lifeless: What is freenet?
[07:39] <mok0> lifeless: n/m got it from Mr. Google
[08:22] <mrooney> dholbach: morning dholbach, just watching your video on upgrading a package :)
[09:33] <slytherin> bigon: ping
[09:35] <slytherin> slomo: ﻿can you please take a look at latest gst-plugins-bad-multiverse0.10 upload whenever you get time. I plan to do similar changes to -ugly-multiverse when updating the package. Also ugly-multiverse will have replaces on -bad-multiverse (<< 0.10.13) because of x264 plugin move.
[09:37] <ziroday> Hi, are there any plans for pidgin 2.5.7 to be stuck in backports?
[09:38] <slytherin> ziroday: the fix for yahoo should land in -updates but I don't know if anyone is actually working on it.
[09:39] <ziroday> slytherin: ah okay, thanks!
[09:40] <bigon> slytherin: pong
[09:42] <slytherin> bigon: I was wondering why telepathy-idle is a suggests for empathy instead of recommends. We aren't shipping any other IRC client in default install, right? So if empathy is replacing pidgin then -idle should be recommends IMHO.
[09:44] <bigon> good question, I'm not sure tp-idle (and empathy support) is 100% functional
[09:46] <slytherin> I am not running empathy latest release. So can't really comment on that. If there are builds for hardy in PPA I will try.
[10:22] <slomo> slytherin: as long as it builds and can be installed i'm fine with it ;)
[10:22] <slomo> slytherin: or do you have any specific questions?
[10:22] <slytherin> slomo: nothing specific
[10:23] <slytherin> slomo: Just so you know, I plan to keep updating the -multiverse packages. :-)
[10:23] <slomo> ok :)
[10:24] <slomo> perfect, it seems nobody every touched the packages after me ;)
[10:27] <slytherin> slomo: right, in fact ugly-multiverse is not updated as per upstream since hardy.
[10:29] <slomo> :)
[10:32] <slytherin> slomo: I just remembered one question. I enabled mplex plugin which uses mjpegtools library. The plugin is supposedly needed by brasero to create video DVD. Am I correct that this plugin should reside in bad-multiverse package (considering mjpegtools build-dep).
[10:32] <slomo> slytherin: yes
[10:53] <kirrus> Hi
[10:53] <kirrus> Can someone have a look at patching this bug: https://bugs.edge.launchpad.net/ubuntu/+source/phpmyadmin/+bug/387215 .. motu-swat?
[10:54] <kirrus> We've had at least 4 servers cracked using this bug so far, so I'd guess it's probably pretty critical, but so far no-one's got past www-data shell (matter of time)
[11:01] <popey> !info phpmyadmin
[11:02] <popey> kirrus: I can't help but think that perhaps you should remove the /config/ directory which would work around this?
[11:07] <kirrus> popey: we've been resetting permissions, so that the files aren't writable by www-data, but we have a fair few servers. It's far easier to deploy an update, than a chmod ;)
[11:08] <popey> sounds like you need landscape ;)
[11:09] <kirrus> popey: landscape costs too much money :(
[11:11] <kirrus> the directors are against anything closed being deployed on our network.. and we have a majority of debian systems still, tho Ubuntu is slowly growing across the systems
[11:12] <sakjur> kirrus: is it possible to access those servers with SSH?
[11:14] <sakjur> You should be able to deploy a bash-script through SSH on those and then just patch it that way
[11:15] <kirrus> sakjur: yes, some, all from our internal management box, but we've not got a way of automatically deploying scripts on them yet - the passwords are stored in the wrong place for us to just be able to easily script a change over ssh. In the process of preparing to deploy clusterjob...
[11:15] <sakjur> I mean, if landscape is too expansive, that's maybe a good way to do simple tasks, it still takes a while, but well, well
[11:16] <sakjur> kirrus: can't you use SSH-keys?
[11:17] <kirrus> sakjur: Yes. But we're not allowed to ssh-key our management box to anything, because if that box is cracked (would be hard), the nefarious individual would have easy access to all the servers
[11:18] <sakjur> kirrus: so you need to do things on place?
[11:18] <sakjur> whoops
[11:18] <sakjur> gotta go to my job
[11:18] <sakjur> sorry
[11:41] <porthose> huats: would you please renew my membership to Mentering Reception
[11:48] <huats> porthose: done
[11:49] <huats> so feels free to handle a few people :P
[11:49] <porthose> thx on my todo list for today :)
[12:07] <andrew_sayers> I've started looking for errors in debian/control files that were missed because of bug #391165.
[12:07] <andrew_sayers> I've found 32 so far, with more likely to come.  Is there anything I should know before I post 32 identical bug reports?
[12:08] <andrew_sayers> (Well, each with minor changes to a template)
[12:17] <Adri2000> bddebian: there is still the @GETTEXT_PACKAGE@.mo problem though, and I didn't manage to find a solution with my basic autotools skills. do you have any idea how this could be fixed?
[12:40] <Laney> andrew_sayers: You should file these against Debian too if they affect there
[12:41] <andrew_sayers> Laney: as well or instead?
[12:41] <Laney> as well
[12:41] <andrew_sayers> Phew :)
[12:41] <andrew_sayers> Anyway, will do.
[12:41] <Laney> and please make sure that dpkg bug gets fixed there too
[12:42] <andrew_sayers> Okay, I'll file a report for that in Debian.
[12:42] <Laney> thanks a lot
[13:03] <bigon> slytherin: maybe if you could open a bug about empathy and tp-idle so I will not forget
[13:06] <slytherin> bigon: I will log a bug. I was hoping I could try latest version. But there doesn't seem to be an easy way for me.
[13:08] <bigon> slytherin: you cannot upgrade to jaunty?
[13:08] <slytherin> bigon: I can not upgrade my office machine to jaunty right now. Busy with releases. And laptop at home is ibook (powerpc), so I will have to compile all the packages myself.
[13:09] <slytherin> I mean build the packages.
[13:09] <directhex> ?
[13:09] <directhex> ppc is still built
[13:10] <slytherin> directhex: the latest releases of empathy are either in karmic or in telepathy ppa.
[13:10] <bigon> yeah all the packages are still built on ppc
[13:11] <bigon> ppa build ppc
[13:11] <slytherin> ppa does not support ppc, right?
[13:11] <directhex> isn't it possible on a per-team basis to get ppc access on a ppa?
[13:11] <directhex> i.e. ppa packages built on a main archive buildd
[13:11] <bigon> slytherin: oh right my bad
[13:12] <ScottK> It is possible to have a non-virtualized PPA.  I think there are three at the moment.
[13:12] <ScottK> e.g. it's not easy to get.
[13:30] <bddebian> Adri2000: Did you try gettextize?
[13:30]  * slytherin feels nice for reporting FTBFS bugs in Debian. :-)
[13:31] <dupondje> https://bugs.launchpad.net/ubuntu/+source/wammu/+bug/391529
[13:31] <dupondje> could somebody check, its a fix for wammu in it :)
[13:31] <dupondje> as python-xml is removed, dependency is removed also, its not needed anymore
[13:32] <slytherin> dupondje: does wammu work after removing dependency? I mean which python module does it use then for xml functions?
[13:32] <dupondje> compiled it without
[13:32] <dupondje> everything seem to work
[13:33] <dupondje> mailed developper and he says: It was needed in some older python versions (something like 2.2, I'm
[13:33] <dupondje> not sure)
[13:33] <slytherin> dupondje: it may be only runtime dependency. Just make sure.
[13:35] <dupondje> slytherin: there is a XML export function
[13:35] <dupondje> works perfectly
[13:35] <dupondje> without the python-xml :)
[13:35] <slytherin> dupondje: cool
[13:36] <dupondje> and if the developper says its not needed :) well :D
[13:36] <slytherin> dupondje: you may want to add that additional information to the bug
[13:37] <dupondje> done
[13:48] <masterkernel> hi all, i need 2 reviewers for my package, kernelcheck (automated tool for custom compiling any 2.6 kernel from the upstream source)
[13:48] <masterkernel> REVU: http://revu.ubuntuwire.com/p/kernelcheck
[13:57]  * maxb wonders why it's called kernelcheck if it doesn't check kernels, but builds them
[13:57] <maxb> :-)
[13:58] <loic-m> When everything from a previous merge has been done upstream and in Debian, and it can be converted to a sync, is it enough to request a sync and detail the reasons in the launchpad request?
[13:58] <Hobbsee> loic-m: yes
[13:59] <loic-m> Hobbsee: as far as keeping the ubuntu changelog, is that done automatically?
[13:59] <RainCT> loic-m: Yes. You can read more about sync requests here: https://wiki.ubuntu.com/SyncRequestProcess
[13:59] <RainCT> loic-m: And yes fixing the changelog is automatic
[13:59] <Hobbsee> loic-m: in the package, or on launchpad?
[14:01] <loic-m> Hobbsee: meaning when merges become sync, what happens to the previous Ubuntu entries in changelog - do we have to do something, or is it done automatically?
[14:01] <Hobbsee> loic-m: you don't have to do anything.  We take debian's version of the package, so they are lost
[14:01] <Hobbsee> (although launchpad will still tell you bits of them, and you can download old versions of the source that have them still)
[14:02] <loic-m> ok, thanks a lot
[14:02] <masterkernel> maxb: don't worry there's a reason. I had originally used the program to check the kernel in the master kernel thread with the latest one to see if i needed to update it (there's still evidence of that if you download v. 1.0)
[14:02] <masterkernel> then somehow it evolved into compiling kernels. idk how
[14:04] <RainCT> Hobbsee: Oh. May it be that "aptitude changelog" gets the changelogs from Launchpad and so includes entries from Ubuntu?
[14:05] <Hobbsee> RainCT: i don't think it gets the changelog that is shown up on the launchpad souce packages page.
[14:05] <loic-m> RainCT: that's what I thought too, since there might still be useful stuff in there
[14:05] <Hobbsee> RainCT: (and i doubt it does, in reality.  Have you actually vound an example of this?)
[14:06] <Hobbsee> loic-m: er, why would there be?  wouldn't everything be duplicated from upstream & debian?
[14:06] <Hobbsee> loic-m: beyond timeline data, that is
[14:07] <RainCT> bug numbers, for instance. or knowing who worked on it
[14:08] <loic-m> Hobbsee: I tend to look at previous Ubuntu changelog entries to get an idea of who has worked on what in package when I need to ask questions ;)
[14:08] <Hobbsee> RainCT: well, that entire branch of code gets overwritten, so, thus, no one from ubuntu did happen to work on the debian branch?
[14:08] <Hobbsee> loic-m: right :)
[14:08] <slytherin> loic-m: for syncs, use of requestsync is preffered. :-)
[14:09] <Laney> loic-m: just use Launchpad for this info
[14:09] <Hobbsee> RainCT: oh, aptitude changelog will grab it from changelogs.ubuntu.com, btw
[14:10] <loic-m> Launchpad is slow...
[14:10] <loic-m> slytherin: thanks, it's also faster ;)
[14:10] <Laney> I have a quick search to open the source package page, so it's no slower than typing aptitude changelog
[14:15] <RainCT> Laney: good idea, I've just set up on too (only had one for bugs so far)
[14:15] <Laney> RainCT: nhandler posted some good ones a while ago
[14:16] <Laney> I use pts and lp the most often
[14:45] <bddebian> Adri2000: Is djplay upstream dead/unresponsive?
[14:46] <mok0> sebner: Flightgear is now in the archive
[14:49] <mok0> Go vote up my idea http://brainstorm.ubuntu.com/idea/20362/
[15:04] <ogra> mok0, already exists
[15:04] <mok0> ogra: you mean the idea or the tracker
[15:04] <ogra> https://launchpad.net/~ogra/+hwdb-submissions
[15:05] <ogra> it will soon be possible to attach hwdb entries to bugs
[15:06] <mok0> ogra: it's not _quite_ what I had in mind
[15:06] <mok0> ogra: I don't see where the hardware is
[15:07] <ogra> in the submission entries
[15:07] <ogra> there is also a real DB thats not accessible yet
[15:07] <ogra> but its in the works
[15:07] <mok0> ogra: don't see it
[15:07] <ogra> ?
[15:08] <mok0> ogra: Each piece of hardware should be like a Bug, where you can have comments etc.
[15:08] <ogra> right, thats what the database will have
[15:10] <ogra> currently it collects the xml data and in parallel stores the items in a db ... atm only the xml files are accessible, but the db will get a frontend, so you can look up your intel98236 graphics card in the future there
[15:10] <mok0> ogra, so those XML files are the raw data that will be parsed to make an entry for each component ?
[15:10] <mok0> ogra, well, go an vote it up then :-)
[15:10] <ogra> well, its already in the works :)
[15:11] <ogra> not sure it needs extra votes
[15:11] <mok0> ogra: heh ok, glad to hear it. If you guys need some input I'm available :-)
[15:12] <ogra> mok0, cr3's team is working on that
[15:12] <ogra> they also do checkbox (the collecting client)
[15:13] <mok0> ogra: is there a team on lp for that=
[15:13] <mok0> ?
[15:13] <ogra> no idea, ask cr3 :)
[15:14] <mok0> ogra, ok thanks!
[15:14] <cr3> mok0: hi there, I'm trying to catchup the backlog... and I need coffee. one moment :)
[15:14] <mok0> cr3: allrighty
[15:15] <al-maisan> how do I figure out what package a particular file belongs to? Like '/bin/ls' for example?
[15:15] <mok0> al-maisan: dpkg -S bin/ls
[15:15] <mok0> al-maisan: but that only works for files installed on your system
[15:16] <Laney> apt-file
[15:16] <Laney> works for all afaik
[15:17] <mok0> It does
[15:29] <cr3> mok0: ok, so I finally caught up with the backlog. if you are speaking of the hardware database in launchpad, this is unfortunately not something I'm working on
[15:30] <mok0> cr3: ah, ogra told me you were
[15:30] <cr3> mok0: I'm sorry to have to bounce you around like this but abel is the one working on that
[15:30] <cr3> mok0: I work on the commercial side of hardware testing, certification.canonical.com, but not on launchpad
[15:30] <mok0> cr3: ok, thanks, I'll get in touch with him, then
[15:31] <mok0> cr3: I just wrote up that Brainstorm entry a couple of days ago, I didn't know about the project
[15:31] <mok0> cr3: so, I am intersted in hearing about it , and if there are things I can do to help
[15:31] <cr3> mok0: what you mentionned in this channel sounds like this page: http://www.ubuntuhcl.org/
[15:32] <mok0> cr3, yes, but within LP, so we could link bugs to it etc
[15:32] <cr3> mok0: however, I don't agree with that kind of hardware database which contains subjective information about hardware apparently works with an arbitrary release of ubuntu
[15:32] <clk> I'm just about to roll a new package, how far off is karmic? can I submit packages for inclusion into karmic at the moment? and when does jaunty go into feature freeze?
[15:33] <mok0> cr3: there may be crashes in a program that only pops up with particular hardware
[15:33] <cr3> mok0: I think hardware compatibility should be far more structured than bugs. there is an intrinsic difference between the two: bugs are transient whereas hardware sticks around for much longer
[15:34] <mok0> cr3: and we have not good way of tracking that atm
[15:34] <mok0> cr3: you have obviously thought a lot more about this than I have
[15:34] <cr3> mok0: apport does a pretty good job of gathering as much information as possible when a crash happens
[15:35] <mok0> cr3: right, but it's not directly visible to users or developers
[15:35] <cr3> mok0: the only problem is that the apport information attached to a bug doesn't necessarily gets structured in such a way that it would be possible to correlate the crash to a particular piece of hardware, hence my obsession on structuring this information properly
[15:36] <mok0> cr3: sounds right
[15:36] <\sh> cr3: is there any way as a normal user to see the certified HW vendors from canonicals site?
[15:36] <cr3> mok0: I may have thought about it a bit more, but I think we're both trying to scratch the same itch :)
[15:36] <clk> Sorry I meant to ask > When is karmic going into feature freeze?
[15:36] <cr3> \sh: http://webapps.ubuntu.com/certification
[15:36] <mok0> clk the info is on the wiki somewhere
[15:37] <clk> thanks mok0 i'll take a look
[15:37] <cr3> mok0: man, that hardware in the wiki is a nightmare to manage, I really need to get back to the doc folks about that
[15:38] <\sh> cr3: thx :) btw...did HP send you some blade examples? bl7000c enclosure and some bl460/465/480/485/495c blades? I wonder if ubuntu just works out of the box...actually I'll see that anyways next week ;)
[15:38] <mok0> cr3, it's difficult to foresee the kind of workflow involving the hwdb + LP that would be useful to have
[15:38] <cr3> \sh: no blades: http://webapps.ubuntu.com/certification/list/?search=HP
[15:39] <\sh> cr3: I read the list..that's why I asked, if they are trying to certify their money makers also for Ubuntu...
[15:39] <cr3> mok0: you've actually put your finger on the problem: it is specifically because it is difficult to foresee that LP has been reluctant to introduce the hwdb too quickly.
[15:39] <clk> one more question, if someone 'nominates' a package for release into a the next version of Ubuntu, does this just mean they would like it to be in the next version or does it mean something more significant?
[15:40] <cr3> \sh: yeah, I hope we'll get to test blades too!
[15:41] <\sh> cr3: what can I do to give you some infos about compatiblity of those blades...I'm going to start to deploy ubuntu (8.04 and 9.04) on those servers..I wonder if you would like to have some infos
[15:42] <cr3> \sh: the best you could do is informally send the outcome of your testing to me on irc or by email
[15:43] <cr3> \sh: if you could run checkbox-cli and submit the information to launchpad, that would also rock
[15:46] <\sh> cr3: cool..will do that :)
[15:47] <iulian> ttx: 'ey.  tomcat6 has just been uploaded this morning.  We can sync it next time with unstable.  What do you say?
[15:48] <ttx> iulian: sounds like a plan. Will let you know if I find any objections in the meantime :)
[15:49] <iulian> ttx: Excellent, that would be be great indeed :)
[15:49] <iulian> s/be//
[16:00] <mok0> cr3: thanks
[16:00]  * mok0 was afk for a while
[16:15] <dupondje> https://bugs.launchpad.net/ubuntu/+source/wammu/+bug/391529 <- sponsorship wanted :)
[16:35] <clk> I'm packaging a GUI used to interface with ghostscript, obviously this package wont work if ghost script is not installed, so should I make ghostscript a dependency or should I just assume anyone installing the gui package will already have ghostscript?
[16:35] <azeem> clk: the former
[16:35] <dstansby> Hi guys, just wondering if anyone can help me with a problem I'm having:
[16:35] <clk> thanks azeem
[16:35] <dstansby> # Regenrate make files using fpcmake.
[16:35] <dstansby> fpcmake -r -Tall
[16:35] <dstansby> Processing Makefile.fpc
[16:35] <dstansby> Error: Target "go32v2", package "rtl" not found
[16:35] <dstansby> make: *** [configure-stamp] Error 1
[16:36] <dstansby> dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2
[16:36] <dstansby> debuild: fatal error at line 1334:
[16:36] <dstansby> dpkg-buildpackage -rfakeroot -d -us -uc -S failed
[16:36] <dstansby> That's the error message I'm getting :(
[16:36] <azeem> dstansby: that's an upstream build system error/problem
[16:36] <azeem> you will have to debug it
[16:37] <dstansby> I'm trying to build a source package that's in the ubuntu repos
[16:37] <azeem> dstansby: do you use pbuildert?
[16:37] <azeem> pbuilder*
[16:37] <dstansby> The command I'm using is 'debuild -S'
[16:38] <azeem> are the Build-Depends installed?
[16:38] <dstansby> I'll just check
[16:40] <dstansby> azeem: It seems some of them weren't. I assumed that they were though, because in the past when I've tried to build without deps I've got an error message telling me which deps were missing
[16:40] <dstansby> Thanks a lot, it's all working now :D
[16:42] <azeem> you usually don't need (all) Build-Depends to build a source package (i.e. debuild -S)
[16:42] <azeem> in this case, apparently some are needed
[16:56] <al-maisan> hello geser, how are things?
[16:56] <al-maisan> Can we have quick chat re. bug #389624?
[16:57] <clk> azeem, any idea what the postscript gui interface "section" would be in the the debian/control file?
[16:57] <clk> whould I just put that as misc?
[16:57] <clk> *would
[16:57] <azeem> what toolkit?
[17:04] <clk> azeem, any idea what the postscript gui interface "section" would be in the the debian/control file?
[17:04] <clk> whould I just put that as misc?
[17:04] <azeem> 17:55 < azeem> what toolkit?
[17:10] <clk> sorry if I missed your reply azeem my wifi kept dropping
[17:10] <azeem> 18:02 < azeem> 17:55 < azeem> what toolkit?
[17:40] <cpl> is there an easy way to find out what "section" a package belongs to in the repo without looking at the debian/control file of the said package?
[17:41] <pochu> emilio@saturno:~$ apt-cache showsrc vinagre | grep Section
[17:41] <pochu> Section: gnome
[17:41] <azeem> cpl: you can look at the package at packages.ubuntu.com
[17:41] <cody-somerville> cpl, Can you elaborate on what you're trying to do?
[17:41] <azeem> or apt-cache
[17:41] <pochu> cpl: the control file may not be right anyway
[17:41] <cody-somerville> cpl, As the value in the control file may be overriden in the repository
[17:41] <cpl> azeem, I was looking at packages.ubuntu.com but I couldnt find the section name on the packages page
[17:41] <pochu> cody-somerville: yeah, apt-cache will show the right one though :)
[17:42] <cody-somerville> pochu, indeed
[17:44] <cpl> any pointers on how I can use apt-cache to get the section name
[17:44] <cpl> apt-cache search showpkg ghostscript brings up nothing
[17:45] <cpl> wait
[17:45] <cpl> nevermind
[17:45] <cpl> I'm an idiot
[17:46] <cpl> actually, I still can't find it
[17:48] <azeem> cpl: what command are you running?
[17:48] <cpl> apt-cache showpkg ghostscript
[17:48] <azeem> who told you to rnu showpkg?
[17:48] <azeem> run*
[17:48] <cpl> no-one
[17:49] <cpl> you said use apt-cache
[17:49] <cpl> I wasn't sure exactly what to do so I looked at the documentation
[17:49] <azeem> why don't you follow pochu's advice from above?
[17:49] <cpl> That's what I though I was doing
[17:49] <cpl> *thought
[17:49] <azeem> did you compare the two command-lines?
[17:49] <azeem> and/or read everything pochu said?
[17:50] <cpl> good point, I didn't see the first thing he said
[17:50] <cpl> thanks
[18:08] <Adri2000> bddebian: I tried gettextize but I still have errors. upstream looks dead though the author sent a mail to the ml a few days ago saying she planned a release soon. I may ask her to update all that autotools stuff
[18:15] <cpl> Does anyone have experience of the Aladdin Free Public Licence
[18:16] <cpl> the FSF dont classify it as a true free license, looks like it's ok to distribute and modify the source as long as it's not resold, I assume that's suitable for the repo?
[18:18] <ScottK> cpl: If it has a non-commercial clause it'll have to go in multiverse
[18:18] <cpl> That's ok
[18:21] <ScottK> cpl: I'm not familiar with the license, but if that's the only issue it's probably fine for multiverse.
[18:22] <cpl> Reading through it, I don't see any other issues. Thanks ScottK
[18:29] <bddebian> Adri2000: Yeah, I tried gettextize too and I even removed IT_PROG_INTLTOOL and got different results but still broken.  I already sent the issue to Melanie (the upstream author). :)
[18:29] <Adri2000> bddebian: oh, ok. sent directly to her or on the ml?
[18:30] <Adri2000> and when did you send it?
[18:30] <bddebian> Adri2000: Directly to her and about 2 hours ago :)
[18:31] <bddebian> Sorry, more precisely 3 hours and 15 minuts ago :)
[18:32] <Adri2000> ok ok :) well tell me when you get an answer
[18:57] <genii> Hello. Is there some place .deb pre/postinst pre/postrm scripts get cached and used other than perhaps /var/lib/dpkg/info/packagename.scriptname  ? I had an error in the postrm, manually fixed it there (/var/lib...postrm) which allowed removal. But then after install of the new package with the fix, it seems to be using the old version for some reason.
[18:58] <\sh> grmpf...what was the url on LP for the NEW queue again?
[19:10] <iulian> \sh: https://launchpad.net/ubuntu/karmic/+queue
[19:15] <ethana2> packaging the wizardpen 0.7 driver
[19:15] <ethana2> It consists of some binary code and a couple .fdi files with a bunch of devices in them
[19:15] <ethana2> Type of package: single binary, multiple binary, library, kernel module, kernel patch or cdbs?
[19:16] <ethana2> It's for most non-wacom graphics tablets
[19:16] <ethana2> I'm /thinking/ kernel module...
[19:16] <ethana2> but the .fdi files aren't a kernel thing I don't think
[19:26] <\sh> iulian: found it already, thx :)
[19:40] <\sh> if nobody objects I'll take some universe merges from the top of the mom list...
[19:40] <\sh> still 20 minutes to go for new software rollout..need to do some work
[19:41] <ScottK> \sh: It's after DIF, so I think it's a free for all.
[19:41] <\sh> ScottK: good .. let's see how many I can get removed from that list
[19:44] <geser> DIF is already in effect?
[19:45] <\sh> geser: tomorrow
[19:45] <\sh> 25th
[19:45] <ScottK> \sh: Right.  I was a day off.
[19:45] <\sh> ScottK: I think a couple of hours don't matter ;)
[19:46] <masterkernel> tomorrow? in that case, can i pay someone to review kernelcheck? ;) jk
[19:46] <\sh> DIF == debian import freeze
[19:46] <\sh> not feature freeze
[19:46] <geser> masterkernel: DIF not FF
[19:46] <masterkernel> *sponsor
[20:22] <ebroder> Any motu-stu types around? I've got a few bugs that I've been trying to get somebody to look at for a few weeks now
[20:23] <pochu> ebroder: stu?
[20:24] <ebroder> Sorry - sru :)
[20:24] <RoAkSoAx> Heya guys, do you know if there is a way which packages are using a specific dependency???
[20:25] <RoAkSoAx> s/way/way to know/
[20:25] <ebroder> aptitude search ~Dpackage
[20:27] <geser> RoAkSoAx: apt-cache rdepends
[20:27] <RoAkSoAx> thanks geser ebroder  :)
[20:28] <loic-m> Does anyone know a bit about handling outdated config.guess files? I'm reading /usr/share/doc/autotools-dev/README.Debian.gz, but I end up with the new file also in the diff.gz as in-source patch
[20:29] <loic-m> And the README doesn't suggest using a patch system
[20:29] <ebroder> loic-m: cdbs will handle preserving the original for you
[20:29] <loic-m> I'm copying the new config.guess/sub during the clean target
[20:29] <ebroder> loic-m: That's the wrong target to do it in
[20:30] <loic-m> ebroder: the package isn't using cdbs, I can't really change that
[20:30] <ebroder> loic-m: clean doesn't always run before builds
[20:30] <ebroder> loic-m: you want to do it in your configure target or whatever
[20:30] <loic-m>  /usr/share/doc/autotools-dev/README.Debian.gz advertises doing it during that target though.
[20:30] <geser> try rm the old ones in clean and copy the ones from autotools-dev in configure or build
[20:30] <geser> this should keep the diff.gz small
[20:31] <loic-m> geser: even though the README says otherwise?
[20:31] <ebroder> loic-m: ==geser. The .diff.gz can't track deleted files
[20:31] <loic-m> ebroder, geser, thanks a lot
[20:31] <geser> yes, therefore the deletion doesn't appear in the diff.gz
[20:32] <ebroder> I honestly have no idea why the README would say to copy them in in the clean stage...
[20:32] <loic-m> If I paste the file during the configure target, I have to do it before calling configure, don't I?
[20:32] <ebroder> loic-m: Yes
[20:33] <ethana2> dpkg-checkbuilddeps: Unmet build dependencies: autotools-dev libx11-dev libxext-dev xautomation xserver-xorg-dev libsysfs-dev
[20:33] <ethana2> Does that mean that they're just not /installed/ or that they're not available at all?
[20:33] <ebroder> ethana2: That they're not installed
[20:34] <loic-m> thanks
[20:34] <ethana2> ebroder: do I have to install them on my actual OS, or can I do that in pbuilder or something?
[20:34] <geser> ethana2: inside your pbuilder is enough
[20:34] <ebroder> ethana2: pbuilder should do that for you, though
[20:34] <ethana2> I tried..
[20:35] <ethana2> I'm going through the debian guide..
[20:35] <geser> and?
[20:35] <ethana2> so it doesn't have ubuntu stuff
[20:35] <ethana2> this was dpkg-buildpackage that I treid
[20:35] <ethana2> can I just throw a tar.gz at pbuilder?
[20:35] <geser> did you pass any options to dpkg-buildpackage?
[20:35]  * RoAkSoAx gives up on trying to fix an unmet dep :S
[20:35] <geser> ethana2: you pass the .dsc to pbuilder
[20:36] <geser> RoAkSoAx: which one?
[20:36] <ethana2> geser: how do I get a .dsc again?
[20:36] <RoAkSoAx> geser, trying to solve revelation http://launchpadlibrarian.net/28050618/buildlog_ubuntu-karmic-i386.revelation_0.4.11-4ubuntu1_FAILEDTOBUILD.txt.gz
[20:36] <ebroder> ethana2: debuild -S
[20:36] <geser> dpkg-buildpackage -S (you might need to install a subset of the build-depends) or debuild -S (which is nearly the same)
[20:37] <RoAkSoAx> geser, in my pbuilder the unmet deps are this: libgdl-1-0: Depends: libgdl-1-common (= 2.26.0-0ubuntu1) but it is not installable
[20:37] <ethana2> ah yes
[20:37] <ethana2> ebroder: thanky'
[20:37] <geser> RoAkSoAx: ah the python-gdl case :)
[20:38] <RoAkSoAx> geser, yeah!! where libgdl-1-0 has been renamed to libgdl-1-2 python-gdl tries to install libgdl-1-0 instead of libgdl-1-2
[20:39] <geser> RoAkSoAx: bug 389728
[20:40] <RoAkSoAx> geser, yes I was actually trying to fix that :)
[20:44] <fabrice_sp> Hi. When building playonlinux in KArmic, it seems ${python:Depends} is substituted with python2.5. Any clue about what's happening?
[20:45] <fabrice_sp> only python2.6 and python-support is installed during the build of the package
[20:45] <geser> fabrice_sp: check the scripts, there is probably somewhere python2.5 set as interpreter
[20:46] <ebroder> fabrice_sp: I think there are a couple of variables/files in the debian/ directory that can change the package to use 2.5
[20:46] <fabrice_sp> thanks geser and ebroder: I'll check the debian files again (didn't found anything before)
[20:47] <RoAkSoAx> fabrice_sp, can this be it: playonlinux-3.5$ grep -sr python2.5 *
[20:47] <RoAkSoAx> python/tools/get_wineversions.py:#!/usr/bin/python2.5
[20:47] <RoAkSoAx>  ??
[20:48] <geser> if the file is included in the deb then it's probably it
[20:48] <fabrice_sp> okkkk
[20:48] <fabrice_sp> I'll patch the file, and see what happen, then. Thanks RoAkSoAx !
[20:48] <RoAkSoAx> fabrice_sp, welcome :)
[20:48] <geser> make it use /usr/bin/python and the dependency on python2.5 should be gone
[20:49] <fabrice_sp> ok. Thanks again!
[20:57] <cpl> I'm packaging something that needs qmake to be used before make, how do I go about this?
[20:58] <ebroder> cpl: cdbs has a qmake class
[20:58] <cpl> the packaging instructions on the wiki only really cover simplistic packages, alot of real world stuff seems to throw questions that the wiki doesnt answer
[20:58] <cpl> ebroder, this is my first package
[20:59] <cpl> ebroder, I'm not using cdbs
[21:00] <cpl> I'm using debhelper
[21:00] <cpl> the wiki says it's the most common
[21:01] <ebroder> cpl: I can't help you, then. I've never written debhelper packages
[21:01] <cpl> ok thanks
[21:02] <pochu> cpl: look at real packages :)
[21:03] <cpl> pochu, I have, but it seems lots of packages have so many little differences depending on how the devs want you to compile their app that there isn't really a standard
[21:03] <cpl> If I could find another package that requires a qmake before install I think that would be good to look at
[21:04] <cpl> even then the specifics will probably be too different to be helpful
[21:05] <cpl> could I just do the qmake to create the makefile then package that?
[21:05] <cpl> or would that be me editing things I'm not supposed too?
[21:05] <cpl> maybe I could do the qmake and make it a diff/
[21:05] <cpl> ?
[21:05] <cpl> or patch
[21:09] <Stupendoussteve> I believe running qmake would generally be done as part of the package compilation
[21:09] <Stupendoussteve> and in debian/rules
[21:10] <cpl> Stupendoussteve, I'll read up on how to edit the rules file in detail
[21:12] <Stupendoussteve> cpl: Does qmake run instead of configure?
[21:12] <cpl> Stupendoussteve, Yes
[21:12] <cpl> it appears so
[21:13] <Stupendoussteve> Should be easier to put it into the rules file then
[21:13] <cpl> mkdir build && cd build && qmake ../activitydiary.pro
[21:13] <cpl> from the install file ^
[21:13] <cpl> So that's what needs to be done in debian/rules ?
[21:14] <Stupendoussteve> Not their steps, but debian/rules usually has a call to the configure script, modifying it to use qmake instead shouldn't be too difficult
[21:14] <Stupendoussteve> may take some trial and error to get it right though
[21:14] <fabrice_sp> RoAkSoAx, geser : it worked! I'm submitting my debdiff to Ubuntu for sponsoring, and will forward it to Debian.
[21:14] <RoAkSoAx> fabrice_sp, awesome! :)
[21:14] <cpl> Thanks Stupendoussteve , I'll see what I can do
[21:15] <Stupendoussteve> Make sure you have qmake in the build-depends as well
[21:15] <cpl> yeah I do
[21:16] <cpl> Stupendoussteve, can I use rules to make the dir that the install file says you need to make?
[21:16] <cpl> or is that not something you should do in rules?
[21:16] <Ampelbein> cpl: i have not read all the conversation, but you could look at qt-creator, qzion or qedje packaging. those are with a build-dep on qmake, maybe you can get a clue there?
[21:17] <cpl> Amaranth, I'll take a look, the way this wants to be built seems overly specific though
[21:25] <RoAkSoAx> Heya guys do you know which package contains  include /usr/share/cdbs/1/class/hlibrary.mk ?
[21:26] <ebroder> RoAkSoAx: dpkg -S $FILE
[21:26] <ebroder> Or if you don't have the package installed, `apt-file search $FIE`
[21:26] <ebroder> *$FILE
[21:26] <masterkernel> RoAkSoAx: haskell-devscripts in karmic
[21:26] <fabrice_sp> haskell-devscripts
[21:26] <fabrice_sp> too late ;-)
[21:26] <RoAkSoAx> but not in Jaunty right?
[21:27] <fabrice_sp> nop
[21:27] <masterkernel> nope
[21:27] <fabrice_sp> only karmic
[21:27] <fabrice_sp> (http://packages.ubuntu.com/search?suite=karmic&searchon=contents&keywords=hlibrary.mk)
[21:27] <RoAkSoAx> ok thanks masterkernel fabrice_sp
[21:27] <masterkernel> when is feature freeze for karmic?
[21:28] <RoAkSoAx> masterkernel, I believe it's around 27 of August
[21:28] <masterkernel> ok thanks
[21:29] <fabrice_sp> masterkernel, https://wiki.ubuntu.com/KarmicReleaseSchedule
[21:46] <yurii> Hi- is there a .pdf guide for packaging?
[21:47] <pochu> there's the packaging-guide in pdf
[21:47] <yurii> a URL for it?
[21:47] <pochu> or the Debian's new maintainers guide
[21:47] <pochu> !packagingguide
[21:48] <yurii> a .pdf version
[21:48] <yurii> not web
[21:48] <cpl> I cant figure out what gtk2.6 is
[21:48] <cpl> I cant find a package even close to that name
[21:49] <pochu> yurii: http://www.debian.org/doc/manuals/maint-guide/maint-guide.en.pdf
[21:49] <cpl> must mean libgtk2.0-0
[21:50] <pochu> yurii: and https://help.ubuntu.com/6.10/pdf/ubuntu/C/packagingguide.pdf
[21:50] <pochu> but this one is outdated
[21:55] <nhandler> I have the complete packaging guide in docbook format if you are interested in converting that to pdf
[21:55] <cpl> can anyone tell what exactly this means?> dpkg-checkbuilddeps: Unmet build dependencies: autotools-dev
[21:55] <nhandler> cpl: Install autotools-dev
[21:55] <cpl> how is that unmet? I'm asking for it via the Build-Depends
[21:55] <Ampelbein> cpl: you don't have the package autotools-dev installed
[21:55] <cpl> in debian/control
[21:56] <nhandler> cpl: How are you building the package?
[21:56] <cpl> debuild
[21:56] <Ampelbein> cpl: then you must install the build-deps manually.
[21:57] <cpl> Amaranth, then what's the point of Build-Depends ?
[21:57] <Ampelbein> cpl: it defines what packages are needed to build the package. (my name is ampelbein, btw)
[21:57] <cpl> if that doesnt pull the packages for me, how are end users going to use the package?
[21:58] <Ampelbein> cpl: these are the dependencies needed to build, either resolved via pbuilder-satisfydepends or by manually installing them.
[21:58] <bddebian> Adri2000: She responded.  She
[21:58] <masterkernel> cpl, build-depends are different from depends
[21:58] <bddebian> will put the patches upstream before the new release but could use some help on the translation stuff :(
[22:00] <Ampelbein> cpl: end users usually don't build packages themselfs. btw: if the package is already in the repositories, a 'sudo apt-get build-dep <foo>' installs the needed packages to build.
[22:00] <cpl> Ampelbein, ok, assuming autotools-dev was never automagically places on the Build-Depends line by dh_make, how would I of known I need it?
[22:00] <cpl> at compile time, I get no missin dep error when I remove it from the Build-Depends line
[22:01] <Ampelbein> cpl: if your package doesn't use autotools you don't need the -dev package.
[22:01] <Ampelbein> cpl: autotools is the aclocal, automake, autoconf stuff
[22:01] <cpl> Ampelbein, How would i find out
[22:01] <cpl> dh_make entered it into the control fine automatically
[22:02] <cpl> *file
[22:02] <cpl> although compilation errors dont mention the dependency
[22:02] <cpl> I now realise I had Build-Depends and depends mixed up by the way
[22:05] <Ampelbein> cpl: sorry, got a disconnect.
[22:05] <cpl> Ampelbein, How would i find out
[22:05] <cpl> dh_make entered it into the control fine automatically
[22:05] <cpl> although compilation errors dont mention the dependency
[22:06] <cpl> I now realise I had Build-Depends and depends mixed up by the way
[22:06] <Ampelbein> cpl: you are supposed to check the build-depends manually. it depends on the software you are trying to package what you need.
[22:06] <cpl> How is this done manually?
[22:07] <Ampelbein> cpl: check what libraries the software links to, which programs are being called in the makefile. most of the time, the authors have a INSTALL file which lists the software needed.
[22:08] <cpl> yeah, thing is, none of those places list this as a dependency
[22:08] <cpl> so why would dh_make put it in the debian/control file?
[22:08] <Ampelbein> cpl: because the author of dh_make thought it would be a good idea to have it listed by default?
[22:08] <azeem> cpl: because somebody convinced the dh_make guy that this is important
[22:09] <azeem> I have an idea who it was
[22:09] <Ampelbein> cpl: autotools are widely used.
[22:09] <cpl> Ampelbein, well, this is the only package job I have looked at where dh_make has added this to the control file
[22:09] <azeem> the rationale is probably that for new ports, config.guess is outdated, so better have it copied over by dh_make
[22:09] <cpl> anyway, I'll roll with this and see how it goes
[22:09] <azeem> cpl: maybe it checks the timestamp
[22:09] <cpl> I just hate it when a tool does something I cant explain
[22:09] <azeem> and if it decides the shipped config.guess copy is too old, does the autotools-dev stuff
[22:10] <azeem> no diea
[22:10] <azeem> idea*
[22:12] <Ampelbein> cpl: azeem just made me think: your package may build on i386 or amd64 but perhaps not on ia64 or lpia because config.guess is outdated. so you may not need the package to build on your architecture, you may still need it on others.
[22:12] <azeem> well
[22:12] <azeem> lpia doesn't need a special config.guess I think
[22:12] <azeem> and ia64 has been supported since 2000 or so
[22:13] <cpl> Yeah I understand why it might be needed, I'm just confused as to why dh_make added the dep, I've seen dh_make do that before
[22:13] <azeem> the last time this was problematic was for the Debian GNU/kFreeBSD port I think
[22:13] <azeem> and some more obscure ports
[22:13] <cpl> I've never seen
[22:13] <cpl> **
[22:13] <azeem> cpl: dh_make isn't really authorative
[22:13] <cpl> also turns out this app has deps that aren't even listed in INSTALL
[22:14] <cpl> lol
[22:14] <Ampelbein> azeem: yeah, i just could not remember a more fitting architecture. i wanted to simply give an explanation.
[22:14] <azeem> it makes some weird choices sometimes; e.g. I usually throw away its debian/rules
[22:14] <azeem> cpl: INSTALL usually only contains generic installation instructions
[22:14] <azeem> look at configure.{in,ac} or README for better information
[22:15] <cpl> Gotta love how vague some developers are within the documentation
[22:15] <ajmitch> many developers will just use the standard boilerplate for that stuff
[22:15] <ajmitch> documentation isn't as fun to update
[22:17] <cpl> checking for flex... no
[22:17] <cpl> checking for lex... no
[22:17] <cpl> You need the 'flex' package
[22:17] <cpl> make: *** [config.status] Error 1
[22:17] <cpl> Depends: ${shlibs:Depends}, ${misc:Depends}, libglade-2.0, libgalde2-dev, xorg-dev, flex
[22:18] <cpl> I know I need flex, that's why it's on the Depends line....................
[22:18] <ajmitch> Build-Depends
[22:18] <cpl> I see
[22:18] <ajmitch> stuff that's required to build the package goes into Build-Depends (and Build-Depends-Indep)
[22:18] <cpl> I didn't know it was needed to build the package
[22:19] <cpl> I thougt it was needed to compile the app
[22:19] <ajmitch> you do now
[22:19] <azeem> cpl: flex is a build tool
[22:19] <azeem> not a runtime thing
[22:19] <cpl> *thought
[22:19] <cpl> ok
[22:19] <ajmitch> building the package is compiling the ap
[22:19] <azeem> cpl: what do you think building the package entails
[22:19] <ajmitch> s/ap/app/
[22:19] <azeem> cpl: and remove those libraries and -dev packages from Depends
[22:20] <cpl> azeem, so where do I specify what dependencies the user needs?
[22:20] <cpl> for aptitude
[22:20] <azeem> cpl: in Depends
[22:20] <azeem> but the libraries are auto-calculated
[22:20] <cpl> ?
[22:20] <azeem> what is unclear?
[22:20] <cpl> yes
[22:21] <cpl> the wiki is no where near detailed enough about this
[22:21] <azeem> for more details, see the Debian policy
[22:21] <cpl> I though I had to tell aptitude, via debian control, what the dependencies are
[22:21] <azeem> btw, xorg-dev is probably wrong in Build-Depends as well; you should specify the X libraries (e.g. libx11-6)
[22:21] <azeem> cpl: shared libraries can be much better figured out dynamically
[22:22] <azeem> see man dpkg-shlibdeps
[22:22] <cpl> So I shouldnt mention anything to do with dependencies?
[22:23] <azeem> you should review the Depends: line after package build and add anything which is missing, and rebuild
[22:24] <cpl> So, if the package install fails due to a missing dependency, then and only then should I add that dependency to the control file?
[22:24] <azeem> I don't think I said that
[22:26] <cpl> I dont understand how I would review the depends
[22:26] <Ampelbein> cpl: it won't fail to install if you missed a dependency. the reason is that the depends: line says apt, what packages are needed to install. you have to see if the application works correctly.
[22:26] <azeem> by looking at them
[22:28] <cpl> Ampelbein, THe last time I built this package I didnt tell control that it needed gtk+-2.0 and it failed to install on any machine except mine
[22:29] <cpl> I dont get why this is so hard for me to understand
[22:29] <azeem> cpl: your control file was wrong then
[22:29] <azeem> and/or your debian/rules
[22:29] <azeem> because this kinda stuff is exactly what is being auto-detected
[22:31] <cpl> Is there a more concise set of documentation for this process anywhere?
[22:31] <azeem> 23:20 < azeem> see man dpkg-shlibdeps
[22:31] <cpl> yes, those are docs for one utility
[22:31] <azeem> cpl: generally, if you don't mess around with the dh_make generated rules/depends, it should just work
[22:31] <cpl> that doesn explain the whole packagine process
[22:32] <azeem> cpl: it's not something you can learn in 10 minutes
[22:32] <Ampelbein> cpl: thats what the packaging guide is for.
[22:32] <cpl> cpl, I know it's not, I've been looking at the wiki on and off for a while now
[22:32] <cpl> it just seems to miss lots if important info
[22:32] <azeem> is the wiki the same as the packaging guide?
[22:32] <cpl> yes
[22:32] <Ampelbein> cpl: see also the debian new maintainers guide, http://www.debian.org/doc/maint-guide/
[22:33] <cpl> are the debiand docs directly transferable to ubuntu?
[22:33] <cpl> *debian
[22:33] <ajmitch> for the most part, yes
[22:34] <azeem> https://wiki.ubuntu.com/PackagingGuide/Complete looks pretty useful to me
[22:34] <RoAkSoAx> Heya guys, I'm working on a python 2.6 transition. Should the I made changes in aclocal.m4 and configure better be in a patch or should I just apply them directly to those files?
[22:35] <ajmitch> probably in a patch, but get the package fixed in debian as well if it's not already
[22:36] <cpl> azeem, it is useful, but after reading it I still wasn't sure exactly what was happening in certain parts of the process
[22:36] <azeem> cpl: certainly most of the above mistakes are explained there
[22:37] <cpl> azeem, if that were true I wouldnt of messed the depends line up
[22:37] <RoAkSoAx> ajmitch, ok thanks
[22:37] <cpl> it doesnt say anything about "auto calculation"
[22:37] <azeem> cpl: maybe you skipped that part
[22:37] <cpl> no
[22:38] <cpl> it doesnt tell me what the build process is actually doing
[22:38] <azeem> "Depends: The list of packages that the binary package depends on for functionality. For hello, we see ${shlibs:Depends}, which is a variable that is used by dpkg-shlibdeps to add the shared library packages needed by the binaries to Depends:. See the dpkg-source(1) and dpkg-shlibdeps(1) man page for more information. "
[22:38] <cpl> yeah, that really doesnt go into enoguh depth
[22:38] <cpl> for someone that has never dealth with this before
[22:38] <cpl> and the man pages
[22:38] <azeem> it doesn't say you should add build depends there, though
[22:39] <cpl> The list of packages that the binary package depends on for functionality
[22:39] <cpl> to me that says you should
[22:39] <azeem> "binary"
[22:39] <cpl> yes
[22:39] <cpl> the build process is making a binary package
[22:39] <azeem> and you install the binary package
[22:39] <cpl> yes
[22:39] <cpl> But
[22:40] <azeem> so you get the binary package as a result of the build process
[22:40] <cpl> rite, so it's only logical to conclude that you put your deps on that line
[22:40] <cpl> so the binary package will call for them via the package manager
[22:40] <cpl> when you are installing
[22:41] <azeem> right
[22:41] <azeem> so what does that have to do with building?
[22:41] <cpl> nothing, it doesnt say it does
[22:41] <azeem> why do you need the X headers to install your binary package?
[22:41] <cpl> but it does say you shoudl list dependencies
[22:41] <cpl> which is what I did
[22:41] <cpl> azeem, I dont know, that what INSTALL says
[22:42] <cpl> *that's
[22:42] <cpl> INSTALL says you need xorg-devel
[22:42] <cpl> which is now known as xorg-dev
[22:42] <azeem> the INSTALL is the source-compile-install documentation
[22:42] <cpl> yes, and I'm compiling the source into the package
[22:42] <cpl> actually
[22:42] <cpl> I see your point
[22:42] <cpl> damn
[22:43] <cpl> If I'm making these mistakes via the documention I'll be very surprised if other less persistent people haven't, and just given up
[22:45] <azeem> cpl: well, you're certainly welcome to provide feedback on the packaging guide I guess
[22:46] <azeem> (though I have nothing to do with it)
[22:46] <cpl> When I've got some experience under my belt I certainly will
[22:46] <azeem> maybe you are right, and it should start off with an explanation of terms - what is a binary, what is a source package, how do you build a binary from a source package
[22:46] <cpl> I think an top down explanation of the process would of helped
[22:47] <cpl> then specific details and processes afterwards
[22:47] <azeem> it's difficult, a lot of people are not interested in the details and just want a black box that provides them with a working .deb
[22:47] <ripps> Is there anybody here with a good understanding of notify-osd? I'm trying to help Qball, the developer of gmpc, to get his libnotify plugin to properly display album images in the notify-osd popups.
[22:55] <cpl> azeem, thank you very much, I know have the package built
[22:55] <cpl> would you say the best way to keep my chroot clean is to rm it after every package job?
[22:56] <cpl> I dont like the idea of devel packages laying around that I dont need anymore
[22:57] <ajmitch> that's why pbuilder or sbuild is usually suggested for building
[22:58] <ajmitch> pbuilder unpacks a tarball for the chroot for each build & cleans it up afterwards
[22:58] <cpl> I looked into pbuilder, the packaging guide starts off by getting you to install it
[22:58] <cpl> but then it doesnt use it
[22:58] <cpl> So i set up a chroot instead
[22:58] <cpl> I'll have to find some decent documentation for pbuilder
[22:59] <cpl> As I have no idea how to do anything within it once i've installed it
[22:59] <cpl> and created a distro with it
[23:00] <ajmitch> once it's setup, it's mostly as case of sudo pbuilder build foo_1.2.3-4.dsc
[23:02] <cpl> got the package working
[23:03] <RoAkSoAx> Heya guys do you know if the requestsync script is buggy or something?
[23:03] <cpl> now I have to go back and sort the copyright details out
[23:03] <cpl> haha, that should be fun
[23:03] <RoAkSoAx> it shows me this error: IOError: No credentials found for 'ubuntu-dev-tools', please see the manage-credentials manpage for help on how to create one for this consumer.
[23:03] <ajmitch> probably the most annoying part of it all
[23:04] <ajmitch> RoAkSoAx: and have you managed your credentials for requestsync? :)
[23:05] <RoAkSoAx> ajmitch, 1. I don't know what that means and 2. I was request syncs couple of weeks ago and did not have any issues
[23:06] <RoAkSoAx> never mind I missed a -s
[23:06] <ajmitch> I was about to ask if you read the manpage as it said
[23:07] <ajmitch> because that's been requestsync's behaviour for a little while now
[23:09] <RoAkSoAx> ajmitch, yeah well in the help says that the -s option is optional. however it showed me that message (with python errors) if I didn't use that option... so I just used it and was ok
[23:29] <RoAkSoAx> any python packager expert around?
[23:35] <Ampelbein> RoAkSoAx: just ask you question, maybe someone can help.
[23:41] <RainCT> RoAkSoAx: Just ask. If you get no answer here you can also try in #debian-python on OFTC.
[23:44] <RoAkSoAx> well I'm trying to merge sugar-hulahop, and I'm adding support for python2.6 and I just would like someone to review my patch to see if the changes that I've done are the right thing to do. Here is my patch: http://pastebin.ubuntu.com/203192/
[23:47] <RainCT> RoAkSoAx: looks good to me, if it works
[23:47] <pochu> huh
[23:47] <pochu> isn't aclocal.m4 autogenerated?
[23:48] <pochu> you should likely autoconf the page
[23:48] <pochu> or autoreconf
[23:48] <pochu> or autohell :)
[23:48] <pochu> or aclocal even
[23:51] <RoAkSoAx> RainCT, thanks.
[23:51] <RoAkSoAx> pochu, so I should do autoreconf ? any guide that I can follow?