[01:26] <MTecknology> I applied a lot of patches to some code. I know the configure and generated_lists files changed. Because those two files changed I know that files in debian/ need to change. the configure file changed a lot. How should I handle this with the rules file?
[01:26] <MTecknology> or, it debian/ at all?
[01:27] <persia> What are you trying to accompiish?
[01:27] <persia> More detail helps get a real answer.  It may get you redirected, but that's not enough for any value.
[01:28] <MTecknology> persia: I'll show you what I'm looking at
[01:29] <MTecknology> http://github.com/dreamcat4/php-fpm/blob/master/readme.markdown -- "Integrated Compilation"
[01:29] <persia> I really think you want to talk to PHP packagers about this :)
[01:29] <persia> You didn't find them here really, other than pointers to PPAs.
[01:29] <MTecknology> I have php5-5.3.1 building the package successfully; I applied those patches
[01:30] <persia> Maybe some of the PPA owners, or the debian folk.
[01:30] <persia> So, you changed some configure flags.
[01:30] <persia> Which changed the set of files that were produced.
[01:30] <persia> And the .debs that you ended up with didn't include these files/
[01:30] <MTecknology> none yet, there's a ./buildconf --force that auto generates the whole configure file
[01:31] <persia> s#/#?#
[01:31] <MTecknology> I didn't make a .deb yet because I know things will be exactly as they are now
[01:31] <persia> Will they?  That's usually not the case.
[01:31] <MTecknology> oh..
[01:32] <persia> Go test, and when you get a failure, maybe someone can help.
[01:32] <MTecknology> ok
[01:32] <MTecknology> I just know I'm far from done
[01:32] <persia> (but again, we don't necessarily know much about PHP packaging)
[01:32] <lifeless> I definitely don't.
[01:32] <lifeless> And you can' make me.
[01:32] <MTecknology> right, I could ask in debian-mentors but I just like the friendly in here
[01:33] <persia> MTecknology: Have you tried asking the debian maintainers?  That's probably better than debian-mentors.
[01:33] <MTecknology> where do I find them?
[01:34] <MTecknology> I see a name in the changelog- jsut email?
[01:37] <MTecknology> persia: does my unwaivering determination at least impress you a little?
[01:38] <MTecknology> :)
[01:38] <persia> Not especially.  Lots of people are determined :)
[01:39] <persia> I''d be more impressed if you were working closely with the Debian PHP team, and interested teams in Ubuntu towards accomplishing something that would generally improve Ubuntu.
[01:39] <MTecknology> am I at least a little more unique?
[01:39] <persia> But maybe I have a narrow focus :)
[01:40] <MTecknology> hey - do you ever sleep?
[01:40] <persia> Several times a week, at least.
[01:41] <persia> I just don't happen to have a close attachment to the planet's diurnal period.
[01:41] <MTecknology> I was just wondering because I went to sleep, you were on; i woke up, you were on; i'm on now, you're on
[01:42] <MTecknology> it's building in pbuilder
[02:06] <MTecknology> persia: my proc is almost 200 deg F [83 deg C]
[02:07] <MTecknology> 188.6F
[02:09] <MTecknology> 206.6 F
[02:18] <MTecknology> 212 F
[02:31] <quidnunc> Is there a way to run the configure step of a deb alone?
[02:35] <quidnunc> Argh. Never mind that won't help me in any case.
[02:35] <persia> quidnunc: Maybe dpkg-reconfigure?
[02:35] <persia> heh :)
[03:06] <MTecknology> it's almost done building - i think
[03:09] <MTecknology> persia: it built fine in pbuilder - no idea what to do now :P
[03:09] <MTecknology> gotta run for a bit
[04:47] <suji11> Good morning
[05:50] <nigelb> my doubt is more or less like I want to package the latest pidgin.  how do I know what its dependencies are?  Where do I see it?
[05:50] <nigelb> micahg: ^
[05:50] <micahg> nigelb: there's already a pidgin developers PPA
[05:50] <micahg> nigelb: https://launchpad.net/~pidgin-developers/+archive/ppa
[05:51] <nigelb> I know
[05:51] <nigelb> its more for the learning that for usage
[05:51] <nigelb> I dont really want to install it, but I'm trying to learn the process
[05:51] <micahg> nigelb: for compiled apps, look at the configure file
[05:51] <nigelb> ah
[05:55] <nigelb> micahg: whoa, thats a big mess.  is there a shortcut here?
[05:56] <micahg> nigelb: a README or INSTALL file possibly...maybe you should start with a smaller app
[05:57] <nigelb> micahg: suggestions? (I thought pidgin was small)
[05:58] <micahg> nigelb: maybe gtg
[05:58] <nigelb> micahg: lemme try that out
[05:59] <micahg> nigelb: pidgin is small compared to firefox
[05:59] <micahg> which is small compared to openoffice.org
[05:59] <micahg> everything is relative :)
[05:59] <nigelb> heh
[06:40] <micahg> nigel_nb: BTW, there are many pieces to packaging...patching would be first I would think
[06:40] <nigel_nb> micahg: lol, I'm pretty sure of my way with patching now
[06:40] <nigel_nb> micahg: patched 2 packages now
[06:41] <nigel_nb> third one, probably before I hit the bed
[06:41] <micahg> nigel_nb: k, that's good, how about merging/updating a package, that would be step 2 I would think
[06:41] <nigel_nb> micahg: unfortunately, I got involved with motu around feature freeze, so now I'll wait until next cycle to learn more
[06:43] <micahg> nigel_nb: feature freeze doesn't stop everything
[06:43] <persia> nigel_nb: There's heaps of work doing in MOTU if you're looking for something.
[06:44] <nigel_nb> persia: there is?
[06:44] <persia> No need to wait until the next cycle.
[06:44] <persia> There is.
[06:44] <nigel_nb> um, how do I find it?
[06:44] <persia> So, there's about 20,000 bugs open and many are triaged, and need fixing.
[06:44] <StevenK> Ask, usually. :-)
[06:44] <nigel_nb> I'm in the processing of fixing one ;)
[06:44] <StevenK> nigel_nb: You'll learn not to say you're bored around persia -- he'll bury you in work.
[06:45] <nigel_nb> StevenK: oh
[06:45] <persia> There's heaps of packages in the archives with unmet dependencies, which will make users unhappy if they try to install them.
[06:45] <persia> Running `apt-cache -i unmet` against a lucid apt-cache will show a goodly list.
[06:45] <nigel_nb> the unmet dependency is something I want to understand too
[06:45] <persia> There's a bunch of packages that can't be built, and someone needs to fix those.
[06:45] <persia> Any of that interest you, or you want more categories ?
[06:46] <nigel_nb> whats the sane way to figure out dependencies?
[06:46] <nigel_nb> I'll stick to that one
[06:46] <persia> OK.
[06:46] <persia> So, with apt-cache you can get a list of stuff that is broken.
[06:46] <persia> Often this is because there was some change in packaging since the last release.
[06:47] <persia> So it's just a bit of detective work to read the history of the packages that aren't provided anymore by comparing karmic and lucid.
[06:47] <persia> And then checking how the dependencies are set in debian/control in the affected package.
[06:47] <persia> And then making some changes.
[06:47] <nigel_nb> can you help on one such example?
[06:47] <persia> This kind of work is also a good way to better understand package relationships, get famliar with control files, and learn the various ways one calls apt-cache.
[06:48]  * micahg still needs to learn that
[06:48] <persia> OK.  Let's look at boa-constructor.
[06:48] <persia> It has an unmet dependency on pychecker.
[06:49] <persia> Do you see that?
[06:49] <nigel_nb> yea, package not available
[06:50] <persia> OK.  Now take a look at a karmic apt-cache.
[06:50] <nigel_nb> for boa or pycheker?
[06:50] <persia> For pychecker.
[06:51] <nigel_nb> I see it
[06:52] <persia> OK,  Next hunt down the latest changelog for that source on changelogs.ubuntu.com
[06:54] <nigel_nb> there is only a kamic changelog
[06:54] <nigel_nb> nothing for lucid
[06:54] <persia> Well, that's true for thoulsands of packages.
[06:54] <nigel_nb> so, we gotta bring it to lucid?
[06:55] <persia> Well, not necessarily.
[06:55] <persia> First we find out why it's not there.
[06:55] <persia> Usually this is a removal.
[06:56] <nigel_nb> ah
[06:57] <persia> So, looking at the changelog, there are some "unstable" entries, which means it was in Debian also.
[06:57] <nigel_nb> yeah
[06:57] <persia> If we remove a package from Ubuntu only that is still in Debian, it shows up in the blacklist:http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[06:58] <stefanlsd> this could also help. https://edge.launchpad.net/ubuntu/+source/pychecker/+publishinghistory
[06:58] <persia> You can check the status of the package in Debian at http;//packages.qa.debian.org
[06:59] <nigel_nb> ah, pychecker was removed because it depends on python 2.5
[07:00] <persia> nigel_nb: Note that 0.8.18-2ubuntu1 was removed.
[07:00] <persia> Now check the status in Debian.  Is there a newer version?
[07:00] <persia> (or revision, technically)
[07:00] <nigel_nb> there is a 0.8.18-3 version
[07:01] <persia> Now, check that changelog entry and see if it says anything about adding support for python2.6
[07:01] <nigel_nb> nope
[07:02] <persia> In that case it's probably still not ported.
[07:02] <persia> So we aren't going to be able to get back pychecker.
[07:02] <nigel_nb> so we remove boa? or add python 2.5?
[07:02] <persia> Next, take a look at the boa-constructor source.  See if you can figure out why it needs pycheker.
[07:02] <persia> One of the release goals for lucid is to not ship python2.5 :)
[07:04] <nigel_nb> getting source
[07:04] <nigel_nb> but I'm not if I can poke around enough to figure out if it needs pychecker
[07:05] <persia> Well, it's not usually that hard to figure out.
[07:05] <persia> Running grep on the source is often enough.
[07:05] <nigel_nb> oh
[07:06] <nigel_nb> something wrong with archive today? seems to be awfully slow
[07:07] <persia> It's probably your mirror (or you don't have one set up).
[07:07] <nigel_nb> i'm degetting the dsc file from package.ubuntu.com
[07:07] <nigel_nb> I dont think that uses a mirror
[07:07] <dholbach> good morning
[07:08] <StevenK> I'm seeing slowness as well, but it's a Telstra problem
[07:08] <nigel_nb> mine's not really slow.  Its stuck!
[07:08] <persia> nigel_nb: apt-get source in a lucid chroot/install is better.  packages.ubuntu.com can be days out of date sometimes.
[07:08] <nigel_nb> I only see "HTTP request sent, awaiting response... "
[07:08] <nigel_nb> sudo pbuilder login works fine?
[07:09] <persia> Plus, with apt-get source you can set up multiple source mirrors in your sources.list, and it pulls from the the first one in the last that contains the newest source.
[07:09] <persia> Sure.  That's a fine way to get into a chroot :)
[07:10] <nigel_nb> my chroot is a mess
[07:11] <nigel_nb> it doesnt have a sources.list it seems?
[07:11] <nigel_nb> "You must put some 'source' URIs in your sources.list"
[07:11] <StevenK> It ought to.
[07:11] <StevenK> Oh, it has a sources.list, but it doesn't have any deb-src lines
[07:12] <nigel_nb> now, I have to take the pain of install vim inside chroot
[07:13] <persia> If you're not running lucid and you're developing lucid, it may be convenient to set up a long-running development chroot.
[07:13] <nigel_nb> meaning?
[07:13] <persia> For instance, create a new tarball with pbuilder and give it a different name.  Install all your development tools in there with --save-after-login
[07:13] <persia> Or use a persistent schroot.
[07:14] <nigel_nb> I have no clue how to do either, but the first one sounds attractive
[07:14] <persia> There are a number of packages where the source only builds (or only builds correctly) in lucid.
[07:14] <nigel_nb> I use pbuilder-dist for building packages
[07:14] <persia> Well, if you set up pbuilder the first time, you'd just run the script again, perhaps with an extra parameter.
[07:14] <nigel_nb> and pbuilder as such for other stuff.. like now
[07:15] <nigel_nb> I should probably isntall an ubuntu-minimal in one of them
[07:16] <persia> Hrm.  I'm not sure how to advise you to do this with pbuilder.
[07:16] <persia> I don't see any --name option or anything.
[07:17] <persia> And I'm not going to recommend someone running karmic install schroot unless they have some specific reason for doing so, because it's complicated (and most of the complication goes away with lucid)
[07:19] <nigel_nb> this is turning up even more screwed up
[07:19] <persia> How so?
[07:20] <nigel_nb> Is this the correct line? "deb-src http://lk.archive.ubuntu.com/ubuntu/ lucid main restricted universe multiverse"
[07:21] <nigel_nb> I get the error "E: Could not open file /var/lib/apt/lists/lk.archive.ubuntu.com_ubuntu_dists_lucid_main_source_Sources - open (2: No such file or directory)"
[07:21] <persia> Did you run apt-get update after adding the line?
[07:21] <nigel_nb> ugh
[07:22] <nigel_nb> looks like I'm doing all the wrong things posible
[07:24] <nigel_nb> persia: I'm going to loose power in exactly 8 minutes.  If I get cut off, we'll have to pick up 2morrow
[07:24] <nigel_nb> (scheduled power cuts)
[07:24] <stefanlsd> nigel_nb: where do you stay?
[07:24] <nigel_nb> stefanlsd: India
[07:24] <persia> nigel_nb: You're going to have to remind me where we are from scratch, but OK.
[07:25] <nigel_nb> if we're lucky it may go an hour late, never know ;)
[07:27] <persia> OK.  So when you have source and a working environment, run grep :)
[07:27] <stefanlsd> yeah, def an issue somewhere, cant connect to security.ubuntu.com from za and us
[07:28] <nigel_nb> ah, so it was not just me
[07:39] <nigel_nb> apt-get source is pulling from debian svn, is that sane?
[07:42] <persia> Not only is it not sane, it's wrong.  Are you sure, or is it just warning you that the soruce is in svn?
[07:42] <nigel_nb> its just warning me I guess
[07:43]  * persia got a warning, but pulled from the mirror
[08:05] <nigel_nb> persia: if you're still around, I did a grep
[08:06] <persia> And what did you see?
[08:06] <nigel_nb> i see something in prefernces
[08:07] <nigel_nb> and controllers
[08:07] <persia> OK, so this tells us that the code is really using pychecker.
[08:07] <persia> So, we have three options
[08:08] <persia> 1) remove boa constructor
[08:08] <persia> 2) patch boa constructor to not use pychecker (which means going through the source, and finding out how it's used, etc.)
[08:09] <persia> Because it's listed in Preferences, this might be just a matter of adjusting the default preferences, adding a wrapper around the actual pychecker call to report an error if pychecker is missing, and demoting pychecker to Suggests:
[08:11] <persia> 3)demote pychecker to Suggests, change the default config, file a bug about boa constructor crashing when configured to use pychecker and pychecker is not installed.
[08:11] <persia> Of these, 2) is generally preferred, because 1) removes something that doesn't *have* to be removed and 3) leaves a buggy package for users.
[08:12] <persia> Since this is going to take a while, file a bug about it and assign yourself.
[08:13] <persia> When you have questions, ask them here.  Lots of people know python and will gladly help you work on unmetdeps
[08:13] <nigelb> persia: I got till "Because.."
[08:13] <nigelb> (lost connection in between)
[08:14] <persia> Ah.
[08:14] <persia> 3)demote pychecker to Suggests, change the default config, file a bug about boa constructor crashing when configured to use pychecker and pychecker is not installed.
[08:14] <persia> Of these, 2) is generally preferred, because 1) removes something that doesn't *have* to be removed and 3) leaves a buggy package for users.
[08:14] <persia> Since this is going to take a while, file a bug about it and assign yourself.
[08:14] <persia> When you have questions, ask them here.  Lots of people know python and will gladly help you work on unmetdeps
[08:14] <nigelb> is there a standard format for the bug?
[08:17] <persia> Not really.
[08:18] <persia> File it against boa constructor reporting that boa-constructor cannot be installed in lucid.
[08:18] <persia> Explain why it can't be installed.
[08:19] <nigelb> is there a way to test run the code I edit?
[08:19] <persia> Yes, but I don't know how to do it with your environment, so I'm going to give you general guidelines.
[08:19] <nigelb> k
[08:20] <persia> 1) Run what-patch to determine how to patch the source, and follow that method.
[08:20] <persia> 2) build the source package including your changes and build it locally with your preferred build tool
[08:21] <persia> 3) Enter a chroot preserving enough environment to be able to launch xclients inside the chroot and show them on your main X server
[08:21] <persia> 4) install the program in the chroot and run it
[08:21] <persia> Note that this method has limitations: it can't test stuff that really exercises X or the kernel or does lots of D-Bus coordination, etc.
[08:21] <nigelb> I didnt understand step 3
[08:22] <persia> But for standalone apps with no hardware interaction, it works great.
[08:23] <persia> I don't know how to do it for your environment.  I use e.g. `schroot -c -p lucid-armel`
[08:23] <persia> Err, "-p -c"
[08:23] <nigelb> I can build another evironment (I really dont mind)
[08:23] <persia> Do you already use LVM?
[08:24] <nigelb> no :(
[08:31] <persia> nigelb: Then just ask someone else how to access the system X server from inside a pbuilder chroot.  That I don't know shouldn't either limit you or require you to do strange things to your system.
[09:40]  * siretart` would very much appreciate testing of x264 encoding with the
[09:40] <siretart`> recently built ffmpeg-extra package in lucid
[09:41] <siretart`> it is using a very recent x264 version to encode, a libx264.c wrapper has been backported
[12:44] <shadeslayer> dholbach: ping
[12:45] <shadeslayer> dholbach: rowinggolfer in #launchpad has agreed to join me in the PPA session
[12:51] <dholbach> shadeslayer: can you please mail packaging-training-coordinators @ lists.launchpad.net with the details?
[12:52] <dholbach> thanks a bunch in advance
[12:52] <dholbach> :)
[12:52] <shadeslayer> sure :)
[12:52] <shadeslayer> dholbach: what details would you need btw?
[12:53] <dholbach> who, when, what :)
[12:53] <shadeslayer> ok :)
[12:53] <dholbach> thanks :-)
[13:25] <shadeslayer> dholbach_: dispatched a mail to the abovesaid address
[13:25] <dholbach_> shadeslayer: awesome, thanks
[13:25] <dholbach_> shadeslayer: somebody should be in touch with you soon
[13:34] <SEJeff> fta, Is there a way to get older releases of your daily thunderbird from the ubuntu-mozilla-daily ppa? Thunderbird 3 is horribly broken and has been for a week or so
[13:38] <shadeslayer> dholbach: awesome :)
[13:38] <rlp10> I'm new here and I'm new to packaging... I want to update a package in jaunty as its old compared with the karmic package
[13:38] <rlp10> I'd like to contribute and I'm reading this: https://wiki.ubuntu.com/PackagingGuide/Complete
[13:39] <rlp10> Could someone please re-assure me that this isn't as difficult as it looks? :)
[13:40] <shadeslayer> rlp10: it isnt
[13:40] <shadeslayer> rlp10: i can help :)
[13:40] <SEJeff> rlp10, There is a good chance you could just download the source package, rebuild it with pbuilder, and have shiney debs
[13:40] <shadeslayer> rlp10: since the package is already in the repos,its *very* easy
[13:41] <rlp10> yay :)
[13:41] <shadeslayer> can anyone tell me what the *.install files created by dh_create do?
[13:41] <rlp10> is there somewhere I should be looking at with instructions to do that rather than the complete packaging guide?
[13:41] <shadeslayer> rlp10: if you have a launchpad account its super easy
[13:41] <rlp10> ok, I'll sign up now
[13:42] <shadeslayer> rlp10: ill help you step by step if you want
[13:42] <MTecknology> shadeslayer: can you help me step by step? :D
[13:42] <rlp10> shadeslayer: thanks so much
[13:43] <MTecknology> I need a lot of help :P
[13:43] <shadeslayer> MTecknology: sure
[13:43] <shadeslayer> MTecknology: ive learnt how to package stuff already in the repos
[13:43] <shadeslayer> MTecknology: and not fishy stuff like hookscripts :D
[13:43] <shadeslayer> s/not/no
[13:44] <shadeslayer> MTecknology: what are you trying to package?
[13:44] <rlp10> shadeslayer: I'm logged into launchpad
[13:44] <MTecknology> shadeslayer: well, I aplied patches for php-fpm to php5-5.3.1. I know how to build what I have from source and get what I want, but I want to build this package.
[13:45] <shadeslayer> MTecknology: ok is this a existing package
[13:45] <shadeslayer> rlp10: ok now make a PPA
[13:45] <MTecknology> ya, not in ubuntu repos yet
[13:45] <shadeslayer> rlp10: you cannot change your launchpad url after you do this!
[13:46] <shadeslayer> MTecknology: ok im struggling with native packages right now :P
[13:46] <shadeslayer> MTecknology: i can help with : https://wiki.ubuntu.com/PackagingGuide/Complete
[13:47] <MTecknology> shadeslayer: I think this is beyond that massive document :P - all I have left to figure out is the debian/ stuff
[13:47] <shadeslayer> rlp10: also read this : https://help.launchpad.net/Packaging/PPA
[13:47] <MTecknology> I'm kind of considering just building it from source on my server and letting a really smart person take over the rest
[13:47] <rlp10> shadeslayer: thanks, reading
[13:47] <shadeslayer> MTecknology: theres a script called dh_make which does all the stuff for you
[13:48] <shadeslayer> MTecknology: usage is : dh_make -e myemail@host.com
[13:48] <MTecknology> shadeslayer: I was trying to work off of what they already did
[13:48] <MTecknology> you think I should start with a fresh debian/ ?
[13:48] <shadeslayer> MTecknology: ok well you need the patch system in the rules file
[13:48] <shadeslayer> MTecknology: well... depends
[13:49] <shadeslayer> MTecknology: it would certainly help :)
[13:49] <MTecknology> If that's best I'll gladly do it
[13:50] <MTecknology> I'll pull up info on the patch I've been working with
[13:51] <MTecknology> http://github.com/dreamcat4/php-fpm/blob/master/readme.markdown - "Integrated Compilation"
[13:51] <rlp10> shadeslayer: so I need to make a PGP key and sign the code of conduct, right?
[13:51] <shadeslayer> MTecknology: you just need to add one line in the rules file to implement the patch system
[13:51] <shadeslayer> rlp10: yes
[13:51] <shadeslayer> rlp10: you do know how to make one?
[13:51] <rlp10> shadeslayer: no sorry, I understand the concept in general terms tho
[13:52] <shadeslayer> rlp10: youll also need to authorize a few packages for uploading stuff to the ppa
[13:52] <MTecknology> shadeslayer: ooh, that's how I should have applied patches....
[13:53] <rlp10> shadeslayer: what does authorise mean in this context?
[13:53] <lfaraone> I'm trying to install files from usr/lib/python*/site-packages/autokey/gtkui into my package, but dh_install doesn't seem to be expanding the glob. How should I write this for it to work as I intend?
[13:53] <shadeslayer> rlp10: authorise as in.. make launchpad realise that this upload should go to your ppa
[13:54] <rlp10> shadeslayer: ok... I'm following instructions here for creating a key https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[13:55] <shadeslayer> rlp10: cool :)
[13:55] <MTecknology> shadeslayer: I just removed the patches I applied and moved the patch to debian/patches/
[13:55] <shadeslayer> rlp10: also according to launchpad : These applications have been authorized to access Launchpad on your behalf. If you revoke an authorization, that application will not be allowed to do anything in Launchpad on your behalf.
[13:55] <shadeslayer> MTecknology: thats better :)
[13:55] <MTecknology> shadeslayer: I feel better; this makes more sense too
[13:55] <shadeslayer> MTecknology: do you know the line you need to put to apply the patch system?
[13:56] <MTecknology> no
[13:56] <MTecknology> is it in the guide?
[13:56] <shadeslayer> MTecknology: dont think so.... ill have to pull it from somewhere
[13:56] <MTecknology> alrighty
[13:58] <MTecknology> shadeslayer: the file is called fpm.patch
[13:59] <shadeslayer> MTecknology: youll need to add quilt as a build-depend
[13:59] <MTecknology> shadeslayer: there's already a lot of patches being applied
[14:00] <MTecknology> in debian/patches/ there's ~46 files
[14:00] <shadeslayer> MTecknology: is this a KDE package?
[14:00] <MTecknology> PHP5
[14:00] <shadeslayer> hmm
[14:01] <shadeslayer> well im not sure about the patch line then
[14:01] <MTecknology> shadeslayer: so perhaps I can just toss the patch in there and build?
[14:01] <shadeslayer> for kde apps its : include /usr/share/pkg-kde-tools/makefiles/1/cdbs/kde.mk
[14:01] <shadeslayer> MTecknology: so there already was apackage?
[14:01] <MTecknology> ya
[14:01] <MTecknology> !info php5
[14:01] <shadeslayer> MTecknology: can you pastebin the rules file in debian/
[14:01] <MTecknology> ok
[14:02] <MTecknology> http://paste.ubuntu.com/382986/
[14:03] <shadeslayer> MTecknology: lines 33 to 40
[14:04] <shadeslayer> make that 42
[14:04] <shadeslayer> rlp10: done with the key?
[14:05] <rlp10> shadeslayer: working on it, I'm afraid real work is calling too, so I might have to come back to this :(
[14:05] <shadeslayer> rlp10: sure :)
[14:06] <shadeslayer> rlp10: i might be giving a session on 27th Feb 1700 UTC
[14:06] <MTecknology> shadeslayer: so the patch will be applied just by being in that directory?
[14:06] <shadeslayer> for this particular purpose
[14:07] <shadeslayer> MTecknology: yeah,just copy the patches in debian/patches
[14:08] <rlp10> shadeslayer: that would be great, would it be in this room?
[14:08] <shadeslayer> rlp10: #ubuntu-classroom
[14:09] <shadeslayer> rlp10: its not finalized yet,ive sent a mail to the organisers :)
[14:09] <MTecknology> shadeslayer: http://paste.ubuntu.com/382989/ This is how you're supposed to install after appying that patch; I'm guessing deb/rules needs to change for that?
[14:09] <rlp10> shadeslayer: i've pencilled it in my diary in any event
[14:09] <rlp10> shadeslayer: thanks for your help today and sorry I couldn't follow it through to completion
[14:10] <shadeslayer> rlp10: no problem
[14:10] <shadeslayer> rlp10: i might also tell something about pbuilder
[14:11] <shadeslayer> MTecknology: that is a part of what file? rules?
[14:12] <shadeslayer> MTecknology: btw im reading : http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-rules
[14:12] <shadeslayer> its pretty good
[14:13] <MTecknology> shadeslayer: if you're compiiling php from source and apply that patch, that's how you're supposed to compile php with the patch after you apply that patch
[14:13] <rlp10> shadeslayer: now? or in your class?
[14:13] <shadeslayer> rlp10: in the class :)
[14:14] <shadeslayer> MTecknology: no no... the patches are handled by lines 33 to 42 in the rules file
[14:14] <rlp10> shadeslayer: I saw something about that in the guide, it looked like clever stuff
[14:14] <shadeslayer> rlp10: nah...
[14:14] <shadeslayer> rlp10: it just mimics what the ppa servers do
[14:14] <shadeslayer> but instead on your local machine
[14:15] <MTecknology> shadeslayer: right, i have that much - how do I make it build that package so it can be installed?
[14:15] <shadeslayer> MTecknology: ok well youve applied the patches,updated changelog and added any other build deps right?
[14:16] <rlp10> shadeslayer: well it's clever stuff from where I'm sitting
[14:16] <shadeslayer> :P
[14:16] <MTecknology> shadeslayer: ya
[14:16] <shadeslayer> MTecknology: ok do you have a very fast net connection?
[14:16] <MTecknology> kinda fast
[14:17] <shadeslayer> MTecknology: sudo apt-get install pbuilder debootstrap devscripts
[14:17] <MTecknology> done
[14:17] <nigelb> how can I access my system X server from inside a pbuilder chroot?
[14:18] <MTecknology> I have a vm with all that installed
[14:19] <shadeslayer> MTecknology: um
[14:19] <shadeslayer> MTecknology: so youre applying the packages etc in a VM?
[14:19] <MTecknology> ya, any package work is in the vm
[14:20] <shadeslayer> ok
[14:20] <MTecknology> I could do a shroot, but then I don't get firefox and thunar :P
[14:20] <shadeslayer> MTecknology: ok now : sudo pbuilder create --debootstrapopts --variant=buildd
[14:20] <shadeslayer> MTecknology: i would suggest you make a pbuilderrc first with a close server
[14:21] <shadeslayer> ( a server which is close to your home )
[14:21] <MTecknology> I don't have a spare system atm :(
[14:21] <MTecknology> I like that idea though
[14:21] <lfaraone> I'm using cdbs, and I need to provide an error handler for dh_installinit. Is there an override I can set?
[14:21] <MTecknology> my laptop got up to 100 C yesterday building php
[14:22] <shadeslayer> MTecknology: ok well you can upload to a PPA in that case
[14:23] <MTecknology> ya, only thing I don't like with that is having to change the version for every failed build
[14:23] <MTecknology> but that's not such a big deal :P
[14:23] <shadeslayer> MTecknology: hehe
[14:24] <shadeslayer> well theres a small problem of authourizing the system to upload stuff.... i cant remember it
[14:24] <MTecknology> better than a proc that's 212 deg F :P
[14:24] <shadeslayer> :D
[14:25] <dholbach> JontheEchidna: can you upload polkit-qt{,-1}? might be better if somebody from the K people uploads those two :)
[14:26] <JontheEchidna> dholbach: would if I could, but the kubuntu-dev upload rights are very incomplete
[14:27] <dholbach> JontheEchidna: maybe you could prod somebody in #kubuntu-devel? :)
[14:27] <JontheEchidna> sure
[14:27] <dholbach> thanks muchly!
[14:28] <MTecknology> dholbach: hi
[14:28] <dholbach> hi MTecknology
[14:28] <MTecknology> dholbach: how've you been?
[14:29] <dholbach> good good
[14:29] <nigelb> how can I access my system X server from inside a pbuilder chroot?  Trying to learn how to fix an unmet dep :)
[14:30] <sistpoty|work> nigelb: mount proc and bind-mount tmp in the chroot (eventually you'll need sys as well)
[14:30] <nigelb> sistpoty|work: you'll have to get it down a little more understandable level :(
[14:31] <sistpoty|work> nigelb: mount -t proc whereveryourchrootis/proc; mount -t bind /tmp /whereeveryourchangerootis/tmp; mount -t sysfs /whereveryourchrootis/sys
[14:32] <nigelb> this has to be from out the chroot I'm guessing?
[14:32] <sistpoty|work> correct
[14:32] <MTecknology> sistpoty|work: -t bind?
[14:33] <sistpoty|work> or --bind
[14:33] <MTecknology> I always use -o bind :P
[14:34] <JontheEchidna> dholbach: we're in freeze now and those are both in main, so I'll ping tomorrow
[14:35] <dholbach> gotcha
[14:39] <slytherin> nigelb: Why do you need to access X form chroot to fix unmet dep?
[14:39] <nigelb> slytherin: have to change the code and run it
[14:39] <nigelb> to see that all works
[14:40] <slytherin> hmm
[14:44] <slytherin> slomo: is there any plan to sync latest gst-plugins-ugly from Debian experimental?
[14:44] <slomo> slytherin: i asked seb128 to sync it a few days ago *shrug* :)
[14:44] <slomo> slytherin: is there anything else missing?
[14:45] <slytherin> slomo: Nothing missing. I like to keep the -multiverse packages in sync with non-multiverse packages. And current multiverse package FTBFS against latest libx264. So I need to decide between latest pre-release or selective patch backports.
[15:07] <Espen77> anywhere I can find info/tutorial on how to make sourche deb of a single python file (for ppa)?
[15:22] <nigelb> sistpoty|work: somethings seems to go wrong
[15:23] <nigelb> I just get a list of stuff that the mount command can do
[15:23] <sistpoty|work> nigelb: probably what MTecknology wrote, use --bind instead of -t bind
[15:23] <nigelb> ah
[15:24] <nigelb> I tried sudo mount --bind proc /var/cache/pbuilder/build/6895/proc and I get 'mount: special device proc does not exist"
[15:28] <sistpoty|work> nigelb: if you want to mount proc inside the chroot, you can either bind-mount /proc or you can use proc as file system type (-t proc)
[15:28] <nigelb> I tried -t proc, doesn't work
[15:29] <sistpoty|work> nigelb: I guess it's mount -t proc none pathtomountpoint
[15:29] <nigelb> sistpoty|work: ah, that worked
[15:29] <sistpoty|work> nigelb: as I read earlier, if you only want X inside the chroot to edit files, why not just editing these from outside the chroot?
[15:29] <MTecknology> YES!
[15:30] <MTecknology> I think I have rules updated correctly now :D
[15:30] <nigelb> sistpoty|work: I have to run the thing after editing to make sure the program works
[15:30] <sistpoty|work> nigelb: ah, so you need it for testing rather then editing :)
[15:31] <nigelb> yeah
[15:46] <MTecknology> I love this error!  debian/rules:180: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
[15:48] <MTecknology> not something you catch by eye :P
[15:48] <Laney> something a decent editor will do for you though
[15:48]  * Laney runs
[15:48] <MTecknology> Laney: you mean vim isn't decent?
[15:49] <MTecknology> Laney: it was a copy/paste into a virtual machine; I did a lot of that and thought I changed them all; vim catches it if you have the first line tabbed by hilighting the next line with red
[15:49] <Laney> yes, that it does
[15:50] <MTecknology> I have 5 lines messed up right after the rule: part
[15:50] <MTecknology> idk what that part is called
[15:51] <MTecknology> Laney: descriptive errors are so nice for the novice liek me :D
[15:53] <Laney> \o
[15:54] <jpds> MTecknology: autocmd BufEnter */debian/rules set noet tabstop=8 shiftwidth=8
[15:56] <MTecknology> jpds: woah- nice
[15:56] <jpds> Same of ?akefile*
[15:57] <MTecknology> jpds: any other nifty tips you have?
[15:59] <jpds> MTecknology: Several.
[15:59] <jpds> MTecknology: eg. http://www.vim.org/scripts/script.php?script_id=2441
[16:00] <MTecknology> thanks
[16:00]  * MTecknology hopes this build succeeds
[16:01]  * MTecknology needs to start/finish a report in an hour
[16:03] <randomaction> Wow, buildds will fail a build based on some warnings: http://wiki.debian.org/ImplicitPointerConversions (just got hit by it)
[16:05] <Laney> james_w: up for running a bunch of syncs?
[16:05] <james_w> Laney: in a few
[16:05] <Laney> sure, http://paste.ubuntu.com/383082/
[16:05] <james_w> feel free to send me the list
[16:06] <Laney> with the usual apologies in advance for typos
[16:06] <Laney> http://orangesquash.org.uk/~laney/haskell-installability/amd64.png the third row of this \o
[16:11] <shadeslayer> MTecknology: hey
[16:11] <shadeslayer> MTecknology: had a power outage...
[16:12] <MTecknology> shadeslayer: retreiving gpgv
[16:12] <MTecknology> shadeslayer: nice to see you back :)
[16:13] <MTecknology> shadeslayer: :( http://launchpadlibrarian.net/39729966/buildlog_ubuntu-karmic-i386.php5_5.3.1-4ppa5_FAILEDTOBUILD.txt.gz
[16:15] <shadeslayer> MTecknology: can you pastebin your rules file?
[16:16] <MTecknology> shadeslayer: http://paste.ubuntu.com/383090/
[16:17] <shadeslayer> hmm..
[16:18] <shadeslayer> MTecknology: looks like something is causing a problem after line 193
[16:19] <shadeslayer> MTecknology: but i dont have a definite idea whats wrong
[16:22] <MTecknology> shadeslayer: I started adding things at line 179; anything related to *fpm* in there was added
[16:22] <MTecknology> shadeslayer: I feel like I have to be really close to finishing this...
[16:23] <shadeslayer> MTecknology: yes actually
[16:23] <shadeslayer> well anyone around to help?
[16:23] <shadeslayer> MTecknology: this is far beyond my knowledge
[16:24] <MTecknology> alrighty, thanks for getting me going in the right direction - especially with the patch
[16:24] <shadeslayer> MTecknology: piece of cake :)
[16:24] <MTecknology> it has a LOT left to download for this pbuilder
[16:25] <MTecknology> retreiving ifupdown :(
[16:25] <shadeslayer> MTecknology: ah you started with pbuilder... good :)
[16:26] <MTecknology> I started the minute you tossed out that line
[16:30] <shadeslayer> MTecknology: any errors downloading?
[16:30] <shadeslayer> the main ubuntu archives are having issues
[16:34] <MTecknology> shadeslayer: that could be why.. it's taking so long - I think I'll just hold off on this for later - I don't have time to keep hammering away :(
[16:35] <shadeslayer> MTecknology: i would suggest a local mirror
[16:35] <MTecknology> physics exam today and a paper due at the beginning of the exam
[16:35] <MTecknology> crap - i need to buy a calculator.. forgot
[16:37] <MTecknology> shadeslayer: physics makes my brain hurt
[16:37] <MTecknology> forgot about other stuff I need to do too.... I need to get some resumes printed off on nice pretty paper
[16:37] <shadeslayer> hehe
[16:38] <shadeslayer> MTecknology: get that done then :P
[16:38] <MTecknology> :'(
[16:57] <jdong> ah, unbelievable how well wl.ko is working these days
[16:58]  * jdong upgrades to lucid at a blazing 8600KB/s
[16:58] <fta> SEJeff, the PPA should have ~30 days of archives (or is it 90?); got to the PPA page and ask for details then superseded versions
[16:59] <arand> debfx: ping
[17:00] <SEJeff> fta, Thankyou
[17:02] <jpds> Guys.
[17:03] <jpds> How does one do: THING=( "foo", "bar" ) in dash?
[17:03] <Myrtti> arrays/lists are a bashism
[17:03] <Myrtti> AFAIK
[17:03] <jpds> s/,//
[17:03] <SEJeff> jpds, Use python :)
[17:03] <jpds> Myrtti: Yeah, I kind of need them for a for loop.
[17:03] <sistpoty|work> THING="foo bar"?
[17:03] <jpds> SEJeff: No can do.
[17:04] <sistpoty|work> (assuming there are never spaces in foo or bar)
[17:04] <LaserJock> ok, so where does one push a bzr branch based off of a lp:ubuntu/<package> ?
[17:04] <SEJeff> jpds, And bash isn't an option? you should be able to iterate in spaces like sistpoty|work says. Otherwise, you can just change IFS
[17:05] <jpds> SEJeff: No, bash isn't an option.
[17:05] <jpds> sistpoty|work: Thanks!
[17:05] <sistpoty|work> yw
[17:09] <shadeslayer> MTecknology: did you get the package to build?
[17:10] <MTecknology> shadeslayer: no, last I did anything I got that error I sent you
[17:11] <MTecknology> shadeslayer: The soonest I'll have time to mess around again is maybe tonight but probably not until this weekend.
[17:13] <shadeslayer> :P
[17:13] <shadeslayer> MTecknology: well you should ask the person who orig. packaged that package
[17:14] <MTecknology> shadeslayer: I'll do that
[17:30] <stefanlsd> james_w: with udd and doing a merge, when do we tag? is it when the merge is done? or when we push it up for merging?
[17:31] <james_w> stefanlsd: when uploading
[17:32] <stefanlsd> james_w: do you mean when i push it to lp:~stefanlsd...  or  (not sure which uploading you are referring to)
[17:33] <james_w> uploading the package to lucid
[17:34] <stefanlsd> james_w: ah ok. is that what bzr mark-uploaded does?
[17:35] <Espen77> are there any easy way to detect dependencies if none is listed in source readme?
[17:36] <james_w> stefanlsd: yep :-)
[17:36] <stefanlsd> james_w: got it. thanks :)
[17:37] <james_w> sgnb: ledit needs a rebuild for the ocaml transition I believe as it is currently un-installable. If I go ahead and do it will it cause trouble?
[17:39] <debfx> arand: pong
[17:41] <arand> debfx: Hia, um, you kind of trailed off before? (the thing of the diff.gz-s being different)
[17:42] <randomaction> james_w: a sync is specifically requested for ledit to move transition forward (bug 526065)
[17:44] <debfx> arand: you need to tell me which files are different compared to a fresh virtualbox-ose dir
[17:45] <james_w> randomaction: gah, I looked at /lucid/+source/ledit somehow
[17:52] <stefanlsd> james_w: im looking at a security update using udd. lp:debian/lenny/audiofile got lenny1 from stable-security (which is cool), is that a new thing as jdstrand wasnt sure that was working. or was it just lucky?
[17:53] <james_w> I wasn't sure whether that was working either :-)
[17:53] <stefanlsd> james_w: hehe. so should it be working (as per design), or we just got lucky :)
[17:54] <james_w> stefanlsd: I didn't do anything special
[17:54] <james_w> it depends on whether LP imports the source packages from there
[17:54] <james_w> which may well depend on whether the Debian archive copies them in to the release pocket at any point
[17:55] <stefanlsd> james_w: kk. i'll do some more and let you know
[17:55] <james_w> thanks
[17:55] <james_w> it is something that I would like to work, so let me know if there are some that don't appear
[17:56] <stefanlsd> james_w: as far as our side goes, should i propose the security merge (karmic-security) against lp:ubuntu/karmic/audiofile (we dont need anything special do we?)
[17:56] <james_w> good question
[17:56] <Laney> thanks james_w
[17:56] <Laney> you BEAUTY!
[17:57] <james_w> that's probably the best thing
[17:57] <james_w> np Laney
[17:57] <Laney> I wonder what a safe way to scp the installability graphs to my webhost from a cron job would be
[18:00]  * Laney finally gets round to filing the soyuz bug
[18:04] <arand> debfx: Hmm, so if the diff.gz-s differ (using zdiff) but the directories when unpacking & applying the two different diffs are exactly the same, then I'm just being stupid and it's the diffs that differ, but not their actual content?
[18:05] <SEJeff> fta, https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+packages?field.name_filter=thunderbird-3.0&field.status_filter=superseded&field.series_filter=karmic
[18:05] <SEJeff> None of those have any "published files" how do I download them without clicking through everything from "view all builds"?
[18:07] <fta> SEJeff, hm, the oldest is 3.0.2~hg20100206r4688
[18:07] <SEJeff> fta, Perfect. Thanks again
[18:08] <fta> too bad LP now expires that fast
[18:08] <SEJeff> fta, Yeah and the latest tbird is unusable. For the first time in the past 4-5 months
[18:09] <fta> SEJeff, you should tell that to micahg when he's back, i handed the package over to him some months ago
[18:10] <SEJeff> Alright. Do you only do the uploads now?
[18:10] <fta> yeah, i'm still doing all those dailies from my own servers, using drobotik
[18:11] <debfx> arand: the diffs probably have a different file order, which makes the diff of the diffs huge
[18:13] <arand> debfx: yea, that makes the most sense I guess, alright, then I should be able to just ignore that. Phew.
[18:33] <stefanlsd> james_w: im following https://wiki.ubuntu.com/DistributedDevelopment/Documentation/UploadingAPackage and in those example they use bzr merge-package to merge into the source they have. to follow that i would bzr branch lp:ubuntu/karmic/audiofile and then bzr merge-package lp:~stefanlsd/ubuntu/karmic/audiofile/merge-lenny1 , but isnt it the same thing if they just branched the merge proposal (ie.
[18:33] <stefanlsd> stefanlsd branch)?
[18:34] <james_w> stefanlsd: kind-of
[18:35] <james_w> it's equivalent
[18:35] <stefanlsd> james_w: yeah, although if the source branch has 'moved on' from another upload... i guess
[19:21] <sgnb> james_w: no pb... but I guess you've seen my sync request bug...
[19:22] <james_w> sgnb: I have now, and so just acted on it, thanks
[19:23] <james_w> sgnb: I clicked a wrong link somewhere and so it was excluded from the list of bugs for the package that I was looking at
[20:12] <randomaction> Is there any prejudice against script-assisted mass rebuild of packages?
[20:14] <Laney> how could there be? Nobody has any way of telling
[20:16] <randomaction> The timestamps will give me away :)
[20:17] <cody-somerville> randomaction, rebuilds or retrys?
[20:17] <randomaction> Anyway, I'm responsible for my uploads.
[20:17] <randomaction> cody-somerville: rebuilds for ocaml transition
[20:18] <cody-somerville> randomaction, People do mass rebuilds for stuff like that all the time.
[20:18] <randomaction> Given how  much easier this is, I'm not surprised :)
[20:19] <persia> randomaction: Please take care to first push the rebuilds against a local builder and verify the results before uploading.
[20:19] <randomaction> ok
[20:20] <persia> I think the most anyone did with scripted changelog entries in a single batch was 417 for a gtk transition a couple years ago: often the lists are split up into 3-4 chunks so that we can share the local build / inspection effort.
[20:20] <Laney> dch -R "Rebuild for blah" is handy
[20:20] <randomaction> yes, dch -R is smart
[20:21] <randomaction> with respect to -XbuildY and -XubuntuY
[20:21] <persia> If you need to do it for a *lot* of packages (>500), please check with the buildd admins first: they may want to you submit in batches.
[20:21] <randomaction> ~50 in this case
[20:21]  * Laney suspects this is OCaml
[20:22] <randomaction> sure it is
[20:22] <Laney> did the coq ftbfs get fixed yet?
[20:22] <randomaction> mab pbuilder-dist doesn't have the "return value" section :(
[20:23] <randomaction> s/mab/man/
[20:24] <persia> That's not enough anyway, because one can rebuild something without transitioning it if the package is constructed in annoying ways.
[20:24] <persia> One needs to actually *test* the result packages to see if they are correct.
[20:24] <persia> Easy way to do this is with dpkg -f (man dpkg-deb)
[20:25] <randomaction> you mean checking dependencies of resulting packages?
[20:25] <persia> Right.
[20:25] <persia> That way you don't get caught when someone hardcoded something.
[20:26] <Laney> or if your rebuilds haven't been built/published yet
[20:26] <persia> So, build everything, iterate over .changes files to get the list of .debs, inspect the .debs to verify the transition.
[20:26] <Laney> I think that the ocaml packaging helpers take care of all of this though
[20:26] <Laney> rendering packages uninstallable and such
[20:27] <persia> This is scriptable, and several people have scripts, but it's dangerous, so nobody publishes the scripts, figuring that anyone who can manage a transition is capable of either doing it manually or writing a script.
[20:27] <randomaction> sgnb: does the transition tracking page show if the packages have been rebuilt or if they have been properly transitioned to new dependencies?
[20:27] <persia> Laney: That's usually the case.  In my experience, with all classes of transition, it's usually 5-10% of pacakges that need manual action, but I think ocaml is more cohesively maintained than many languages.
[20:28] <Laney> they must have been transitioned to be installable
[20:28] <Laney> at least, that's the case with Haskell, and we stole the idea from sgnb
[20:29] <Laney> (exposing an ABI hash through Provides)
[20:36] <randomaction> in this transition in some cases it's hard to verify because for some packages the dependency change is visible only on armel/ia64
[20:36] <randomaction> but at least I can ensure that all builds and nothing depends on old ocaml
[20:36] <persia> That's why we have `pbuilder dist lucid armel create` :)
[20:37]  * persia doesn't have any good suggestions for ia64
[20:37] <Laney> I am amazed that ghc6 looks to be building on ia64
[20:37] <Laney> but I won't believe it until it gets to the stage2 compiler
[20:37] <Laney> and I won't really believe it until it finishes
[20:38] <randomaction> Hmm, can one cross-build in pbuilder in other ways than for i386 on amd64?
[20:38] <persia> Right now the only foreign arch supported is armel on i386 or amd64.
[20:39] <persia> I know of work going on to make powepc work on i386 and amd64, and hope to get armel working on powerpc.
[20:39] <persia> But none of that will work for lucid.
[20:39] <persia> I don't know of significant progress getting emulated builds working for sparc or ia64 on any platform, nor for getting foreign i386 or amd64 working anywhere.
[20:40] <persia> I hear sparc is possible, but still at the "needs more work on qemu" stage.
[20:40] <randomaction> That's kinda cool because packages fail on armel in unusual ways (not that I expect it to be easy to debug)
[20:40] <Laney> I think we traded ia64 for armel :(
[20:40] <persia> Be warned that it's not perfect yet: some syscalls still aren't supported (like gh6 fails in configure), but it works for many packages.
[20:41] <Laney> but it shouldn't be too hard to get both of them back
[20:41] <randomaction> Is it only for lucid pbuilder? It's not mentioned in karmic docs.
[20:42] <persia> The changes to pbuilder-dist and mk-sbuild{-lv,} are only in lucid.
[20:42] <persia> And I think the qemu in karmic supports fewer syscalls.
[20:55] <sgnb> randomaction: "green" means "has been rebuilt", "red" means "needs rebuild"
[20:55] <sgnb> red packages shouldn't be installable
[20:56] <sgnb> randomaction: so back to your initial question, both
[20:57] <randomaction> we were discussing the possibility of packages to have been rebuilt, but still have wrong dependencies
[21:10] <Laney> crimsun: almost through to xmonad :)
[22:02] <diverse_izzue> hi all, i was sent here from #ubuntu+1. i was using a program called xppaut under karmic, i cannot find it in the lucid repositories. was itremoved on purpose or is that a bug?
[22:04] <geser> diverse_izzue: on purpose, see Debian bug 566638
[22:05] <diverse_izzue> geser, thanks. it's true that it's a bitch of a program, but still useful for certain tasks...
[22:09]  * persia discovers bug #509217 and encourages people to press the "Me Too" button to make noise and restore the value of wget for patch exchange
[22:14] <JontheEchidna> it broke batpaste from kubuntu-dev-tools too :(
[22:14] <ScottK> persia: I did so, but it's not like there aren't plenty of other pastebins one could use.
[22:14] <persia> ScottK: Yeah, but a bunch of our tools default to paste.ubuntu.com
[22:14] <persia> If we complain, and get delayed, it makes sense to patch the tools.
[22:15] <persia> If we don't complain, it's not clear which is the right direction.
[22:18] <ScottK> JontheEchidna: http://kubuntu.pastebin.com/ seems to get some usage, perhaps that instead.
[22:19] <ScottK> persia: In cases where there are effective alternatives available, I think it's more cost effective just to switch.
[22:20] <persia> ScottK: I guess.  There's a bunch of tools (I haven't grepped the archive) which would need patching.
[22:20] <persia> And I'd expect to get complaints in the form of responses to -changes mails if I uploaded that.
[22:20] <persia> Which makes it a distributed cost for each individual user or a high cost for the developers that change the defaults.
[22:20] <ScottK> Fortunately pastebinit defaults to pastebin.com
[22:21] <persia> Yes, that's one of the tools where the patch was dropped, but it was hidden in the form of a sync.
[22:22] <persia> But it's complicated by bug #526849 :)
[22:22] <ScottK> Interesting.
[22:23] <persia> So as an individual user, I agree with you that the cost is lower to switch.  But I submit that the total cost of not having stuff just work for all users is higher than the cost of trying to make it just work.
[22:23] <persia> On the same basis that we put in the extra effort to make the distribution good.
[22:24] <persia> (because the cost of a locally hacked box full of third-party repos is likely less than the cost of maintaining a distribution, as long as you only have one machine)
[22:34] <cnd> lifeless: I just ran bzr import-dsc, but at the end I got an error about KnitPackRepository not being compatible "different rich-root support"
[22:35] <cnd> what's going on here?
[22:37] <lifeless> you have two different formats of bzr branch
[22:37] <lifeless> do you have a need to interoperate with folk that don't have bzr 2.0?
[22:37] <cnd> lifeless: no
[22:37] <lifeless> then just run 'bzr upgrade' all over the place :)
[22:37] <cnd> I'm guessing the lp branch isn't up to the latest version?
[22:38] <cnd> how do I upgrade the lp branch?
[22:38] <lifeless> 'bzr upgrade lp:...'
[22:38] <cnd> ok
[22:38] <lifeless> or click on the button on the website
[22:38] <lifeless> though that doesn't always work and is hard to debug at the moment
[22:39] <cnd> I had no idea you could update the lp repo from a remote computer :)
[22:39] <cnd> spiffy...
[23:17] <MTecknology> I don't see what error happened here....  http://launchpadlibrarian.net/39747108/buildlog_ubuntu-karmic-lpia.php5_5.3.1-4ppa6_FAILEDTOBUILD.txt.gz
[23:17] <MTecknology> FAILED [dpkg-buildpackage died]
[23:17] <MTecknology> I see that, but no reason why
[23:18] <MTecknology> I'm also noticing that I added a file to debian/patches/ but that wasn't applied with the rest. I'm guessing that's part of why it broke
[23:19] <persia> Just out of curiosity, are you also asking these questions in other fora, and getting rebuked?
[23:20] <persia> Because if you're asking in more appropriate places and people are telling you they won't help you, that's one thing, but if you're not even trying to look for people who work with php, that's another.
[23:21] <MTecknology> persia: I asked in ##php and tried to get a hold of a couple people in changelogs without response
[23:21] <MTecknology> persia: right now, I'm trying to understand the quilt system
[23:22] <jpds> MTecknology: dpkg-buildpackage: error: debian/rules build gave error exit status 2
[23:22] <persia> MTecknology: Did you try contact the Ubuntu server folk or the Debian PHP folk?
[23:23] <MTecknology> persia: aside from the people listed in the changelog - I don't know who they are
[23:25] <persia> MTecknology: https://wiki.ubuntu.com/ServerTeam will likely help you contact the server team.  http://packages.qa.debian.org/p/php5.html includes the address of the Debian PHP team mailing list.
[23:26] <persia> MTecknology: And it's not important *who* they are, but where they communicate.  The key is to find interested people in public fora, not to poke individuals on the chance they might be interested.
[23:28] <MTecknology> persia: alrighty, I'll try to read up on how the quilt patchign system is used too - that's where I'm stuck atm
[23:29] <persia> !patch
[23:29] <persia> MTecknology: The PatchSystems guide has a good bit of documentation about hat.
[23:29] <Laney> try /usr/share/doc/quilt/
[23:29] <persia> Works too.
[23:39]  * Aniya i can't believe this!!!! who the f*ck are you to do this, DIEGOPOP??? http://www.youtube.com/watch?v=cAMMiiAcSjk
[23:46] <lifeless> Aniya: please moderate your language. Also thats offtopic here.
[23:55] <lifeless> jussi01: ping
[23:55] <lifeless> jussi01: can you renew my irc-ubuntu-motu-ops membership ?