[04:13] <pabelanger> What an exercise, finally have reprepro and rebuildd working together.  Yay, for local package repository
[04:39] <MTecknology> ok... so... override_dh_fixperms:  if I place that in debian/rules it'll automatically be used, nothing special, just all magic?
[04:48] <micahg> MTecknology: I thought with overrides you have to do something
[04:50] <MTecknology> micahg: oh.. I'm only adding it to change the permissions of one directory, would it maybe make more sense to just put it right after dh_fixperms?
[04:51] <micahg> MTecknology: hmm, I thought that you can the dh_foo, if appropriate, in the override along with whatever using the override for
[04:51] <micahg> *call
[04:52] <MTecknology> oh
[05:00] <MTecknology> micahg: If a user installed the package, then upgraded the package but never changed that directory, could I make the permissions get updated on it?
[05:00] <micahg> MTecknology: which directory?
[05:00] <MTecknology> micahg: /var/log/nginx
[05:01] <MTecknology> 750 instead of 755
[05:02] <micahg> MTecknology: Yeah, that should be fine as long as you have a good reason :), you might want to add a news file so people aren't shocked
[05:04] <MTecknology> micahg: I'll add it to the news file; i'd add the change to postinst but then every single update the permission will be reapplied; i'd rather just do it once for old updates and if the user changes it then leave it alone
[05:05] <micahg> MTecknology: yes, that's best, cleaning up after oneself is fine, but sysadmins should have the final say
[05:05] <micahg> MTecknology: check the version in the postinst
[05:06] <MTecknology> oh... I was under the assumption that that postinst happened after the new package was installed
[05:07] <micahg> MTecknology: hmm, you might have access to the old version, I'm not so clear, maybe someone else knows
[05:07] <micahg> *version number
[05:10] <micahg> MTecknology: yeah, you're right, http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
[05:11] <micahg> MTecknology: you could check it in the preinst
[05:35] <MTecknology> micahg: I had to run for a minute.. "new-preinst upgrade old-version
[05:36] <MTecknology> micahg: I had to run for a minute.. "new-preinst upgrade old-version" does that mean there should be an old-version variable in there?
[05:36] <micahg> MTecknology: I believe so :)
[05:36] <MTecknology> $2 i assume?
[05:36] <micahg> I think so
[05:36] <MTecknology> :D
[05:37] <MTecknology> heh.. so I'll just need to know how to compare the versions
[05:37] <micahg> MTecknology: dpkg --compare-versions :)
[05:41] <MTecknology> micahg: and to grab the new version?
[05:42] <micahg> MTecknology: you shouldn't need to worry about the new version, right?
[05:42] <MTecknology> what else would i be comparing against?
[05:42] <micahg> MTecknology: the last bad version
[05:42] <micahg> or the first good version depending on how you compare
[05:43] <MTecknology> oh!
[05:43] <MTecknology> I created a preisnt and didn't even need it :P
[05:44] <MTecknology> except postinst doesn't seem to have that version for an upgrade
[05:44] <micahg> MTecknology: whcih is why you should do it in preinst :)
[05:48] <MTecknology> if dpkg --compare-versions "$most_recently_configured_version" lt "0.8.54-4"; then chmod 750 /var/log/nginx; fi
[05:52] <MTecknology> micahg: thanks a bunch :D
[05:53] <micahg> MTecknology: you're welcome
[05:53] <MTecknology> micahg: now to test it out and see if things still build; I made a lot of changes (should close every open debian and launchpad bug against the package.) :D
[05:54] <micahg> MTecknology: awesome
[05:54] <MTecknology> even added a feature through a patch that it doesn't look like igor will accept
[05:55] <micahg> MTecknology: is Igor upstream?, we'd want Debian to take that then
[05:56] <MTecknology> :S ... debuild failed
[05:56] <MTecknology> micahg: because of all the work i did with the package, the guys that manage it in debian asked me to help maintain; so what i do winds up right there
[05:57] <micahg> MTecknology: that's great, work in one place and lots benefit
[05:57] <MTecknology> by igor, I meant the guy that controls what winds up in nginx
[05:57] <micahg> MTecknology: right, so if upstream rejects and Debian takes it that's fine for Ubuntu
[05:57] <MTecknology> apparently i messed up debian/rules bad enough that debuild won't even complete
[05:58] <MTecknology> oh.. it was only complaining about a little itty bitty thing....
[06:00] <MTecknology> micahg: ya know.... I put a LOT of work into this thing; now I'm looking back and wondering where I'd be if this channel didn't exist.. I'd probably have given up entirely and got nowhere
[06:01] <micahg> MTecknology: I'm sure that'll make a lot of people here smile :)
[06:03] <MTecknology> micahg: I hope so; I wouldn't even want to /try/ to get a list of everyone that's helped me...
[06:27] <jonathan> hi everyone
[06:30] <jonathan> I'm interested in joining the prospective developers but I'm confused as to where to go to start
[06:30] <jonathan> uh oh, guess my text got cut off
[06:30] <jonathan> would anyone happen to know where one would start off in joining the perspective developers?
[06:32] <MTecknology> jonathan: which developers?
[06:32] <jonathan> I was looking at the ubuntu website and it said that prospective developers was a good place to start in joining the development team
[06:33] <MTecknology> oh.. there's a lot of places developers can look to contribute; that's part of why it's such an easy place to jump into
[06:33] <jonathan> I'm just confused on what I need to do in order to get started
[06:34] <MTecknology> you could look into some bugs for a package you particularly like and try to fix them
[06:34] <MTecknology> fix them, build a patch, and then add to the bug report
[06:34] <jonathan> that's it?
[06:35] <MTecknology> that's one place that's somewhat easy to jump into
[06:35] <MTecknology> otherwise you could look through and try to triage all bugs in ubuntu :)
[06:35] <jonathan> hehe
[06:35] <jonathan> I'm sort of new to coding
[06:36] <jonathan> I'll have to handle easy things
[06:36] <MTecknology> there's no one language used; a lot packages produced for ubuntu are python driven though
[06:37] <jmarsden> jonathan: You may find https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Development/Devbeginnings#Ubuntu%20Development%20Beginnings has a few things you can try out as you get started.
[06:37] <evilvish> jonathan: bug triage is relatively easy and gives you a good idea about the packages.. and where to get involved..
[06:37] <jonathan> and I can just come here if I happen to have questions?
[06:37] <MTecknology> triage is where i started out at; i thought that if i just sat there and hammered away, i could be 'that guy' that got through everything :P
[06:38] <MTecknology> jonathan: nope, questions are hated in here.... actually, some of the most amazing devs i know hang out in here
[06:38] <evilvish> jonathan: depending on what you are doing, we have channels different channels..
[06:38] <MTecknology> always eager to help new guys
[06:38] <jonathan> where do I go if I have questions or happen to need to talk to someone?
[06:39] <MTecknology> there's #ubuntu-packaging if you want to get into packaging
[06:39] <MTecknology> jonathan: you can ask where the best place is to ask too :)
[06:39] <jmarsden> jonathan: For questions that are definitely about triage, you may find #ubuntu-bugs is a good place to ask them.
[06:41] <jonathan> by ubuntu packaging do you mean maintaining packages?
[06:41] <MTecknology> ya
[06:41] <jonathan> someone like me would be capable of doing that?
[06:41] <MTecknology> that's what I'm working on right now actually
[06:42] <MTecknology> and I'm very far from an expert
[06:42] <jonathan> how much coding is involved in maintaining packages?
[06:43] <MTecknology> depends.. ideally, not much
[06:43] <jonathan> I guess that would be a good place to start then
[06:43] <MTecknology> if you start though.. my best suggestion is 1) setup a dev system using debootstrap 2) create a user inside of that 3) do your dev in there
[06:44] <MTecknology> if/when you start breaking things or installing php5-dev (i'm doing so now) you're not messing with your base system and it makes new environments incredibly easy to play with
[06:44] <MTecknology> jonathan: https://wiki.ubuntu.com/PackagingGuide/Complete
[06:46] <jonathan> I've never used debootstrap before
[06:46] <jonathan> do you have a guide for that?
[06:47] <MTecknology> aptitude install debootstrap; debootstrap natty natty; chroot natty
[06:47] <MTecknology> debootstrap is so easy it's actually scary :P
[06:47] <jonathan> ok, I think the first thing I'll work on is mastering all those packaging commands
[06:48] <MTecknology> nah, then you'll never get anything done :P
[06:48] <jonathan> which ones should I focus on?
[06:49] <MTecknology> jonathan: up until a month ago I was always editing the timestamp line in debian/changelog by hand and screwed up a lot; then i found dch and life got easier
[06:50] <jonathan> if I may ask, how long have you been a linux user?
[06:50] <MTecknology> jonathan: there's a billion (or so) tools to make your life easier; best to just take a walk through that complete guide, and then start playing and figure out what you don't understand
[06:50] <jonathan> I've used linux for a few months so far
[06:50] <MTecknology> i started playing with linux when 5.04 came out (my senior year in HS)
[06:51] <jonathan> that was last year for me
[06:51] <jonathan> ok, I'll look through the guide then
[06:51] <jonathan> thanks for the help
[06:52] <MTecknology> jonathan: always feel free to ask questions; sounds like #ubuntu-packaging may be a good channel for you
[06:55] <MTecknology> only 7min wait time estimated for amd64 ppa builders.... I'm about to skew that estimate...
[06:56] <maco> upoading OOo?
[06:56] <MTecknology> maco: not that bad, 13596k
[06:57] <MTecknology> maco: providing a backport of php5 for lucid and maverick because it was such a huge request with nginx
[07:00] <MTecknology> maco: at least i didn't trigger a complete rebuild of python :D
[07:37] <MTecknology> dangit.....
[07:40] <MTecknology> I have package nginx-full that depends on package nginx being already installed; package nginx depends on nginx-full | nginx-light.. so nginx needs to be installed before nginx-full is finished up; but installing nginx means you need to install one of the others
[07:41] <MTecknology> any tips on making this work?
[07:43] <jmarsden> MTecknology: install nginx-light first?  That will satisfy the dependency.  Then install nginx, then install nginx-full.  Sounds like it will do what you want??
[07:45] <MTecknology> jmarsden: nginx-full and nginx-light are conflicting packages; they both require nginx to be installed first though; it's like apache-common
[07:46] <jmarsden> Then you have a circular dependency, if nginx depends on -light or -full and they each depend on nginx.
[07:46] <MTecknology> yup
[07:46] <MTecknology> I'm not sure what the right way is to deal with it
[07:47] <MTecknology> jmarsden: I'm sure it's my control file - lemme grab it
[07:47] <jmarsden> Don't do that :)  Avoid recursive dependencies :)  apache-common doesn't depend on apache-mpm etc...
[07:48] <MTecknology> jmarsden: oh......... that's making more sense now :)
[07:49] <MTecknology> jmarsden: so instead of Depends: nginx-full; I'm looking at Reccomends: nginx-full ?
[07:50] <MTecknology> or would I want Suggests?
[07:51] <MTecknology> Recommends: nginx-full | nginx-light ?
[07:51] <jmarsden> Suggests is less "forceful" to package managers, recommends will mean if you apt-get install nginx you *will* pull in nginx-full...  Eww, not sure you want the | stuf in Recommends.
[07:52] <MTecknology> ok- that makes sense :)
[07:55] <jmarsden> Are the names set in stone?  Maybe you should rename what i snow nginx to nginx-common and then rename nginx-full to nginx ???
[07:56] <jmarsden> That way apt-get install nginx will do what most people expect.
[07:57] <MTecknology> I considered different names like that; but the only thing held in nginx-full or nginx-light is a binary and one or two other tiny things; nginx has most everything; but to deal with the way things look now it made the most sense to have nginx instead of nginx-common
[07:58] <jmarsden> OK.  If there is an existing "tradition" for that naming scheme, then it makes sense to keep it.
[08:03] <MTecknology> jmarsden: uploaded again... we'll see if things get fixed :)
[08:06] <jmarsden> OK.  You can sometimes avoid the upload/wait-for-builders/test/oops/edit... cycle delay by setting up your own local repository, incidentally.  But I need to go to bed, you'll need to google for info on how to do that yourself :)
[08:07] <MTecknology> jmarsden: alrighty, i should do that too... I wanted to be sleeping 4hr ago :P    thanks :)
[08:07] <jmarsden> Goodnight.
[08:18] <dholbach> good morning
[08:52] <MTecknology> !info php5-fpm
[08:52] <MTecknology> !info php5-fpm natty
[08:52] <MTecknology> zul: What happened? :(
[08:54] <MTecknology> zul: I just bumped up to 11.04 and it seems to have gone buh-bye
[13:22] <paultag> MTecknology: http://lists.debian.org/debian-devel/2009/09/msg00348.html  <-- related?
[13:24] <paultag> php5 (5.3.3-2) unstable; urgency=low
[13:24] <paultag>   * Don't build FPM SAPI now
[13:24] <paultag>  -- Chuck Short <zulcss@ubuntu.com>   Fri, 07 Jan 2011 22:44:56 +0000
[13:24] <paultag> MTecknology: might want to get in touch with that feller if it's a big deal
[13:57] <ari-tczew> bdrung: bug 702765 is ready.
[13:59] <udienz> ari-tczew, about bash merging. You can take it i will merging firestarter
[14:00] <ari-tczew> udienz: I doubt that there is anyone willing to sponsor.
[14:01] <ari-tczew> cjwatson wouldn't touch it. doko is maintainer, but he delayed merge to next upstream release.
[14:01] <ari-tczew> and I'm not suprised. bash is very impotant package.
[14:02] <udienz> hm.. ok ok
[14:03] <Rhonda> I still don't really understand why bash has the need for such a lengthy diff in the first place.
[14:04] <cjwatson> the merge in question isn't even all that important; most of the important changes are already in Ubuntu
[14:04] <cjwatson> so I don't understand the lengthy debate about it
[14:05]  * Rhonda . o O ( especially since the maintainer on both sides is the same person, actually … )
[14:05] <BlackZ> I'm agreed with cjwatson; I said that in the bug report, though :)
[14:06] <cjwatson> Rhonda: I can understand plenty of reasons for that from my own experience, THB
[14:06] <cjwatson> TBH
[14:06] <cjwatson> not all my packages are synced
[14:07] <cjwatson> important> I mean, I don't mean to diss udienz, but it does seem reasonable to spend effort on merges with important changes first
[14:09] <Rhonda> Like pgadmin3, thanks for ACKing it, cjwatson ;)
[14:09] <Rhonda> Though no merge but sync, actually.
[14:10] <cjwatson> I think I just processed it
[14:10] <cjwatson> that's mostly scripted, no need to thank me :)
[14:11] <Rhonda> Whatever, thanks anyway. :)
[14:11] <ari-tczew> I hope that in next Debian cycle most packages will support Ubuntu changes in modern, parallel system
[14:12] <cjwatson> I don't find it that simple
[14:12] <ari-tczew> so maybe we will gain more syncs
[14:12] <cjwatson> in particular I'm not convinced that that interacts brilliantly with revision control
[14:12] <Rhonda> ari-tczew: Actually dpkg is ready for that and buxy did blog on how to do it.
[14:12] <Rhonda> … in source v3
[14:13] <Laney> the implementation there isn't as good as it could have been, IMHO
[14:13] <Laney> you need to maintain entire separate series files for each distro
[14:13] <cjwatson> I know dpkg can do it, but think of what the unpacked trees look like and how you deal with that in revision control; you end up having diffs in the unpacked tree even though it's the same version, which is very confusing when you then come to modify it
[14:13] <cjwatson> so I haven't implemented that for any of my packages
[14:13] <Rhonda> There is a lot of things that aren't as good as they could have been and annoy people indeed, in source v3 in general, but it's definitely a step in the proper direction
[14:14] <ari-tczew> +1 ^^
[14:14] <Laney> I (and the cli teams) find that keeping VCS branches for Ubuntu is a good way to manage the delta
[14:14] <Laney> git merging is excellent for this workflow
[14:14] <cjwatson> right, I prefer that to the approach of multiple series files
[14:15] <cjwatson> it's much easier to see what's happening
[14:15] <Laney> I would probably use unapply-patches in the multiple-series workflow
[14:16] <Rhonda> Laney: I also consider VCS branches proper.
[14:16] <Rhonda> I just haven't anyone approach me to do an ubuntu branch for irssi yet.  %-/
[14:17] <Rhonda> Hmm, actually I could do that myself me thinks.
[14:17] <Laney> It's in main, so you will have to get upload rights for it
[14:17] <Rhonda> And step on the toes of those who have worked without contacting me so far. :P
[14:17] <Laney> (if you want to upload yourself)
[14:17] <Rhonda> oh
[14:17] <Laney> that should be a formality though
[14:17] <Rhonda> I guess I will have to apply because of logcheck anyway.
[14:18] <Laney> you can get per-package rights, and the Debian maintainer should be almost guaranteed to receive them
[14:18] <Rhonda> So what else from me is in main that I'm not aware of? Any cheap way to find out?  :D
[14:18] <Laney> UDD? :P
[14:18] <Rhonda> nah, grep-dctrl!
[14:18] <Laney> or g.. yes
[14:19] <Rhonda> huhm
[14:19] <cjwatson> the problem with unapply-patches (and traditional patch systems) is that you can't use $vcs blame coherently between upstream and patched source files
[14:19] <Rhonda> Laney: I don't have the packages files at my hand, so I might need to ressort to udd.  %-/
[14:19] <cjwatson> well, one of the problems
[14:19] <Rhonda> … or start adding deb-src for ubuntu onto my system. :)
[14:19] <Laney> I want to figure out if topgit makes sense
[14:20] <cjwatson> Rhonda: or chdist
[14:20] <Rhonda> cjwatson: What's chdist?
[14:20] <cjwatson> it's in devscripts
[14:21] <Laney> and I also want a way to indicate to Ubuntu developers that the Debian maintainer is maintaining a branch for the package
[14:21] <Laney> probably Vcs-foo
[14:21] <cjwatson> http://manpages.ubuntu.com/manpages/maverick/en/man1/chdist.1.html
[14:21] <cjwatson> I use it on an Ubuntu system so that I can do 'chdist apt-get unstable -d source <package>'
[14:22]  * Rhonda goes to http://deb.at/Mchdist instead  :P
[14:24] <Rhonda> huhm
[14:25] <Rhonda> $ grep-dctrl -FMaintainer,Original-Maintainer,Uploaders 'Gerfried Fuchs' -sPackage,Section /var/lib/apt/lists/at.archive.ubuntu.com_ubuntu_dists_natty_* | grep-dctrl -v -FSection universe
[14:26] <Rhonda> So it's beep, irssi and logcheck  \o/
[14:27] <Rhonda> Laney: Thanks for pushing me to dig it up
[14:28] <Laney> \o
[14:28] <Laney> now get applying!
[14:31] <Rhonda> hah
[14:31] <Rhonda> If time permits I would. The irc meetings aren't quite working for me these days.  %-/
[14:31] <geser> 19:00 UTC doesn't suite you either?
[14:36] <Rhonda> That's around the time my young one goes to bed, and we have time to talk with each other, my SO and me
[15:26] <bdrung> ari-tczew: done
[15:27] <ari-tczew> bdrung: thanks
[15:36] <Rhonda> Oh. Still had an intrepid chroot and wondered why it gave me errors.
[15:38] <bdrung> all sync and merge requests processed
[17:03] <al-maisan> hello, I am having trouble installing a package (python-scipy) on natty; the errors are as follows: http://pastebin.ubuntu.com/558620/
[17:03] <al-maisan> what is puzzling is that the quoted dependency "Depends: python-numpy (< 1:1.5)" is not in the python-scipy package's debian/control file
[17:04] <al-maisan> any ideas why this breaks?
[17:24] <geser> al-maisan: http://packages.ubuntu.com/natty/python-scipy shows this versioned dependency too
[17:24]  * al-maisan looks
[17:25] <al-maisan> oh, I see.
[17:25] <al-maisan> thanks geser !
[18:04] <ScottK> Hopefully whoever uploaded the new numpy is also taking care of the transition.
[18:05] <maco> ScottK: does your brain pronounce that package's name with the proper -py ending or do you keep rhyming with an adjective for mashed potatoes?
[18:06] <ScottK> Depends.  That one rhymes with pie.  Scipy however sounds like the peanut butter.
[18:09] <geser> not http://en.wikipedia.org/wiki/Skippy_the_Bush_Kangaroo ? :)
[18:11] <al-maisan> re. the new numpy .. /me hopes the same .. I went back to rev. 1:1.4.1-5ubuntu4 for the time being
[18:17] <tumbleweed> ScottK: he's supposed to (he's a mentoree of mine). I'll prod him again
[18:18] <ScottK> tumbleweed: Thanks.
[18:20] <ScottK> geser: No.  http://en.wikipedia.org/wiki/Skippy_(peanut_butter) - Also not http://skippyslist.com/list/
[18:47] <ari-tczew> ScottK: around?
[18:48] <ScottK> ari-tczew: Somewhat.
[18:49] <ari-tczew> ScottK: could you try build gnome-power-manager on natty (armel) without that change: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gnome-power-manager/natty/revision/123#debian/rules
[18:49] <ScottK> ari-tczew: Link to a .dsc I can dget and build without change and I'll try it.
[18:49] <ScottK> Link/Link me
[18:50] <ari-tczew> ScottK: give me 5 minutes
[19:08] <m4n1sh>  i had the trunk build of gaj in my PPA
[19:08] <m4n1sh> now there is an official release
[19:08] <m4n1sh> so for adding the entry in changelog
[19:08] <m4n1sh> should I remove the changelog entry of the trunk build
[19:08] <m4n1sh> or keep it there?
[19:10] <ari-tczew> m4n1sh: remove
[19:10] <ari-tczew> keep information only about ubuntu package
[19:11] <m4n1sh> ari-tczew: yeah. Since I would ask a DD to upload it
[19:11] <m4n1sh> so I think it needs to go
[19:11] <m4n1sh> ari-tczew: thanks for help
[19:11] <m4n1sh> just wanted to learn the best practices
[19:12] <ari-tczew> m4n1sh: You're welcome.
[19:25] <ari-tczew> ScottK: armel = ARM ?
[19:25] <ScottK> ari-tczew: For our purposes yes.
[19:26] <ScottK> arm is the processor and also the name of a now defunct architecture in Debian that was replaced by armel (IIRC little endian versus big endian is the difference)
[19:38] <ari-tczew> ScottK: http://people.ubuntu.com/~ari-tczew/ScottK/ let me know when you will start build :)
[19:41] <ScottK> ari-tczew: I have to update the natty chroot on that box first, so it'll be a few minutes.
[20:41] <ari-tczew> ScottK: How it's going?
[22:10] <ScottK> ari-tczew: Started the build and then had to leave.  Just got back.  I'll have a look and see.
[22:11] <ScottK> ari-tczew: Successful build.  Do you need the build log?
[22:11] <ari-tczew> ScottK: if you could upload somewhere?
[22:12] <ScottK> Sure
[22:14] <ScottK> ari-tczew: http://pastebin.com/QRrF9W0E
[22:15] <ari-tczew> ScottK: thanks :)
[22:16] <ScottK> ari-tczew: You're welcome.