=== asac_ is now known as asac [00:52] The universe-contributors icon seems to be on a white background while most team icons seem to be on a transparent icon... [02:15] Hello stani === Kopfgeldjaeger is now known as Kopfi|offline [05:09] someone have time to explain something to me, if I were to create a new package with code from someone else's code, I provide where it came from, the author's information, and all other copyright information but maintain the source for the package on my own correct, the get-orig-source rule is not supposed to pull from some where other than where the package's source is (not its upstream source)? [05:25] foxbuntu: get-orig-source should (probably) get the most recent upstream tarball. The code that the package is packaging. [05:26] RAOF, ok makes sense, but the file in the package should be showing up in the diff then correct? [05:28] foxbuntu: "the file in the package"? What file? [05:29] s/file/files (the source code in the package) [05:30] RAOF, essentially just the same as if I was the original source author [05:31] the only difference is the orig tarball comes from an upstream source [05:31] I'm not sure what you're saying. [05:32] RAOF, he wants to know if all the files in orig.tar.gz should be in the diff [05:33] No. [05:33] RAOF, even if they are in the package? [05:34] The diff is the changes you make to the upstream .orig.tar.gz to turn it into a source package; generally, only the debian/ directory should be there. [05:34] RAOF, ok I understand [05:50] any motu up? [05:52] nxvl: Am I not looking at one? [05:52] wgrant: yep but i need a second ACK [05:53] Ah. A new package? That discounts me. [05:53] wgrant: is a web app [05:53] wgrant: from dustin [05:54] wgrant: You're opposed to new packages now? [05:54] persia: In all but exceptional cases. [05:55] Makes sense. We've a really poor track record of actually maintaining any of them. [05:55] that's why i use to upload to debian and sync to ubuntu [05:55] :D [05:56] That is what one should do, yes. [05:56] Yeah, that's better as it means someone is then responsible for it being updated, or it gets removed, [05:58] yup [05:59] people use to upload to ubuntu and forget about their packages [06:00] Well, some people. I've also seen some packages that get maintained. The trick is that it's hard to know in advance. [06:01] yup [06:01] you can know that some people will maintain it [06:02] Hi [06:02] as the package i'm asking for the 2nd ACK [06:02] I was working on a package for debian (google-gadgets) and i decided to post it to REVU so it could possibly get into intrepid before the freeze in a few days, if someone could review the package (http://revu.ubuntuwire.com/details.py?package=google-gadgets) it would be greatly appreciated. [06:04] nxvl: No, you can't. We've had packages which were brought in by very active people who are still active, but just haven't checked the bugs on that package or whether there was a new upstream. [06:04] It's more a matter of best guess than anything else. [06:04] agreed [06:04] then i retract myself from what i said [06:04] and btw [06:04] talking about retractions [06:05] persia: i've been following Dustin applications [06:05] nxvl: Yes? [06:05] persia: and i understand your concerns, but in favor of Dustin i need to say that the core of his work is on uptream [06:05] he has an interesting model of work [06:05] he hack and patches upstream [06:06] and then imports it to ubuntu [06:06] so he may doesn't have a lot of ubuntu specific uploads into universi [06:06] but he has a lot of code into universe [06:06] nxvl: I understand. As I think I made clear, I've no issues with him technically. Also, to me it seems that the discussion is quieting: I'm not sure why there have been no other votes. [06:06] does that count as indirect contributions? [06:07] I didn't vote against him, just didn't vote because of the previous MC voting procedures (which have now been changed) [06:07] persia: geser said he has no time, i don't understad why nixternal hasn't vote [06:08] persia: yeah, i know, and that's cool, since there are nothing to complain about him, that's why i understand a retraction, but i would't understand a negative vote [06:09] persia: i think nixternal is waiting for more discussion [06:09] nxvl: I'm glad you understand. Some of the mail makes me feel like I've voted against him, or that I'm somehow blocking him, which isn't very comfortable. [06:10] persia: but what i meant is, despide of the techical thing, which is clear we haven't any complains on that part, he has do a lot of contributions to universe, but not directly [06:10] being that pushing code tu upstream and them import it into ubuntu [06:10] I am pleased that discussion was able to continue. In the past everybody just gave their +1s and candidates were approved with minimal discussion, in cases where they should have perhaps not been. [06:11] nxvl: Right, and I suspect that might be part of the issue. He does immense amounts of work, much of which is good, but is it work done explicitly for Ubuntu? [06:11] persia: and also some comments for some people on other applicants aplications [06:11] persia: in upstream yes [06:11] wgrant: I'm very glad to hear that. Thank you. I feel a little bad, because Dustin's work is good in my technical review, but still stand by my decision to allow discussion. [06:12] persia: i've talked large with him since we are on the server team and we work together most of the time [06:12] persia: and for example, for ecryptfs he didn't patch the ubuntu package [06:12] persia: he started to work with upstream, and when the tools was in good shape ask upstream to release and then include it in ubuntu [06:12] nxvl: Right. I understand. His name appears all over the place, with a lot of work done completely upstream or in Debian. [06:12] persia: I fully support that decision. [06:12] and the goeal of all that work was specificaly for ubunut [06:13] so it's work made for ubuntu, but not directly [06:14] nxvl: Understood. I'm fairly undecided on the question of whether one must work *in* Ubuntu to work *on* Ubuntu. I have a preference for stronger teams, and think that there is value in having MOTU be a team, rather than just an upload permission bit. [06:14] he's just making it backwards [06:14] be use to patch ubuntu packages [06:14] and then push our changes to upstream and then sync [06:14] But that preference isn't strong enough to make me say we should exclude those who do upstream work. [06:14] but he pushes his changes to upstream and then import them to ubuntu [06:14] which i find a good workflow [06:14] nxvl: Taking the argument for the sake of debate, rather than personal opinion: [06:15] Sure, but how does commit access to Ubuntu help that workflow? [06:15] persia: yeah, i'm not trying to change your mind actually, just discussing it on IRC, which i find better than using ML [06:16] nxvl: For quick discussions, I agree. For many discussions, I prefer the mailing list just because it has a wider audience. [06:16] yeah [06:16] this time i'm extending the discussion [06:17] i use to discuss things on IRC and then go to ML [06:17] So, back to my devil's advocate question: how does commit access to Ubuntu help an upstream-focused workflow? [06:17] persia: for better/quick inclussion of the new upstream version [06:18] also at some point upstream inclussion is not permited anymore [06:18] so i expect to see more work from dustin after FF [06:19] nxvl: So why would it not be appropriate to evaluate involvement after that work has been presented? [06:19] and i also agree that he doesn't show to much here and doesn't use the normal workflow for sponsorship, since he pings canonical employees and/or specific people to sponsor his work, instead of using uus and this channel [06:20] nxvl: Right, which are the two sides of the debate. [06:21] I think geser put it best when talking about the wave/particle thing. What is MOTU? Is it a team, or people who can upload or both? [06:21] persia: actually that's what i mean. Given the actual state of his application i expect to see more work from him from this week on, and then maybe change one more MC member mind to give a positive vote [06:22] I don't know the answer to that question, but I think it's worth discussion. I feel bad that Dustin specifically got hit by the discussion, but given the way we work, a couple weeks rarely makes a difference. [06:22] i actually disagree on that [06:22] i count contributors as part of the MOTU team [06:22] without commit access [06:22] but part of the team [06:23] I consider contributors a vital and critical part of the Ubuntu Development team, but not yet MOTU. [06:24] that depends on what MOTU means for you [06:24] nxvl: Right, which is the core thing. [06:25] exactly [06:25] To me, MOTU is the "Masters of the Universe": the people who are ultimately responsible for making sure that the universe component is as good as we can make it be. [06:25] development is a BIG part of the MOTU team, and the core of it [06:25] This has nothing to do with upload rights. [06:25] but we still have community [06:25] which is also an important part of it [06:26] See, I completely fail to understand any distinction between development and community. [06:26] Ubuntu is a commity-driven distribution, and Ubuntu Developers (whether Core, MOTU, or UUC) are all community members who are contributing with development work. [06:27] Many members of those teams also participate in other factors of the Ubuntu community. [06:27] I very much feel that having a separate "MOTU" community is the wrong direction: we are all part of the Ubuntu Community, and MOTU is a team that tries to reach certain goals in that community. [06:27] as i see it, development is hang here, make patches, fix bugs and review some consitrbutions, and community is teach new people, convince them to jump in and make it easy to them to start [06:28] That said, it still leaves open the question as to whether this is because of upload rights or because of membership in the team by accolation. [06:28] nxvl: See, I don't see the difference between those things. [06:28] Getting people involved is often a matter or working with their bugs (or fixing them), and making Ubuntu better for them. [06:28] persia: because you take care of the 2 parts, but not all of the members [06:28] Reviewing contributions isn't that different than teaching new people. [06:30] nxvl: Except I claim that the difference is artifical, and use of such separate terms is a semantic construction that encourages discrimination within the Ubuntu community, a practice that I do not believe leads to the ultimate growth of Ubuntu. [06:30] oh yeah i just read a previus comment of you, i'm not separating it as in 2 different team [06:31] what i was trying to say is that you can contribute to MOTU community directly without the help of no-one, oposite to development that you need a sponsort or commit access [06:31] nxvl: No, but you use different terms, which then allows the asking of the question "Is this person involved in development or community", which I don't think is a meaningful question. [06:31] agreed [06:31] You support the idea that there is a distinction by saying "persia: because you take care of the 2 parts, but not all of the members", which I also think is meaningless. [06:32] I don't know of any MOTU who is not part of the community (and if you do, please let me know), and I don't know of any MOTU who does not do any development (and if there is one, they ought be encouraged to come back and help more) [06:33] yes, i thing i said it wrong [06:33] what i was trying to say is that you don't need to be a MOTU with upload rights to be part of the MOTU community [06:33] which was the original discussion [06:33] nxvl: No worries. The idea that there is a separate "community" within Ubuntu is an unfortunate meme that has spread far: it is not surprising to see it repeated, as much as I neither understand why it is present, or how to destroy it. [06:34] See, again, I don't think there is a separate "MOTU" community. There is a separate Ubuntu Development community, as much as I would prefer there not to be, but I do not beleive there is any value in creating sharper distinctions within our ranks. [06:36] what i've notice in the ubuntu community in general, in difference from the others starts with the end users [06:36] See, I think we all ought focus on that. We are, after all, end users. [06:36] yes, but different end users [06:36] How? [06:37] for example: a common gentoo user know what he is doing and has somehow technical skills, oposite to ubuntu that targets to the less technical users [06:37] While I can say that I am a developer, and an expert with certain things, there are areas of the system that I don't understand. [06:38] I've had bugs that annoy me for years, but aren't sufficiently annoying for me to want to fix them. [06:38] same with debian, they somehow knows what he's doing and/or needs to investigate to do stuff [06:38] Either I am an end-user, sharing the same annoyances as everyone else, and therefore part of a large community, or I am separated into being a developer, who is being irresponsible by not fixing the bugs. I choose the former because the latter is simply too disenheartening. [06:39] persia: yes, but you understand how an aplication works, my mom doesn't [06:40] nxvl: No, my point was that I don't understand how some applications work. [06:40] persia: and the objetive ubuntu users are users like my mom [06:40] No, the target Ubuntu users are everyone. Your Mom and you and I. [06:40] yep [06:40] but make it as easy as it can so my mom can use it [06:41] I have no interest in making a distribution that works for your Mom. I work on Ubuntu because I find it the best way to get others to work on Ubuntu because I am unhappy that Ubuntu doesn't work the way I want. [06:41] I'd prefer to make it easy for _me_ to use it. [06:41] It's entirely selfish, and entirely to improve my own computing experience. [06:41] If this happens to make it easy for someone else (and it almost certainly will), all the better. [06:42] so the core and mayority of the users are mom-users (to stop mentioning my mom) so the percentage of posible developers are less that in other distributions [06:42] On the other hand, if this happens to benefit your Mom, that's a good thing, and makes me feel warm and tingly inside. [06:42] RAOF: Precisely. [06:42] nxvl: See, that's divisive argument. [06:43] One of the things I remember most fondly about my involvement with Ubuntu was back in Hoary: a 9 year old joined #ubuntu looking for a photo management application. pornview was perfectly suited for his needs, but he couldn't install it because of the name. [06:43] In Dapper, that same person ended up submitting some very insightful bugs that helped make Dapper better. [06:43] what i mean is: for each 100 ubuntu users 20 or more know a program language and can become DD one day [06:44] in ubuntu that 5 over 100 [06:44] err [06:44] Now, that person isn't around so much (high school in the US can be very distracting), but I think the contribution was good, and I think the goal ought be to encourage more users to do that sort of thing. [06:44] 100/20 for debian [06:44] nxvl: Yes, but you miss the point. [06:44] _Everyone_ can become a DD one day; everyone can become a MOTU one day. [06:44] The point is that if we are all part of the same community, and we all work together, sharing what we can, we get something better. [06:45] "Linux for Human Beings" [06:45] If we say "You're not a developer" or "You don't have any technical skills" the users become mere consumers, rather than part of the community. [06:45] RAOF: if you are interested on it, and that's the difference between the 20 and the rest [06:45] RAOF: not the actual techinical skills [06:45] nxvl: Right. [06:46] I do some user support for ubuntustudio. Typically it's the end users who claim they have no technical skills that are able to track down some problem so we can get it fixed. [06:47] I am very technical and a Dev for the Mythbuntu Project and some normal issues slip by my view simply because I am not thinking from a non-technical user's perspective, a linux user is part of the community regardless of their involvement of it progressions [06:48] foxbuntu: Yes, but I contend that those users who feed you stuff *are* directly involved in the improvement of mythbuntu, regardless of how much technical experience they may have. [06:49] persia, I would agree [06:49] the users are the most important part of a development project [06:49] Indeed, and that includes all users, including those of us involved in this conversation. [06:50] also you can tell that from the quality of the bug reports [06:51] nxvl: This is a good metric, but generally if one is helpful with those with poor bug reports, the future bug reports from the same source are better. [06:51] agreed [06:51] persia, indeed...I came from very little coding experience and became a developer [06:52] Note also that this applies to people who choose to focus on coding: I've seen lots of bad bug reports from very technically ept people who just couldn't be bothered to write it clearly. [06:52] foxbuntu: yes, but you have development interest [06:52] at least interest in development [06:53] well [06:53] i need to go [06:53] it was pleasure to discuss with all of you [06:53] as always! [06:53] persia, so, help them, most users even of high technical skill have never delt with bug reports and dont know how to submit useful information [06:54] nxvl: You're looking at it backwards. Consider the case of Con Kolivas: who had no coding experience, or clear interest, but wanted linux to be better, and got very involved in the kernel. [06:54] foxbuntu: Precisely :) [06:55] persia: not actually, that's what i mean, the interest better than the technical background [06:55] persia, actually for Mythbuntu we have added tools to do just that for the 8.10 cycle [06:55] nxvl: Right, but the interest can be cultivated by creating an inclusive community, which is why I argue against divisive terms. [06:56] foxbuntu: Cool. Are they highly mythbuntu specific, or can they be generalised more widely? [06:56] persia: agreed [06:56] ok [06:56] now that one more discussion ended with persia convincing me [06:56] nxvl: Thanks for letting me stand on a soapbox with you as the apparent object of my rant :) [06:56] i'm gone [06:57] Have a good night :) [06:57] persia, its actually fairly generic...grabs common log data and posts it to pastebin and provides the link through the interface [06:57] persia: have a good ... [06:57] :) [06:57] afternoon [06:57] :D [06:57] Buenas noches nxvl. [06:57] jpds: igualmente! [06:57] :P [06:57] read you [06:57] foxbuntu: Nifty. Is that as an apport hook, or a separate hook of some sort? [06:58] persia, all custom, so they can be gathered and posted on demand and its got intergration into the MythTV Frontend for easy access [06:59] persia, its not as nice as apport but gathers things needed in Mythbuntu land for good bug reports [07:00] but would work fine for other things [07:00] foxbuntu: Nifty. Be cool if we could find a way to extend that more generally, with more front-ends. I can imagine that the discussion in #ubuntu would be more productive if everyone brought along the right logs. [07:00] persia, certianly could be done [07:36] Are there any "Build-Depends" exception experts around? I'm trying to figure out how to *prevent* icedtea-java7-jdk satisfying 'java6-jdk'. Debian policy manual doesn't seem to allow ! for package names, only architectures === fargiolas|afk is now known as fargiolas [07:40] IntuitiveNipple: Don't use either? [07:41] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-July/000460.html [07:42] It's a package for Gutsy - the Hardy+ versions run okay, but the Gutsy version fails on run because it was built using icedtea - it causes "UnsupportedClassVersionError" [07:43] Ah. Just build-depend against a specific other package then, perhaps using | construction to optionally allow other providers of java6-jdk [07:43] The *intention* was to have it build using a java 1.5 compiler, but icedtea-satisfied the build-depends. I was hoping to keep the same control file for each version to save having to maintain separate strands but... ! [07:43] * persia doesn't really think icedtea belonged in gutsy anyway, and is surprised that anything was built against it, given the date on which it was uploaded [07:44] Am I correct in thinking the or operator in build depends will cause the first package available to be installed? [07:45] Yeah, it is a pain. I've packaged the latest red5 Flash server for Gutsy Hardy & Intrepid, but just found out (on my own server) that the Gutsy edition has this 'problen' so trying to figure out an elegant solution [07:46] Ideally it looks like the Gutsy package needs to build-depend on java2-compiler [07:46] The | operator will install the package first named in the sequence if none is installed, but not force the installation if there is already one of the mentioned packages listed. [07:47] Yeah.. so the former situ on a buildd where none should already be installed [07:47] Does it build cleanly with java2-compiler? [07:47] Not tried yet! It builds cleanly for all of them, it just doesn't *run* ! [07:47] IntuitiveNipple: For modern buildds, that is frequently the case, although there still exist some buildds that would preserve previous installed packages in ther interests of speed (but I think none that are default buildds for any distributions) [07:48] I did extensive build-tests locally before it went up to PPA, and was testing locally on the openjdk6-jre for running it so didn't think to suspect this issue [07:48] Ah. Maybe it needs a different JRE to run? There've been a few packages that could build cleanly with anything, but required certain JREs to actually run. [07:49] Conversely, there was at least one package that needed specific (and different) versions to build and run at one point (although I think it's fixed now) [07:49] I've tried all the available JREs on Gutsy all give the same problem, and reading up on the exception basically says "don't compile it with icedtea - it messes things up" [07:51] Hence trying to figure out how to ensure [07:51] sun-java6-jdk is used (which provides java2-compiler) [07:52] Build-Depends: ... sun-java6-jdk | java2-compiler ... [07:52] yeah, I thought of that but... I would prefer the Hardy/Intrepid packages to build with openjdk ... and annoyingly the provides of the Sun and OpenJDK and icedtea packages don't coincide [07:53] I'l probably end up having to have two different control files, to make this sane [07:54] Not too much of an issue since I have automated build/publish scripts that already re-write changelog for each release... I can extend that to look for and use an alternate control if it is there. [08:02] Hey, i was away for awhile but just read the above conversation between some (persaia, nxvl, foxbuntu) and part of it made me wonder why REVU exists at all. I maintain two packages in Debian. Now I realize it was the best path to take as more people can use them, but the reason I submitted my first Debian package was that it sat in REVU for over a month without even a comment. Why doesn't Ubuntu just send people that way to begin [08:03] asomething: It's mostly because there is a matter of debate. Some believe we should have new packages in Ubuntu. Some believe we shouldn't. [08:03] Members of the first school created REVU as a means to ensure that if new packages were being added to Ubuntu, they were of good quality, and had been submitted for peer review. [08:04] Personally, although I'm not so much a fan of new packages, I'm a huge supporter of REVU, as I believe that if we are going to have new packages, getting them peer reviewed is the right way to do it. [08:05] I guess the PPAs do a curve-ball around REVU now? [08:05] IntuitiveNipple: Well, many Ubuntu Developers mostly ignore the PPAs as examples of packaging being done. [08:06] not as examples, I mean to get packages published quickly [08:06] At UDS Boston there was talk about using PPAs as part of a review process, but due to the nature of the way that PPAs are implemented, this turns out not to work at all in practice. [08:06] I know for all my packages I spend many hours ensuring the packages are absolutely correct. [08:06] I've even had to learn how to format man-pages :D [08:07] Well, there's a difference between publishing in a PPA and publishing in Ubuntu. PPAs are really just a way to host a third-party repo without building the infrastructure oneself. It comes from good ideas, but in execution, it's left a fair amount to be desired, and is for a long time was unusable by distribution developers. [08:08] IntuitiveNipple: Right, and I suspect that comes from your initial experiences with peer review :) [08:08] I guess I understand the point of of REVU, but maybe there should be a more explicit attempt at sending people willing to maintain packages to Debian. Especially since debian.mentors has been more responsive in my case than REVU... [08:08] asomething: It depends on timing. At the time of REVU creation, m.d.o was fairly unresponsive. Right now, m.d.o is fairly responsive, and REVU is mostly unresponsive. [08:10] persia: no, I've never been involved in 'official' packaging. It comes from my being a perfectionist :D [08:10] with an new stable Debian release coming up, this might change... priority is going to RC bugs. [08:10] I'm not sure the scale won't top back in time. Ideally, they would both be responsive, or the many-times-mooted idea of building a new m.d.o that included some of the REVU features for wide public review for insertion into Debian, with participation from both distribuitions. [08:10] would be actualised [08:10] IntuitiveNipple: I know better than that: I've seen your name in changelogs. [08:10] persia: huh? [08:11] asomething: Indeed. It goes back and forth. [08:11] I've not done anything official... aside from occasionally reporting bugs [08:16] persia: infact, I've got an update to one of my packages sitting on mentors now for ten days. longest time without a reply yet... I think I'll have to do a Ubuntu revision to get in before the Intrepid FF. I'd prefer to sync, but it's better to get it in... [08:16] asomething: If ten days is the longest time without a reply, m.d.o has gotten *much* better, and it definitely the place for people to go now. [08:17] At the time of REVU's creation, m.d.o would be months without a reply. [08:18] These codes... what is m.d.o ? [08:18] persia: m.d.o has been very responsive. the site its self is nice as well [08:18] mentors.debian.org [08:18] asomething: Indeed, which is a good thing :) [08:18] ^^ IntuitiveNipple: [08:19] (especially because REVU has been *so* inactive this cycle) [08:21] So, if I've packaged stuff and put it in my PPA, what might be different if I was to 'backport' it for inclusion in Debian? Presumably I've got to 'pbuilder' it for Debian too? How about the fact the number of architectures supported? [08:21] Generally it's best to test it against Debian, but the differences should be fairly minor. [08:22] Note that some packagses will depend on Ubuntu-specific bits, like branded Mozilla apps or differences in the Ubuntu kernel, and these need a bit more tweaking. === tuxmaniac is now known as slytherin [08:23] Yeah, I think that would be an issue for me, and the extra 'hassle' of figuring out the issues isn't something I'd want on top of the existing process! [08:24] It's mostly just a matter of testing. For 99% of packages, there's no strong reason for divergence. [08:26] IntuitiveNipple: you should check out https://wiki.ubuntu.com/PbuilderHowto#Multiple%20pbuilders [08:28] asomething: :D http://tjworld.net/wiki/Linux/Ubuntu/Packages/CreatingPbuilderVariations [08:30] IntuitiveNipple: that looks better, guess you know ;-) [08:31] hehehe [08:31] all my build/testing is automated her [08:31] s/her/here/ [08:48] IntuitiveNipple: just looked you up (LP people search, not some strange government database) , you should put more things up for inclusion... you seem more than qualified... [08:49] Persia has been trying to persuade me of that. [08:52] if they let smucks like me in the archive (not a MOTU just through sponsors and Debian), someone like you would be a great addition :) [08:52] I'm already busy with kernel stuff, packaging is just a sideline :) === slytherin is now known as tuxmaniac [09:07] How does one handle a package version such as 2.10.33-2.2build1? [09:13] xnevermore: That's surely not the upstream version, right? [09:15] no [09:16] i'd just never seen an ubuntu package named as such, and am not sure how to increment it [09:18] Ah, right. [09:18] The 'build1' suffix indicates that it's needed a no-change rebuild. [09:19] no-change? [09:19] Well, changelog changes only. [09:19] No source changes, just a changelog entry. [09:19] So the next Ubuntu revision of that package would be 2.10.33-2.2ubuntu1 [09:20] ahhh... what about the number before ubuntu/build? I thought it was supposed to be either a 1 or 0, and certainly not decimal pointed [09:21] xnevermore: Decimal indicates security update. [09:23] hmm... well a 1 means debian derived, a 0 means its not, so what does 2.2 mean exactly? [09:23] and IS it a debian package or ubuntu? [09:24] It's derived from the -2.2 debian package. [09:24] Because we needed a rebuild, someone added a changelog entry and uploaded the build1 package. [09:25] Currently it's exactly the same source as the 2.10.33-2.2 Debian package. [09:25] ok, that seems reasonable enough. [09:37] jpds: Not necessarily a security upload. Could be all sorts of reasons for an NMU that resulted in something like -2.2 [09:38] persia: Right. [10:48] Hi. Does MOTU handle pulling in updates from Debian as well? I just came to say that you might want to pull in the latest iproute package, which was given a freeze exception to go into Lenny. It fixes some bugs, but maybe most importantly the version you're currently carrying differs from all other versions in it's output syntax (which was reverted in the new version). [10:48] I see no reason that updating should cause you any problems. [10:50] fatal_, iproute is in main, you may want to file a new sync request to have it in intrepid before FF. [10:51] DktrKranz: I'm not up to speed on how things work in ubuntu, would you mind doing it for me? :) [10:52] fatal_: https://wiki.ubuntu.com/SyncRequestProcess [10:52] I guess it's not too much to care about though.... not like your next version will be a long time support (AFAIK), so it'll only last 6 months. [10:55] bye! [10:55] Hmm. [11:15] hi! Could someone check on bug #132130? i created a debdiff and would like to know if thats ok. [11:15] Launchpad bug 132130 in istanbul "istanbul crashed with AttributeError in stop_recording()" [Medium,Triaged] https://launchpad.net/bugs/132130 === DreamThi1f is now known as DreamThief === Kopfi|offline is now known as Kopfgeldjaeger === thunderstruck is now known as gnomefreak [11:47] Ampelbein: as istanbul uses quilt for patch management, you should use it to add new patches. And when I read the debian bug it looks like the mentioned patch is already applied in the version in intrepid. [11:48] geser: ok, thanks for the info. [12:38] can someone give me an idea on why this is failing? all i did was change control maintainers* and changelog http://pastebin.mozilla.org/523414 [12:39] gnomefreak: The clean target doesn't work, apparently. [12:39] cannot represent change to smartirc4net-0.4.5.1/bin/Meebey.SmartIrc4net.dll.mdb: binary file contents changed < [12:39] That file should be removed on clean. [12:39] RAOF: ah ok let me look at it in rules [12:42] thats odd smuxi has clean: clean-patched unpatch but libsmartirc* doesnt have that line but that wont remove that binary AFAIK [12:43] yep it fails with that too but gives differnet error [12:43] Wow. The PPA build chroot is horribly broken; my build's just failed unpacking the dependencies! [12:48] hmm wonder if nobinonly script will help this [12:48] removing by hand fixes it seems like for good [12:51] this is gonna fail on PPA i guess i have work to do today [12:51] thank RAOF [13:19] moin [13:22] got a noob question, the rules file is a bash scrip right? [13:25] Laney, I'm looking at goocanvasmm, sorry for being so late. [13:27] loell: no, debian/rules is a Makefile [13:29] geser, it technically can be a bash script, there are a few packages that use that vs. a makefile [13:29] I don't remember if policy changed to require it to be a makefile [13:31] NCommander: "This file must be an executable makefile" [http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules] [13:32] Ok [13:32] I guess that's been defined then [13:37] NCommander, so basically the syntax is of bash? === asac_ is now known as asac [13:38] THere are no bashisms [13:38] what syntax does it follow then? [13:38] Pop open an existing package, and take a look [13:39] (hello is a good package to see) [13:44] NCommander, i'm currently viewing it [13:44] its pretty much [13:44] target: [13:44] command1 [13:44] command2 [13:44] (remember, use tabs, not spaces) [13:44] what i'd actually like to do, is a costumize parameter for ./configure [13:45] something like [13:45] if amd64 then pass this [13:45] Just ./configure *arguement one* *argtwo*, etc. [13:46] NCommander, hang on i'll paste something, try to see what might be wrong with my syntax [13:46] on pastebin [13:48] NCommander, http://paste.ubuntu.com/39900/ [13:48] ;) [13:49] what's the issue? [13:50] when it build in amd64, it will trigger an error instead of building it [13:50] I think you need quotes around --disable-wine [13:50] NCommander, ah i see [13:50] loell: what error do you get? [13:51] gesser, just a sec, accessing my ppa ;) [13:52] geser, https://launchpad.net/~loell/+archive/+build/698157 [13:52] oops, its suppose to be http://launchpadlibrarian.net/16992542/buildlog_ubuntu-hardy-amd64.gyachi_1.1.48-1~ubuntu2_FAILEDTOBUILD.txt.gz [13:54] geser, basically it just says, dpkg-buildpackage: failure: debian/rules build gave error exit status 2 [13:55] loell: looks like configure isn't called at all [13:55] my guess is the indention in your debian/rules [13:56] try either indenting the WINE = ... line or move this ifeq block before the targets [13:56] geser, ah ok :) [13:57] i'll try both NCommander and your suggestions, it should be somewhere there :) [13:57] thanks both.. [14:33] morning LucidFox === Kopfgeldjaeger is now known as Kopfi|offline === fargiolas is now known as fargiolas|afk === paul__ is now known as Kiliman === Kiliman is now known as Kilimanjaro [17:05] I received this comment - Apps in menu file is deprecated, please adhere to new standard - Anyone know where i can read up about this? [17:08] stefanlsd: http://standards.freedesktop.org/menu-spec/latest/apa.html [17:09] Oh, sorry. menu files. [17:09] file:///usr/share/doc/menu/html/ch3.html [17:18] persia: thanks! [17:26] persia, can you help me figure out a transition? [17:26] I'm not sure if I can make this work with conflicts/replaces, or if I need to make dummy packages [17:28] It looks to me like the last wine upload wasn't the right fix, can someone have a look and see if they agree? [17:28] * Added procps to Build-Depends to make postinst happy. [17:29] I think it should be in Depends, as the postinst is install-time, not build-time. === Kopfi|offline is now known as Kopfgeldjaeger [17:30] http://launchpadlibrarian.net/16971889/buildlog_ubuntu-intrepid-i386.lmms_0.3.2-1ubuntu2_FAILEDTOBUILD.txt.gz is a build failure that it is causing [17:30] Yeah, that looks wrong [17:31] It seems you can only have one package in the Replaces field [17:32] what's the best way to deal with fixes to a Ubuntu native package (ubuntu-dev-tools)? Should I request a merge for my change in bzr or rather request sponsorship for a built package? [17:32] The former I believe in the case of ubuntu-dev-tools, but I may be wrong [17:35] NCommander, thanks, will do [17:35] hey jelmer [17:35] NCommander: grep-dctrl , -F Replaces -s Package,Replaces < /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_intrepid_main_binary-i386_Packages [17:36] NCommander: that suggests you can have more than one Package in a Replaces field [17:36] Doesnbt' seem to work though [17:36] grep-dctrl [17:36] er [17:36] Conflicts: xfce4-mcs-manager, xfce4-mcs-plugins, xfce4-mcs-plugins-extra [17:36] Replaces: xfce4-mcs-manager, xfce4-mcs-plugins, xfce4-mcs-plugins-extra [17:36] That's what I have in control [17:37] dpkg: considering removing xfce4-mcs-manager in favour of xfce4-settings ... [17:37] dpkg: no, cannot proceed with removal of xfce4-mcs-manager (--auto-deconfigure will help): [17:37] xfce4-mcs-plugins-extra depends on xfce4-mcs-manager (>= 4.4.0) [17:37] you would need a Provides: to fix that one I think [17:37]