| mohadib | hello | 02:20 |
|---|---|---|
| mohadib | im building a deb to hopefully be included in ubuntu | 02:20 |
| mohadib | i am making an ant file for the package | 02:20 |
| mohadib | my pacjage depends on swt-gtk, and needs it to compile | 02:21 |
| mohadib | should i refrence where apt put the swt lib in my ant file? | 02:21 |
| mohadib | or should i include the lib? im pretty confused | 02:21 |
| persia | You should reference the system library. | 02:21 |
| mohadib | ok, thanks | 02:22 |
| persia | Ideally, your package won't contain any libraries, and just use the system libraries. | 02:22 |
| mohadib | aye, i made one that does that | 02:22 |
| mohadib | but i was told i did it wrong | 02:22 |
| persia | The normal way to do this is to set up ant to not care which one is used, and to set the CLASSPATH in debian/rules | 02:22 |
| mohadib | and i got to use dh_make and all this stuff | 02:22 |
| persia | Please don't use dh_make :) | 02:22 |
| mohadib | ok | 02:22 |
| mohadib | i have a java app i want to package | 02:23 |
| mohadib | can you tell me the most straight forward way to do it? | 02:23 |
| mohadib | i have 100 conflicting answers so far | 02:23 |
| persia | Hrm. | 02:23 |
| persia | So, I have an opinion as to which I think to be the easiest. | 02:23 |
| persia | But that's not necessarily the easiest for *you* | 02:24 |
| mohadib | please to share it :) | 02:24 |
| mohadib | ah | 02:24 |
| persia | There's no true way to package :) | 02:24 |
| persia | As long as the result package is policy-compliant, it is correct. | 02:24 |
| mohadib | do i have to submit source and a make file so ubuntu can compile it? | 02:24 |
| mohadib | i cant just submit a jar? | 02:24 |
| mohadib | :S | 02:24 |
| persia | I tend to recommend not using dh_make because it leaves around lots of extra files and sets some incorrect defaults. | 02:24 |
| persia | A source jar is fine :) But we need to compile it to ensure that the binaries released match the source. Otherwise we can't know that we can fix bugs in it. | 02:25 |
| mohadib | ah | 02:25 |
| mohadib | so the idea is to submit a source package with directions to build and install? | 02:25 |
| persia | Well, directions to build/install, licensing documentation, and hints on how the package relates to other packages. | 02:26 |
| mohadib | i see | 02:26 |
| persia | We encode these in the debian/rules, debian/copyright, and debian/control files. | 02:26 |
| mohadib | ok, so i hsould have rules call ant? | 02:26 |
| persia | We also have a debian/changelog file that tracks changes to the package. | 02:26 |
| persia | Right. | 02:26 |
| persia | There's lots of different ways to do this. My current favorite is to use /usr/share/doc/debhelper/rules.tiny for debian/rules | 02:27 |
| mohadib | http://openactive.org/pastebin/paste/show/6 | 02:28 |
| mohadib | does that look ok for rules? | 02:28 |
| persia | This will call dh_auto_clean, dh_auto_configure, dh_auto_build, and dh_auto_install to make a best guess as to how to build the package. | 02:28 |
| persia | You'll need a clean: rule. | 02:29 |
| persia | clean: should return the package to the state it was in prior to the build. | 02:29 |
| persia | This usually involves a call to `ant clean` or similar. | 02:30 |
| mohadib | ok thanks | 02:30 |
| nigelb | A few of the sugar packges have been deleted from karmic and lucid, but the deps are failing rebuild. Okay to request removal of all of them? | 02:41 |
| persia | nigelb: Why were they removed? | 02:43 |
| nigelb | we moved to a newer version | 02:43 |
| nigelb | in lucid the version is sugar-0.88 | 02:43 |
| nigelb | but there are a bunch of .84 and .86 packages in failed to rebuild queue | 02:43 |
| persia | That's confusing. Why do the package names change for a version change? | 02:44 |
| nigelb | I have no idea :( | 02:45 |
| nigelb | sugar seems to have names based on version, sugar-0.84, sugar-0.86, sugar-0.88 | 02:45 |
| persia | My suggestion would be to investigate this. While we both have no idea, we're not qualified to say what to do with these packages :) | 02:45 |
| nigelb | lfaraone: thoughts on this ^ | 02:45 |
| nigelb | since you're on the sugar team :) | 02:46 |
| nigelb | persia: I'm out of anything I can understand on umet deps and failed to rebuild :( | 02:46 |
| persia | nigelb: What don't you understand? I'd be happy to help for some of these things (where I know something, or generic information is likely to be correct). | 02:47 |
| nigelb | I'll take the first unmet dep then | 02:47 |
| nigelb | lemme load up the chroot | 02:47 |
| lfaraone | nigelb: Uh, .86 was re | 02:53 |
| lfaraone | *removed? | 02:53 |
| lfaraone | nigelb: That seems odd, since .88 is still not out yet (.87 will eventually become .88) | 02:54 |
| nigelb | lfaraone: appologies, 0.84 was removed | 02:55 |
| lfaraone | nigelb: so what ftbfs? | 02:56 |
| nigelb | some thing that depends on .84 | 02:56 |
| nigelb | hold on, I'll get the exact packages | 02:56 |
| nigelb | sugar-chat-activity-0.84 and sugar-read-activity-0.84 | 02:57 |
| persia | lfaraone: Do you know why these packages have these names instead of e.g. sugar-chat-activity ? | 02:59 |
| persia | (at a sourcepackage level: binary is entirely different) | 02:59 |
| lfaraone | persia: because it's an activity (what sugar calls Applixations) and it is called Chat. It only works with sugar. | 03:00 |
| nigelb | it makes it a bit different hunting through LP for it, I went by pure instinct | 03:00 |
| lfaraone | Oh, didn't see your earlier message. | 03:00 |
| persia | lfaraone: That explains the "sugar" and "activity" parts. I'm presuming the binary version is important for compatibilility. Why does it have that *source* package name? Do we really expect parallel installations of different versions of sugar? | 03:01 |
| persia | and is there a strong reason to support this? | 03:01 |
| lfaraone | No idea, that's imported from Debian. I haven't done much work on sugar packaging in a while | 03:01 |
| nigelb | persia: we can't have it anyway | 03:01 |
| nigelb | because the main build deps are not around | 03:01 |
| persia | nigelb: That's a different issue. | 03:01 |
| lfaraone | persia: Well, the Peru and Uruguay deployments are on .84/.82, so no. | 03:02 |
| ScottK | Debian does support parallel Sugar versions. | 03:02 |
| persia | Yes. I just don't understand why. | 03:02 |
| lfaraone | persia: Because the maintainer, Jonas, decided to do so. | 03:02 |
| persia | Oh well. | 03:03 |
| nigelb | um, so what can we do now? | 03:04 |
| lfaraone | persia: He uses git, which I find incredibily difficult to package with. Attempts to work with him in the past have been futile. | 03:04 |
| lfaraone | nigelb: Remove the packages which depend on .84. | 03:04 |
| nigelb | will file a bug | 03:08 |
| nigelb | lfaraone: take a look at this http://paste.ubuntu.com/386038/ | 03:11 |
| nigelb | should I request removal of the entire bunch? | 03:11 |
| lfaraone | nigelb: Nock yourself out :) | 03:13 |
| nigelb | lfaraone: another of my doubts is, when sugar-0.84 is already removed in lucid, why is it showing in my apt-cache | 03:13 |
| lfaraone | nigelb: because it's cached :) | 03:15 |
| nigelb | ah, so I only request removal of the ftbfs? | 03:15 |
| persia | nigelb: Better to request removal of the entire -0.84 stack, if it's not complete. I suspect some were just missed in the partial removal effort. | 03:21 |
| nigelb | persia: on grepping unmet, I find a bunch of sugar packages | 03:21 |
| persia | I suspect that once you clean up the FTBFS, you'll find some in unmetdeps, and the last few will end up as (relatively) unmaintained orphans. | 03:21 |
| nigelb | dont I have to file a request for each package individually? | 03:22 |
| micahg | mozilla team was already going to remove sugar-browser-activity-0.84 nigelb | 03:22 |
| persia | Well, don't remove sugar, just the old version that we know is gone :) The rest may need a bit of work to get both 0.86 and 0.88 in good shape for lucid. | 03:22 |
| micahg | s/remove/request removal | 03:22 |
| nigelb | ah, well, yaay, I found something to do ;) | 03:22 |
| nigelb | micahg: I'll do it for ya :) | 03:22 |
| nigelb | micahg: sugar browse 0.84 isn't already removed? | 03:24 |
| nigelb | I dont see it in my cache | 03:24 |
| mohadib | im looking at an exmple rules file, to build it issues ant -f build/build.xml | 03:25 |
| mohadib | for clean it calls the ant task clean that deletes ${build} | 03:25 |
| mohadib | wouldnt that delete the build.xml file? | 03:25 |
| mohadib | <property name="build" location="build"/> | 03:25 |
| mohadib | that means /build in the root? | 03:25 |
| mohadib | oh | 03:26 |
| mohadib | its create /build/build, sorry | 03:26 |
| persia | mohadib: /usr/share/perl5/Debian/Debhelper/Buildsystem/ant.pm has build.xml in ./ which makes me think this is a common practice. | 03:27 |
| nigelb | okay, in case of deletion, I follow the same procedure as sponsorship? (since I'm not yet MOTU) | 03:28 |
| ScottK | Yes. | 03:28 |
| nigelb | thank you :) | 03:28 |
| nigelb | bug 529824 good enough? anything more I should be adding? | 03:29 |
| ubottu | Launchpad bug 529824 in sugar-chat-activity-0.84 "Please remove sugar-chat-activity-0.84 from Lucid" [Undecided,New] https://launchpad.net/bugs/529824 | 03:29 |
| micahg | nigelb: yep, already gone | 03:29 |
| nigelb | micahg: :) | 03:29 |
| persia | mohadib: You may also find #ubuntu-java to be a better place for java-specific questions. | 03:29 |
| nigelb | oh no! | 03:31 |
| nigelb | I accidentally subcribed main sponsers instead of universe | 03:31 |
| nigelb | ugh! how do I fix this ugly mistake | 03:31 |
| lfaraone | Just switch it over. | 03:31 |
| lfaraone | No big. | 03:31 |
| nigelb | I cant remove the main guys | 03:32 |
| lfaraone | nigelb: Just sub univ, someone in main sponsors will sort it out. | 03:33 |
| nigelb | okay, just did that now. | 03:33 |
| * lfaraone is out for the night. | 03:34 | |
| nigelb | lfaraone: good night :) | 03:34 |
| ScottK | nigelb: Fixed | 03:37 |
| nigelb | ScottK: thanks again :) | 03:37 |
| nigelb | The epiphany-extensions-more is no longer being maintained and doesn't work with epiphany version in lucid, another target for removal? | 03:42 |
| persia | nigelb: I generally try first to fix it, and only seek removal if there is some reason it cannot be fixed (which is different than there being some reason I can't fix it) | 03:43 |
| nigelb | persia: but upstream says it won't work with epiphany 2.28 and above | 03:44 |
| nigelb | and lucid version is now 2.29 | 03:44 |
| ScottK | That'd be good enough for me. | 03:45 |
| persia | nigelb: That calls into "cannot be fixed" :) | 03:46 |
| nigelb | thats what I thought too! | 03:46 |
| nigelb | persia: If it were possible to be be fixed, I'd bug you for teaching me how ;) | 03:47 |
| persia | I'd be the wrong person: for that bug, I'd point at micahg | 03:47 |
| nigelb | well, anyone who could ;) | 03:48 |
| micahg | nigelb: epiphany changed to webkit only with 2.28+ | 03:53 |
| micahg | nigelb: extensions were gecko based | 03:53 |
| nigelb | micahg: so now, we end up having to remove it | 03:53 |
| nigelb | micahg: it didn't work with karmic either I guess | 03:53 |
| micahg | nigelb: wait, it seems like the extensions were ported | 03:54 |
| nigelb | micahg: oh? | 03:55 |
| nigelb | the gnome site said, it work anymore and they use something new, which is extremely unstable | 03:55 |
| nigelb | http://live.gnome.org/Epiphany/ThirdPartyExtensions | 03:55 |
| micahg | oh, nm, the regular extenions were, but the -more wasn't | 03:55 |
| nigelb | yup | 03:56 |
| nigelb | I did a thorough read :) | 03:56 |
| mohadib | is this wrong? http://openactive.org/pastebin/paste/show/7 | 04:05 |
| mohadib | the deb gets made | 04:05 |
| mohadib | but my files are not included | 04:05 |
| mohadib | just readme and changelog, stuff created by dh_build | 04:05 |
| mohadib | ah, think i see the problem | 04:07 |
| mohadib | hm no | 04:09 |
| persia | mohadib: The last paste you had included a dh_install call. | 04:16 |
| persia | mohadib: You probably also don't want to use the cp calls (especially because they install to an unsired location) | 04:17 |
| mohadib | well, i changed to debian/syspage/ and it seems to do what i want now | 04:18 |
| mohadib | is ok? | 04:18 |
| persia | mohadib: creating debian/install with http://openactive.org/pastebin/paste/show/8 adding dh_install, and dropping the cp calls should work. | 04:18 |
| persia | If it does what you want, it's OK, but it may not be best practice :) | 04:18 |
| mohadib | no, ill do what you said | 04:19 |
| mohadib | thank you | 04:19 |
| mohadib | no point in getting into bad practices now | 04:19 |
| persia | Well, I'm not sure not using debhelper is a bad practice, but in general, debhelper makes things easier and the same model used for dh_install also works for other dh_* calls. | 04:20 |
| persia | But I think using cp is poor practice, and if one wants to avoid using debhelper, using the "install" program is better. | 04:21 |
| * persia notes that some of the exposition is just for those reading along | 04:21 | |
| mohadib | can i see how the files will be installed from a deb without installing the deb | 04:22 |
| mohadib | like dpkg -L | 04:22 |
| persia | dpkg --contents | 04:22 |
| mohadib | ahh ty | 04:22 |
| mohadib | that worked great, the dh_install thanks | 04:23 |
| Anzenketh | Hello I am developing a patch for bug 529744 I have edited it on my karmic system I was wondering how to test the patch to make sure It did what I said I wanted it to do. | 07:21 |
| ubottu | Launchpad bug 529744 in gnome-system-tools "When creating a new user, "Shortname" should really be "Username" ." [Low,Triaged] https://launchpad.net/bugs/529744 | 07:21 |
| persia | Anzenketh: I can't see the patch in the bug report. | 07:22 |
| persia | But in general patch testing consists of 1) download or unpack fresh source, 2) apply the patch, 3) build, 4) test | 07:23 |
| Anzenketh | Yep I just removed it forgot to so I could change karmic to lucid | 07:23 |
| nigelb | Anzenketh: how did you get the source? | 07:23 |
| Anzenketh | dget -xu | 07:24 |
| ddecator | in everyone's opinion, how much programming knowledge is needed to work on patches? i'm learning basic python, and i'm wondering if by the time i'm done i'll be able to actually do any patch work | 07:24 |
| Anzenketh | persia: So just run ./config make make install then launch it from wherever I find the binary. | 07:24 |
| nigelb | um, no | 07:24 |
| persia | Anzenketh: Depending on your level of familiarity with debian-format packaging, you may find other ways to work better, but that *ought* to work. You may want to run `debian/rules patch` beforehand: this doesn't always work, but should apply any pending patches. | 07:25 |
| persia | (or check debian/README.source for closer guidance : again this isn't always there, but it *ought* be) | 07:25 |
| Anzenketh | ok will read README.source | 07:26 |
| Anzenketh | the pdbuilder just though me though a loop | 07:26 |
| Anzenketh | No clue what it is or how to use it. My familiary with debian-format packaging is close to none | 07:26 |
| persia | Anzenketh: Then just ignore the packaging, except for applying patches. | 07:28 |
| persia | Anzenketh: And if you're not doing the packaging, talking about patches in #ubuntu-bugs is likely more on topic. | 07:28 |
| nigelb | persia: would it be okay if I just packaged it for him and gave credit? | 07:36 |
| Anzenketh | Thanks for your help I will go read more of the wiki. | 07:37 |
| persia | nigelb: Absolutely. The usual way to do that would be for you to be listed in the changelog, and to credit Anzenketh in a comment for the specific line you add to Debian changelog when making the change. | 07:37 |
| persia | e.g. "Patch to frob quux (thanks J. Hacker)" | 07:38 |
| nigelb | ah, I'll get that done in a few | 07:38 |
| Anzenketh | I almost got the fixed debdiff up there nigelb | 07:40 |
| nigelb | Anzenketh: dont worry on errors. I'll fix the whole thing up and give you a feedback (though I may just start afresh and credit you with it) | 07:41 |
| persia | nigelb: Thanks for helping out the Reviewers team! | 07:41 |
| nigelb | persia: are there any requirements to join there? | 07:41 |
| persia | nigelb: There's ~2000 more patches in the bugtracker that could use the same attention, if you're up for hitting some of them. | 07:41 |
| nigelb | I'm sure I can read patches well enough | 07:41 |
| persia | nigelb: You're expected to be competent to review patches and familiar enough with Ubuntu Development to be able to get stuff uploaded. | 07:42 |
| nigelb | bah, uploaded | 07:42 |
| nigelb | meaning, I should have upload rights or I should have uploaded packages? | 07:42 |
| === NCommander_ is now known as NCommander | ||
| === NCommander is now known as Guest88162 | ||
| persia | nigelb: You should be capable of getting stuff uploaded. That can be directly or indirectly. Doesn't matter. | 07:43 |
| === Guest88162 is now known as NCommmander | ||
| nigelb | persia: I'll help out with a few of those ~2000 patches and apply to join :) | 07:44 |
| persia | nigelb: Some Reviewers work closely with upstreams to get stuff accepted there, and get it uploaded by the sync/merge process. Others are Debian developers (or nascent ones) and get stuff uploaded there. Some are Ubuntu Developers. | 07:44 |
| Anzenketh | nigelb: I changed the changelog. | 07:45 |
| nigelb | I'm pretty much blind on Debian Development. | 07:45 |
| persia | Any of those are good working models: much of patch review is like bug triage, except with code rather than problems. | 07:45 |
| * Anzenketh goes back to reading the wiki | 07:45 | |
| nigelb | I know. I have had this team in sights for something | 07:45 |
| nigelb | persia: I think we need an easier process for new contributors. Like for fixing a proper bug from launchpad | 07:45 |
| nigelb | I'm thinking of writing a small blog post based on this bug fix for future reference. | 07:46 |
| nigelb | s/easier process/easier documentation | 07:46 |
| nigelb | Anzenketh: okay, a few things you should remember for future. | 07:49 |
| nigelb | each package uses its own patch system, so that any new patch can be unapplied if its not working. When working on a bug fix, you must ensure that you write a patch under this system | 07:49 |
| persia | nigelb: I wrote one: https://wiki.ubuntu.com/Bugs/HowToFix?action=recall&rev=16 is the most modern copy available. Someone else made it complicated, and I haven't gotten around to fixing it yet. Feel free to wade in if you like :) | 07:49 |
| nigelb | this package for example, uses quilt. | 07:49 |
| nigelb | persia: I will write a post of my own and ask for review to be included in the wiki. | 07:50 |
| nigelb | which seems saner | 07:50 |
| persia | Please work to fix what we have, rather than adding more. | 07:50 |
| persia | Lots of different conflicting documents just confuse users. | 07:51 |
| nigelb | okay :) | 07:52 |
| nigelb | Are patching systems like quilt, cdbs used only downstream? Or does upstream use them too? | 08:01 |
| slytherin | nigelb: Why would upstream use a patch system? | 08:01 |
| persia | There's no good answer to that question :) | 08:01 |
| nigelb | I'm just asking something that just popped in ;) | 08:01 |
| nigelb | why is there no good answer? | 08:02 |
| persia | So, we have some systems (cdbs-simplepatchsys, dpatch) that are only used in Debian and derivatives. | 08:02 |
| persia | Other patch systems are more widely used. | 08:02 |
| Rhonda | nigelb: upstream as in Debian uses patch systems too, yes. :P | 08:02 |
| nigelb | I counted debian as downstream too :) | 08:02 |
| Rhonda | It's upstream from Ubuntu's point of view. | 08:02 |
| nigelb | since I *know* debian uses them | 08:02 |
| nigelb | I should framed properly | 08:03 |
| persia | Generally patch systems are used by various distributors who are *not* the original authors, or for release that are not trunk. | 08:03 |
| Rhonda | Ubuntu is downstream from Debian's point of view. | 08:03 |
| persia | VCSs that support branches are often used for this as well. | 08:03 |
| nigelb | like git having several branches | 08:03 |
| nigelb | Rhonda: I wanted to ask from a debian standpoint. But I framed wrongly :) | 08:03 |
| Rhonda | I know one upstream that uses plain patch/diff as patch system, though. For carrying extra patches. | 08:04 |
| persia | Original software authors rarely need to maintain sets of patches to their code, generally instead maintaining a single trunk source. VCSs are commonly used to keep track of patches applied. | 08:04 |
| nigelb | ah, that pretty much answers my question and beyond :) | 08:04 |
| Rhonda | t-prot carries some patches in the "contrib/" subdirectory, even though the developer produces those patches himself. | 08:04 |
| persia | Since distributors (like Debian or Ubuntu) may be pulling from the authors directly, or from some patched version distributed by a more specialised distributor, there exists no correct answer to "Does upstream use patch systems". Debian certainly does. upstream from there gets murky. Original authors are unlikely to use them. | 08:05 |
| persia | (except in special cases, as Rhonda notes) | 08:05 |
| Rhonda | Isn't there these php patches that are also distributed seperately that gets applied? | 08:06 |
| Rhonda | kishino or something like that? Never can remember the name. | 08:06 |
| persia | There are. There's also sets of patches for MAME and vim that get developed as essentially separate upstreams. | 08:08 |
| persia | (and likely several more cases) | 08:08 |
| nigelb | It does get really murky then | 08:09 |
| nigelb | btw, if the new patch tagging guidelines are out, why arent all the patches according to them? | 08:09 |
| Rhonda | persia, btw., LP #528957 about that sdl issue, it starts to pop up now from various places. :/ | 08:10 |
| ubottu | Launchpad bug 528957 in wesnoth "mouse button clicks not detected in windowed mode" [Undecided,Confirmed] https://launchpad.net/bugs/528957 | 08:10 |
| persia | nigelb: My rule of thumb is to just submit an ordinary patch upstream unless I'm willing to act as a (nascent) upstream developer. | 08:10 |
| Rhonda | nigelb: Because it's a guideline and not a policy must and people are lazy. | 08:10 |
| persia | Rhonda: It's all over the place :( Do you know if a good general solution is available? | 08:10 |
| nigelb | persia: makes sense :) | 08:10 |
| Rhonda | persia: Not totally sure. Maybe rolling back to 1.2.13 would be worthwhile, depending on the influence of the issue that triggered the sync in the first place. Maybe even the solution for that one could get cherry-picked, I'm unsure. :/ | 08:11 |
| nigelb | I see like 9 patches in the debian/patches directory and none of them are tagged per debian/ubuntu guidelines. Is that normal? | 08:11 |
| persia | nigelb: Unfortunately DEP3 has little takeup so far. | 08:12 |
| Rhonda | persia: If I would have some more time at my hands I really would dig into git bisect and try to pin down which commit did break the click thing in sdl. :( | 08:12 |
| * Rhonda really wonders why noone has done that so far. %-/ | 08:12 | |
| nigelb | I'm going to tag if off anyway. | 08:12 |
| nigelb | all the bugs I have worked on, I have tagged, going to keep tradition here | 08:12 |
| persia | lool: Have you any thoughts on the matter? | 08:13 |
| Rhonda | nigelb: Yes, that's completely normal. Like said, it's a pretty new thing, it's not enforced, lintian only recently started to mention it, … | 08:13 |
| persia | nigelb: Please do tag your patches. Please don't tag other people's patches arbitrarily. | 08:13 |
| nigelb | persia: I dont have the patience to do that for others ;) | 08:13 |
| persia | Excellent :) | 08:13 |
| persia | Some people do, and it's always frustrating, because their tags are almost universally ignored or rejected when received. | 08:14 |
| slytherin | Any members of SRU team around? | 08:14 |
| persia | The effort is appreciated, but misdirected. it's like uploads to Ubuntu that create a variance with Debian to only bump the standards version (with no other changes). | 08:14 |
| persia | slytherin: SRU is consolidated: check in -devel :) | 08:15 |
| slytherin | ok | 08:15 |
| Rhonda | Submit such things back, maybe they are appreciated. :) | 08:15 |
| nigelb | I have to learn debian bts one day | 08:17 |
| nigelb | It totally scares me right now | 08:17 |
| persia | Rhonda: Reports that e.g. Standards-Version can be bumped from 3.8.3 to 3.8.4? Lots of people got complaints submitting stuff as bugs that was available from the PTS. | 08:18 |
| Rhonda | Erm, yes, that doesn't make sense, I agree. :) | 08:18 |
| Rhonda | nigelb: It's not that complicated, once you got around that it's mainly a mail interface. :) | 08:19 |
| nigelb | Rhonda: I got that figured out only earlier today. :/ | 08:19 |
| persia | We've had folks that aggressively tested stuff and submitted that class of report. I think we don't have any right now, but those folk aren't folk I want to share with Debian yet :) | 08:19 |
| duanedesign | hello nigelb | 08:21 |
| nigelb | Anzenketh: you need a little bit more of eduction with debian packing before you attempt to upload a debdiff | 08:24 |
| nigelb | so, I would suggest uploading simple patches for now. :) | 08:25 |
| Anzenketh | I was not planning on doing anything besides string-fixes | 08:25 |
| nigelb | Anzenketh: even so. Take a look at my debdiff once I upload it. you'll understand what I mean. | 08:26 |
| persia | Anzenketh: I'd second nigelb's recommendations. When I was starting, I found it was much more effective to just fix the bugs with patches, and get someone else to worry about getting it integrated and uploaded. Looking at the differences between what I produced and what was uploaded helped me to understand how to work with packaging. | 08:37 |
| Anzenketh | Ya the link you gave me on how to get started helped a lot | 08:38 |
| Anzenketh | I found out what what-patch did | 08:38 |
| lool | persia: on DEP3? | 08:46 |
| persia | lool: On libsdl1.2 and bugs like 528957 | 08:47 |
| * lool loads | 08:48 | |
| persia | crimsun suggested that it fixed some stuff, but you did another merge, and I wonder if you'd had a chance to look at the issues that are keeping .14 out of squeeze as part of that. | 08:48 |
| persia | Debian bug #565788 has some of the details, but I don't think anyone has really dug into it. | 08:49 |
| ubottu | Debian bug 565788 in libsdl1.2debian-all "Upgrading SDL breaks Wesnoth" [Critical,Open] http://bugs.debian.org/565788 | 08:49 |
| persia | Right now, we have a situation where some stuff seems broken with .13 and other stuff with .14 and we're shipping .14 | 08:49 |
| lool | I only merged packaging changes AFAIR; the previous merge had been from experimental and mine was from unstable, I was a bit surprized to see we picked up an experimental package for lucid though | 08:49 |
| lool | I personally have many weirdnesses with mouse clicks | 08:50 |
| persia | Oh well. I have a feeling crimsun has far to much already needing to be looked at for lucid. Maybe someone else can find time to track down the issue. | 08:50 |
| lool | I think that someone should talk with SDL upstream mentionning imminence of debian and ubuntu releases affected by this bug and perhaps others | 08:50 |
| persia | lool: In apps other than wesnoth, but using SDL, or generally? | 08:51 |
| lool | I'm not on top of sdl bugs, sorry; it fixed a static build issue for me | 08:51 |
| lool | In one SDL app and generally | 08:51 |
| persia | No worries. I was just hoping that you'd noticed when you merged. | 08:51 |
| nigelb | Anzenketh: deleting your patch and uploading my debdiff | 09:09 |
| Anzenketh | ok | 09:10 |
| persia | nigelb: We usually leave the original patches in the bug for the historical record. | 09:11 |
| nigelb | persia: oh no! | 09:12 |
| Anzenketh | Ya it does look differnt. | 09:12 |
| nigelb | persia: I'll make sure I dont do that next time. anything to be done now? | 09:12 |
| persia | nigelb: Adding a comment when uploading your debdiff like "debdiff applying Anzenketh 's patch" makes it extra clear for sponsors. | 09:12 |
| persia | nigelb: Just follow the same procedure as if you're getting your own fix uploaded. | 09:12 |
| nigelb | I never wrote a simple patch :( | 09:13 |
| nigelb | I never got to learn how to do that | 09:13 |
| persia | Read revision 16 of Bugs/HowToPatch :) | 09:14 |
| persia | (or any earlier revision, but 16 is the most polished before the attack of the debdiff instructions) | 09:14 |
| Anzenketh | Attack of debdiff instructions? | 09:14 |
| nigelb | Anything I can do now to rectify the situation | 09:14 |
| persia | nigelb: Not really. Needs discussion. | 09:15 |
| persia | Anzenketh: There are continual efforts to update the wiki. At one point the instructions to create a simple patch were overwritten with instructions to create a debdiff for a candidate upload. This was done to reduce the number of different ways we instructed people to do things. Unfortunately, it's a lot more complex to create a candidate upload than to create a patch. | 09:17 |
| persia | Until we sort our the procedures and processes for handling different categories of code contributions, it's hard to change the documentation to match current practices. | 09:17 |
| nigelb | yea, like patching system, tagging - all needs to get integrated | 09:18 |
| persia | So I've not changed it back until more discussion happens (my last email on the subject was in December, but only got one reply) | 09:18 |
| persia | nigelb: Right. I don't think everyone who contributes code should need to learn that stuff, but I do think anyone who wants to be an Ubuntu developer should. | 09:18 |
| nigelb | persia: yup. everyone generating debdiff should know | 09:19 |
| persia | I think lots of people agree with that, but there are many people who think we shouldn't have two completely different procedures for code contributors, and that all code contributors should be treated the same. | 09:19 |
| persia | That debate is not yet concluded. | 09:19 |
| nigelb | In my case maco_ was kind enough to teach me. So i know. | 09:19 |
| nigelb | persia: could you unsubsribe reviewers? I've subscribed main sponsers | 09:21 |
| persia | No, but I'll see if I can fix things so I can next time :) | 09:22 |
| Anzenketh | So if the current instructions are wrong what are prospective developers to do? | 09:22 |
| persia | Anzenketh: Right now, prospective developers are told they have to learn how to make debdiffs. | 09:23 |
| persia | And random folk submit random patches that the reviewers review. | 09:23 |
| nigelb | persia: the reviews team wiki seems to indicate the same thing | 09:23 |
| persia | nigelb: Which thing? | 09:23 |
| nigelb | "For patch authors who can't upload yet we have the SponsorshipProcess. Unfortunately, there's also a big list of bugs with patches that are not following the process. Likely, because they are not aware of it. " | 09:23 |
| nigelb | Everyone is expected to use sponsorship. Not just give a patch. | 09:24 |
| persia | Oh, yeah. | 09:24 |
| persia | I personally disagree strongly with that. | 09:24 |
| persia | I don't think everyone needs to do that. | 09:24 |
| persia | It's too much work, and most folk just give up because it's hard. | 09:24 |
| nigelb | exactly | 09:24 |
| nigelb | that isn't fair to prospective contributors | 09:24 |
| Anzenketh | I don't even know how to do the sponcership process. | 09:25 |
| persia | But I'm not going to overwrite someone's wiki changes without discussion, and I only try to restart the discussion every few months. | 09:25 |
| Anzenketh | Directions on that are not verry clear either. | 09:25 |
| nigelb | its pretty easy, once you have a debdiff, subscribe sponsors depending on where your package is | 09:25 |
| persia | Anzenketh: Don't worry about it. if you can make patches, submit them and pretend you didn't read the wiki. Folk like nigelb will be happy to help get those to the right place (sometimes Ubuntu, sometimes upstream, sometimes Debian, sometimes all three). | 09:25 |
| Rhonda | persia, I know nothing about gnome-app-install, can you take a look at #82436 with respect to wether gnome-app-install (still?) wants to pull in the wesnoth-core package instead of wesnoth? | 09:26 |
| persia | But a discussion of how to create/submit patches *not* using the sponsorship process really doesn't belong here. it belongs in #ubuntu-bugs (or maybe somewhere else, if there's a channel I don't know about). | 09:27 |
| Rhonda | The bug is still open for that somehow. | 09:27 |
| persia | bug #82436 | 09:27 |
| ubottu | Launchpad bug 82436 in gnome-app-install "wesnoth-all meta-package request (for gnome-app-install)" [Undecided,Confirmed] https://launchpad.net/bugs/82436 | 09:27 |
| * persia suspects that's really a bug in app-install-data-ubuntu | 09:28 | |
| persia | Or not. Seems I said gnome-app-install last time I investigated it :) | 09:29 |
| Rhonda | :) | 09:29 |
| * Anzenketh just relized what they ment by subscribe | 09:31 | |
| persia | Rhonda: I think that bug doesn't matter anymore. software-center seems to look at app-install-data, which has the correct package hint to install "wesnoth" rather then "wesnoth-all" or "wesnoth-core". | 09:41 |
| persia | And this is unlikely to be fixed as a stable release update. | 09:41 |
| persia | So, I think gnome-app-install still has a bug, but I suspect it won't be fixed, and that most users won't encounter it. | 09:42 |
| Rhonda | I encounter it in my bugs page. :) | 09:42 |
| persia | Which page? I think that's a bug. | 09:43 |
| Rhonda | bugs.lp.net/~rhonda shows it to me everytime I go there | 09:44 |
| Rhonda | It's the only five-digit bugnumber on my page. :P | 09:45 |
| persia | Aha. It's there because you commented on it. | 09:46 |
| persia | Rhonda: mvo is looking at it, and will apparently sort it. | 09:49 |
| Rhonda | persia: I commented it because it was also a wesnoth bug. :) | 09:56 |
| Rhonda | It's a bit annoying that one can add "also-affects" but can't remove that anymore it seems. :/ | 09:57 |
| nigelb | Rhonda: we can :) | 09:57 |
| persia | There's a bug open about that. | 09:57 |
| persia | nigelb: No, we can't. | 09:57 |
| Rhonda | … | 09:57 |
| * Rhonda nibbles on nigelb. :) | 09:57 | |
| persia | nigelb: We can reassign, but never remove. | 09:57 |
| nigelb | okay, so the last time I did that was quite a while back then | 09:57 |
| persia | No, you've never been able to do it :) | 09:58 |
| * nigelb got confused with "also affects me" and and "also affects project" | 09:59 | |
| persia | Well, one could reassign to no package, but that just destroys (likely valid) history. | 09:59 |
| persia | heh | 09:59 |
| * nigelb notes that Rhonda didn't really elaborate which affects-me it was | 09:59 | |
| Rhonda | nigelb: Then again, one can't unsubscribe from bugs that one got subscribed through other means, this is also a long-standing bug. | 10:00 |
| Rhonda | I got told of to have set that bug back from Triaged to Confirmed because nothing at all happened in over a year … But it's annoying to have it in a state that says "yeah, we know how to do it" for such a long time without any progress, at all. :( | 10:00 |
| nigelb | Rhonda: you have a clean bugs.lp page? | 10:01 |
| persia | It's bug #204980 | 10:01 |
| ubottu | Launchpad bug 204980 in malone "bug contacts should be able to unsubscribe from implicit subscriptions" [High,Triaged] https://launchpad.net/bugs/204980 | 10:01 |
| persia | And bug #484319 | 10:01 |
| ubottu | Launchpad bug 484319 in malone "Add unsubscribe link in bug mail for structural and implicit subscriptions" [Low,Triaged] https://launchpad.net/bugs/484319 | 10:01 |
| Rhonda | nigelb: What do you mean with a "clean bugs.lp page"? | 10:01 |
| nigelb | Rhonda: everything fix released only ;) | 10:01 |
| nigelb | except for this one probably | 10:01 |
| Rhonda | No, but like said, this is the only 5 digit issue. :) | 10:02 |
| nigelb | oh, is there a difference in number of digits for different bugs? | 10:02 |
| Rhonda | I never will have a clean page, that's totally out of scope with that much interests on my hands. | 10:02 |
| nigelb | I didn't know | 10:02 |
| Rhonda | Sure, there is even LP #1 ;) | 10:02 |
| persia | nigelb: fewer digits indicate older bugs. | 10:02 |
| nigelb | oh, so this must be really old and ticking you off somewhat ;) | 10:03 |
| Rhonda | It in fact is because _I_ did my part of fixing the issue. :) | 10:03 |
| Rhonda | Given that LP seems to want to track the same bug in multiple packages not as seperate bugs but rather merges all the packages into it it can get easily annoying, especially since one can't unsubscribe from implicit subcriptions anymore. | 10:04 |
| nigelb | haha | 10:04 |
| Rhonda | nigelb: You might laugh, it was the thing that got me unsubscribing from irssi because of that multitude-merged perl transition bug that affected tons of packages and I received lots of mails that were totally unrelated to irssi. | 10:05 |
| persia | And weren't technically the same bug, but rather the same *class* of bug. | 10:06 |
| nigelb | that isn't fun | 10:06 |
| nigelb | but look at me, I'm subscribed to rhythmbox. I'll get mails like ubuntu cheated me of my money, I didn't get my mp3 and they kill kittens | 10:06 |
| Rhonda | sigwtf, bug #493299 | 10:07 |
| ubottu | Launchpad bug 493299 in irssi "irssi does not show notification bubbles" [Undecided,New] https://launchpad.net/bugs/493299 | 10:07 |
| * Rhonda now is happy to have unsubscribed from irssi all together. … %-) | 10:07 | |
| persia | Rhonda: Just mark it duplicate to 493297. | 10:08 |
| Rhonda | Sure, but … wtf :) | 10:09 |
| nigelb | no one packaged it? | 10:09 |
| Rhonda | It's a terminal based irc client! libnotify??! | 10:09 |
| Rhonda | The world is going crazy. :) | 10:10 |
| nigelb | lol, but most users use the libnotify script for irssi | 10:10 |
| Rhonda | I extremely highly doubt that. | 10:10 |
| * arand does.. | 10:11 | |
| Laney | I doubt that you could ever have evidence to support that, even if it were true | 10:11 |
| * nigelb edits | 10:11 | |
| nigelb | Many irssi users tend to use libnotify scripts for irssi | 10:11 |
| Laney | Some ... | 10:12 |
| Laney | and regardless, that doesn't make it a bug in irssi | 10:12 |
| Rhonda | I still don't buy the "many" | 10:12 |
| * nigelb edits to "Some" | 10:12 | |
| nigelb | and I agree, it does not make it a bug | 10:12 |
| Rhonda | In xchat, yes. In kopete, yes. But … hell, irssi usually runs inside screen on a remote system. :) | 10:13 |
| persia | Rhonda: You do know about the telepathy irssi plugin, right? | 10:17 |
| * Rhonda drops dead. | 10:18 | |
| Rhonda | persia: Do you want to take over maintenance of irssi? :) | 10:18 |
| persia | Rhonda: Not in the least bit :) | 10:22 |
| nigelb | Rhonda: if you want help with the bugs I could try :) | 10:23 |
| Rhonda | nigelb: I rather want help with the other irssi bugs, triaged. Including those reported in Debian. ;) | 10:23 |
| nigelb | Rhonda: I'll make you a deal. teach me how to deal with debian bts, I'll help you after finishing 1 round of rhythmbox | 10:24 |
| Rhonda | nigelb: Install devscripts and reportbug, for a start. :) | 10:27 |
| nigelb | both are here | 10:27 |
| persia | nigelb: Be careful with reportbug: you may want to read the docs (especially about Ubuntu changes), or install it in a Debian chroot. | 10:29 |
| nigelb | yes, a debian chroot is impending, especially to give back upstream. I've been lazy | 10:30 |
| persia | s/impending/pending/ | 10:31 |
| * nigelb needs to use smaller words | 10:31 | |
| rawang | hi, when I type "debuild -S", everything looks perfect, but when i dput, it doesn't upload the .orig.tar.gz? | 10:31 |
| Rhonda | How do I get bug #493048 linked to the upstream bugreport? | 10:31 |
| ubottu | Launchpad bug 493048 in irssi "Tab-completion of channel names cannot be properly used with /join in irssi" [Low,Triaged] https://launchpad.net/bugs/493048 | 10:32 |
| nigelb | I think flyspray is not supported | 10:32 |
| nigelb | (or whatever the upstream is) | 10:32 |
| rawang | nigelb, you mean me? | 10:33 |
| persia | Rhonda: Also, for bug manipulation, you may find more folk with more developed bug tweaking skills in #ubuntu-bugs (although nigelb is definitely one of them) | 10:33 |
| Rhonda | rawang: Also use the -sa switch, it seems that dpkg seems from your version number dpkg seems to think the orig.tar.gz should already bee in the archive. | 10:33 |
| nigelb | rawang: nope | 10:33 |
| Rhonda | nigelb: Yes, seems to be flyspay. | 10:33 |
| persia | rawang: Examine your source.changes file : it likely doesn't include a reference to the orig.tar.gz. You may want -sa as well. | 10:33 |
| rawang | sure | 10:33 |
| nigelb | Rhonda: I once ran into same issue. LP doesn't support flyspray tracking yet. | 10:33 |
| nigelb | you'll have to leave it as a comment | 10:34 |
| rawang | persia, but why it foget the orig.tar.gz? I just use "debuilld -S" with lots of packages and without any problem? :) | 10:35 |
| === shadeslayer is now known as shadeslayer_ | ||
| Rhonda | rawang: What's the version number? dpkg decides according to that wether it wants to include the .orig.tar.gz or not. | 10:35 |
| persia | rawang: debuild believed, based on the revision string, that you didn't need it. | 10:35 |
| persia | (version doesn't matter, only revision, but that's a quibble) | 10:36 |
| rawang | the package version? it's 0.1.7-1~pre1 in changelog file | 10:36 |
| Rhonda | The revision is part of the version</nitpick> | 10:37 |
| Rhonda | rawang: Ah, because it's not a plain -1 or -0 it thinks that the source should be in the pool already, yes. | 10:37 |
| rawang | but with my other packages, no problem with "x.x.x-1~pre1" | 10:37 |
| persia | Rhonda: Ah. I perhaps have different semantics than you. I always say that the version and revision are separated by the final '-' in the changelog entry. Do you know of an authoritative source of correct semantics? | 10:38 |
| nigelb | Rhonda: small world | 10:39 |
| nigelb | Rhonda: the same bug that I once triaged is what you're trying to link ;) | 10:40 |
| Rhonda | nigelb: I just stumbled upon it, yes. :) | 10:40 |
| Rhonda | persia: The overall thing is the version. :) | 10:40 |
| Rhonda | persia: dpkg --compare-version takes the whole thing, not only the part before the dash. | 10:41 |
| Rhonda | --compare-versions even. | 10:41 |
| rawang | Rhonda, 0.1.7 and 0.1.7-1, which one is newer? | 10:42 |
| Rhonda | persia: A version is compare of (optional) epoch + colon, upstream version, and optional dash + revision. | 10:42 |
| Rhonda | rawang: dpkg --compare-versions 0.1.7 '<<' 0.1.7-1 && "echo 0.1.7-1 is newer" | 10:42 |
| persia | Rhonda: OK. and what would you call #\(.*\)-[^-]*# ? | 10:42 |
| Rhonda | persia: a regular expression statement | 10:42 |
| persia | Ah, ${EPOCH}:${UVERSION}-${REVISION} ? | 10:43 |
| persia | I meant the match :p | 10:43 |
| Rhonda | rawang: erm, s/"echo /echo "/ of course. :) | 10:43 |
| Rhonda | persia: (${EPOCH}:)?${UVERSION}(-${REVISION})? - I said optional. :) | 10:44 |
| rawang | Rhonda, http://pastebin.org/99347 is the reason why orig.tar.gz is not include while i type "debuild -S" ? | 10:44 |
| persia | Rhonda: Thanks. I'll adjust my semantic map. | 10:44 |
| Rhonda | rawang: And the .orig.tar.gz is referenced in the .dsc file? | 10:45 |
| rawang | Rhonda, yes, it was | 10:45 |
| Rhonda | was, or is? | 10:45 |
| rawang | Rhonda, it is :) | 10:46 |
| persia | rawang: That looks suspiciously like it's being packaged for a PPA or other 3rd party repository. I'll recommend you use a revision like "-0ppaX" or "-0rawangX" rather than "-1~ppaX". | 10:46 |
| rawang | and i have compared the sha1 and sha256, it's identical | 10:46 |
| Rhonda | persia: trivia: what epoch is considered equal to version x? :) | 10:47 |
| rawang | persia, ok, my goal is to upload to debian archive, that's just a test environment :) | 10:47 |
| persia | Rhonda: 0? | 10:47 |
| Rhonda | rawang: I wouldn't go musing around what went wrong where too much and just add the -sa switch. Much less trouble and time waste. :) | 10:47 |
| Rhonda | persia: Right! :) 0:x = :x = x :) | 10:48 |
| rawang | Rhonda, sure, thanks a lot! :) | 10:48 |
| * persia decides to upload the next new packaged project as ~:... just to see what breaks | 10:48 | |
| Rhonda | epochs aren't allowed to contain ~ so the upload will get rejected. | 10:49 |
| rawang | Rhonda, but seems that there is no explanation about "-sa" in debuild manpage | 10:49 |
| nigelb | there should be -s and -a | 10:49 |
| Rhonda | rawang: Indirect explenation: dpkg-buildpackage(1) options may be given on the command line. | 10:50 |
| Rhonda | nigelb: No, there shouldn't. | 10:50 |
| rawang | nigelb, Rhonda ok, got it. | 10:50 |
| nigelb | Rhonda: my mistake :) | 10:50 |
| Rhonda | rawang: A lot of building tools hand over all options they don't know themself to dpkg-buildpackage. | 10:51 |
| Rhonda | Actually, I can't think of one that doesn't, or at least has a special flag to pass such options along. | 10:51 |
| * Rhonda . o O ( like --debbuildopts in cowbuilder ) | 10:51 | |
| rawang | Rhonda, yes, make sense, -sa option belongs to dpkg-genchanges. :) | 10:51 |
| persia | Rhonda: Do you know that to be true for Soyuz ? :) | 10:52 |
| Rhonda | persia: No, but then, I wouldn't mind if that thing breaks, so be my guest. :P | 10:52 |
| nigelb | I'm off folks, later :) | 10:52 |
| rawang | nigelb, byebye :) | 10:54 |
| shadeslayer_ | nigelb: bye! :0 | 10:54 |
| shadeslayer_ | *:) | 10:54 |
| arand | I'm trying to rebuild maxima to use libread6 instead of libread5, would I in this case simply change the line in debian/control from "libreadline5-dev | libreadline-dev" to "libreadline6-dev | libreadline-dev" ? | 11:45 |
| hyperair | shouldn't libreadline-dev be enough? | 11:47 |
| Laney | not if it's a virtual package | 11:47 |
| Laney | (is it?) | 11:47 |
| hyperair | it isn't | 11:47 |
| Rhonda | It isn't | 11:47 |
| Rhonda | And libreadline-dev depends on libreadline6-dev. :) | 11:48 |
| hyperair | yep | 11:48 |
| Rhonda | arand: Simply drop the "libreadline5-dev | " part. | 11:48 |
| arand | Rhonda: Ok, and then just put something in changelog? (No patch-making necessary here?) | 11:49 |
| * Laney eyes maxima | 11:50 | |
| Rhonda | If you change something you need to document that change in the changelog, yes. :) "drop libreadline5-dev alternative to build with libreadline6" or such. | 11:50 |
| Laney | those changes should be forwarded to Debian | 11:50 |
| Rhonda | I would expect that there is already such a bugreport. | 11:50 |
| Rhonda | There was some massbug filing about that issue. | 11:51 |
| Laney | not readline, all the other ones | 11:51 |
| Laney | http://changelogs.ubuntu.com/changelogs/pool/universe/m/maxima/maxima_5.20.1-5ubuntu1/changelog | 11:51 |
| hyperair | why not readline? | 11:55 |
| Laney | that's just not what I was talking about | 11:56 |
| randomaction | the readline change was already made in 5.20.0-1 | 12:04 |
| arand | Hmm, I'm getting failed builds for no-changes now on maxima (karmic) | 12:04 |
| arand | randomaction: Yea, but it's not in karmic. | 12:04 |
| arand | hence Bug #529902 | 12:05 |
| ubottu | Launchpad bug 529902 in maxima "maxima tries to find /lib/libreadline.so.5 but 9.10 has .6" [Undecided,Fix released] https://launchpad.net/bugs/529902 | 12:05 |
| arand | So if I'm getting build errors and failure to build when using a fresh pbuilder (after dpkg-source, debuild -S -uc -us), something bad is afoot? | 12:12 |
| shadeslayer_ | arand: probably | 12:13 |
| shadeslayer_ | arand: is the chroot updated and working? | 12:13 |
| arand | I just ran a "pbuilder --create" that should be sufficient? | 12:14 |
| shadeslayer_ | arand: can you pastebin the errors? | 12:14 |
| arand | http://pastebin.ubuntu.com/386252/ | 12:14 |
| shadeslayer_ | arand: not necessarily... the main servers are a bit wobbly these days,i failed 3 times to create a chroot with the main servers | 12:15 |
| shadeslayer_ | and then i used a local server in india | 12:15 |
| shadeslayer_ | arand: any errors while creating the chroot? | 12:15 |
| arand | I do not think so, I can recheck.. | 12:16 |
| shadeslayer_ | please do :) | 12:17 |
| shadeslayer_ | arand: if its fine,then i cant think of the solution :P | 12:17 |
| arand | It's just using the downloaded cache now I guess, but no errors on creating the chroot... | 12:21 |
| shadeslayer_ | hmm.. no idea then :( | 12:21 |
| arand | more bork in maxima, bleh! | 12:21 |
| arand | So in this case i should be reportin a "fail to build from source" bug? | 12:26 |
| persia | Well, best to try to fix it :) | 12:28 |
| persia | And if you're fixing it whilst you're working on the unmetdeps bug, no need to file a new bug. | 12:29 |
| arand | Eh, well, I have no idea how to fix it though, which is the crux.. | 12:29 |
| persia | arand: Well, are you willing to try? | 12:30 |
| arand | persia: Definitely. | 12:30 |
| persia | If it was my bug, I'd start by trying to run the build under gdb in a chroot. | 12:31 |
| persia | You seem to be using pbuilder, so pbuilder-dist lucid login, apt-get install gdb, apt-get build-dep maxima. | 12:31 |
| persia | Grab the sources. | 12:31 |
| randomaction | arand: which version of maxima are you building, and for which release of ubuntu? (sorry, I've been disconnected and may have missed this information) | 12:32 |
| persia | Do a local build with debuild -b (you'll discard this, so don't worry about it not being clean) | 12:32 |
| arand | persia: it's for karmic. | 12:32 |
| persia | arand: Once it fails, rerun the last entry from debian/rules under gdb, and dig up a backtrace. | 12:32 |
| persia | Then s/lucid/karmic/ :p | 12:32 |
| arand | persia: ok, I'm on it | 12:34 |
| arand | persia: Hmm, something is a bit odd, I get no prompt in "pbuilder-dist karmic login" and no bash-completion, etc... | 12:49 |
| * persia doesn't use pbuilder, and so is poorly-qualified to troubleshoot this class of issue | 12:50 | |
| guardian | hello, when i want to build a 32bit package on a 64bit box, I'm launching ./configure CC="gcc -m32" -- are there cross compiling options that would let autoconf pass the -m32 option to gcc? I mean explicitly telling "the compiler is gcc and it has to be invoked with the -m32" kinda defeats the purpose of autoconf isn't it? | 12:50 |
| persia | guardian: What is your larger goal? | 12:51 |
| joaopinto | guardian, it's easier to setup a 32bits schroot and build from there | 12:51 |
| guardian | the large goal is to be able to build my package for any 64b or 32bit platform that supports autotools | 12:51 |
| bjsnider | is the cdrkit vs. cdrtools fight ever going to be resolved? | 12:52 |
| guardian | the next step, after linux build, is to use autotools on mac but i'm still polishing linux builds on ubuntu :) | 12:52 |
| persia | bjsnider: No. | 12:52 |
| bjsnider | then someone is going to have to write brand new software that does what cdrtools does | 12:52 |
| persia | guardian: I'm not that familiar with cross-compilation, but we generally build stuff in a way such that it doesn't matter if the underlying hardware is 32 or 64 bit, but rather the environment as a whole. | 12:53 |
| persia | bjsnider: It's been done a couple times before. | 12:53 |
| bjsnider | i don't mean a fork, i mean brand new code | 12:53 |
| persia | guardian: So, we tend to build in managed chroots (using pbuilder or sbuild/schroot) that are constructed to believe they are 32-bit or 64-bit. | 12:53 |
| guardian | ok | 12:54 |
| persia | bjsnider: Yes, so do I :) Anyway, the easiest way to resolve it is for optical drives to become obsolete. | 12:54 |
| guardian | so, invoking configure --host=x86_64-pc-linux-gnu isn't supposed to work? | 12:54 |
| guardian | apparently it lloks for x86_64-pc-linux-gcc that doesn't exist | 12:55 |
| persia | It's suppsoed. We just don't do it that way :) | 12:55 |
| joaopinto | cross compiling is not trivial | 12:55 |
| persia | Not at all. | 12:56 |
| bjsnider | persia, i was hoping for a less depressing answer than that | 12:56 |
| guardian | it's not trivial and it often is as trivial as invoking configure with CC="gcc -m32 or CC="gcc -m64", that's why I was looking for an option that would let autoconf do it | 12:56 |
| guardian | i'm building a shared library btw | 12:56 |
| bjsnider | i don't have enough coffee in me right now to handle that | 12:57 |
| guardian | that only has the C runtime as a dependency | 12:57 |
| persia | guardian: -m32 vs. -m64 ignores a whole heap of valid -m values in Ubuntu :) | 12:57 |
| persia | We have 6 mainline architectures, most of which have a couple of different available personalities. | 12:58 |
| guardian | ok so the way to go is to chroot and let autoconf decide, that's what you're telling | 12:59 |
| persia | That's what we usually do, because it's easier to write portable software than to write cross-compilable software. | 13:00 |
| guardian | side question, let say I want to ease someone's life for a corporate internal tool, so that she launches "make" and it builds both x86 32b and 64b versions of my library -- according to what you just said, I'm better of writing a shell script that asserts gcc has multilib support and then launches configure 2 times from different build trees (one for i386, one for x86_64) with either CC="gcc -m32" or CC="gcc -m64" and finally invoke make one time in | 13:06 |
| guardian | build tree? | 13:06 |
| persia | guardian: For that case, I'd probably want to make cross-compile work. It's just not how we do it :) | 13:13 |
| === myrtti is now known as Myrtti | ||
| guardian | persia: and in case of cross compiling, what should i pass to the --host option? x86_64-something-but-what ? | 13:16 |
| persia | I'm not an especially good person to ask. Like I said, we don't usually do it that way. | 13:17 |
| guardian | ok | 13:17 |
| guardian | thank you anyway | 13:18 |
| === dyfet` is now known as dyfet | ||
| arand | Does these lines indicate why it fails to build: http://pastebin.ubuntu.com/386283/ ?? Or do I need to look further into the automake procedure? | 13:35 |
| persia | arand: That's likely the issue, yes. | 13:37 |
| persia | arand: Now you just have to track down where gcl-depends.mk is supposed to be created. | 13:38 |
| arand | persia: Hmm and how would I do that?... | 13:39 |
| persia | arand: I'd probably start with `grep -rin gcl-depends .` in the base directory. | 13:40 |
| arand | persia: What i found; http://pastebin.ubuntu.com/386303/ (ignoring./share/contrib/lurkmathml/maximadiffs.txt AND ./ChangeLog) With what little I can tell to mee it looks as though it should be created in src...? | 13:54 |
| * persia consults the make manual | 13:55 | |
| bjsnider | persia, what i can't figure out is why opensuse agreed to include cdrtools | 13:56 |
| persia | bjsnider: Does it matter that they did? | 13:58 |
| persia | Even if it does, does it matter why? | 13:58 |
| persia | And even if it matters why, does it matter for Ubuntu? | 13:58 |
| bjsnider | persia, because they should be facing the same issues ubuntu is with regard to cdrtools | 13:59 |
| eolo999 | hi, i' trying to package sphinx-search for hardy, everything works out except when i try to install the package i got a wronge version dependency error: sphinx depends on libpq5 (>= 8.4~0cvs20090328); however: Version of libpq5 on system is 8.3.9-0ubuntu8.04. Where does that dependency came out if the only thing I addded in control file was postgresql-server-dev-8.3? | 14:00 |
| eolo999 | and another question: how much time does it take to a package to be shown in launchpad PPA? | 14:01 |
| persia | arand: I'm getting confused about when include directives happen. | 14:03 |
| persia | arand: But try running the command that's supposed to generate the file, and see what happens. | 14:03 |
| kreuter | hi, #ubuntu-motu. can anybody help me make some progress on a sync request? | 14:05 |
| arand | eolo999: Depends on build queue, you can check the status of build and get a rough ETA | 14:06 |
| persia | kreuter: Sure. Where are you now? | 14:07 |
| eolo999 | arand: where do i find the queue? | 14:07 |
| kreuter | persia: https://bugs.launchpad.net/ubuntu/+bug/520610 | 14:07 |
| ubottu | Launchpad bug 520610 in ubuntu "mongodb sync request" [Undecided,New] | 14:07 |
| arand | eolo999: view package details, and on that page "view all builds" | 14:08 |
| eolo999 | ok | 14:08 |
| eolo999 | thx | 14:08 |
| kreuter | I'm not clear from the last comment what I'm supposed to do next. | 14:08 |
| arand | eolo999: However, that will only say something useful if you do have packages that are building.. | 14:09 |
| persia | kreuter: The last comment isn't actually that helpful, unfortunately. | 14:09 |
| persia | kreuter: it's a new package, so the first step is to request a freeze exception from the release managers. | 14:10 |
| kreuter | okay. how do I do that? | 14:10 |
| persia | kreuter: Update the description to indicate why mongodb is so cool that it *must* be in lucid, and subscribe ubuntu-release. | 14:10 |
| kreuter | does "we (10gen) receive continuous requests for Ubuntu packages" suffice? | 14:11 |
| arand | persia: I'm not quite sure what to do with all the $VARs ... | 14:12 |
| kreuter | and should I create a new lp bug, or just append to the current one? | 14:13 |
| persia | arand: Try running "make gcl-depends.mk" in ./src/ | 14:13 |
| persia | kreuter: I'd just keep reusing the bug, for easier tracking of all the history. | 14:13 |
| kreuter | ok | 14:13 |
| * persia has never done an FFe for a NEW package, and hopes someone else has a good hint for rationale | 14:13 | |
| Laney | don't forget about lucid-backports | 14:14 |
| persia | Laney: There's a bit of history here: kreuter came by just around FF and asked for inclusion, and was told to talk to Debian, and has done so. Do you know if there's a way to start populating lucid-backports prior to lucid release? | 14:15 |
| Laney | I'm not sure when it opens (ScottK or jdong might know though), but I guess that it can be pre-approved in any case. | 14:16 |
| arand | persia: just "make" gives "no rule..." and if I secify the makefile: http://pastebin.ubuntu.com/386319/ | 14:16 |
| eolo999 | is it possible that debuild take dependencies version from my karmic install and doesn't use pbuilder environment? | 14:17 |
| persia | arand: Ah, right, you'd have to generate all the makefiles first. | 14:17 |
| Laney | eolo999: not just possible, but certain | 14:17 |
| Laney | you need to call it with pbuilder build xxx.dsc or pdebuild | 14:18 |
| persia | arand: do you not get a Makefile with debuild -b ? | 14:18 |
| kreuter | I'm supposed to subscribe "Ubuntu Release Team"? | 14:18 |
| persia | kreuter: Yes. | 14:18 |
| kreuter | ok. done. | 14:18 |
| kreuter | now I wait? | 14:18 |
| eolo999 | Laney: great! so i can "run pdebuild -S"? | 14:19 |
| LimCore | hi, I was thinking, would it be nice to have a security tool that interactivly warns when a new application tries to connect to internet, and then remember user's decissions? (sort of like well known ZoneAlarm or Outpost products where for windows) | 14:19 |
| arand | persia: if you mean Makefile.am I do have one in src/ (and in ../) | 14:19 |
| persia | arand: No, I mean Makefile | 14:20 |
| persia | arand: Makefile.am probably generates Makefile.in which probably generates Makefile | 14:20 |
| eolo999 | I created the env with: sudo pbuilder-dist hardy amd64 create. How do i use it to build a source package based on that env? | 14:22 |
| * eolo999 is really a newbie | 14:23 | |
| Laney | you don't need to build a source package in the chroot | 14:23 |
| persia | Well, for some packages you might, depending. | 14:24 |
| persia | For instance, if you're running MoeOS, and you want to compile for lucid, and the package has versioned build-depends required for building sources ... | 14:24 |
| Laney | alright, if you can't satisfy the build-depends required to run clean: then yes you do. | 14:25 |
| arand | persia: No I have none of that, hmm, I found this bit earlier in the debuild -b output, is it relevant?: http://pastebin.ubuntu.com/386322/ | 14:25 |
| eolo999 | ok, found something in the packaging guide, i stopped reading too early | 14:25 |
| persia | arand: That looks like the output of the call to clean. | 14:25 |
| persia | arand: Did you manually delete anything or run clean after your call to debuild -b? | 14:26 |
| arand | persia: I still get that error if I dpkg-source in a fresh dir and run debuild -b again | 14:31 |
| kklimonda | LimCore: most people don't even read what is written on the popup dialog so they would probably just press "Allow" to dismiss it faster and use the program they have installed. I'm not sure if it's going to help them. | 14:31 |
| persia | arand: That's expected. The trick is that once you have run debuild-b, you are at the point of the crash. | 14:31 |
| LimCore | kklimonda: it will help thoes users that do read | 14:31 |
| persia | arand: And *then* you can run `cd src; make gcl-depends.mk` to try to replicate. | 14:32 |
| LimCore | the users that do not read can not be helped, but then other then general secure by default system, they can only blame themselves, if they will run a binary from internet or smth | 14:32 |
| persia | arand: and if you're extra lucky, you can edit Makefile to add a debugger call, and get a backtrace, and fix it. | 14:32 |
| kklimonda | LimCore: but to answer the question you have asked on #-bugs the libboost and wxwidgets are kinda heavy dependencies and wxwidgets is not in the main so getting such an application to the default cd would be hard task | 14:32 |
| eolo999 | it seems that even dh_make should have run with different env settings | 14:32 |
| arand | persia: Yea, ok, now it seems I have all the makefiles as they should be | 14:33 |
| arand | persia: So I would want to add $(how do I add a debugger call?) somewhere in here?: http://pastebin.ubuntu.com/386327/ (that's from the makefile) | 14:38 |
| persia | arand: Right. I'd probably insert echo at the beginning, and then add another line with gdb $(EXECUTEGCL) | 14:39 |
| persia | You can then add the arguments back inside gdb | 14:40 |
| persia | There are, of course, lots of other ways to do it :) | 14:40 |
| * persia grumbles at the massive dependency list for aptitude in sid | 14:41 | |
| arand | persia: http://pastebin.ubuntu.com/386330/ like so? | 14:42 |
| kreuter | persia: so now I'm supposed to get a sponsor review. how do I do that? | 14:45 |
| persia | kreuter: Wait for me to finish building the package :) | 14:46 |
| kreuter | ok :) | 14:46 |
| persia | At this point the rest is out of your hands. Just watch the bug traffic, and it should tell you the status. | 14:46 |
| kreuter | <nod> | 14:46 |
| persia | Unless something unexpected happens, it will probably be available in the next week or so. | 14:46 |
| persia | kreuter: Once it is accepted, you probably want to subscribe to bugmail, and try to make sure fixes are made available. You may also want to subscribe to the package in the Debian BTS. | 14:47 |
| arand | persia: And then run "gdb make" "makefile" "break EXECUTEGCL" and "run" ? | 14:49 |
| kreuter | persia: okay. | 14:50 |
| kreuter | thanks again! | 14:50 |
| persia | No, just run make `gcl-depends.mk`the gdb call inteh makefile will run gdb. | 14:50 |
| persia | But like I said, there's lots of ways. You can run gdb outside make too. | 14:51 |
| kreuter | hm. was I also supposed to have subscribed ubuntu-main-sponsors? | 14:52 |
| arand | Ok, I'll try that. | 14:52 |
| kreuter | (and is it still important for me to do so now?) | 14:52 |
| persia | kreuter: No, and no. | 14:53 |
| kreuter | okay and okay! | 14:54 |
| arand | persia: That just gave meMakefile:2398: *** missing separator. Stop. | 14:54 |
| persia | kreuter: For now, MOTU remains in charge of new packages. This ought change at some point, but it's not yet clear how to implement that. | 14:54 |
| persia | arand: That means there's a syntax errror in your makefile. | 14:54 |
| arand | persia: Hmm, seems I ran make at the wrong point before, now when I simply removed the gdb things from the makefile (I apparently didn't fit them in syntax properly) i instead get this on "make gcl-depends.mk": http://paste.ubuntu.com/386344/ | 15:02 |
| persia | arand: Excellent! You've found the bug, Try typing ":H" for help. | 15:04 |
| persia | I have no idea how to tell you to fix this, but you're getting to the point where you can probably track it down. | 15:04 |
| persia | (and it's a great opportunity to improve your lisp) | 15:04 |
| arand | I don't know a single bit of lisp :( | 15:05 |
| * persia suspects that will no longer be true in a couple hours | 15:06 | |
| === debfx_ is now known as debfx | ||
| hyperair | any motu-release people around? | 16:07 |
| persia | hyperair: MOTU Release is going away. Go find ubuntu-release in -devel. | 16:08 |
| hyperair | oh whoops | 16:08 |
| ScottK | Gone, not going. | 16:08 |
| hyperair | heheh | 16:08 |
| persia | Oh cool. | 16:08 |
| ikt | gone? | 16:09 |
| hyperair | ikt: yeah, archive reorg. | 16:09 |
| ikt | opps | 16:10 |
| ikt | read that wrong | 16:10 |
| ikt | motu release is going away | 16:10 |
| ikt | not motu | 16:10 |
| persia | ikt: No, MOTU still exists. | 16:11 |
| persia | ikt: But please feel free to participate in the discussion of the transitoin from Masters of the Universe to Masters of the Unseeded (or whatever MOTU ends up expanding as) | 16:11 |
| persia | (on the ubuntu-motu@ mailing list) | 16:11 |
| ikt | that's cool, I'm just getting used to bug triage, so I'm sure I'll be more active here soon >.> | 16:13 |
| hyperair | unseeded eh | 16:13 |
| hyperair | heheh | 16:13 |
| hyperair | i think masters of the universe sounds cooler =p | 16:14 |
| hyperair | but it wouldn't make much sense if universe itself disappears. | 16:14 |
| persia | Me too, but that requires a definition of "universe" that doesn't include lots of stuff, which is tricky once there are no components. | 16:14 |
| arand | persia: https://bugs.edge.launchpad.net/ubuntu/+source/maxima/+bug/296643/comments/12 :( Should I just fix the dependency and test-build it in ppa instead? | 16:15 |
| ubottu | Launchpad bug 296643 in maxima "Please merge maxima 5.17.1-1 (universe) from Debian unstable (main)." [Wishlist,Fix released] | 16:15 |
| hyperair | persia: components are going away? | 16:15 |
| * persia thinks people should actually read mail and check the references | 16:16 | |
| persia | https://wiki.ubuntu.com/ArchiveReorganisation/Components | 16:16 |
| ScottK | Universe of everything else. | 16:22 |
| lbrinkma | I have a problem with my anjuta-extras package: I can't get away the lintian warning: pkg-has-shlibs-control-file-but-no-actual-shared libs. I've no idea how to solve that, please help me. You can get the package at https://launchpad.net/~lbrinkma/+archive/ppa | 16:23 |
| kamalmostafa | I would like a clarification about the "motu-release is gone" situation please: How does that affect the FFe process? (https://wiki.ubuntu.com/FreezeExceptionProcess still advises that "motu-release" should be subscribed). What about all the bugs in the motu-release queue right now? | 16:25 |
| jbernard | lbrinkma: have you tried passing the '-I' flag to lintian? I find that often sheds light on what's going on | 16:25 |
| jbernard | lbrinkma: er, '-i' i meant | 16:26 |
| lbrinkma | jbernard: I've tried running 'lintian-info -t pkg-has-shlibs-control-file-but-no-actual-shared libs' and the information was not very helpful. I think, cdbs is causing this problem. | 16:28 |
| ScottK | kamalmostafa: motu-release/ubuntu-release. | 16:34 |
| === yofel_ is now known as yofel | ||
| lbrinkma | I've tried running with '-i'. It's the same as running lintian-info. I've no idea what to do next and I want to get the package to lucid. Everyday later makes it harder to get it accepted. | 16:38 |
| hyperair | featurefreeze is on already. i don't think you can get in any new packges. | 16:40 |
| lbrinkma | hyperair: It's not really new. The splitted up the anjuta package into anjuta and anjuta-extras. | 16:42 |
| hyperair | lbrinkma: can you check the contents of the deb with dpkg-deb -c package.deb? if there is a library in /usr/lib/ then dh_makeshlibs will create a shlibs control file. | 16:42 |
| kamalmostafa | ScottK: I think you're saying that motu-release is replaced by ubuntu-release, so I'll subscribe that to my pending FFe request. thanks. | 16:44 |
| lbrinkma | hyperair: there are files in /usr/lib/anjuta/ | 16:46 |
| hyperair | lbrinkma: got a build log? | 16:46 |
| hyperair | lbrinkma: and is the package uploaded somewhere? | 16:47 |
| wrapster | how do i list out all the diverts that have currently been provided by dpkg? | 16:47 |
| LaserJock | hey all, I'd like to file a sync request for a new upstream bug-fix-only release, is there anything special I need to do for that? | 16:47 |
| lbrinkma | hyperair: yes, in my ppa https://launchpad.net/~lbrinkma/+archive/ppa | 16:47 |
| hyperair | okay lemme download and see | 16:47 |
| wrapster | guys anyone knows about it? | 16:48 |
| hyperair | wrapster: man dpkg-divert | 16:48 |
| hyperair | dpkg-divert --list | 16:48 |
| hyperair | lbrinkma: well, i'm not sure why, but dh_makeshlibs is misbehaving. | 17:06 |
| hyperair | lbrinkma: solution is to make it not run, somehow. | 17:07 |
| hyperair | or rather, workaround. | 17:07 |
| hyperair | lbrinkma: or just get rid of cdbs. | 17:09 |
| lbrinkma | hyperair: how to do that? I'm not very familiar with cdbs | 17:09 |
| hyperair | lbrinkma: just get rid of it and use dh7 | 17:10 |
| lbrinkma | hyperair: How to do that best? I could rebuild the package and copy over the files or what to do? | 17:11 |
| hyperair | just change debian/control and debian/rules | 17:11 |
| hyperair | rewrite the debian/rules | 17:11 |
| lbrinkma | what to do in the control file: just delete cdbs dep | 17:12 |
| hyperair | delete cdbs dep, make debhelper's version 7.0.50 | 17:14 |
| hyperair | replace the rules with this: | 17:15 |
| hyperair | %: | 17:15 |
| hyperair | <tab>dh $@ | 17:15 |
| hyperair | override_dh_makeshlibs: | 17:15 |
| hyperair | the override_dh_makeshlibs is empty to avoid dh_makeshlibs from being called. | 17:15 |
| lbrinkma | hyperair: thank you very much for helping me | 17:18 |
| hyperair | lbrinkma: no problem. | 17:18 |
| === dpm is now known as dpm-afk | ||
| LaserJock | curse you v3 dpkg format!!! | 18:57 |
| === maco2_ is now known as maco2 | ||
| bdrung_ | LaserJock: why? | 20:15 |
| LaserJock | bdrung_: because I'm needing to backport a package to karmic | 20:16 |
| LaserJock | bdrung_: which means I need to un-v3 it | 20:16 |
| LaserJock | bdrung_: which meant that I needed to repack the .orig.tar.gz since it was a bz2 | 20:17 |
| LaserJock | which meant I have to reupload a tarball for the exact same thing that's already in the archives | 20:17 |
| bdrung_ | LaserJock: yeah, backporting v3 is a PITA, but i love it nonetheless | 20:18 |
| LaserJock | I haven't seen a package that really used it in a way that I was like "oh awesome" but I'm sure there are some about | 20:18 |
| bdrung_ | LaserJock: ist a cleaner debian/rules and a not-repacked bz2 source awesome enough? | 20:20 |
| LaserJock | I haven't seen much cleaner debian/rules, but yeah bz2 is great ... unless you're trying to backport :-) | 20:21 |
| Rhonda | bdrung_: I'm not that sure how much cleaner v3 makes debian/rules, to be honest. Sounds like buzzword merchandizing to me, can you clearify? | 20:23 |
| bdrung_ | Rhonda: you don't need a patch system in there (and you can drop the patch system from B-D) | 20:24 |
| geser | LaserJock: backporting from lucid+1 to lucid won't have this v3 format problem | 20:24 |
| Rhonda | LaserJock: And yes, the pain that the v3 format brings doesn't really work for its benefits. | 20:24 |
| LaserJock | geser: sure, but that doesn't help me now ;p | 20:24 |
| Rhonda | bdrung_: That doesn't make it much cleaner, and actually, one does need a patch system if one wants to work properly with it. | 20:25 |
| azeem | hey LaserJock | 20:25 |
| LaserJock | hi azeem | 20:25 |
| azeem | Rhonda: patch system cluttering up debian/rules | 20:25 |
| LaserJock | azeem: I'm trying to get gchemutils 0.10.12-1 into Debichem PPA | 20:25 |
| azeem | yay | 20:25 |
| bdrung_ | Rhonda: you don't have to. you can extract, edit the source, debuild, and the patch will created for you. | 20:25 |
| LaserJock | azeem: which is causing this v3 mess due needing newer goffice | 20:25 |
| Rhonda | azeem: Sorry, but that's a plain bullshit. A single include line and an patch and unpatch requirements to two targets are *FAR* from "cluttering up debian/rules". | 20:26 |
| azeem | Rhonda: please watch your language in here | 20:26 |
| Rhonda | s/bullshit/intentionally false advertising/, sorry. | 20:26 |
| azeem | LaserJock: hrm, which packages have been converted to v3? The debichem ones or goffice? | 20:26 |
| LaserJock | it seems like Debhelp 7 has more going for debian/rules maybe | 20:27 |
| LaserJock | azeem: goffice | 20:27 |
| azeem | ok | 20:27 |
| bdrung_ | Rhonda: compared to a three line debian/rules - it's a huge benefit ;) | 20:27 |
| LaserJock | anyway, there will be benefits to v3 in the future for sure | 20:27 |
| LaserJock | being able to do bz2 orig.tar. files is great | 20:28 |
| Rhonda | bdrung_: A three line debian/rules is a very bad idea and a regression to readable debian/rules IMHO. It might make things easier for 80% (where things already were easy) but makes it a lot harder for the remaining 20% of the packages. | 20:28 |
| azeem | nobody said you have to use 3-line debian/rules for all packages | 20:28 |
| * Rhonda points azeem at bdrung_ | 20:28 | |
| Rhonda | azeem: Unfortunately the documentation isn't there anymore to not get a 3-line debian/rules to start off from. | 20:29 |
| bdrung_ | Rhonda: yes, some packages needs more than this | 20:29 |
| Rhonda | It's hiding the posibilities that some packages actually _do_ require behind its three lines, and doesn't document properly how to work. | 20:30 |
| LaserJock | *anyway* it's not a peeing contest, debian/rules is as long (hopefully) as it needs to be to get the job done | 20:30 |
| Rhonda | That's a huge regression from a usability point of view. | 20:30 |
| Rhonda | hmmmmm | 20:40 |
| Rhonda | The requested URL /changelogs/pool/main/d/dpkg/dpkg_1.15.5.6ubuntu1/changelog was not found on this server. | 20:40 |
| kees | when motu-release folks get a moment, can two members ACK bug 530309 please? | 20:54 |
| ubottu | Launchpad bug 530309 in ltp "FFe: sync ltp with Debian" [Undecided,New] https://launchpad.net/bugs/530309 | 20:54 |
| === dpm-afk is now known as dpm | ||
| geser | kees: motu-release is getting merged into ubuntu-release, but I don't know what's the status is right *now* | 20:55 |
| kees | geser: yeah, that's why I figured I should just follow existing processes | 20:56 |
| iulian | kees: Done. | 21:10 |
| kees | iulian: thanks | 21:11 |
| alkisg | How can I discard a bzr push done by someone else? The launchpad tree is in rev. 79, in my local disk I have 78, and I want to discard 79... | 21:11 |
| jpds | alkisg: bzr pull; bzr uncommit; bzr revert; bzr push --overwrite? | 21:28 |
| alkisg | jpds: thank you :) | 21:28 |
| wrapster | hi | 21:34 |
| wrapster | are there any docs available to learn how APT works? | 21:34 |
| jcastro | lucas: I owe you a beer, the debian squid maintainer seems receptive to having the deb proxy thing an optional config | 21:34 |
| lucas | jcastro: perfect :) | 21:35 |
| matttbe | Hello nhandler_ and ScottK | 21:38 |
| matttbe | I'm part of the Cairo-Dock team and we need 1 'ack' in order to accept our update on Ubuntu Lucid asked more than 2 weeks ago... | 21:38 |
| matttbe | it seems that you can help us :) | 21:38 |
| matttbe | this is the two bugs: https://bugs.launchpad.net/ubuntu/+source/cairo-dock/+bug/521534 & https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/521536 | 21:39 |
| ubottu | Launchpad bug 521534 in cairo-dock "Please update cairo-dock to 2.1.3-3 version" [Undecided,Confirmed] | 21:39 |
| matttbe | or maybe someone else can help us? | 21:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!