[00:00] I have no objection to that, and I will happily add my concern as the first bit of feedback if that doesn't convince you to weaken your argument :-) [00:00] Oh. I don't think that this process solves the problem of not having stuff stored in a useful location. [00:01] * Hobbsee wonders where this wiki page is? [00:01] https://wiki.ubuntu.com/UbuntuDevelopment/News [00:02] james_w, I took Edgy mostly off (well, X wouldn't start for about 3 months). When I came back, things were a little different. [00:02] well, I wasn't going that far, just that it makes it harder for just any developer to send the mail to -devel-annouce. The wiki page means that even if those who initially agree to shepherd the process disappear there is nothing lost [00:02] Having a list of news-type postings wouldn't have helped me much. [00:03] ah, thanks [00:03] lists.ubuntu.com has full archives of all submissions to the news team. [00:03] persia: hopefully that will be one thing we can discuss at Hobbsee's UDS session, or at least during UDS. [00:04] persia: any objection to me adding a note that no-one has actually asked the news team yet? [00:04] james_w, That works for me. [00:04] No. [00:05] james_w: indeed. [00:05] james_w, So you're thinking intro in the next MOTU meeting, chatting at UDS, and decision in the following MOTU meeting? [00:05] Hobbsee's UDS session ? we're discussing Hobbsee ? [00:05] where can i subscribe ? [00:06] ogra: yes, clearly we're discussing how much I suck. i'm sure certain flamers will be delighted to attend... [00:06] persia: well, that feels heavyweight for me. I don't feel we need a MOTU decision about this. [00:06] oh, i thought we can dress you up in funny ways ... :) "wear these shoes with that hat i just found online" [00:07] ogra: oh dear... [00:07] persia: If you wish to ask for one that is fine [00:07] james_w, That wiki page says "Will be introduced at the 28th November MOTU Meeting". I didn't add that part. [00:07] ogra: https://blueprints.edge.launchpad.net/ubuntu/+spec/retaining-ubuntu-developers [00:08] Personally, I think it's nice to discuss things at MOTU Meetings. [00:08] my proposal to the lists was going to be that if there was no clear consensus on on the wiki page soon then I would just ask for volunteers to go the news-team route [00:08] Hobbsee, subscribed [00:08] ogra: oh dear ;) [00:08] :) [00:08] the MOTU meeting just gave a nice milestone at which to make that call. [00:08] * Hobbsee is apparently going to get the entire development team subscribed to this. [00:08] perhaps i'm just going to get lynchmobbed at the end? [00:08] we can add it to the agenda if it is desired [00:09] persia: Since you will be offline for a while, what is your position re your merges? Do you want them taken care of? [00:09] james_w, OK, although we've had a lot of fairly dead-end ML discussions recently. I'd like to get back to the relatively quicker route of using MOTU Meetings to quick review/approve/proceed with basic stuff [00:10] persia: yeah, I was trying to avoid a long ML discussion, by having a short non-ML discussion and calling your proposal the winner if we didn't get anywhere [00:10] TheMuso, I should only have lash (which is annoying tarball-in-tarball) and matchbox-window-manager (which stefanlsd already did) outstanding. freqtweak still shouldn't be merged, unless someone wants pain. There's a couple useful bits in debian, but no code patches. [00:11] matchbox is uploaded [00:11] TheMuso, If I get new ones, and someone grabs them, I won't complain (this is a standing policy: excepting freqtweak, I don't really care if people upload stuff I uploaded last, and freqtweak is mostly special because the Debian tarball is so ugly, and it's orphaned, and nobody has made any useful improvements. [00:12] james_w, Ah. I was waiting to look at the BTS entry, but thank you. [00:12] persia: Ok fair enough. [00:14] And I won't actually cause the pain to anyone merging freqtweak: they just get to try to track down the very different ways Bart and I chose to work with dead upstream, and figure how just how many of my patches Bart finally applied, or whether some bits are missing. [00:14] * persia should really try to adopt it again: it's been long enough that maybe it won't get blocked this time [00:25] persia: thanks for your help [00:25] yeeehaaaw! the upload worked, and the lintian issue I had earlier has been resolved! [00:26] now all that's left as far as issues are concerned is my changelog... apparently something is "missing or invalid" [00:26] Did you use dch --create to create your changelog? [00:26] oh, when was I supposed to do that? [00:27] That's the preferred way to construct debian/changelog [00:27] it has a changelog included in debian/ [00:28] stefanlsd, bug 506352 looks perfect. Well described and well tagged. Thank you very much. [00:28] Error: Launchpad bug 506352 could not be found [00:28] JonReagan, Right, but you got a complaint that it's missing or invalid. I'm guessing there's something funny with that changelog. [00:28] Hobbsee: still around? [00:28] james_w: yes [00:28] Hobbsee: on to point 2 in your brainstorm.txt :-) [00:29] ah, k, thanks... I remember seeing a page for the changelog on the wiki. I'll give that a look [00:29] JonReagan: hurrah! [00:29] james_w: woot :) [00:29] Hobbsee: "- Wiki documentation!" <- what do you mean by that? [00:31] james_w: kinda the news stuff that was being discussed earlier, and a bit that I mentioned yesterday about the triaging with jono [00:31] james_w: we need a good way of saying 'Here's the latest information you need to know, in digest form' [00:32] by digest do you mean like a diff from when you last knew everything? [00:32] james_w: most of hte discussions happen after long threads on the mailing list, and don't get put somewhere where someone can take 10 minutes to read and think on what's been decided, and remember it [00:32] james_w: maybe it should be something like "major decisions / changes made in " [00:32] and just keep updating the wiki page [00:32] hmm, I'm having trouble seeing how that is different from the news stuff [00:32] we don't actually have that many, iirc - but stuff like the maintainer field change, which has changed again. [00:33] i don't think it is, as such, except that I thought you were sending out the news in chunks, whereas what I was thinking was one page that routinely gets updated after every major decision. I think one would be taken from the other and sent out :) [00:33] for that one you just get it pointed out the first time you get it wrong :-) [00:33] (i think they're both needed) [00:33] well... [00:34] * Hobbsee wonders if you can rss-ize wiki pages. [00:34] that was my proposal for how the news would work [00:34] right, yes [00:34] you can subscribe by mail on moin [00:34] it was a rather unedited brain-dump. [00:34] . o 0 (email2rss?) [00:34] james_w, The issue is that the news thing serves a slightly different purpose. [00:34] but i do think it's important to have a listing where one does *not* have to chain thru bits of mailing list archives to read them, too [00:35] james_w, The "Today's best practices" document is more useful, especially if it's fed to everyone every cycle, and required to be updated for major decisions. [00:35] content-wise, one would definetly be a subset of the other - in fact, the wiki'd version would probably be an amalgamation of all the posts that had been sent out [00:35] persia: perhaps we have a different idea of what the news thing would be then [00:35] It's not so much news, as a quick explanation of current practices and pointers to current Docs. [00:35] We maintained one up to Breezy or so, but then lost track. [00:36] persia: ah, I haven't seen that, does it still exist? [00:36] that's a point. i'd not realised that was persia's definition either :) [00:36] I'm having trouble seeing how it is different to the wiki though [00:36] What? [00:36] james_w: in my proposal? [00:36] I think the news thing is interesting from a news perspective. I'd like to see news. [00:37] I just don't think news solves the issue of maintaining a useful wiki page of knowledge or practices. [00:37] erm, sorry, typing too quickly [00:37] does the Breezy "best practices" document still exist somewhere, I would be interested in reading it. [00:37] My disagreement about new implementation is fairly minor, and only about the implementation. [00:37] I'm looking for it. [00:38] thanks [00:38] my other point was that the "current" state stuff is just the wiki documentation isn't it? [00:38] current state stuff? [00:38] Well, yes, but it would be nice to have a summary bullet page. [00:39] james_w: btw, if you're taking notes of this discussion, along with annotations, i'd apprecaite them sent to me, etc. [00:39] while there may be valid concerns about it being incomplete or hard to navigate that would be different to being something that would be missing [00:39] james_w: i'm not sure I'll be able to run such a high profile session completely on my own :P [00:39] Mind you, the wiki in general needs help, and many of the recent semi-incomplete revamps haven't helped (and I share responsibility for at least two of them) [00:40] I'm trying to grasp if there is something missing, or it is just insufficient effort in maintaining the wiki. [00:40] james_w, The part that's oft considered "missing" is the "Well, I've been away for a while: how do I get started again" page. [00:41] and I'm also having trouble envisioning what would be on the "summary bullet page" as opposed to a general wiki documentation index. [00:42] persia++ [00:42] persia: in what ways does a list of the decisions taken and new tools, processes, and best practices not provide that? [00:43] (damn, just noticed a thinko in my mail) [00:44] james_w, It's a TLDR thing. [00:44] james_w, You're entirely correct, but the trick is to make it look trivially easy, rather than wading through history. [00:44] persia: TLDR? [00:44] I'm also very much not convinced that some things would make that news, as they happen gradually enough nobody notices unless they've been away for a while. [00:45] Hobbsee, Too-Long-Didn't-Read. [00:45] persia: oh :) [00:45] * persia almost never suffers from that problem, but knows that many do, and avoiding it is key to making something that looks useful [00:45] hmm, a way for someone to catch up on all changes in a certain time frame without at least looking over a list of the changes within that timeframe? neat. [00:46] james_w, Right. It's a bit of a snark [00:46] james_w, The two easy solutions are 1) don't change anything (people change, not gonna happen) [00:46] i think it's meant to be written "tl;dr" [00:47] some things not making it is a valid concern though. I'm not sure any process will easily capture things happening too slowly to notice. [00:47] 2) Create a semi-accurate short summary document "Jaunty Development is different than Intrepid Development in these four ways". [00:47] That's clearly incomplete, but satisfies the desire for understanding. [00:47] james_w, And no, it's not a substitute for the wiki being dredged properly. [00:47] persia: I agree with your two points. That is one role that I see the news things filling. [00:48] And to me, it's completely separate from news. I'd like to hear more about what people are planning and doing, but that's not process and the like. [00:49] Intrepid was released on this date, here is a list of things that happened since that date, each a title and one paragraph with links for more information seems like a good way to organise it [00:49] james_w: i don't *actually* think there's that many decisions that get taken, in a cycle, on a technical note, for things that are required for later releases. dh_icons, major X dependancy changes, mono changes, maintainer field changes, that kind of thing was what I was imagining. Were you thinking of other type of things apart from that? [00:49] See, I want news to have things like "We've decided to move to X 1.6, with the following implications" "The new armel port is underway, has these outstanding issues, but is otherwise in fairly good shape" "OpenJDK will now be the default Java for Ubuntu, so everything should be aligned to work with that". [00:49] persia, i'm planning and doing things. perhaps you've hard of them? :p [00:50] directhex, Yes. you sent mail. Thank you. [00:50] Hobbsee: in my head it would be a superset of those things, including the things that persia lists. [00:51] james_w, None of these are interesting to someone who has been away for 6 months, as they're mostly done, or not actively important. What is interesting is "There's a new team called UUC" or "We can do normal uploads or bzr pushes now" or "Soyuz *finally* supports orig.tar.bz2, so don't bother re-wrapping the source". [00:51] skimming the titles would hopefully allow you to quickly see "dh_iconcache is deprecated, use dh_icons" and read that, but skip over "OpenJDK will now be the default Java for Ubuntu" if you don't work on Java packages. [00:51] It's not whether one works on Java packages. [00:52] It's that it's not even interesting to someone who does work on Java packages who's been away for a while. [00:52] it's obvious from looking at the state of the stack. [00:52] james_w: right, yes. [00:52] and with the list of everything it would be easier for interested parties to compile the list of things that affect the workflow [00:52] armel is news today. In 6 months, it won't have mattered. [00:53] Oh, sure. The news can be a source of input to a "What changed" wiki page, and an important one. I just think they are different. [00:53] persia: if it is obvious, how hard is it to skip it? [00:53] james_w, You're missing my point. [00:54] The problem is not that the information doesn't exist. [00:54] It's easy to collect by skimming the ubuntu-devel@ archives, reading the ubuntu-devel-announce@ archives, and going through the MOTU Meeting minutes. [00:55] Sometimes it's worth going through the CC and TB minutes also, but those usually have slightly less effect to most developers (with a few key exceptions). [00:55] The problem is that people don't want to read that. [00:56] ok, I would say that the list of news items would provide an acceptable granularity to me. [00:56] james_w, I understand that. [00:57] given the opposite, but lesser, concern that too much filtering will lead to things of interest to someone being left out. [00:57] Most of the old devs who swing by need to be caught fast. Anything that doesn't fit in a quick span of vague attention will get skipped ("Bah, too much changed"), unless there's some external motivation to engage again. [00:58] There have been a few who went away and came back. [00:58] and I'm satisfied if work on the news project can make it easier to achieve what you want. [00:58] There have been many who went away, came back for a day or two, said hi, asked a coupe questions, and left saying it was confusing. [00:58] I don't think the news archive would serve them, and there's few others who would clearly benefit. [00:59] james_w, Um. Firstly, I don't really care if this exists. I'd rather have a "current best practices" document than "changes since when", and to push it to everyone every few months. [00:59] james_w, Also, I think there's *huge* value in news regardless of this other thing. [01:00] My only objection is that I don't think news in-and-of-itself addresses the request. [01:00] ok, I can accept that [01:00] would your "best practices" thing be like the dev-ref, but more useful? [01:01] james_w, Shorter, more based on variation from current Debian practice, and more useful. [01:01] ok [01:02] Whlie there's lots of people who don't come from Debian, it remains a great source of documentation, and I think listing things like "Everything is maintained by teams, and the current maintainer string should be taken as guidance rather than restriction" is more useful than "Ubuntu is collaborative, and works on the basis of collected and contributed patches by interested parties". [01:03] Writing that takes a bunch or work by someone (and I'd still like to find the old one), but it's punchy, and if we make it a practice to put all significant choices and decisions there, it becomes a useful reference, even if much of it ends up being pointers to more verbose explanations. [01:04] * james_w nods [01:05] Hobbsee: another one for you :-) [01:05] Anyway, I'm not especially promoting that right now, as I don't have the idea for it strongly enough to start drafting something. [01:05] Hobbsee: "- Decrease sponsorship times, for various teams" [01:05] persia: yeah, it sounds like something I would like to see, but I don't want to walk down that path just now. [01:09] james_w: hmm? [01:09] Hobbsee: sorry, I mean I'm not sure what you mean by that. [01:09] reducing time from subscription to upload [01:09] james_w: the sponsorship queues can get very long [01:10] I thought you might mean people feel like they have to spend too much time sponsoring [01:10] oh [01:10] Frustratingly, when the sponsoring queue is in the 30-40 range, there are lots of sponsors. When it gets above 50, it seems all sponsoring mostly stops for a while. [01:10] hadn't thought of it that way [01:10] or perhaps that applications took too long to process [01:10] Probably just needs work on how we organise sponsoring. [01:11] just delete items if it threatens to hit 50? [01:11] No. [01:11] damn [01:12] I've gone through it about 10 times and pushed out non-debdiffs to get down to the magic number, but people kept yelling at me for that, so I stopped. [01:12] heh [01:12] i liked that solution too :P [01:12] and shoving debian stuff out of the queue, after it was already in ubuntu [01:13] The idea was to add a tag to them, and have interested contributors use that tag to make debdiffs, which seemed to work, but generated a lot of bugmail, and annoyed some patch authors who didn't know how to make debdifs, and didn't espectially want to learn. [01:13] * james_w notes that the universe queue is at 49 [01:13] james_w, Thank you for that. [01:13] without pruning stuff that shouldn't really be on there [01:14] * persia isn't sure if this is good or bad. [01:15] Either we're not getting that many submissions, or there's been an immense amount of work done. [01:16] it's dropped by almost 100 in the last week [01:16] What's your guess on merges vs. bugfixes by count? [01:17] i have a question I was hoping to get some help with, i am fairly new to all this [01:17] 90% merges/syncs of the newer items [01:17] serialorder, What's the question. [01:17] (i.e. anything added since Intrepid) [01:17] i am attempting to apply to create patch a simple bug fix and repackage [01:17] james_w, Right. That means we're not getting enough submissions. [01:18] serialorder, Excellent. That's why we're here. [01:18] Have you determined which patch fixes the bug? [01:18] that part went fine but just out of curiosity I ran licensecheck -r --copyright . and noticed there are several copyright holders listed in the output that are not in debain/copyright [01:18] serialorder, Which package? [01:19] uml-utilities [01:19] serialorder, That's probably not worth fixing directly, but it is worth filing a bug about it. Extra points for filing the bug in the Debian BTS. [01:19] persia: 250 sponsored uploads this week, which is around average I think [01:20] ok so i will file a bug about it [01:20] I think that number is right [01:20] james_w, Roughly, yeah. [01:20] are you saying I should file in both or only Debain BTS [01:21] serialorder, I like both linked, but lots of people would say only the Debian BTS. [01:21] ok, thanks for the help persia [01:21] It's not something we fix in Ubuntu for packages in Debian, except in very special cases (e.g. where one of the missing authors complains). [01:21] So the only reason for the Ubuntu bug is to track the Debian bug, and maybe provide an announcement in case anyone wants to complain. [01:22] oh ok, that is good to know [01:22] this can all be a bit daunting at first [01:23] serialorder, The basic rule is: if it's a package only in Ubuntu, we fix everything we can for every upload. [01:23] If it's a pacakge also in Debian, we mostly concentrate on bugfixes, or adjustments to make it work better in Ubuntu. We send all the bugfixes also to Debian and upstream so everyone benefits. [01:24] The exceptions are usually for release freezes of one sort or another, where certain types of uploads become restricted. [01:26] if the fix closes a bug I am supposed to include something like (closes: #) in the change log correct? [01:26] LP: #nnnnnnn [01:26] closes: is used to close Debian bugs. [01:27] thanks , i thought it did'nt look right [01:29] james_w, My apologies, but I'm not finding it. I've looked through about 1000 wiki page titles, and maybe 75 pages, but I think it's gone. [01:30] persia: no problem, thanks for looking :-) [01:30] I remember it mentioning the GCC ABI change, and the X libraries transition, and stuff like that. [01:30] persia: if you ever stumble across it I would like to see it [01:30] Sure. [01:30] Problem is that it takes about a month (straight) to read the wiki, so it's easy to lose stuff. [01:31] I've still not actually finished processing https://wiki.ubuntu.com/MOTU/WikiCleanUp/SomeReviewNotes [01:32] That it exists still, the date it was last edited, and the number of referenced pages that still exist are a good indication of just how much cruft is there. [01:42] Is there somewhere I can read up on what clean-la.mk is trying to fix? [01:42] does it just make .la files less useful, but make dependency management easier? [01:47] Aargh. Must not reply to mono troll on ubuntu-motu@ [01:47] RAOF: yes, you musn't. I already got a lovely reply to *my* mail to him today. [01:48] (Hopefully by putting that determination in the public sphere, I'll be able to actually resist) [01:48] RAOF: yes. Try very hard not to feed the trolls. Go find beer instead ;) [01:49] Hm. I suppose the sun /is/ over the yardarm... [01:54] james_w, My (vague) understanding is that it's trying to avoid .la files, and discourage both use and the possibility they might be used at build time to make dependency chains more sensible. Unfortunately, I don't know of any good doc about it. [01:55] persia: ok, thanks. [01:55] I'm looking at a sponsorship request, and whether to forward the change to Debian [01:56] Which one? [01:56] the changelog entry when it was introduced was about "fixing" the .la file, which makes it sound like something that should be, but I'm pretty convinced it's not something to forward [01:56] though it seems a little odd to do it on a per-package basis [01:57] bug 299350 [01:57] Launchpad bug 299350 in libnxml "Please merge libnxml 0.18.3-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/299350 [02:01] james_w, I'll agree it's odd to do on a per-package basis. On the other hand, I can see iulian's arguments, and think that including that is useful. [02:01] .la based dependency chains get *very* annoying. [02:02] I guess if it involves packaging modifications not appropriate for Debian to cope with the stripped .las anyway then we wouldn't gain anything by doing it for all packages [02:02] The per-package basis might be to preserve those cases where we *need* .la files, or it might be part of an attempt at a gentle introduction to Debian. [02:03] I think current Debian practices to reduce dependencies are moving in different directions (from what small bits I see), but until there's a reduction in the Debian pacakge itself, it probably has some value. [02:04] I wouldn't forward this patch to Debian, personally, it's far too awkward, relies on Ubuntu infrastruture, etc. [02:04] yeah, I just wondered if the "fix" was a "fix", and so we should send a bug report. [02:06] Well, yes and no. [02:06] It's a "fix", but it's not clear if the problem being fixed either exists or is important in Debian. [02:09] pitti or slangasek would be the experts on this. My main argument against sending it back is that I can't find a bug for clean-la.mk on CDBS. [02:09] I'd presume that if that were applicable to Debian, it would be there. [02:12] pff, name droppers. Can someone give me some summary context? === ubott2 is now known as ubottu [02:14] james_w: so what clean-la.mk does is munge the .la files in the installed package so that there are no dependencies. It has been debated whether this is a correct thing to do, but the strongest opponent to it is Keybuk, who won't stand in the way of pushing it to Debian if that's the question [02:15] slangasek: the question boiled down to whether using clean-la.mk indicated that there was a bug in the package that should be reported to Debian [02:16] are you asking whether a patch should be forwarded up to Debian to /use/ clean-la.mk, or are you asking whether the use of clean-la.mk implies bugginess in the package? [02:16] The latter [02:17] then no [02:20] thanks slangasek [02:21] is a debian/watch file necessary for a package? [02:21] JonReagan, It's very strongly recommended for packages that are not also in Debian, so we can more easily track when a new upstream is available. [02:22] ah... k, thanks. [02:22] If a debian/watch file cannot be constructed, please construct a get-orig-source rule. [02:22] bug 299353 is an interesting one [02:22] Launchpad bug 299353 in libkipi "Please merge libkipi 0.1.6-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/299353 [02:22] Many reviewers will not advocate a package without one of the two. [02:22] persia: thanks [02:23] * persia seems to remember being disturbed by libkipi previously [02:23] the -common package is gone, so the libpackage should ship its own icons, but that would seemingly make libkipi0 and libkipi5 not co-installable. [02:25] and a quick glance suggests to me that removing libkipi0 is tied up with the KDE4 transition, so I'm not chasing that rabbit [02:26] ok persia I have another question [02:26] I'd be suspicious of that. Last merge by that merger I reviewed was a thoughtless copy&paste. [02:26] serialorder, Just ask generally. I could have fallen asleep by now :) [02:26] well i saw you typing away [02:26] but point taken [02:27] persia: suspicious of what? [02:28] james_w, Suspicious of the merge because 1) it's adding a dependency to a package that doesn't exist, and 2) I had a poor experience with the last merge from the same person. [02:28] (that was last week or earlier this week or something) [02:29] oh, that's always a good one. [02:29] * Hobbsee encountered that a while ago, but then discovered an out of date cache. [02:29] persia: yeah, I'm talking about what should happen, the proposed debdiff is certainly wrong [02:29] the package I have been working on, uml-utilities was never synced in hardy or intrepid, last version that has an ubuntu specific build is in gutsy [02:30] when I post the fix to this bug should I also create a sync request bug as well? [02:30] james_w, Well, there are two options. #1) unsub the sponsors and leave a comment saying what should be done, or #2 (my favorite) do it yourself, ignore the debdiff, and close the bug. [02:31] I often attach the correct debdiff to a bug so that the merger can examine the difference, and include a paragraph about why it was completely wrong. [02:31] persia: I'm trying to do number two [02:31] This is just a clear case of trusting MoM. [02:32] I'd be tempted to sync, if that's the outstanding change [02:32] james_w: libkipi-common is gone? [02:32] * persia looks harder at the debdiff [02:32] No, it's there. I read rmadison wrong. [02:32] james_w, Ignore most of what I've said. [02:32] Hobbsee: I looked at the last upload of the source package [02:32] ...that used to provide it [02:32] * persia goes back to the list of things that are annoying, but must be done, rather than making more mistakes here. [02:33] has it moved? [02:33] libkipi-common | 4:4.1.2-0ubuntu3 | jaunty | amd64, i386 [02:33] persia: er, that'd be old [02:33] kdegraphics | 4:4.1.3-1ubuntu1 | jaunty | source [02:33] james_w: would be right, there, and it needs to be NBSd out [02:35] * persia tries harder to avoid making mistakes by stopping typing [02:35] Hobbsee: I'm trying :-) [02:35] it would have been uploaded by now if the solution was obvious [02:35] heh [02:36] libkipi0 Depends: libkipi5? [02:39] where? [02:39] no, that's my suggestion [02:39] oh [02:39] libkipi0 would then have the icons it needs installed [02:39] they would still be co-installable [02:40] and builds would still work as the -dev symlink wouldn't change [02:40] it does make me want to take a shower though [02:41] er, is making the kde3 version depend on the kde4 version a really wise move? [02:41] oh, there's a kdegraphics-kde4 [02:41] you can ask that in #kubuntu-devel, anyway [02:42] ah, not any more [02:42] james_w: there was, anyway. it's been phased out, afaik. [02:42] when we had the emss of 2 kdes. [02:42] if the packages aren't co-installable then it would make it impossible to install some kde3 apps on jaunty [02:43] im going to try asking this one more time [02:43] the package I have been working on, uml-utilities, the upstream version was never synced in hardy or intrepid, last version that has an ubuntu specific build is in gutsy [02:43] when I post the fix to this bug should I also create a sync request bug as well? [02:44] oh, sorry serialorder, missed your question [02:44] serialorder: I don't see a new version in Debian we can sync [02:44] http://packages.ubuntu.com/source/uml-utilities [02:44] but you mean update to the new upstream version [02:44] that is where i am looking [02:45] maybe that is the wrong place? [02:45] or im using the wrong words [02:45] "sync" has a specific meaning in Ubuntu, usually to pull in a version of a package from Debian [02:45] in this case we have the same version as Debian, so there is nothing to sync [02:45] if there is a new upstream then it would be possible to update to that though [02:45] ok maybe i am confused then [02:46] is there a reason the versions in hardy and intrepid dunot have an ubuntu ending? [02:46] james_w: Wow, I probably should've thought about that. Thanks for cleaning up the formatting :) [02:46] (re: ubuntu dev news) [02:46] Yasumoto: no problem [02:47] Yasumoto: apologies if I munged your meaning at all [02:48] not at all, thanks [02:48] james_w: I think im confused then, is there a reason the versions in hardy and intrepid do not have an ubuntu# ending? [02:49] james_w: they're coinstallable, no question, it's just whether one should be able to remove the kde4 version if desired that is the question [02:49] * Hobbsee apparently can't type today [02:49] serialorder: that means that the package is unmodified from Debian [02:49] are those only introduced when there is a bug fix introduced in ubuntu but not upstream [02:49] ahhh ok [02:49] Hobbsee: yes, but a sync would mean they were no longer co-installable. [02:50] Hobbsee: and given that ubuntu is now kde4 I'm not sure why you would want to remove a kde4 lib from your system [02:50] james_w: point taken. [02:51] james_w: unless you ran it on gnome, and didn't want more kde deps than you absolutely had to have. [02:51] I agree it's not nice, but neither is a lib shipping images [02:51] it being stuff like digikam : that's a real scenario [02:51] debian should be able to be reasoned with, though. [02:51] james_w: last question, so if i applied a patch and rebuilt to resolve the bug then in launchpad all I need to do is attach the debdiff and subscribe sponsors right? [02:51] but if Riddell dropped -common then he may have a plan [02:51] they're pretty good, there, and the kde guys have connections [02:51] RAOF: thanks for being so patient/helping me merge :) [02:52] serialorder: correct [02:52] sweet thanks! [02:52] Yasumoto: No problem. You noticed that I added another missed remaining change to the changelog, I guess? [02:52] Hobbsee: I'll talk to someone in the morning. Thanks for your advice [02:52] james_w: you're welcome. [02:54] RAOF: yeah, thanks for catching that [03:00] Where can I find out how to package something, where the original source package format is a .zip ? [03:00] Not a .tar.gz or tar.bz2 as is "normal" [03:00] jmarsden: unzip, tar & gz it? [03:01] afaik, there's no actual 'difference' than it would be with a normal package [03:01] I can,. but I think there is supposed to be a way to do it... http://www.debian.org/doc/maint-guide/ch-first.en.html says you can but it "takes more knowledge..." ? [03:01] hmm, libkipi5 doesn't Conflict/Replace libkipi-common [03:02] isn't that required for moving files between packages? [03:02] the changelog says "(add conflicts/replaces)" but it doesn't add those ones at least [03:02] * Hobbsee notes the possibility of a bad merge [03:03] but, you'd think so? [03:04] jmarsden: i presume that means for things like sources in git / bzr / etc [03:04] where you're doing a checkout [03:04] i can't imagine zip files should be on that list [03:04] * james_w stops looking and will wait to ask someone more knowledgeable [03:05] OK. I just thought that by unzip and tar I'm making an undocumented and un-automated change to the original sources "tarball", in a way... if it's Ok to just do that, then I'll just do that :-) [03:06] The guide says things are compicated if ... "the source file format being neither in tar.gz. nor tar.bz2" ... [03:06] jmarsden: that's true. [03:06] jmarsden: I *suspect* it's just an oversight of the guide. [03:06] OK, thanks. [03:07] jmarsden: but yes, document that you did unzip and tar it, so people will be able to figure out why they can't find an upstream tarball ;P [03:07] OK :) [03:07] certainly fro stuff like bzr & git, you want to ignore certain directories, etc. [03:07] which would require more knowledge [03:31] jmarsden: It doesn't _have_ to be an undocumented, unautomated change to the original sources; you can easily automate this in a get-orig-source rule in your debian/rules file. [03:32] RAOF: OK... sounds like what I was thinking of... any quick pointers to examples of that or a tutorial or something? [03:32] https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball [03:32] Thanks! [04:14] Can some motu take a look at http://revu.ubuntuwire.com/details.py?package=teamgit [04:14] it has already received some prilim review [04:22] hey guys, could someone please tell me why this happens at line 70? http://paste.ubuntu.com/75079/ [04:22] dpkg: dependency problems prevent configuration of pbuilder-satisfydepends-dummy: [04:28] x1250: I'd guess the problem is that you don't have universe enabled in your pbuilder chroot. [04:31] RAOF, right. Thanks. [04:50] I have been looking at harvest and found a package called moodbar has a patch from fedora for it. [04:50] How do I figure out what the patch does? [04:51] The patch is found on the fedora website. [04:51] Here: http://cvs.fedoraproject.org/viewvc/devel/moodbar/moodbar-0.1.2-glib.patch?view=markup [04:52] I would like to learn to patch packages but am sure in the changelog you want to state why the package is being patched. [04:52] Or do I just say something like: "patched with fedora patch"? [05:05] You'd _definitely_ need to know what the patch does before doing anything else. [05:05] As for how to work this out... it depends. If they've been nice and documented it, the patch should have something telling you what it actually does, or a reference to a bug to follow up, or somesuch. [05:06] If it _doesn't_, then you need to use initiative; see if you can read what the patch does. See if you can find the first time the patch appeared in the Fedora package; what bugs did that release fix? Etc. [05:11] RAOF, thanks. This is what I needed to know. I was just wondering if fedora had an official way of documenting their patches and thought if so you guys would know about it. [06:01] jsmidt: Now that I've actually _looked_ at the patch, it's obvious what it's doing, and I'd guess we don't need to (or have already) apply it; if we didn't have something like that, moodbar would be quite consistently crashing. [06:04] RAOF, okay, thanks. [06:05]