=== tuantub_ is now known as tuantub [00:53] How to extract a source package (to rebuild it) with dpkg-source [00:53] i get an error "public key not found" [00:53] ignore that error [00:54] but my package is not extracted [00:54] ha..... wait. [00:54] i think it's another problem. [00:54] my old dpkg-buildpackage replace the proper .dsc. [00:54] thanks. === nellery_ is now known as nellery === lukjad007 is now known as ShadowChild [02:24] superm1: I'm looking at http://www.dell.com/home/laptops and wondering what happened to Latitude laptops. Are they gone or just renamed? [02:24] ScottK, they're not for general consumer purchases, you have to come from a different entrance to the website [02:24] "For Small and Medium Business" [02:25] superm1: OK. Thanks. I guess I never saw the consumer version before. [02:25] Right. [02:25] latitude get worldwide warranty and stuff [02:25] consumer models don't [02:27] * ScottK has only ever had Latitude. [02:33] * masterkernel wonders if it has always been this quiet in here [02:36] it varies in here [02:36] when are most of the motu reviewers in here [02:38] probably during the day in the US or europe, I think [02:38] again, it varies [04:05] what does that mean? dpkg-shlibdeps: failure: no dependency information found for /opt/pdflib-lite/lib/libpdf.so.6 [04:06] What can I do for that ? [04:08] aboudreault: It looks like that means that something in your package is linking to /opt/pdflib-lite/lib/libpdf.so.6, and this file isn't being managed by dpkg, so dpkg-shlibdeps can't work out what package add to Depends. [04:10] How can I make it to be managed with dpkg ? [04:10] In fact, I did an apt-get source, added an option and tried to recompile [04:11] Ah. So, that's not actually being linked in to your package? [04:12] yes it is. because I've added a "--with-pdf" option to the package. So, now it's a dependency [04:13] So, this won't be a problem if you're just trying to make a local package. [04:13] Because that file isn't in a package, but you don't care because you don't need correct dependencies. [04:14] haa... your are right. I've installed that library manually because there is no package. [04:14] So, I can surely tell dpkg to ignore that dependency? [04:15] The build isn't failing, is it? I didn't think that was a fatal error. [04:15] yes it is [04:16] Hm. Well, you could write a shlibs.local file, I guess. [04:16] good, I'll google that. thanks for the hint :) [04:32] it's look like I have to specify a "package name" that is supposed to contain the file in the shlibs.local file [04:36] Yeah. Pick an installed package; let's call it libc6 [04:37] that's what's I thought.... strange hack, but that will work. [04:37] 'Evening. === MTecknology is now known as otecknology === otecknology is now known as MTecknology [04:49] I'm new to packaging and would like to work on one of the pieces of software that I use. I found several pages in the Ubuntu wiki about how to get started. There's a lot there, and I'm trying to get my brain wrapped around it all. Can someone give me a few tips and pointers? [04:52] Or perhaps answer a few introductory questions? [04:52] !packagingguide [04:52] The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports [04:52] That's probably where you want to be :) [04:52] mattschafer: As questions as you have them and people will generally answer. [04:53] RAOF: I've read through all of those. Thanks for the links. [04:55] So my first basic question is this: I found the package I want in the Debian being_packaged list. However, it's been there with no other activity I can find for over 19 months. Does this mean that I ought not to start an Ubuntu packaging attempt? [04:55] mattschafer: Is it an RFP bug or an ITP bug? [04:56] Oh, let me check. I think it was ITP, but I'll confirm. [04:56] It's an ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449031 [04:56] Debian bug 449031 in wnpp "RFP: chandler-desktop -- Personal Information Management application" [Wishlist,Open] [04:57] mattschafer: Either way if it's been that long it shouldn't stop you. Since it's an ITP, you might email the person and see if they are still interested, got any useful work done you might leverage, or perhaps ran into some reason it couldn't reasonably be packaged. [04:58] ScottK: Right. That's a good idea. [04:59] Okay, I need to read the PackagingGuide in detail. There are many large areas where the package doesn't comply with the Debian guide. Same is probably true for Ubuntu. [05:00] Debian/Ubuntu packaging are about 98% the same. [05:01] And it's not important if the package complies with the guide, so long as it complies with policy. [05:01] There's lots of ways to construct a correct package. [05:02] One of the developers of Chandler Desktop said that he started the process of learning packaging about 18 months ago, but then had to pull back from the project. He said that there are some MOTUs that may have history from his initial discussions back then. I think he even went to a MOTU conference. How might I find those folks? Or is it not important, as others will pick up when I dig into it? [05:02] persia: So the guide is not policy? Is there an Ubuntu packaging policy doc somewhere? [05:02] mattschafer, I believe the Ubuntu policy is in the Ubuntu debian-policy package. [05:03] Ah. I was looking for it online. [05:03] But except for a few minor notes related to maintainers, merge changes, etc. they are the same. [05:03] I see that there is both a debian-policy package and an ubuntu-policy package. [05:04] I'll install those. Thanks. [05:04] Then it's the ubuntu-policy package :) [05:05] As for finding people, I suspect the majority were just helping package, rather than specifically interested in chandler (although I may be mistaken). If there's a package on REVU, you might check the comments, but I think you"re better off just taking a fresh start. [05:05] Okay, here's another question. Is it better to start by packaging for Ubuntu; or is it better to package in Debian, then let Ubuntu pick it up? [05:05] persia: Probably true. Those efforts happened so long ago. [05:05] Doesn't really matter where you start. Best to have it in Debian when you finish. [05:06] In other words, the answer to that question depends on whether you personally find us or the debian-mentors group a better match to your personal work methods. [05:06] Ahhhh. I don't know any of you. :) [05:07] I just started looking into this about 3 days ago. [05:07] Well then. Start here. When you get your package in good shape, get it into Debian. Maintain it there, unless you need to have a difference especially for Ubuntu. [05:08] Sounds good. Thanks. [05:09] I think my first steps are to contact the Debian maintainer in the ITP, start reading the packaging guides and policy manuals, and create an account in Launchpad. [05:09] That's a good start :) [05:09] Then start digging into the source tree to see how I might tame that beast. (It's pretty wicked in there.) [05:10] Indeed. When you get stuck with that part, ask specific questions here. [05:10] (we might just point you at the policy manual, but we might have a good answer) [05:10] I know of three packages that they compile and include within Chandler Desktop that have modifications not integrated by upstream. [05:10] In at least one case, the modifications are "bordering on a fork" [05:11] So I'll have my work cut out for me, I bet. [05:12] Do you think the weekly packaging training sessions would be useful? [05:13] I'd hope they have some use :) [05:14] You might want to review the logs. They tend to explain one or another way of doing things fairly verbosely. [05:14] Hmm. More specifically: Do you think they'd be useful for someone literally completely new to packaging? Or do you need some familiarity to make sense of it? [05:14] Attending them regularly can be interesting, if you'd like to learn about other ways of packaging stuff. [05:15] Okay, great. Just found the page of logs. [05:15] Depends on the class. Some assume familiarity, and some don't. it also depends on who attended: they are usually structured to be educational to those present, rather than to make educational logs. [05:16] Well, thanks for all of your help. I think I have enough to keep me busy for the next several evenings. [07:28] good morning [07:39] dholbach: hi [07:39] hiya MTecknology [07:40] dholbach: so, how's life? [07:40] I'm slowly waking up and reviewing a bunch of patches atm [07:40] how are you? [07:41] doing ok [07:41] feeling kinda sad, I might need to make a ban [07:59] G'morning dholbach! [07:59] heya iulian! [08:07] persia: geser: Can either of you please try building lucene2 from debian unstable and file a sync request if it builds? I tried twice on my laptop but unit tests are failing. Not sure what the issue is, but I suspect it is because of space constraint. The unit test seems to write a lot of data. [08:07] slytherin, I'm having some HW limitations right now. Dunno if I can build it. [08:08] persia: ok. By the way, did you manage to check the powerpc chroot taken from buildd? [08:09] slytherin, I did. It didn't fail for me. Dunno why. [08:09] surprising === RAOF__ is now known as RAOF_13 === RAOF_13 is now known as RAOF === thekorn is now known as _thekorn [09:10] slytherin: trying to build right now, but given that I've seen "[junit] Test org.apache.lucene.search.TestRemoteCachingWrapperFilter FAILED" I don't know if it makes sense to let it build further [09:17] nhandler: my karma's been rising fairly steadily for a while - I think I've just been busy in ways that LP notices ;-) === _thekorn is now known as thekorn === proppy1 is now known as propp1 [09:26] geser: I don't remember which test was failing. I had kept the laptop on overnight as the build takes lot of time (specifically unit tests). === propp1 is now known as proppy [10:08] iulian: ping [10:09] ttx: Hey [10:10] iulian: thx for looking after the tomcat6 merges :) [10:10] iulian: I was wondering if we should not just sync them though. [10:11] iulian: Debian might actually be right in their use of openjdk- vs default- [10:12] iulian: on the build-depends side, tomcat6 doesn't build with gcj so it makes sense to force openjdk-6-jdk [10:12] iulian: on the runtime depends side, as long as they keep the "| java6-runtime-headless" it isn't worth keeping the delta [10:12] ttx: Oh, so, do you recommend to change it back to openjdk? [10:13] I can do that right now. [10:13] iulian: well, the package was originally done in Ubuntu and later adopted by debian, so it's not really "changing it back" [10:13] iulian: it's more accepting their changes :) [10:13] Ah [10:13] Right [10:14] iulian: the only somewhat wrong thing in there is the libservlet2.5-java depends [10:15] but that's not worth keeping the delta [10:17] ttx: Hmm, could you please enlighten me a bit about libservlet2.5-java? [10:18] iulian: it all comes from the default-java things, that point to different options based on arch [10:18] iulian: default-jre-headless usually points to openjdk-6-jre-headless but can also point to gcj on some arch [10:19] iulian: if the library requires Java 6 it makes sense to write "openjdk-6-jre-headless | java6-runtime-headless" [10:20] to force Java 6 options [10:20] Ah-ha. [10:20] iuian: however if it requires only Java 2... [10:20] iulian: "openjdk-6-jre-headless | java2-runtime-headless" is a bit too much [10:20] "default-jre-headless | java2-runtime-headless" is better [10:20] but that's just being picky [10:21] and it's more for affecting debian than us (since we have our default-java uising openjdk-6) [10:21] iulian: so if they are happy with it, we should probably be as well [10:24] ttx: That being said, should we accept their changes and stay in sync with Sid? [10:25] iulian: I'd say so. Haven't tested the last release though. [10:27] iulian: let me check how they did the tomcat-juli.jar thing [10:28] ttx: Excellent, thanks! [10:30] My lappy somehow freezes when building packages or removing large files, I have no idea why :-( [10:31] bad i/o scheduler? [10:32] Probably, no clue. === ShadowChild is now known as lukjad007 [10:34] I don't remember it freezing in this way back when I was using the ext3 fs. [10:35] oho. [10:35] are you an intel gpu user? [10:38] hyperair: Nah. [10:40] hyperair: Is this bug known? [10:55] iulian: i had it when intel's GEM memory usage hit ~2G or so. then it'd start fighting with disk io for cache === ttx is now known as ttx_ [12:25] is this the right channel to ask whether it is possible to view the changelog of a package w/o installing it? (like hypothetical "apt-cache showchangelog ") === foursixnine is now known as santiago-ve [12:33] up_the_irons: not really, but u can just check it on packages.ubuntu.com [12:34] dupondje: ok thanks [12:35] apt-listchanges [12:43] directhex: thanks === WelshDragon is now known as YDdraigGoch [13:29] Laney: have you already read at mok0's email in ubuntu-motu? [13:29] no [13:29] * mok0 wakes up.. [13:30] good timing, I only *just* came back online [13:30] was reading my emails [13:30] \o/ [13:30] oh [13:30] yeah don't do anything about that just yet [13:30] Laney: You care about Haskell? [13:30] 6.10.4 is coming soon [13:30] I do! [13:30] Laney: cool [13:30] (Must admit I know nxt to nothing about it) [13:31] I was wondering if there's some kind of status page to write stuff like this [13:31] "don't worry about this, it's under control" [13:31] Laney: just reply to my message. [13:31] I will, but I bet most people won't see it [13:31] it would be better if we had a whiteboard [13:31] replying anyway [13:32] Laney: yes... some kind of status of all packages, like MoM perhaps [13:32] even more coarse than that, just a list of bullets [13:32] MOTU current affairs or something [13:33] dholbach: do you know of anything like this? [13:33] Laney: why don't you make one on the wiki and link to it from MOTUs team page? [13:33] I will if nothing exists already [13:33] Laney: the hard thing about these pages is keeping them current [13:34] yeah [13:34] Don't know what we can do about that, besides recording date + submitter [13:34] Laney, Even MoM has problems, if a merged package appears in a new version, the old comments still hang around [13:35] Laney: yes, and target release [13:35] maybe split it up by release cycle [13:35] :) [13:35] Beat you to that one :-) [13:35] Laney: I hope that harvest will have something like that for all kinds of things in a few weeks, I'll just be quite busy in the next 2 weeks and not get around to doing something about it [13:36] * mok0 thinks we need to ask the supreme leader to relax the release schedule... releases are getting increasingly buggy [13:37] we're just guinea pigs for the LTS release anyway:) [13:37] Laney: well the ground troops can wear out [13:38] Laney: and the LTS can become a "phhhfft" rather than a "BOOOM" [13:38] so for now I guess the wiki is the best option [13:38] * mok0 hugs dholbach [13:38] soon I'd hope we could have a ftbfs.csv generated and add it to harvest [13:38] or unmetdeps.csv or whatever [13:46] dholbach: here I am ... :P [13:46] i was thinking to put geser's page results on harvest. [13:47] gaspa: sure do it :) [13:48] is that what you said before? [13:49] dholbach: I mean... you said that you'd like to have a ftbfs.csv ... if results like geser's page goes well, we had already much work done. [13:50] sure, add it to harvest-data [13:53] wait, wasn't there an ubuntu developers news thing? [13:53] * Laney starts the cogs spinning [13:54] james_w: I think you were involved with it? [13:54] hi jcfp [13:54] hi Laney [13:55] thanks for looking at that patch :) [13:55] no worries, sorry I forgot about it in the house move... :( [13:56] * mok0 excuses his ignorance, but what is this harvest thing you're talking about? [13:57] isn't that the low hanging fruit thing? [13:57] yeah [13:57] url? [13:57] some way of finding stuff to work on... I never figured out how to get anything from it sadly [13:57] http://daniel.holba.ch/harvest [13:58] it's not superduperhelpful at the moment [13:58] but I plan to put some work into it this cycle [13:58] there's a big list of patches, and you're supposed to check if we want to take them AFAICS [13:58] dholbach: of course you could make a tutorial in #ubuntu-classroom [13:59] there were tutorials in open week [13:59] there's also the output of edos on karmic :P [13:59] mok0: what kind of tutorial? [13:59] edos-{build,}decheck, I mean [13:59] dholbach: you know, teaching a class [13:59] about what? [13:59] dholbach: harvest [13:59] I hope to make it intuitive soon :) [14:00] dholbach: of course [14:01] dholbach: oh, I see you have patches from fedora too cool [14:02] it's a bit broken right now, that's why I'd prefer to not put too much work into it in its current form [14:02] the plan is to django-ify it [14:02] and I'll put some work into kicking that effort off into two weeks or something [14:03] dholbach: ah, django... have been wanting to learn that a long time now [14:03] cool, I'll note you down as people to speak to when it becomes a bit clearer what needs doing to make harvest useful again :) [14:04] dholbach: please do! [14:04] * dholbach hugs mok0! [14:04] :-) [14:06] hey motus [14:06] What kind of device does the armel buildd run on, does anyone know? [14:07] Marks mobile phone perhaps... [14:07] I'm doing a cat << EOF | uudecode > image.png [14:07] but the data that follows contains backticks that are interpreted [14:07] what can I do so that everything that follows just goes to uudecode? [14:08] highvoltage: why do you need that cat << EOF stuff? uuencode will handel embedded input [14:08] s/handel/handle [14:08] mok0: I want to put it in a dpatch file, persia suggested I do it like that [14:09] highvoltage: you are supplying a png for the app? [14:09] mok0: yes [14:10] highvoltage: just uuencode the file, and save it as *.png.uu in debian/ [14:10] highvoltage: at install time, uudecode the file from debian/ and install it [14:10] mok0: I could do that, but persia said I get extra points if I do it inside the patch :) [14:11] highvoltage: I understand the challenge, but I don't see the point [14:11] highvoltage: better to make it as simple as possible [14:11] mok0: ok [14:11] highvoltage: you can _create_ a png.uu file via a patch, and then uudecode it [14:12] Hrm? That doesn;t make sense. [14:12] highvoltage: personally, I like putting stuff like that in debian/ easier to maintain [14:12] dpatch is an executable shell script. Makes sense to use it. [14:12] Otherwise, yeah, just stuff a file in debian/ and unpack in rules. [14:13] persia: that's mis-use of dpatch IMHO [14:13] mok0, Hrm? Why. dpatch is shell scripts precisely to support odd stuff like that. [14:13] whoops, I think I posted to ubuntu-motu from the wrong address [14:14] persia: I think that's not very intuitive. dpatch is for applying patches [14:14] Laney, just cancel when you get the moderation mail and repost. [14:14] mok0, Well, it depends. [14:14] Laney: I'll accept it [14:14] I'll just wait for it to be accepted [14:14] thanks soren [14:14] Laney: There. [14:14] it's not intuitive to create, but it's intuitive to use, because the patch changes the file, as one would expect. [14:14] too kind [14:14] persia: can you give me an example of a package where dpatch is used to run scripts? [14:15] Every single dpatch is a shell script. [14:15] Laney: And added that address as an acceptabl sender. [14:15] oh, awesome [14:15] persia: well, they have the shebang line I know that [14:15] persia: so if I'd want to use cat in the dpatch file, would I need to escape all the backticks? [14:15] I try not to use it for Ubuntu stuff but that's not the fist time I've got it wrong [14:15] highvoltage, Yes. [14:15] persia: perhaps in this particular instance mok0's way would be better? [14:16] highvoltage, mok0's way is both more common and easier. [14:16] persia: but that's just used to start dpatch in a "clever" way [14:16] highvoltage: ;-) [14:16] mok0, and this is why :) [14:17] ok I'm not going to do the cat thing in dpatch then to make things simpler for a future maintainer [14:17] persia: so I could hide an evil script in there and take over the buildd's hehehe [14:17] The point being that using dpatch to place the binary allows one to comply with the guideline to easily allow the source to be patched with debian/rules patch and no fuss. [14:17] (I'll get my extra points some other way ;) ) [14:17] otherwise, one needs to make debian/rules more complicated [14:17] * persia prefers simple debian/rules [14:17] mok0, No, you could take over the build instance, same as you could if you just stuck something in debian/rules. [14:17] persia: rules is a documentation of how the package is built [14:18] * Laney wonders what the MOTU Reporting Page is for [14:18] Laney: reporting indecent behaviour among the MOTU? [14:18] Laney, We're supposed to do a monthly report. Nobody has volunteered to be our monthly reporter for a very long time. Are you up for it? [14:19] mok0, Well, it depends. I like the idea that one gets the patched source with a single command more than I like the idea that debian/rules documents the build. [14:19] persia: Not really. Apart from a lack of time, I see a lack of interest too. I was just searching for an existing MOTU whiteboard [14:19] persia: matter of taste I guess... [14:19] I suppose one could do uudecode stuff in patch:, but I don't like to complicate things. [14:19] Laney, whiteboard? Towards what end? [14:20] mok0, Indeed :) [14:20] documenting goings on of note [14:20] specifically "Don't panic about all the uninstallable haskell packages" in my case [14:20] Wasn't there an initiative to coordinate with the News team to publish those? [14:20] persia: our chat started with my ML email a while ago [14:20] Oh, for that, send a note to ubuntu-devel@ [14:20] yeah, I pinged James earlier because my distant memory has something like this [14:21] persia: the point is that email are not remembered very long. What we need it Google Wave :-) [14:21] s/it/is [14:22] mok0, Erm, maybe. In this instance, I think email is better, because the information is only meaningful for a moderate amount of time. [14:22] persia: that's true, and a wiki page needs to be kept up-to-date [14:23] I guess I'd intend it to contain ongoing items of work, not really sure [14:23] Right. Wikis are bad for this sort of thing, unless you've only a few people. [14:23] Laney, For ongoing work, there was MOTU/TODO, but it's now very out of date. [14:23] Laney, persia, if you Re: the original status message in email, it will be grouped by a modern threaded mail client [14:24] Actually, it might be better just to have a continuing thread on the mailing list, where new versions of the text are posted [14:25] I'm not worried about updating the status, it's more about letting people know what's going on so they don't worry or duplicate work or ... [14:25] Right. Because this is a one-time notice, use email. [14:25] For lots of other things, email isn't best. [14:25] Personally, I very much dislike the update-through-email model. [14:25] But then again, I don't much like email, so perhaps I'm biased. [14:26] reminds me of Usenet FAQs [14:26] Perhaps, if there was an automated posting at the beginning at each month, it would appear at every web summary page [14:26] Laney: right [14:27] that's too much imo [14:27] the point of a wiki was to be simple, but it's been pointed out that this is perhaps unnecessary [14:27] Laney: 90% of the info on the wiki is outdated [14:28] Laney: or feels that way [14:28] I am very much not surprised by that [14:29] I find the wiki clunky and hard to navigate and use, so pretty much don't. [14:30] Laney: when google wave appears we should replace it [14:30] * Laney runs before he gets himself into "you fix it" territory :) [14:30] Laney: it's like archaeological culture layers... you have to live on top of them [14:31] it's fine to read as individual pages of documentation (where it's still current) though [14:32] Laney: right. There are 10% of the pages that are relatively maintained [14:33] Well, I'm not sure that as much as that is maintained, but there's lots that hasn't gotten that stale as well. [14:34] * mok0 sighs [14:35] Maybe we need something more like the git community book and less like a wiki [14:35] Hrm? Why? [14:36] (for MOTU docs) [14:36] How does that change anything? [14:36] mainly with regards to organisation and consistency [14:36] Changing the format doesn't change the contents meaningfully. [14:37] Well it wouldn't just be a straight port, but editing too [14:37] I don't think that organic growth is producing the best quality documentation [14:38] Ah, but that would require editors and structure, which would require people doing it. [14:38] I'd personally rather those who can be developers be developers, and I don't trust those who can't be developers to document it correctly. [14:38] yes, it would require a big initial push [14:38] In other words, it's up to us to document it best we can. [14:38] does anyone have any idea if the package sync script will be run at least once before DIF? [14:39] We've done a couple reviews and edits of the MOTU sections of the wiki previously. Feel free to lead another :) [14:39] slytherin: It was going to be done today if it hasn't already [14:39] * mok0 has argued for a MOTU blog [14:40] Laney: it hasn't already. [14:40] slytherin, Should be run every ArchiveAdmin day through DIF day. [14:40] mok0: You could hack wordpress to use lplib auth! [14:40] mok0, Doesn't really help. Timeliness, lack of utility over time, etc. [14:41] persia: perhaps but it's not as prolific as a wiki [14:41] mok0, Hrm? How do you mean? [14:42] persia: there will be "pages" and there will be "blog entries". The former typically for documentation, the latter for temporary messages. [14:42] Erm, except what temporary messages don't belong on ubuntu-devel@ ? [14:43] persia: the "pages" will be a single text file, not a bunch of #included segments from who knows where [14:43] Oh, I don't like that either, but dholbach was the last person to drive a wiki cleanup, and did it that way. Feel free to unwind it if you have the time and patience. [14:43] persia: I don't :-) [14:44] Right. I don't think changing the format changes anything. [14:44] persia: I propose moving everything to a blog :-) [14:44] Hard to have static docs in a blog. [14:44] persia: no, you just have a "page" [14:45] And pages link to other pages, and we can all edit the pages? [14:45] persia: yep [14:45] And there's a special page that shows the recently changed pages, and another than shows the new pages? [14:45] persia: sort of like a wiki ;-) [14:45] and you can get RSS feeds from these? [14:45] persia: yes [14:45] Yeah. That's my point :) [14:46] You're just changing the format of the entries. [14:46] persia: seriously, Google Wave will turn everything around [14:46] Seriously, I don't think this is a problem that technology can address. [14:46] The problem is that nobody wants to handle the docs. [14:46] persia: have you watched the video? [14:46] And the one person who did step in an try to do it did it in a way nobody else wants to use. [14:47] I've watched the video, but I still say it's irrelevant. [14:47] Laney: persia: looks like sync has been done but the changes are not advertised on karmic-changes mailing list. [14:47] persia: well, that's your prerogative if you do the work [14:47] slytherin, autosync generally isn't advertised there. [14:47] I thought it was [14:48] mok0, Indeed. I don't blame that person, I just say that's where we are. Redoing everything is just makework. [14:48] persia: I guess [14:48] persia: we are too pressed with these damn semi-annual releases [14:49] So, I'd rather fix it. If there's a specific issue with our specific underlying technology, that's diffe3rent. To me, the problem is entirely social. [14:49] persia: with all this release work, there is no time to improve our infrastructure. That is my point [14:50] persia: -devs are wearing out fast, and newcomers don't know the history [14:50] mok0, Well, that's not strictly true. Some of us could, and some of us have in the past. Just nobody is doing it now. [14:50] persia: you said that last year :-) [14:50] persia: and will be saying it a year from now [14:50] Yes. Nothing much has changed since then. It remains true. [14:51] persia: I could change if we were heard by the top of the pyramid [14:51] I doubt I'll be saying that a year from now. if we don't update the infrastructure, we will lose the game. [14:51] persia: exactly [14:51] What do you mean "I could change if we were heard by the top of the pyramid"? [14:51] persia: many MOTUs move on to do main work [14:52] Ah, yes. [14:52] That's why I believe in ArchiveReorganisation. [14:52] persia: I mean that the semi-annual schedule is wearing everybody out [14:52] Well, the schedule isn't going to change. [14:52] Perhaps we're not doing it right, as less of us used to do it before. [14:52] persia: we are just patching the same bugs over and over b/c there is no time to submit to upstream [14:53] We spend a lot of time doing more merges past DIF. This is good for users, but not specifically required. [14:53] Hrm. That's an interesting perspective. [14:53] persia: that's because many bugs are solved by upstream updates [14:53] I know. They also cause some bugs. It's not clear what is the right answer. [14:54] Originally, the right answer was to sync sid, and fix all the bugs over six months in a small subset of packages for each flavour. [14:54]