[10:51] <doko_> ScottK: http://paste.ubuntu.com/286360/ didn't look yet. do you have more info in the meantime?
[10:51] <doko_> geser: 3) it does
[10:54] <stani> Can someone make bug https://bugs.launchpad.net/ubuntu/+source/phatch/+bug/448971 public?
[10:54] <stani> sorry I  mean bug https://bugs.launchpad.net/bugs/442466
[10:55] <stani> pochu, ScottK ^
[10:57] <iulian> stani: Done.
[10:58] <stani> julian: Thanks a lot!
[10:58] <iulian> You're welcome.
[10:58]  * iulian -> lunch.
[11:18] <skar> any place where i can read up on applying my patch to a source deb and then building it?
[11:25] <geser> skar: if you don't care about proper integration into the source package: simply apply the patch
[11:25] <geser> and then debuild -b (after installing the build-dependencies, it will complain about missing build-dependencies)
[11:26] <skar> geser: well, i've installed the glibc source deb, and the dir has a dsc, diff and tar.gz file. how do i ask debuild to just unpack, apply patches it has but stop short of building?
[11:26] <geser> skar: dpkg-source -x the_package_you_want_extracted.dsc
[11:28] <geser> I don't know which patch system glibc uses, so I can't tell you how to apply the patches included in the source package. But as long as your patch doesn't collide with other, the order should matter (first yours and the the ones from the package or vice versa)
[11:28] <skar> geser: thanks, now i've got a dir within which some tar.bz2 files and debian dir are present. i still can't find my header file in there which is what i need to patch.
[11:28] <skar> geser: it seems glibc uses quilt.
[11:28] <skar> debian/rules.d/quilt.mk:     @echo -n "Unapplying patches..."
[11:28] <Laney> quilt push -a
[11:30] <geser> Laney: from the message skar typed it sounds like glibc uses tar-in-tar :(
[11:30] <Laney> oh I only read the second line
[11:30] <Laney> indeed that is pain
[11:31] <skar> well, i started debuild, made the process sleep with Ctrl+Z, applied my patch, then resumed the build with fg and it build my new libc fine. but it's ugly.
[11:32] <skar> what i want is cleaner, simpler one which must be what the package maintainers must be using.
[11:35] <skar> geser, Laney: thanks for the tips. any ideas on how to apply the patch, then start the build without overwriting the patched sources again?
[11:37] <geser> skar: there is certainly a cleaner way but as didn't look at the glibc package I can't tell
[11:37] <skar> geser: oh ok. thanks anyway. will study the build process.
[12:42] <RainCT> siretart: thanks, trying it out now
[12:55] <wrapster> http://pastie.org/651337 ; can anyone help me out with this.. Im trying to include a wrapper withing the binutils pkg itself.. strangely the dh_links work fine.. but i get an error like so:
[12:55] <wrapster> cp /usr/sfw/bin/gas debian/binutils/usr/sfw/bin/gas-real
[12:55] <wrapster> cp: cannot create regular file `debian/binutils/usr/sfw/bin/gas-real': No such file or directory
[12:57] <geser> wrapster: check if the target directory exist before you cp into it
[12:58] <funkyHat> I got an error message from rosetta, saying it couldn't import a file because of text encoding problems. Do I need to do anything about this? (my upload was nothing to do with translations)
[12:58] <wrapster> geser: ok thanks.
[12:58] <wrapster> will revert back.
[12:58] <geser> funkyHat: better ask someone familiar with rosetta or translation in #launchpad about it
[12:59] <funkyHat> thanks geser, I've asked in #launchpad
[13:05] <Laibsch> How can I get the grab-merge script to merge from Debian unstable instead of debian testing?
[13:06] <geser> grab-merge download just the files from MoM. And MoM tries merging against Debian unstable
[13:08] <Laibsch> OK
[13:08] <Laibsch> Why is wordpress still at the version in testing ten days after upload?
[13:09] <Laibsch> or in other words
[13:09] <AnAnt> feature freeze
[13:09] <AnAnt> oh
[13:09] <Laibsch> when is MoM going to have 2.8.4-3?
[13:09] <AnAnt> probably in karmic+1
[13:10] <Laibsch> hm, that's not satisfactory
[13:10] <Laibsch> How do I explicitly merge against unstable, then
[13:10] <Laibsch> ?
[13:10] <AnAnt> erm, sorry, I think I answered the wrong question
[13:11] <AnAnt> I thought you meant when will 2.8.4-3 be in Ubuntu
[13:11] <Laibsch> I kind of had the feeling you were a bit off
[13:11] <Laibsch> Although the question somehow is about when 2.8.4-3 will be in Ubuntu ;-)
[13:12] <Laibsch> I'd like to get it merged
[13:14] <geser> Laibsch: then do it by hand: take the package from Debian and apply the Ubuntu delta on it
[13:14] <Laibsch> hm
[13:14] <Laibsch> never done it
[13:15] <Laibsch> I expect a patch conflict at least in  debian/changelog
[13:15] <Laibsch> if not elsewhere as well
[13:16] <geser> than that's a good opportunity to learn it :)
[13:19] <directhex> Laibsch, if the only *needed* delta is changelog, request a sync (the ubuntu changelog will die)
[13:20] <Laibsch> directhex: no, that is not the case
[13:20] <Laibsch> geser: if you give more details, I may fix this package
[13:21] <Laibsch> if not, I may drop the ball on it
[13:32] <geser> Laibsch: I usually go to the PTS page to find all the needed links: http://packages.qa.debian.org/w/wordpress.html
[13:32] <geser> there you will find the link to the .dsc file from unstable which you can pass to dget to download it all
[13:33] <Laibsch> I'm aware of that
[13:33] <geser> and there is also the link to the patch file with all Ubuntu changes
[13:33] <Laibsch> But that doesn't merge things magically
[13:35] <geser> true, but after applying the Ubuntu patch you just need to resolve the conflicts, pretty certain debian/changelog
[13:35] <geser> the advantage MoM has, it does merging the changelog pretty good
[13:35] <geser> other merge conflicts it also leaves to resolve for the merger
[13:36] <Laibsch> true
[13:36] <Laibsch> http://patches.ubuntu.com/w/wordpress/wordpress_2.8.4-1ubuntu1.patch looks like a good way
[13:36] <Laibsch> thanks
[13:36] <wrapster> hi
[13:37] <wrapster> the build came through perfectly but when i install i dont see that wrapper at all..
[13:37] <wrapster> geser: how is it possible that a few lines can be exectued with the remainng are not?
[13:39] <geser> wrapster: what you mean? your wrapper didn't end in the built deb package?
[13:39] <ScottK> doko_: I did see that failure before, but didn't figure it out.
[13:40] <wrapster> geser: no
[13:40] <wrapster> according to that pastie.. a file called gas-real has to exist in /usr/sfw/bin/ ; all i can see is just gas.. and im very sure thats coming from the dh_link
[13:42] <wrapster> geser: well the debian/binutils dir has /usr/sfw/bin/ and gas/gas-real as well.. but dpkg -i <binutils> wont install that at all?
[13:43] <AnAnt> could someone sponsor http://revu.ubuntuwire.com/details.py?package=sabily-xsplash-artwork please ?
[13:44] <joaopinto> hell, can someone sponsor the fix for bug 449502 ?
[13:44] <joaopinto> hello :P
[13:44] <geser> wrapster: if it's in the package then dpkg should also install it
[13:45] <wrapster> geser: then why is it not? coz the dh_link is set up and just 1 line down and it doesnt work...
[13:45] <wrapster> or is my logic wrong thre?
[13:45] <wrapster> here is the story...
[13:46] <geser> wrapster: can you pastebin the contents of the build deb file (dpkg-deb -c)?
[13:47] <wrapster> apparently gas has a -K option (set at runtime) which i want to negate and i had written a wrapper to solve it. first mv gas to gas-real then open a sh script called gas which internally calls gas-real `echo $@ |sed 's/-K//g' ... i thought of doing that.. in the rules file itself so that when pkg is built it will be automatically created...
[13:47] <geser> joaopinto: you might have greater success if you subscribe ubuntu-universe-sponsors to it. on a quick look your fix looks good. did you forward it already to Debian?
[13:48] <joaopinto> geser, I did, but actually I had great  success asking here :)
[13:49] <joaopinto> subscrbing sponsors anyway
[13:49] <wrapster> geser: http://pastie.org/651383
[13:51] <geser> wrapster: does http://pastie.org/651337 still contain you most recent changes?
[13:51] <wrapster> geser: thats the latest
[13:52] <wrapster> mkdir -p debian/binutils/$(TAR_DIR) <before line:16>
[13:52] <geser> wrapster: because there you copy /usr/sfw/bin/gas from the host system (and not from the build) to gas-real. check your build log if cp didn't complain about anything (like missing source file)
[13:53] <wrapster> well actually there is no /usr/sfw/bin/gas until this pkg is installed.
[13:53] <wrapster> i created that as well...
[13:56] <geser> wrapster: I didn't look at dh_link, but I assume it works inside the staging dir from where your package get build it the end but your cp command tries to copy a file from your host system (the one that is currently building the package) and not from that staging dir
[13:56] <wrapster> oh
[13:56] <wrapster> i get that..
[13:57] <wrapster> but the strange thing is if you just cut this out and create a makfile out of this and run.. it works perferctly
[13:57] <wrapster> :(
[13:57] <wrapster> ive tried
[13:57] <geser> hmm
[13:59] <geser> wrapster: and a hint: you could store the wrapper (the shell script) in debian/ (as e.g. gas) and just copy it to its destination instead of creating it in debian/rules (no fighting with escaping needed)
[13:59]  * geser will be back in around 30 min
[13:59] <wrapster> oh cool.. could you elaborate..
[14:18] <wrapster> guys if anyone else was following up  mine and geser conversation could you pls look at this http://pastie.org/651416 and let me know if ive written it right?
[14:22] <skar> geser: hi, got the patch to work fine. all the patches were stored in a debian/patches/i386 dir :) but the build takes very long, due to it building all sorts of locales. any idea to do only certain locales?
[14:24] <geser> wrapster: looks good
[14:24] <geser> skar: sorry, no idea
[14:25] <skar> geser: np. thanks for the tips though. will look into the build process further and dig out where locales list is and change it :)
[14:32] <joaopinto> dholbach, about bug 449177, I was about to fix the FTFBS on the ubuntu package, by chanding debian rules to use automake1.11, I guess that's a btter a fix than build depend on automake1.10
[14:33] <joaopinto> will the sync be performed ?
[14:34] <joaopinto> I remember someone telling me that a sync requires more effot because it requires an archive admin action, unlike a debdiff sponsor
[14:36] <geser> joaopinto: but a sync has the advantage that the package will be auto-synced in karmic+1 instead of appearing on the merge list
[14:36] <joaopinto> ok
[14:37] <joaopinto> so I should file a bug for the Debian package
[14:53] <wrapster> geser: thank you for your idea
[14:59] <wrapster> geser: it did not work!!!
[14:59] <geser> can you explain?
[15:00] <wrapster> geser: http://pastie.org/651466
[15:02] <geser> hmm, did it end in the .deb?
[15:03] <wrapster> geser: again i can see it in debian/binutils/usr/sfw/bin/ but its not while dpkg -i
[15:03] <wrapster> geser: no it did not
[15:04] <geser> can you pastebin all your changes? I want to try it in my karmic pbuilder
[15:04] <wrapster> geser: http://pastie.org/651471
[15:04] <wrapster> one moment.
[15:06] <wrapster> geser: here it is http://pastie.org/651383
[15:07] <wrapster> TAR_DIR= /usr/sfw/bin/
[15:08] <Zelut> if a package provides a symlink which points to a file provided by another package, but said file does not exist, which package is at fault? (ie; which should I report the bug on)?
[15:08] <RainCT> Zelut: That depends whether the file should really be there or not.
[15:10] <Zelut> RainCT: /usr/share/doc/bash/ includes a file 'completion-contrib' which points to ../bash-completion/contrib. There is no contrib file.
[15:15] <wrapster> geser: i created a new rule for this... lets see if it works now.
[15:21] <wrapster> geser: any luck?
[15:21] <geser> wrapster: waiting on the build results
[15:21] <wrapster> geser: ok...
[15:33] <wrapster> geser: what do you think could be wrong ?
[15:34] <wrapster> and is your done?
[15:35] <Zelut> RainCT: I know its just a papercut bug, bug which should I report the issue for?
[15:40] <RainCT> Zelut: I can't say without looking into it
[16:03] <wrapster> geser: is it done?
[16:04] <geser> wrapster: more or less (had to install debhelper as it wasn't listed in build-depends)
[16:04] <wrapster> ok.. i tried creating a new rule didnt help
[16:04] <wrapster> i really dont get it...
[16:07] <geser> wrapster: the build finished, looking into it now
[16:10] <wrapster> geser: btw just so you know.. i have put these cmds under the install target section.
[16:10] <geser> wrapster: I could reproduce your problem
[16:10] <wrapster> and any idea what can be done?
[16:11] <geser> not yet
[16:17] <geser> wrapster: I hope I found it, will let you know when "debian/rules binary" is done building the new deb
[16:18] <wrapster> ok... thanks..
[16:18] <wrapster> im praying it works.
[16:19] <wrapster> geser: also i would like to know if the rules can be tested individually.. so that i can actually narrow down the issue?
[16:19] <wrapster> instead of running buildpkg every time and waiiting for hrs
[16:20] <geser> wrapster: yes, the rules are called in order: clean -> build -> binary (which often depends on install)
[16:21] <geser> you can call debian/rules with the target you need (e.g. once it got build, you can call the binary target several times in case you need to add a fix there)
[16:22] <wrapster> make -f debian/rules <target> ?
[16:22] <geser> but it's a good idea to test-build it at the end from clean, just to be sure you didn't miss anything
[16:22] <geser> wrapster: yes, or debian/rules <target> (it's executable :)
[16:22] <wrapster> ok... so did you narrow down on the issue?
[16:23] <wrapster> this has taken me hrs ... being a newbie .. its very tough
[16:23] <wrapster> :(
[16:23] <geser> wrapster: -rw-r--r-- root/root        56 2009-10-12 15:17 ./usr/sfw/bin/gas (there is a chmod +x missing)
[16:24] <geser> wrapster: the package doesn't use debian/binutils but debian/tmp as a staging dir
[16:24] <wrapster> oh crap.
[16:24] <geser> wrapster: cp debian/gas debian/tmp/usr/sfw/bin/gas
[16:24] <wrapster> how did you figure it out?
[16:25] <wrapster> it will help me also ..
[16:28] <geser> wrapster: there are some variables used within the debian/rules file for the destination, one of them is d_bin (for the binutils package; look around line 33)
[16:29] <geser> wrapster: alternative you could look into the directories below debian/ to check from which your package gets build (as it will have the same contents as the deb)
[16:29] <wrapster> ok i so far had thought that the staging dir is a standar meaning.. debian/<pkgname> would be that.. i didnt know its not so..
[16:31] <geser> wrapster: newer packages use debian/<package> now, but some packages still use debian/tmp (its predecessor)
[16:31] <wrapster> ok.
[16:31] <wrapster> so are you rebuilding .?
[16:31] <wrapster> im trying it out here!!!
[16:43] <wrapster> geser: worked like a charm
[16:43] <wrapster> thanks a ton
[16:45] <\sh> siretart, pingeling....
[17:12] <leonel> how it's called when you want  a newer package for dapper ??
[17:13] <james_w> leonel: backports?
[17:14] <leonel> james_w: but included as official and not in backports?
[17:14] <james_w> SRU?
[17:16] <leonel> have a problem with the dapper  patch for squirrelmail .. bug    446838
[17:26] <ari-tczew> leonel: did you read wiki? https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging
[17:28] <ari-tczew> very poor work
[17:33] <leonel> ari-tczew: why very poor ?
[17:36] <ari-tczew> only in patch2:
[17:36] <ari-tczew> unchanged:
[17:36] <ari-tczew> --- squirrelmail-1.4.13.orig/src/options_order.php
[17:36] <ari-tczew> +++ squirrelmail-1.4.13/src/options_order.php
[17:36] <ari-tczew> wtf?
[17:36] <ari-tczew> where is patch?
[17:39] <leonel> ari-tczew: what debdiff are you looking at ?
[17:41] <ari-tczew> http://launchpadlibrarian.net/33428968/sqjaunty.debdiff
[17:41] <ari-tczew> please compare with this: http://launchpadlibrarian.net/33234876/drupal5_5.18-1.1ubuntu2.debdiff
[17:43] <leonel> drupal  uses  dpatch
[17:43] <leonel> squirrelmail  had no   debian/patches dir
[17:43] <leonel> the previous  patches for squirrelmail where applied  by someone else and did the patching inline
[17:43] <leonel> that's the road I've followed
[17:45] <ari-tczew> leonel: https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[17:45] <leonel> ari-tczew: yes I've read
[17:45] <ari-tczew> I can't believe that squirrelmail can't using patchsystem.
[17:45] <leonel> ari-tczew: I've follow as the previous patches went in
[17:45] <leonel> ari-tczew: this is not my first patch ..
[17:46] <leonel> ari-tczew: even I'm not an expert ..
[17:46] <leonel> ari-tczew: I've did my best  editing 19 files for  5  Ubuntu versions..
[17:48] <ari-tczew> yhym I see
[17:49] <leonel> so what is really wrong so I can fix it ?
[17:50] <ari-tczew> Best work is include a patch to debian/patches
[17:50] <joaopinto> afaik the usual rule is to keep whatever patch system is used on Debian, if it was none, keep it none :P
[17:50] <leonel> so edit  the package to include a patching system ?
[17:51] <ari-tczew> bingo !
[17:51] <sistpoty|work> ari-tczew: nope, what joaopinto wrote
[17:51] <leonel> joaopinto: that's what I've always known
[17:52] <leonel> so that's why as I've said ..  I've followed the patches as ther where comming ..  no patching system in squirrelmail so   patched inline
[17:52] <ari-tczew> maybe you wrong patched files?
[17:52] <ari-tczew> try again
[17:53] <joaopinto> ari-tczew, there is nothing wrong with his approach per the latest discussion about patches management
[17:53] <leonel> ari-tczew: WHAT ???
[17:53] <sistpoty|work> ari-tczew: any changes are in the .diff.gz so recovering from unwanted changes can be done easily
[17:56] <ari-tczew> OK, I'll no long intrude in this case.
[18:02] <ahasenack> hey, is apport in karmic ok? It doesn't catch crashes in python scripts that do not run as root because the crash file can't get written to /var/crash
[18:02] <ahasenack> example: https://pastebin.canonical.com/23217/
[18:02] <ahasenack> ups, wait
[18:02]  * ahasenack switches the pastebin
[18:03] <ahasenack> http://pastebin.ubuntu.com/291714/
[18:06] <ahasenack> hmm, I may have an old version
[18:06]  * ahasenack updates
[18:32] <james_w> ahasenack: what are the permissions on your /var/crash?
[18:35] <ahasenack> james_w: 0700 root:root
[18:35] <james_w> that's why then
[18:35] <ahasenack> james_w: but I'm updating this karmic vm now, it's a few days behind, maybe something changed
[18:35] <james_w> something has changed that
[18:35] <ahasenack> james_w: so what are the original permissions and what sets it?
[18:36] <ahasenack> james_w: oops, wait
[18:36] <ahasenack> james_w: it's 0755, not that it changes much
[18:38] <ahasenack> it's also root:root 0755 in another karmic instance I have, and that one is up-to-date
[18:39] <ahasenack> I wonder if apport is actually a daemon that catches the errors and has write permissions there
[18:39] <ahasenack>  /etc/init.d/apport is an upstart job now, and I don't know how do start or handle these. I know there is nothing like "apport" running right now
[18:44] <james_w> ahasenack: the apport upstrart job creates it
[18:44] <james_w>     mkdir -p -m 1777 /var/crash
[18:44] <ahasenack> james_w: where is that mkdir line? In /etc/init.d/apport?
[18:45] <james_w> /etc/init/apport.conf
[18:45] <ahasenack> ok, I'll reboot the machine and let's see what happens
[18:45] <ahasenack> james_w: is there a way to run these upstart jobs manually like in the "old days"? Like /etc/init.d/apport start
[18:46] <james_w> sudo start apport
[18:46] <james_w> or sudo service apport start
[18:47] <ahasenack> so, just doing that doesn't fix the directory, likely because it's already there
[18:48] <james_w> yeah
[18:48] <james_w> one thing I can see is that update-notifier-common ships the dir
[18:50] <james_w> which it didn't seem to in jaunty
[18:51] <james_w> and so new installs will probably see this
[18:51] <ahasenack> ups, I guess this machine has a problem now
[18:51] <ahasenack> init: mountall post-stop process (942) terminated with status 1
[18:53] <ahasenack> getting a segv
[18:53]  * ahasenack searches launchpad
[21:37]  * jdong kicks thunderbird for not compacting more often
[23:18] <nikolam> hello
[23:19] <nikolam> link https://bugs.launchpad.net/ubuntu/+filebug on launchpad redirects me to ubuntu wiki
[23:19] <nikolam> instead of letting me file a bug
[23:19] <nikolam> so there is a bug about filing bugs on launchpad? :)
[23:19] <joaopinto> nikolam, read the wiki
[23:20] <joaopinto> on the bottom there is a description on how to manually file a bug report
[23:20] <joaopinto> nikolam, is not a bug, is a feature
[23:20] <nikolam> aha..
[23:20] <nikolam> interestin.
[23:20] <nikolam> Maybe that should be explaind on top of the wiki.
[23:21] <nikolam> right noe i am again confused joaopinto
[23:21] <nikolam> i am reading it, but i am not sure how to file a bug
[23:21] <joaopinto> ufff
[23:21] <nikolam> and i filed them many before
[23:22] <joaopinto> http://bugs.launchpad.net/ubuntu/+source/PACKAGENAME/+filebug?no-redirect
[23:22] <joaopinto> nikolam, the goal is to make bug filing restricted to those who can read a page :P
[23:22] <nikolam> i think the goal is to having less bug reports
[23:23] <nikolam> pet example, my bug have nothing to do with apport etc
[23:23] <joaopinto> less unusefull bug reports, yes
[23:23] <micahg> nikolam: the goal is to collect information about the package in question to save back and forth for triagers
[23:23] <joaopinto> nikolam, this is not related to apport, apport is just a tool to make bug reporting easier
[23:24] <nikolam> but what about bugs that have nothing to do with triaging?
[23:24] <joaopinto> nikolam, erm, you are not getting the point
[23:24] <nikolam> Like, request for packaging new package etc
[23:24] <joaopinto> nothing changed, except for the process for opening bugs
[23:24] <joaopinto> nikolam, for those you use the links described on the wiki
[23:25] <nikolam> I would like to have those links inside launchpad, and not only on wiki, thats all.
[23:25] <joaopinto> nikolam, that would defeat the purpose of the change, as it would allow to people filing bugs without providing the required info
[23:26] <nikolam> is this suppost to be right place to file a bug? https://bugs.launchpad.net/ubuntu/+source/PACKAGENAME/+filebug?no-redirect
[23:27] <joaopinto> if you you are going to file a bug against a package, better use, ubuntu-bug package
[23:27] <nikolam> I don`t see point of launchpad as whole if user is requred to manually change link it should be able to click to
[23:27] <joaopinto> if't it's for a project
[23:27] <joaopinto> https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect
[23:27] <joaopinto> nikolam, a user is not required to use launchpad links, it is required to use the "Report bug" function, or to run the ubuntu-bug command
[23:28] <joaopinto> nikolam, why are you complaining if you didn't read the full wiki page yet ?
[23:28] <joaopinto> in this complain time you could have read the page and have a better understanding of the changes
[23:28] <nikolam> joaopinto, i think that there is very small amount of people/users that will EVER read full wiki page
[23:29] <nikolam> And theis conclusion would be.. it doesn`t work.
[23:29] <joaopinto> nikolam, those which are not qualitified to provide the information for a bug or for a process, don't add any benefite to participate in such process
[23:29] <nikolam> I don`t say idea is bad, it is very good one, actally
[23:29] <micahg> guys this discussion is more suited for the #ubuntu-bugs channel
[23:29] <micahg> *people
[23:30] <nikolam> oki :) micahg
[23:30] <nikolam> anyway, we understand , say I understand it now..