=== Amaranth_ is now known as Amaranth === Amaranth_ is now known as Amaranth === Amaranth_ is now known as Amaranth === Amaranth_ is now known as Amaranth [04:13] What an exercise, finally have reprepro and rebuildd working together. Yay, for local package repository [04:39] ok... so... override_dh_fixperms: if I place that in debian/rules it'll automatically be used, nothing special, just all magic? [04:48] MTecknology: I thought with overrides you have to do something [04:50] 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] MTecknology: hmm, I thought that you can the dh_foo, if appropriate, in the override along with whatever using the override for [04:51] *call [04:52] oh [05:00] 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] MTecknology: which directory? [05:00] micahg: /var/log/nginx [05:01] 750 instead of 755 [05:02] 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] 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] MTecknology: yes, that's best, cleaning up after oneself is fine, but sysadmins should have the final say [05:05] MTecknology: check the version in the postinst [05:06] oh... I was under the assumption that that postinst happened after the new package was installed [05:07] MTecknology: hmm, you might have access to the old version, I'm not so clear, maybe someone else knows [05:07] *version number [05:10] MTecknology: yeah, you're right, http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html [05:11] MTecknology: you could check it in the preinst [05:35] micahg: I had to run for a minute.. "new-preinst upgrade old-version [05:36] 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] MTecknology: I believe so :) [05:36] $2 i assume? [05:36] I think so [05:36] :D [05:37] heh.. so I'll just need to know how to compare the versions [05:37] MTecknology: dpkg --compare-versions :) [05:41] micahg: and to grab the new version? [05:42] MTecknology: you shouldn't need to worry about the new version, right? [05:42] what else would i be comparing against? [05:42] MTecknology: the last bad version [05:42] or the first good version depending on how you compare [05:43] oh! [05:43] I created a preisnt and didn't even need it :P [05:44] except postinst doesn't seem to have that version for an upgrade [05:44] MTecknology: whcih is why you should do it in preinst :) [05:48] if dpkg --compare-versions "$most_recently_configured_version" lt "0.8.54-4"; then chmod 750 /var/log/nginx; fi [05:52] micahg: thanks a bunch :D [05:53] MTecknology: you're welcome [05:53] 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] MTecknology: awesome [05:54] even added a feature through a patch that it doesn't look like igor will accept [05:55] MTecknology: is Igor upstream?, we'd want Debian to take that then [05:56] :S ... debuild failed [05:56] 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] MTecknology: that's great, work in one place and lots benefit [05:57] by igor, I meant the guy that controls what winds up in nginx [05:57] MTecknology: right, so if upstream rejects and Debian takes it that's fine for Ubuntu [05:57] apparently i messed up debian/rules bad enough that debuild won't even complete [05:58] oh.. it was only complaining about a little itty bitty thing.... [06:00] 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] MTecknology: I'm sure that'll make a lot of people here smile :) [06:03] micahg: I hope so; I wouldn't even want to /try/ to get a list of everyone that's helped me... [06:27] hi everyone [06:30] I'm interested in joining the prospective developers but I'm confused as to where to go to start [06:30] uh oh, guess my text got cut off [06:30] would anyone happen to know where one would start off in joining the perspective developers? [06:32] jonathan: which developers? [06:32] 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] 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] I'm just confused on what I need to do in order to get started [06:34] you could look into some bugs for a package you particularly like and try to fix them [06:34] fix them, build a patch, and then add to the bug report [06:34] that's it? [06:35] that's one place that's somewhat easy to jump into [06:35] otherwise you could look through and try to triage all bugs in ubuntu :) [06:35] hehe [06:35] I'm sort of new to coding [06:36] I'll have to handle easy things [06:36] there's no one language used; a lot packages produced for ubuntu are python driven though [06:37] 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] jonathan: bug triage is relatively easy and gives you a good idea about the packages.. and where to get involved.. [06:37] and I can just come here if I happen to have questions? [06:37] 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] jonathan: nope, questions are hated in here.... actually, some of the most amazing devs i know hang out in here [06:38] jonathan: depending on what you are doing, we have channels different channels.. [06:38] always eager to help new guys [06:38] where do I go if I have questions or happen to need to talk to someone? [06:39] there's #ubuntu-packaging if you want to get into packaging [06:39] jonathan: you can ask where the best place is to ask too :) [06:39] jonathan: For questions that are definitely about triage, you may find #ubuntu-bugs is a good place to ask them. [06:41] by ubuntu packaging do you mean maintaining packages? [06:41] ya [06:41] someone like me would be capable of doing that? [06:41] that's what I'm working on right now actually [06:42] and I'm very far from an expert [06:42] how much coding is involved in maintaining packages? [06:43] depends.. ideally, not much [06:43] I guess that would be a good place to start then [06:43] 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] 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] jonathan: https://wiki.ubuntu.com/PackagingGuide/Complete [06:46] I've never used debootstrap before [06:46] do you have a guide for that? [06:47] aptitude install debootstrap; debootstrap natty natty; chroot natty [06:47] debootstrap is so easy it's actually scary :P [06:47] ok, I think the first thing I'll work on is mastering all those packaging commands [06:48] nah, then you'll never get anything done :P [06:48] which ones should I focus on? [06:49] 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] if I may ask, how long have you been a linux user? [06:50] 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] I've used linux for a few months so far [06:50] i started playing with linux when 5.04 came out (my senior year in HS) [06:51] that was last year for me [06:51] ok, I'll look through the guide then [06:51] thanks for the help [06:52] jonathan: always feel free to ask questions; sounds like #ubuntu-packaging may be a good channel for you [06:55] only 7min wait time estimated for amd64 ppa builders.... I'm about to skew that estimate... [06:56] upoading OOo? [06:56] maco: not that bad, 13596k [06:57] maco: providing a backport of php5 for lucid and maverick because it was such a huge request with nginx [07:00] maco: at least i didn't trigger a complete rebuild of python :D [07:37] dangit..... [07:40] 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] any tips on making this work? [07:43] 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] 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] Then you have a circular dependency, if nginx depends on -light or -full and they each depend on nginx. [07:46] yup [07:46] I'm not sure what the right way is to deal with it [07:47] jmarsden: I'm sure it's my control file - lemme grab it [07:47] Don't do that :) Avoid recursive dependencies :) apache-common doesn't depend on apache-mpm etc... [07:48] jmarsden: oh......... that's making more sense now :) [07:49] jmarsden: so instead of Depends: nginx-full; I'm looking at Reccomends: nginx-full ? [07:50] or would I want Suggests? [07:51] Recommends: nginx-full | nginx-light ? [07:51] 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] ok- that makes sense :) [07:55] 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] That way apt-get install nginx will do what most people expect. [07:57] 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] OK. If there is an existing "tradition" for that naming scheme, then it makes sense to keep it. [08:03] jmarsden: uploaded again... we'll see if things get fixed :) [08:06] 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] jmarsden: alrighty, i should do that too... I wanted to be sleeping 4hr ago :P thanks :) [08:07] Goodnight. [08:18] good morning [08:52] !info php5-fpm [08:52] php5-fpm (source: php5): server-side, HTML-embedded scripting language (FPM-CGI binary). In component universe, is optional. Version 5.3.3-1ubuntu9.3 (maverick), package size 2875 kB, installed size 7628 kB [08:52] !info php5-fpm natty [08:52] Package php5-fpm does not exist in natty [08:52] zul: What happened? :( [08:54] zul: I just bumped up to 11.04 and it seems to have gone buh-bye === JanC_ is now known as JanC === bilalakhtar_ is now known as cdbs [13:22] MTecknology: http://lists.debian.org/debian-devel/2009/09/msg00348.html <-- related? [13:24] php5 (5.3.3-2) unstable; urgency=low [13:24] * Don't build FPM SAPI now [13:24] -- Chuck Short Fri, 07 Jan 2011 22:44:56 +0000 [13:24] MTecknology: might want to get in touch with that feller if it's a big deal [13:57] bdrung: bug 702765 is ready. [13:57] Launchpad bug 702765 in libgcrypt11 (Ubuntu) "Please sync libgcrypt11 1.4.6-4 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/702765 [13:59] ari-tczew, about bash merging. You can take it i will merging firestarter [14:00] udienz: I doubt that there is anyone willing to sponsor. [14:01] cjwatson wouldn't touch it. doko is maintainer, but he delayed merge to next upstream release. [14:01] and I'm not suprised. bash is very impotant package. [14:02] hm.. ok ok [14:03] I still don't really understand why bash has the need for such a lengthy diff in the first place. [14:04] the merge in question isn't even all that important; most of the important changes are already in Ubuntu [14:04] 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] I'm agreed with cjwatson; I said that in the bug report, though :) [14:06] Rhonda: I can understand plenty of reasons for that from my own experience, THB [14:06] TBH [14:06] not all my packages are synced [14:07] 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] Like pgadmin3, thanks for ACKing it, cjwatson ;) [14:09] Though no merge but sync, actually. [14:10] I think I just processed it [14:10] that's mostly scripted, no need to thank me :) [14:11] Whatever, thanks anyway. :) [14:11] I hope that in next Debian cycle most packages will support Ubuntu changes in modern, parallel system [14:12] I don't find it that simple [14:12] so maybe we will gain more syncs [14:12] in particular I'm not convinced that that interacts brilliantly with revision control [14:12] ari-tczew: Actually dpkg is ready for that and buxy did blog on how to do it. [14:12] … in source v3 [14:13] the implementation there isn't as good as it could have been, IMHO [14:13] you need to maintain entire separate series files for each distro [14:13] 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] so I haven't implemented that for any of my packages [14:13] 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] +1 ^^ [14:14] I (and the cli teams) find that keeping VCS branches for Ubuntu is a good way to manage the delta [14:14] git merging is excellent for this workflow [14:14] right, I prefer that to the approach of multiple series files [14:15] it's much easier to see what's happening [14:15] I would probably use unapply-patches in the multiple-series workflow [14:16] Laney: I also consider VCS branches proper. [14:16] I just haven't anyone approach me to do an ubuntu branch for irssi yet. %-/ [14:17] Hmm, actually I could do that myself me thinks. [14:17] It's in main, so you will have to get upload rights for it [14:17] And step on the toes of those who have worked without contacting me so far. :P [14:17] (if you want to upload yourself) [14:17] oh [14:17] that should be a formality though [14:17] I guess I will have to apply because of logcheck anyway. [14:18] you can get per-package rights, and the Debian maintainer should be almost guaranteed to receive them [14:18] So what else from me is in main that I'm not aware of? Any cheap way to find out? :D [14:18] UDD? :P [14:18] nah, grep-dctrl! [14:18] or g.. yes [14:19] huhm [14:19] 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] Laney: I don't have the packages files at my hand, so I might need to ressort to udd. %-/ [14:19] well, one of the problems [14:19] … or start adding deb-src for ubuntu onto my system. :) [14:19] I want to figure out if topgit makes sense [14:20] Rhonda: or chdist [14:20] cjwatson: What's chdist? [14:20] it's in devscripts [14:21] and I also want a way to indicate to Ubuntu developers that the Debian maintainer is maintaining a branch for the package [14:21] probably Vcs-foo [14:21] http://manpages.ubuntu.com/manpages/maverick/en/man1/chdist.1.html [14:21] I use it on an Ubuntu system so that I can do 'chdist apt-get unstable -d source ' [14:22] * Rhonda goes to http://deb.at/Mchdist instead :P [14:24] huhm [14:25] $ 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] So it's beep, irssi and logcheck \o/ [14:27] Laney: Thanks for pushing me to dig it up [14:28] \o [14:28] now get applying! [14:31] hah [14:31] If time permits I would. The irc meetings aren't quite working for me these days. %-/ [14:31] 19:00 UTC doesn't suite you either? [14:36] That's around the time my young one goes to bed, and we have time to talk with each other, my SO and me === zul_ is now known as zul [15:26] ari-tczew: done [15:27] bdrung: thanks [15:36] Oh. Still had an intrepid chroot and wondered why it gave me errors. [15:38] all sync and merge requests processed [17:03] hello, I am having trouble installing a package (python-scipy) on natty; the errors are as follows: http://pastebin.ubuntu.com/558620/ [17:03] 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] any ideas why this breaks? [17:24] al-maisan: http://packages.ubuntu.com/natty/python-scipy shows this versioned dependency too [17:24] * al-maisan looks [17:25] oh, I see. [17:25] thanks geser ! === Kmos is now known as Guest50434 [18:04] Hopefully whoever uploaded the new numpy is also taking care of the transition. [18:05] 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] Depends. That one rhymes with pie. Scipy however sounds like the peanut butter. [18:09] not http://en.wikipedia.org/wiki/Skippy_the_Bush_Kangaroo ? :) [18:11] re. the new numpy .. /me hopes the same .. I went back to rev. 1:1.4.1-5ubuntu4 for the time being [18:17] ScottK: he's supposed to (he's a mentoree of mine). I'll prod him again [18:18] tumbleweed: Thanks. [18:20] geser: No. http://en.wikipedia.org/wiki/Skippy_(peanut_butter) - Also not http://skippyslist.com/list/ === al-maisan is now known as almaisan-away [18:47] ScottK: around? [18:48] ari-tczew: Somewhat. [18:49] 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] ari-tczew: Link to a .dsc I can dget and build without change and I'll try it. [18:49] Link/Link me [18:50] ScottK: give me 5 minutes [19:08] i had the trunk build of gaj in my PPA [19:08] now there is an official release [19:08] so for adding the entry in changelog [19:08] should I remove the changelog entry of the trunk build [19:08] or keep it there? [19:10] m4n1sh: remove [19:10] keep information only about ubuntu package [19:11] ari-tczew: yeah. Since I would ask a DD to upload it [19:11] so I think it needs to go [19:11] ari-tczew: thanks for help [19:11] just wanted to learn the best practices [19:12] m4n1sh: You're welcome. [19:25] ScottK: armel = ARM ? [19:25] ari-tczew: For our purposes yes. [19:26] 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] ScottK: http://people.ubuntu.com/~ari-tczew/ScottK/ let me know when you will start build :) [19:41] ari-tczew: I have to update the natty chroot on that box first, so it'll be a few minutes. [20:41] ScottK: How it's going? [22:10] ari-tczew: Started the build and then had to leave. Just got back. I'll have a look and see. [22:11] ari-tczew: Successful build. Do you need the build log? [22:11] ScottK: if you could upload somewhere? [22:12] Sure [22:14] ari-tczew: http://pastebin.com/QRrF9W0E [22:15] ScottK: thanks :) [22:16] ari-tczew: You're welcome.