[02:20] hello [02:20] im building a deb to hopefully be included in ubuntu [02:20] i am making an ant file for the package [02:21] my pacjage depends on swt-gtk, and needs it to compile [02:21] should i refrence where apt put the swt lib in my ant file? [02:21] or should i include the lib? im pretty confused [02:21] You should reference the system library. [02:22] ok, thanks [02:22] Ideally, your package won't contain any libraries, and just use the system libraries. [02:22] aye, i made one that does that [02:22] but i was told i did it wrong [02:22] 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] and i got to use dh_make and all this stuff [02:22] Please don't use dh_make :) [02:22] ok [02:23] i have a java app i want to package [02:23] can you tell me the most straight forward way to do it? [02:23] i have 100 conflicting answers so far [02:23] Hrm. [02:23] So, I have an opinion as to which I think to be the easiest. [02:24] But that's not necessarily the easiest for *you* [02:24] please to share it :) [02:24] ah [02:24] There's no true way to package :) [02:24] As long as the result package is policy-compliant, it is correct. [02:24] do i have to submit source and a make file so ubuntu can compile it? [02:24] i cant just submit a jar? [02:24] :S [02:24] I tend to recommend not using dh_make because it leaves around lots of extra files and sets some incorrect defaults. [02:25] 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] ah [02:25] so the idea is to submit a source package with directions to build and install? [02:26] Well, directions to build/install, licensing documentation, and hints on how the package relates to other packages. [02:26] i see [02:26] We encode these in the debian/rules, debian/copyright, and debian/control files. [02:26] ok, so i hsould have rules call ant? [02:26] We also have a debian/changelog file that tracks changes to the package. [02:26] Right. [02:27] 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:28] http://openactive.org/pastebin/paste/show/6 [02:28] does that look ok for rules? [02:28] 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:29] You'll need a clean: rule. [02:29] clean: should return the package to the state it was in prior to the build. [02:30] This usually involves a call to `ant clean` or similar. [02:30] ok thanks [02:41] 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:43] nigelb: Why were they removed? [02:43] we moved to a newer version [02:43] in lucid the version is sugar-0.88 [02:43] but there are a bunch of .84 and .86 packages in failed to rebuild queue [02:44] That's confusing. Why do the package names change for a version change? [02:45] I have no idea :( [02:45] sugar seems to have names based on version, sugar-0.84, sugar-0.86, sugar-0.88 [02:45] 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] lfaraone: thoughts on this ^ [02:46] since you're on the sugar team :) [02:46] persia: I'm out of anything I can understand on umet deps and failed to rebuild :( [02:47] 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] I'll take the first unmet dep then [02:47] lemme load up the chroot [02:53] nigelb: Uh, .86 was re [02:53] *removed? [02:54] nigelb: That seems odd, since .88 is still not out yet (.87 will eventually become .88) [02:55] lfaraone: appologies, 0.84 was removed [02:56] nigelb: so what ftbfs? [02:56] some thing that depends on .84 [02:56] hold on, I'll get the exact packages [02:57] sugar-chat-activity-0.84 and sugar-read-activity-0.84 [02:59] lfaraone: Do you know why these packages have these names instead of e.g. sugar-chat-activity ? [02:59] (at a sourcepackage level: binary is entirely different) [03:00] persia: because it's an activity (what sugar calls Applixations) and it is called Chat. It only works with sugar. [03:00] it makes it a bit different hunting through LP for it, I went by pure instinct [03:00] Oh, didn't see your earlier message. [03:01] 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] and is there a strong reason to support this? [03:01] No idea, that's imported from Debian. I haven't done much work on sugar packaging in a while [03:01] persia: we can't have it anyway [03:01] because the main build deps are not around [03:01] nigelb: That's a different issue. [03:02] persia: Well, the Peru and Uruguay deployments are on .84/.82, so no. [03:02] Debian does support parallel Sugar versions. [03:02] Yes. I just don't understand why. [03:02] persia: Because the maintainer, Jonas, decided to do so. [03:03] Oh well. [03:04] um, so what can we do now? [03:04] 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] nigelb: Remove the packages which depend on .84. [03:08] will file a bug [03:11] lfaraone: take a look at this http://paste.ubuntu.com/386038/ [03:11] should I request removal of the entire bunch? [03:13] nigelb: Nock yourself out :) [03:13] lfaraone: another of my doubts is, when sugar-0.84 is already removed in lucid, why is it showing in my apt-cache [03:15] nigelb: because it's cached :) [03:15] ah, so I only request removal of the ftbfs? [03:21] 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] persia: on grepping unmet, I find a bunch of sugar packages [03:21] 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:22] dont I have to file a request for each package individually? [03:22] mozilla team was already going to remove sugar-browser-activity-0.84 nigelb [03:22] 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] s/remove/request removal [03:22] ah, well, yaay, I found something to do ;) [03:22] micahg: I'll do it for ya :) [03:24] micahg: sugar browse 0.84 isn't already removed? [03:24] I dont see it in my cache [03:25] im looking at an exmple rules file, to build it issues ant -f build/build.xml [03:25] for clean it calls the ant task clean that deletes ${build} [03:25] wouldnt that delete the build.xml file? [03:25] [03:25] that means /build in the root? [03:26] oh [03:26] its create /build/build, sorry [03:27] mohadib: /usr/share/perl5/Debian/Debhelper/Buildsystem/ant.pm has build.xml in ./ which makes me think this is a common practice. [03:28] okay, in case of deletion, I follow the same procedure as sponsorship? (since I'm not yet MOTU) [03:28] Yes. [03:28] thank you :) [03:29] bug 529824 good enough? anything more I should be adding? [03:29] 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] nigelb: yep, already gone [03:29] micahg: :) [03:29] mohadib: You may also find #ubuntu-java to be a better place for java-specific questions. [03:31] oh no! [03:31] I accidentally subcribed main sponsers instead of universe [03:31] ugh! how do I fix this ugly mistake [03:31] Just switch it over. [03:31] No big. [03:32] I cant remove the main guys [03:33] nigelb: Just sub univ, someone in main sponsors will sort it out. [03:33] okay, just did that now. [03:34] * lfaraone is out for the night. [03:34] lfaraone: good night :) [03:37] nigelb: Fixed [03:37] ScottK: thanks again :) [03:42] The epiphany-extensions-more is no longer being maintained and doesn't work with epiphany version in lucid, another target for removal? [03:43] 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:44] persia: but upstream says it won't work with epiphany 2.28 and above [03:44] and lucid version is now 2.29 [03:45] That'd be good enough for me. [03:46] nigelb: That calls into "cannot be fixed" :) [03:46] thats what I thought too! [03:47] persia: If it were possible to be be fixed, I'd bug you for teaching me how ;) [03:47] I'd be the wrong person: for that bug, I'd point at micahg [03:48] well, anyone who could ;) [03:53] nigelb: epiphany changed to webkit only with 2.28+ [03:53] nigelb: extensions were gecko based [03:53] micahg: so now, we end up having to remove it [03:53] micahg: it didn't work with karmic either I guess [03:54] nigelb: wait, it seems like the extensions were ported [03:55] micahg: oh? [03:55] the gnome site said, it work anymore and they use something new, which is extremely unstable [03:55] http://live.gnome.org/Epiphany/ThirdPartyExtensions [03:55] oh, nm, the regular extenions were, but the -more wasn't [03:56] yup [03:56] I did a thorough read :) [04:05] is this wrong? http://openactive.org/pastebin/paste/show/7 [04:05] the deb gets made [04:05] but my files are not included [04:05] just readme and changelog, stuff created by dh_build [04:07] ah, think i see the problem [04:09] hm no [04:16] mohadib: The last paste you had included a dh_install call. [04:17] mohadib: You probably also don't want to use the cp calls (especially because they install to an unsired location) [04:18] well, i changed to debian/syspage/ and it seems to do what i want now [04:18] is ok? [04:18] mohadib: creating debian/install with http://openactive.org/pastebin/paste/show/8 adding dh_install, and dropping the cp calls should work. [04:18] If it does what you want, it's OK, but it may not be best practice :) [04:19] no, ill do what you said [04:19] thank you [04:19] no point in getting into bad practices now [04:20] 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:21] 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:22] can i see how the files will be installed from a deb without installing the deb [04:22] like dpkg -L [04:22] dpkg --contents [04:22] ahh ty [04:23] that worked great, the dh_install thanks [07:21] 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] 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:22] Anzenketh: I can't see the patch in the bug report. [07:23] But in general patch testing consists of 1) download or unpack fresh source, 2) apply the patch, 3) build, 4) test [07:23] Yep I just removed it forgot to so I could change karmic to lucid [07:23] Anzenketh: how did you get the source? [07:24] dget -xu [07:24] 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] persia: So just run ./config make make install then launch it from wherever I find the binary. [07:24] um, no [07:25] 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] (or check debian/README.source for closer guidance : again this isn't always there, but it *ought* be) [07:26] ok will read README.source [07:26] the pdbuilder just though me though a loop [07:26] No clue what it is or how to use it. My familiary with debian-format packaging is close to none [07:28] Anzenketh: Then just ignore the packaging, except for applying patches. [07:28] Anzenketh: And if you're not doing the packaging, talking about patches in #ubuntu-bugs is likely more on topic. [07:36] persia: would it be okay if I just packaged it for him and gave credit? [07:37] Thanks for your help I will go read more of the wiki. [07:37] 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:38] e.g. "Patch to frob quux (thanks J. Hacker)" [07:38] ah, I'll get that done in a few [07:40] I almost got the fixed debdiff up there nigelb [07:41] 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] nigelb: Thanks for helping out the Reviewers team! [07:41] persia: are there any requirements to join there? [07:41] 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] I'm sure I can read patches well enough [07:42] 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] bah, uploaded [07:42] meaning, I should have upload rights or I should have uploaded packages? === NCommander_ is now known as NCommander === NCommander is now known as Guest88162 [07:43] nigelb: You should be capable of getting stuff uploaded. That can be directly or indirectly. Doesn't matter. === Guest88162 is now known as NCommmander [07:44] persia: I'll help out with a few of those ~2000 patches and apply to join :) [07:44] 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:45] nigelb: I changed the changelog. [07:45] I'm pretty much blind on Debian Development. [07:45] 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] I know. I have had this team in sights for something [07:45] persia: I think we need an easier process for new contributors. Like for fixing a proper bug from launchpad [07:46] I'm thinking of writing a small blog post based on this bug fix for future reference. [07:46] s/easier process/easier documentation [07:49] Anzenketh: okay, a few things you should remember for future. [07:49] 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] 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] this package for example, uses quilt. [07:50] persia: I will write a post of my own and ask for review to be included in the wiki. [07:50] which seems saner [07:50] Please work to fix what we have, rather than adding more. [07:51] Lots of different conflicting documents just confuse users. [07:52] okay :) [08:01] Are patching systems like quilt, cdbs used only downstream? Or does upstream use them too? [08:01] nigelb: Why would upstream use a patch system? [08:01] There's no good answer to that question :) [08:01] I'm just asking something that just popped in ;) [08:02] why is there no good answer? [08:02] So, we have some systems (cdbs-simplepatchsys, dpatch) that are only used in Debian and derivatives. [08:02] Other patch systems are more widely used. [08:02] nigelb: upstream as in Debian uses patch systems too, yes. :P [08:02] I counted debian as downstream too :) [08:02] It's upstream from Ubuntu's point of view. [08:02] since I *know* debian uses them [08:03] I should framed properly [08:03] Generally patch systems are used by various distributors who are *not* the original authors, or for release that are not trunk. [08:03] Ubuntu is downstream from Debian's point of view. [08:03] VCSs that support branches are often used for this as well. [08:03] like git having several branches [08:03] Rhonda: I wanted to ask from a debian standpoint. But I framed wrongly :) [08:04] I know one upstream that uses plain patch/diff as patch system, though. For carrying extra patches. [08:04] 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] ah, that pretty much answers my question and beyond :) [08:04] t-prot carries some patches in the "contrib/" subdirectory, even though the developer produces those patches himself. [08:05] 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] (except in special cases, as Rhonda notes) [08:06] Isn't there these php patches that are also distributed seperately that gets applied? [08:06] kishino or something like that? Never can remember the name. [08:08] There are. There's also sets of patches for MAME and vim that get developed as essentially separate upstreams. [08:08] (and likely several more cases) [08:09] It does get really murky then [08:09] btw, if the new patch tagging guidelines are out, why arent all the patches according to them? [08:10] persia, btw., LP #528957 about that sdl issue, it starts to pop up now from various places. :/ [08:10] Launchpad bug 528957 in wesnoth "mouse button clicks not detected in windowed mode" [Undecided,Confirmed] https://launchpad.net/bugs/528957 [08:10] 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] nigelb: Because it's a guideline and not a policy must and people are lazy. [08:10] Rhonda: It's all over the place :( Do you know if a good general solution is available? [08:10] persia: makes sense :) [08:11] 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] I see like 9 patches in the debian/patches directory and none of them are tagged per debian/ubuntu guidelines. Is that normal? [08:12] nigelb: Unfortunately DEP3 has little takeup so far. [08:12] 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] I'm going to tag if off anyway. [08:12] all the bugs I have worked on, I have tagged, going to keep tradition here [08:13] lool: Have you any thoughts on the matter? [08:13] 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] nigelb: Please do tag your patches. Please don't tag other people's patches arbitrarily. [08:13] persia: I dont have the patience to do that for others ;) [08:13] Excellent :) [08:14] Some people do, and it's always frustrating, because their tags are almost universally ignored or rejected when received. [08:14] Any members of SRU team around? [08:14] 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:15] slytherin: SRU is consolidated: check in -devel :) [08:15] ok [08:15] Submit such things back, maybe they are appreciated. :) [08:17] I have to learn debian bts one day [08:17] It totally scares me right now [08:18] 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] Erm, yes, that doesn't make sense, I agree. :) [08:19] nigelb: It's not that complicated, once you got around that it's mainly a mail interface. :) [08:19] Rhonda: I got that figured out only earlier today. :/ [08:19] 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:21] hello nigelb [08:24] Anzenketh: you need a little bit more of eduction with debian packing before you attempt to upload a debdiff [08:25] so, I would suggest uploading simple patches for now. :) [08:25] I was not planning on doing anything besides string-fixes [08:26] Anzenketh: even so. Take a look at my debdiff once I upload it. you'll understand what I mean. [08:37] 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:38] Ya the link you gave me on how to get started helped a lot [08:38] I found out what what-patch did [08:46] persia: on DEP3? [08:47] lool: On libsdl1.2 and bugs like 528957 [08:48] * lool loads [08:48] 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:49] Debian bug #565788 has some of the details, but I don't think anyone has really dug into it. [08:49] Debian bug 565788 in libsdl1.2debian-all "Upgrading SDL breaks Wesnoth" [Critical,Open] http://bugs.debian.org/565788 [08:49] 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] 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:50] I personally have many weirdnesses with mouse clicks [08:50] 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] I think that someone should talk with SDL upstream mentionning imminence of debian and ubuntu releases affected by this bug and perhaps others [08:51] lool: In apps other than wesnoth, but using SDL, or generally? [08:51] I'm not on top of sdl bugs, sorry; it fixed a static build issue for me [08:51] In one SDL app and generally [08:51] No worries. I was just hoping that you'd noticed when you merged. [09:09] Anzenketh: deleting your patch and uploading my debdiff [09:10] ok [09:11] nigelb: We usually leave the original patches in the bug for the historical record. [09:12] persia: oh no! [09:12] Ya it does look differnt. [09:12] persia: I'll make sure I dont do that next time. anything to be done now? [09:12] nigelb: Adding a comment when uploading your debdiff like "debdiff applying Anzenketh 's patch" makes it extra clear for sponsors. [09:12] nigelb: Just follow the same procedure as if you're getting your own fix uploaded. [09:13] I never wrote a simple patch :( [09:13] I never got to learn how to do that [09:14] Read revision 16 of Bugs/HowToPatch :) [09:14] (or any earlier revision, but 16 is the most polished before the attack of the debdiff instructions) [09:14] Attack of debdiff instructions? [09:14] Anything I can do now to rectify the situation [09:15] nigelb: Not really. Needs discussion. [09:17] 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] 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:18] yea, like patching system, tagging - all needs to get integrated [09:18] 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] 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:19] persia: yup. everyone generating debdiff should know [09:19] 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] That debate is not yet concluded. [09:19] In my case maco_ was kind enough to teach me. So i know. [09:21] persia: could you unsubsribe reviewers? I've subscribed main sponsers [09:22] No, but I'll see if I can fix things so I can next time :) [09:22] So if the current instructions are wrong what are prospective developers to do? [09:23] Anzenketh: Right now, prospective developers are told they have to learn how to make debdiffs. [09:23] And random folk submit random patches that the reviewers review. [09:23] persia: the reviews team wiki seems to indicate the same thing [09:23] nigelb: Which thing? [09:23] "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:24] Everyone is expected to use sponsorship. Not just give a patch. [09:24] Oh, yeah. [09:24] I personally disagree strongly with that. [09:24] I don't think everyone needs to do that. [09:24] It's too much work, and most folk just give up because it's hard. [09:24] exactly [09:24] that isn't fair to prospective contributors [09:25] I don't even know how to do the sponcership process. [09:25] 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] Directions on that are not verry clear either. [09:25] its pretty easy, once you have a debdiff, subscribe sponsors depending on where your package is [09:25] 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:26] 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:27] 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] The bug is still open for that somehow. [09:27] bug #82436 [09:27] Launchpad bug 82436 in gnome-app-install "wesnoth-all meta-package request (for gnome-app-install)" [Undecided,Confirmed] https://launchpad.net/bugs/82436 [09:28] * persia suspects that's really a bug in app-install-data-ubuntu [09:29] Or not. Seems I said gnome-app-install last time I investigated it :) [09:29] :) [09:31] * Anzenketh just relized what they ment by subscribe [09:41] 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] And this is unlikely to be fixed as a stable release update. [09:42] 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] I encounter it in my bugs page. :) [09:43] Which page? I think that's a bug. [09:44] bugs.lp.net/~rhonda shows it to me everytime I go there [09:45] It's the only five-digit bugnumber on my page. :P [09:46] Aha. It's there because you commented on it. [09:49] Rhonda: mvo is looking at it, and will apparently sort it. [09:56] persia: I commented it because it was also a wesnoth bug. :) [09:57] It's a bit annoying that one can add "also-affects" but can't remove that anymore it seems. :/ [09:57] Rhonda: we can :) [09:57] There's a bug open about that. [09:57] nigelb: No, we can't. [09:57] … [09:57] * Rhonda nibbles on nigelb. :) [09:57] nigelb: We can reassign, but never remove. [09:57] okay, so the last time I did that was quite a while back then [09:58] No, you've never been able to do it :) [09:59] * nigelb got confused with "also affects me" and and "also affects project" [09:59] Well, one could reassign to no package, but that just destroys (likely valid) history. [09:59] heh [09:59] * nigelb notes that Rhonda didn't really elaborate which affects-me it was [10:00] 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] 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:01] Rhonda: you have a clean bugs.lp page? [10:01] It's bug #204980 [10:01] Launchpad bug 204980 in malone "bug contacts should be able to unsubscribe from implicit subscriptions" [High,Triaged] https://launchpad.net/bugs/204980 [10:01] And bug #484319 [10:01] 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] nigelb: What do you mean with a "clean bugs.lp page"? [10:01] Rhonda: everything fix released only ;) [10:01] except for this one probably [10:02] No, but like said, this is the only 5 digit issue. :) [10:02] oh, is there a difference in number of digits for different bugs? [10:02] I never will have a clean page, that's totally out of scope with that much interests on my hands. [10:02] I didn't know [10:02] Sure, there is even LP #1 ;) [10:02] nigelb: fewer digits indicate older bugs. [10:03] oh, so this must be really old and ticking you off somewhat ;) [10:03] It in fact is because _I_ did my part of fixing the issue. :) [10:04] 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] haha [10:05] 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:06]