Re: Testing Njam package
On 11/4/05, Anibal Avelar <[EMAIL PROTECTED]> wrote: > > Hi, I'm working in the njam package. I have ready a beta package. Perhaps you might want to have a look at the njam package in ubuntu: http://archive.ubuntu.com/ubuntu/pool/universe/n/njam/ It already includes a man page, I just checked. -- regards, Reinhard
Re: Proposal for collaborative maintenance of packages
On Mo, 2005-12-19 at 15:38 +0100, Stephan Hermann wrote: > On Monday 19 December 2005 11:17, Raphael Hertzog wrote: > > Actually, the Ubuntu people doing REVU didn't event think of using a VCS > > because they are handling uploads of source packages in their system. > > Adding a VCS layer has some advantages however : traceability of > > contributions from an applicant is one for example. > > Well, REVU was a tool which we needed for a special purpose: > > To get rid of the wiki page we had. That we've accomplished. > > REVU2 will be a much better approach. That's right. REVU was written for a very special purpose: to assist exact the workflow MOTUs have. It was designed after we defined that workflow. REVU2 will optimize that. What Raphael is suggesting has a brighter scope: He talks about 'collaborative maintenance', so more than one developer works on the same package. This is basically what we MOTUs do with all universe packages. This means that the results of the project Raphael started is very valuable to us MOTUs. > What you are suggesting is already there. It's called "hct" and it's keybuks > child. So, seeing this in an environment of Ubuntu: I think (or I hope) hct > will be included in launchpad, and then we will include some parts of REVU3 > (I hope :)) into launchpad as well. > You can read everything on http://wiki.launchpad.canonical.com, especially > the > part about Soyuz. > For the REVU2 part, you can read the spec on > https://launchpad.net/distros/ubuntu/+spec/revu . > > So, IMHO for the MOTU area, there is no need to reinvent a wheel. I disagree. Soyuz is a reimplementation of the archive software. HCT addresses the problem of package publishing within Soyuz. In what scope HCT will support 'collaborative maintenance' is AFAIK quite unclear. I'm very sure that the 'collaborative maintenance' project will help us to reduce divergence from debian in ubuntu. That's the reason why I will definitively join that project, and I want to encourage fellow MOTUs to support it as well. Divergence is a topic that IMO we didn't discuss too much lately, which I will try to start shortly. The utnubu project addresses divergence from ubuntu to debian, I think we should also have a serious discussion about this. But this is another topic. -- Reinhard Tartler <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Proposal for collaborative maintenance of packages
On So, 2005-12-18 at 17:19 +0100, Raphael Hertzog wrote: > following the last discussion at the Debian-QA meeting on Darmstadt, it > appears that the proposal called "Collaborative maintenance" is of generic > interest : > - for Debian sponsors and Debian mentors > - for QA which may use the infrastructure for orphaned packages > - for Ubuntu's MOTU School > > I tried to describe the big lines of the project in this wiki page: > http://wiki.debian.org/CollaborativeMaintenance I very welcome your ideas. I think they have definitively the potential to improve the quality of both debian and ubuntu. > I'm crossposting this to all people involved (even people responsible of > the REVU tool used by Ubuntu) because I'm sure that we should all work > together to realize this project. Thank you for your invitation, I'm very interested in making this project a success. I think it is rather long term, though. > This infrastructure is seriously needed in Debian because: > - team maintenance with SVN is more and more popular, and a good web > interface above a SVN repo of Debian packages would help all those > teams > - an official way to follow interaction between mentors and sponsors is > needed and actual mentors.debian.net/sponsors.debian.net are not enough > for that > - we need to facilitate the work of sponsors because we're lacking > sponsors > - we need to let skilled external contributors maintain packages for us > (when they don't want to become DD) on your wiki page, you mention explicitly getting packages from MOTUs, potential MOTUs and completely newcomers into debian. I really appreciate that. I agree that such an infrastructure is needed. People have already pointed out in this thread, that launchpad is supposed to address some of the points you mentioned in your email and on the wiki page. I'd like to comment on this, too: Launchpad is all about collaboration, yes, so it is an interesting tool for this project. Still, I don't think launchpad is the answer for the complete project scope. You are talking about "collaborative maintenance", this means several persons working on a specific debian source package. I'm not sure in what scope HCT will be able to address this, since it also defines a bit different workflow. Since VCS seem to be quite political, and there are a lot of opinions about that topic. I agree that a VCS is very useful to track changes. You want to use it for being able to track the contributions of a submitter. I agree that this feature is very useful to ubuntu as well, since we would this information for approving MOTU candidates. Therefore I don't want anyone to force a specific tool. Therefore I'd suggest that SVN should not be the only interface for submitting packages. svn-buildpackage is a really nice tool, I like it very much. But I also accept that some people refuse to use SVN, as well that some people refuse using launchpad and HCT because of political reasons. Therefore I'd rather using svn as 'backend', where all Meta information is used. But I'd really appreciate it, if there were alternative interfaces to submit contributions. I could imagine having an bidirectional svn <-> bzr gateway, so that bzr users can submitt via this tool as well. (as far as I heard hct will use bzr under the hoods as well, so perhaps this way we could gain hct as additional interface). An obvious simple interface would be raw source packages, uploaded by dput or other means. This is the only interface REVU currently provides. > The very same reasoning applies even more to Ubuntu where packages do not > have an official maintainer. Changes on packages have to be monitored to > know if a package needs to be uploaded. Also they have the same > problematic of "sponsoring" with their "MOTU school". Not only to MOTUs. I think the scope can easily extended to quite every group maintained package or set of packages. I see no reason not to accept external help. > Furthermore, if we can standardize this infrastructure between > Debian/Ubuntu, it will be easier to integrate packages created by Ubuntu > MOTU in Debian (I'm speaking of packages which don't exist in Debian yet). I could imagine that the utnubu team will be interested in using such an infrastructure to invite newcomers getting their packages into debian and eventually into ubuntu as well. Therefore I added utnubu-discuss to CC: list as well. -- Reinhard Tartler <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Proposal for collaborative maintenance of packages
On Mo, 2005-12-19 at 11:17 +0100, Raphael Hertzog wrote: > I don't want to change how Ubuntu works. I just want to find a decent > way for Debian to let external contributors integrate their work within > Debian and in particular for Ubuntu developers. Because it's in the > interest of Ubuntu developers to merge their work within Debian. We are still improving our workflows. So every suggestion is welcome. Your scope matches the work we MOTUs do very well, so I think we can and should work together for the profit of both debian and ubuntu. > Actually, the Ubuntu people doing REVU didn't event think of using a VCS > because they are handling uploads of source packages in their system. > Adding a VCS layer has some advantages however : traceability of > contributions from an applicant is one for example. To be honest, I really considered using a VCS under the hoods for REVU as well, but I'd decided against it, because I think it would be worth it given the scope of REVU. For a larger scope like you suggest, we should definitively use the opportunities it offers. > I'd like to have wrappers for doing things locally : > - download source package from the good repository (without having to > type a huge URL) > - run most checks on it (pbuilder, piuparts, lintian, ...) > - display analysis > - etc. Yes, this is effectively what REVU is supposed to do. I think REVU2 can contribute some code this as well as the presentation of the results. > But applicants should directly learn how to work in teams since that > what they will have to do later anyway ... so the use of a VCS in the > process is a good thing (in the Debian point of view at least). Even more in ubuntu, where we have much fewer explicit maintainers, and most uploads are effective NMUs anyway. I could image that some day, MOTUs will rather think about a set of 'diverged' packages, which needs active maintenance. Changes to diverged packages could be tracked in tools from this project. > However that use could be hidden behind the scenes for those who prefer > to not use such a system. I'm thinking here of REVU which handles upload > of source package directly. A script could be written to integrate the > source in the repository... This is exactly what I mean with "providing several interfaces", not just svn. Svn is great, sure, but I wouldn't want to force everyone to use svn and/or svn-buildpackage. svn-buildpackage can be useful as backend, though. -- Reinhard Tartler <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [OT?] debmirror does not add index files
Goswin von Brederlow wrote: > Try using http. Or try reprepro instead. I'm considering orphaning > debmirror in favour of reprepro. does reprepro support 'real' mirroring of Packages/Sources file preserving signatures from the upstream mirror? From what I see it does not. This is the only feature which keeps me on debmirror. Greetings, Reinhard > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Choice between ubuntu or brand new package for Bug#345039
David Newgas <[EMAIL PROTECTED]> writes: > Bug#345039 is an request for > "kzenexplorer" (http://kzenexplorer.sourceforge.net/) to be included in > Debian. It is currently already in Ubuntu > (http://packages.ubuntu.com/kzenexplorer). I created a brand new Debian > package (lintian clean except for lack of a man page) before noticing it > was in Ubuntu. Which is preferred, a new package or using the Ubuntu > one? I think it is most polite if you would ask the ubuntu contributor of the package for collaboration. If you doesn't answer, forward that mail to 'ubuntu-motu@lists.ubuntu.com' for additional attention. > And if the latter, is it simply done by using the Ubuntu > orig.tar.gz/diff.gz/dsc ? If the ubuntu package suits you, then you can take this as base, and use that as debian package. Example from my personal experience: The package keepassx was uploaded to ubuntu, and I noticed that it was missing in debian. I mailed the maintainer in ubuntu, and now he is a Co-Maintainer of the keepassx package in debian. Later I requested the debian source package to be synced into ubuntu, so we have the same source package in both distros. In general, if you want to adpot a package from ubuntu, feel free to just take that as base. If it doesn't suit you (because it uses CDBS or something), feel free to package it on your own. In any case it is very polite to mail the ubuntu contributor and CC: ubuntu-motu@, so that we can see if we really need the divergence. The best solution for both distros is to maintain a package in debian and sync it to ubuntu. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Looking for a maintainer with experience in debconf programming
Hi there, I intend to take over an existing package not being in debian yet. The original packager seems dead, at least he didn't respond me in two emails, but anyway. He used a lot of debconf in his package. I'm not a debconf pro at all, and I would feel much better if someone could look at the .postinst and the .config file of the boxbackup source package and tell me the biggest mistakes: http://siretart.tauware.de/upload-queue In fact, I'm considering dropping all the debconf magic, converting the current script with a config-setup helper. I expect this would faciliate upgrades, but I'm still a bit undecided. Thanks for your answers. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for a maintainer with experience in debconf programming
James Westby <[EMAIL PROTECTED]> writes: > On (17/04/07 22:08), Reinhard Tartler wrote: >> I intend to take over an existing package not being in debian yet. The >> original packager seems dead, at least he didn't respond me in two >> emails, but anyway. >> >> He used a lot of debconf in his package. I'm not a debconf pro at all, >> and I would feel much better if someone could look at the .postinst and >> the .config file of the boxbackup source package and tell me the biggest >> mistakes: >> >> http://siretart.tauware.de/upload-queue > > I have taken a very quick glance over the scripts. It appears like his > implementation is pretty good, the templates look good, and the config > and postinst seem fairly clean. Thank you very much for your review. > > However there is an option to handle the config files through debconf. > It appears as though if this is enabled the config files will be > overwritten unconditionally from postinst, which isn't good. I'm not > sure whether they are marked as conffiles, so it might not be a policy > violation, but it is definately discouraged. > > You may wish to look in to ucf if you would like to build on his work > but avoid this problem. Ok, I'll look into this. thanks for pointer. >> In fact, I'm considering dropping all the debconf magic, converting the >> current script with a config-setup helper. I expect this would faciliate >> upgrades, but I'm still a bit undecided. >> > > Could you tell me what config-setup is please? No, I don't now about some software called config-setup. I would have to write a helper script which does the setup of a boxbackup site. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpJxkwAPETNk.pgp Description: PGP signature
Re: RFS: php-ffmpeg
"Raphael Geissert" <[EMAIL PROTECTED]> writes: > Build dependencies are ok now (I tested with pbuilder). > After testing under a clean chroot I noticed that it doesn't depend at > all on ffmpeg. How that? are you shipping (yet another) private copy of the ffmpeg source? Please don't do that. Supporting ffmpeg security-wise is hard nowadays anyways, please don't make it even harder by shipping yet another copy of ffmpeg. Thanks. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prompt to install missing software?
John Pye <[EMAIL PROTECTED]> writes: > Another thought: doesn't Totem have some kind of 'codec finder'? Implemented here: https://wiki.ubuntu.com/EasyCodecInstallation No idea what's the status about that in Debian. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of (un)sponsored packages on Mentors (approximate)
Christoph Haas <[EMAIL PROTECTED]> writes: >> Perhaps someone could motivate siretart to adapt REVU >> (revu.tauware.de) features to mentors.d.n code and Debian? I seem to >> have seen a video or read somewhere that he intended to do something >> like this. > > I'm about to refactor m.d.n anyway (as I do every to years for the sheer > boredom). Wow. Well, the plan was to refacture REVU as well, so perhaps we could coordinate/merge the ideas of REVU here? > So if anyone could tell me what features REVU has that m.d.n is lacking > then I'll consider adding them in the next release. The main motivation of programming REVU was to get rid of using a wiki for reviewing packages. (no shit, in ubuntu, we used a terribly long wiki site for exchanging comments about the package). What users of revu like (I think) is the possibility to directly comment on the upload. You get instant feedback from the reviewers what still need to be done on the package. What reviwers of revu like is that you can directly see the source of the package, can verify things like debian/copyright and debian/rules online, can look at buildlogs and lintian/linda reports and so on. This way you can check the things which are very often done wrong by beginners before you download the package and have a closer look. You can read more on how REVU is supposed to work here: https://wiki.ubuntu.com/REVU2Spec As for development, I've been contacted by the LiMux project and from the debian games team who are both interested in trying out revu. I remember some french ubuntu group, who are maintaining their own revu instance (sorry, I forgot the link, it was in plain french anyway). I could really need some help, since I'm currently rather busy with other work :( -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of (un)sponsored packages on Mentors (approximate)
"Paul Wise" <[EMAIL PROTECTED]> writes: > On 7/28/07, Rogério Brito <[EMAIL PROTECTED]> wrote: > >> Do you happen to have the link to this video? I would love to watch it >> and learn more about the process of packaging programs. > > My memory is sketchy, but I think it was the debconf7 debian-games BoF: > > http://meetings-archive.debian.net/pub/debian-meetings/2007/debconf7/low/341_Debian_Games_Team_BoF.ogg Yes, that's it. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of (un)sponsored packages on Mentors (approximate)
"Raphael Geissert" <[EMAIL PROTECTED]> writes: >> Can mark comments as 'advocating an upload' > > By the way, is there any way to make sure that the person marking a > comment as 'advocating an upload' is really a DD (or in REVU's case > UD, if that's how they call them :-/ ) Yes. >> Unpacked source trees > > I think it is easier to download the package files and check > everything in the local computer than browsing every single file with > a web browser. Otherwise I would expect the online file viewer to have > syntax colouring and that kind of things. As said in my previous post, this is intended to have a rough overview of the package to decide if it's worth at all to download it. Had helped me a lot while reviewing ubuntu packages. >> Lintian/linda output >> >> FTBFS checks > > What kind of checks does it perform? Lintian/linda, plus a pbuilder log. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of (un)sponsored packages on Mentors (approximate)
"Raphael Geissert" <[EMAIL PROTECTED]> writes: >> > What kind of checks does it perform? >> >> Lintian/linda, plus a pbuilder log. > > Is every uploaded package automatically built inside a pbuilder? No. It needs a local admin to manually start the build. The binaries aren't available for download either. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: steam-powered
"Michael Gilbert" <[EMAIL PROTECTED]> writes: > I am looking for a sponsor for my package "steam-powered". > > * Package name: steam-powered > Version : 5 > Upstream Author : Michael Gilbert > * URL : no website > * License : gpl > Section : contrib/games Does the package has an active and resposive upstream? How do you intend to care for bugreports? Where do you intend to forward bugs in the games installed by steam-powered to? Are you willing and able to do a security audit of the software? As far as I understand, it downloads more or less random executable binary data from a commercial vendor (valve), and executes the software. Doesn't this impose a security risk for the user? How can Debian support this package security wise? On what architectures does your package work? only on i386 or on amd64 as well? > It builds these binary packages: > counter-strike - Valve's counter-strike video game > counter-strike-source - Valve's counter-strike-source video game > day-of-defeat - Valve's day-of-defeat video game > day-of-defeat-source - Valve's day-of-defeat-source video game > half-life - Valve's half-life video game > half-life2 - Valve's half-life2 video game > steam-powered - Valve's steam game content delivery system What are the contents of that binary packages? AFAIU, it downloads the software from the net, so why provide binary packages here? TBH, I see a lot of problems for debian with supporting this package. Unless you can find a supportive DD helping you with the package, and can satisfactory answer questions like in this email, I don't see a place for it in Debian. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: amtterm
Hello PIAT, Franklin PIAT <[EMAIL PROTECTED]> writes: > I am looking for a sponsor for my package "amtterm". "Paul Wise" <[EMAIL PROTECTED]> writes on 31.10.2007: > Quick review of the diff: > > The patches need proper authorship info (name and email) > > Might want to use quilt for the patches > > 10_destdir.dpatch shouldn't be necessary, you can usually override > makefile variables by doing something like $(MAKE) prefix=/usr > > the homepage you specify is more of a download location, which usually > goes in debian/copyright. probably best to remove it > > mk/*.dep and maybe Make.config look like they should be removed in > debian/rules clean. > > Don't forget to send the patches upstream > > debian/watch only needs to be 2 lines long > > Remove the commented out commands and other cruft from debian/rules if > you don't need them. It seems that you did not react to Paul's suggestions to improve the package. Moreover it seems that you have not updated to package since that 27 Oct 2007. ay I ask you if you are still interested in maintaining the package? At our university, we have quite a number of machines with Intel's AMT and having a well maintained package would be helpful. You might also be interested to hear that a collegue of mine, Michael Gernoth (CC'ed) maintains a private git repository of amt at [1]. He just mentioned to me that at least some of his package really should go in the debian package. Please tell me if you are interested in Co-Maintenance or if you prefer if someone else would take over this ITP. [1] http://git.zerfleddert.de/cgi-bin/gitweb.cgi/amt -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#523338: ITP: radare -- Free advanced command line hexadecimal editor
AFAIUI sponsor requests should go to debian-mentors. Please not that I'm not a mentors regular, so I'm not really sure of the exact procedures here. Nevertheless, I'm copying the mailing list. Sebastian Reichel writes: > I am searching for a sponsor, so feel free to do so ;) My preliminary review of http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=radare minor points: * spurious configure target, please remove it. * build-target could be improved, e.g. by placing both variants in different make targets. also consider a VPATH build. * clean rules unpatches before running clean. This will break if you had modifications to the clean parts of the build system. You don't do that here, but I'm mentioning it just in case. The src/arch directory seems to contain source files of various licenses, that I believe are part of the created binaries. I therefore do not think that we can redistribute the radare binary under GPLv2. E.g.: - src/arch/dalvik seems to come from the android project, which is Apache License 2.0. Please note that in debian/copyright. - src/arch/x86/udis86/* seem to be BSD licensed. - the files in src/arch/sparc seem to be GPL-3 licensed. In general, run the tool `devscripts -r .` in the top level root directory to get a brief license check. AFAIUI this is the tool ftpmaster uses to examine NEW packages. I fear debian/copyright needs to mention all this. Are there other opinions on that from mentors? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: aegis (updated package, NMU)
Walter Franzini writes: > Dear mentors, > > I am looking for a sponsor for the new version 4.24-5.1 > of package "aegis". This upload is an NMU fixing also 2 RC bugs. > > It builds these binary packages: > aegis - transaction-based software configuration management > aegis-doc - documentation for aegis > aegis-tk - aegis Tk user interface > aegis-web - aegis web based user interface > > The package appears to be lintian clean. > > The upload would fix these bugs: 419472, 509994, 522336, 530042, 533921, > 540343 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/a/aegis > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget http://mentors.debian.net/debian/pool/main/a/aegis/aegis_4.24-5.1.dsc > > I would be glad if someone uploaded this package for me. I've had a brief look at the package, and have a few comments on it: - the orig.tar.gz you've used is content-identical but not bit-identical. This means that the archive will reject the upload because the checksums do not match. - you did not follow the NMU protocol [1]. At the minimum, you should attach the debdiff to the bugs you are addressing here. In order to faciliate this, please have a look at the nmudiff(1) command, espc. at the option '--old'. - Did you manage to talk about this NMU with Christian Meder? Does he acknowledge this upload? In case you didn't manage to contact him, I think you should adopt the package and use maintainer version numbering. Espc. after reading #470162 [1] http://www.debian.org/doc/developers-reference/pkgs.html#nmu-guidelines -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: aegis (updated package, NMU)
CC'ing Christian, so that he is in loop. Walter Franzini writes: >> - the orig.tar.gz you've used is content-identical but not >>bit-identical. This means that the archive will reject the upload >>because the checksums do not match. > > I'll regenerate the .changes using the proper archive. > > The problem may be related to the procedure used to produce the upstream > tarball, it is created with file ownership different from root.root and > git-buildpackage /probably/ is unable to reproduce it exactly. git-buildpackage is able to reproduce exactly iff you use pristine-tar, which is optional. In any case, I find the pristine-tar integration pretty easy to use. >> - Did you manage to talk about this NMU with Christian Meder? Does he >>acknowledge this upload? In case you didn't manage to contact him, I >>think you should adopt the package and use maintainer version >>numbering. Espc. after reading #470162 > > I don't know if he acknoledge the upload, but I've CCed him in my first > RFS without receiving any response. I've also announced my intention to > NMU on the BTS a week before the upload, without reactions. > > If I'm not wrong, you are suggesting I hijack the package (since it's > not orphaned). Essentially yes. > Is it possible to do sponsored hijack? You'd need to find a sponsor that signs the hijack with his key. Given at the history of the aegis package, I think I'd be willing to do so. Christian seems to be very busy since quite some time. While he did answer to your most recent posts about aegis on debian-de...@l.d.o., as far as I understand you, he has not gotten back to you. If you follow up on the bug reports to obey the NMU protocol, I'd be willing to upload your NMU at once. For an hijack, I'd upload to 10/day-delayed, so that Christian has some time to object to this upload either by doing another upload in the mean time or by asking me to abort the upload. If other debian developers disagree that this is a good way to go, please tell me. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: aegis (updated package, NMU)
Walter Franzini writes: > Reinhard Tartler writes: > > [...] > >> If you follow up on the bug reports to obey the NMU protocol, I'd be >> willing to upload your NMU at once. > > I've updated the package on m.d.n to include the proper orig.tar.gz and > sent the output of nmudiff to the variuos bugs. OK, NMU is uploaded to DELAYED/2, this means that it should reach the archive on tuesday. Christian, if you object the NMU, please just tell me to abort the NMU or even better, upload a new version of aegis with the version 4.24-6 or later. This will also discard the NMU. You might also consider accepting Walter as new co-maintainer or maintainer. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpKEaCC5pQ8N.pgp Description: PGP signature
Re: RFS: aegis (updated package, NMU)
Walter Franzini writes:
>
> Looking at https://buildd.debian.org/~luk/status/package.php?p=aegis
> there are some dependencies installability problem:
>
> * on kfreebsd-* fhist is missing due to #414005 (still open after 2 years)
>
> I'll contact the maintainer.
I'm CC'ing the kfreebsd porter list. Maybe they want to do an porter
NMU, or can give at least input how to solve this?
> * on ia64 and mips:
>
> aegis (= 4.24-5.1) build-depends on debhelper (>= 5) {debhelper (= 7.4.2)}
> debhelper (= 7.4.2) depends on dpkg-dev (>= 1.14.19) {dpkg-dev (= 1.15.4)}
> dpkg-dev (= 1.15.4) depends on perl-modules {perl-modules (= 5.10.1-4)}
>
> How should I handle the above problem?
I guess this is a transitional problem that can be resolved by the
debian-wb-team. (also CC'ed).
@debian-wb-team, can you confirm my guess? Is there anything that we can
or should do about this?
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: aegis (updated package, NMU)
Walter Franzini writes:
> Do you have the time to upload 4.24-5.2?
> It fix #549231 introduced in 4.24-5.1.
Uploaded without delay.
Small fix: I've removed the duplicate ${misc:Depends} in debian/control
just before uploading.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678500: marked as done (RFS: cppreference-doc/20120620-1 [ITP] -- C and C++ standard library reference manual for English language.)
On Sun, Nov 11, 2012 at 5:24 AM, Debian Bug Tracking System wrote: > Your message dated Sun, 11 Nov 2012 04:20:30 + > with message-id > and subject line closing RFS: cppreference-doc/20120620-1 [ITP] -- C and C++ > standard library reference manual for English language. > has caused the Debian Bug report #678500, > regarding RFS: cppreference-doc/20120620-1 [ITP] -- C and C++ standard > library reference manual for English language. > to be marked as done. > From: Bart Martens > To: 678500-d...@bugs.debian.org > Cc: > Date: Sun, 11 Nov 2012 04:20:30 + > Subject: closing RFS: cppreference-doc/20120620-1 [ITP] -- C and C++ standard > library reference manual for English language. > Package cppreference-doc has been removed from mentors. Hi, I wonder what happened? Did you find a sponsor? Do you still look for a sponsor? Why have you had the package removed from mentors? I just came across this resource and was happy to see that someone already worked on packaging. Now I wonder why it hasn't been uploaded yet. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0cceb4AbJW=r1r+_or2x4sjfwkaqhubo40ytfcy3tpnxm...@mail.gmail.com
Re: Bug#733767: RFS: entr/2.5-1 [ITP] -- Run arbitrary commands when files change
On Wed, Jan 8, 2014 at 11:07 AM, Yuri D'Elia wrote: > On 12/31/2013 07:13 PM, Yuri D'Elia wrote: >> I am looking for a sponsor for my package "entr": >> >> * Package name: entr >> Version : 2.5 >> Upstream Author : Eric Radman >> * URL : http://entrproject.org/ >> * License : ISC, BSD-3-Clause, BSD-2-Clause >> Programming Lang: C >> Description : Run arbitrary commands when files change > > Anybody interested in sponsoring the package? thanks for preparing the package, it looks fine to me and works in my chroot, so I've uploaded it for you. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0cceb1pgys-wccu_zw+szk-shum8fvn_n6+x+_0km0fjh...@mail.gmail.com
Re: Bug#737046: RFS: entr/2.6-1
On Thu, Feb 6, 2014 at 2:36 AM, Yuri D'Elia wrote: > On 01/29/2014 06:32 PM, Yuri D'Elia wrote: >> Changes since the last upload: >> >> * New upstream release. >> * Override build to use shared copy of strlcpy (and friends) using libbsd. >> * Fixes build on kFreeBSD. > > ♩ Ding-a♫ling-aling Hi Yuri, I'm willing to sponsor this package again for you, but I missed your email as I don't read mentors on a regular basis. Before uploading, could you please have the VCS-* fields not point to Eric's upstream mercurial repositories? These fields are intended to point to your packaging VCS instead, so that tools such as http://manpages.debian.net/debcheckout work out of the box. For myself, I prefer doing packaging on git.debian.org, regardeless of what VCS upstream uses. You are free to do so as well, ideally as part of collab-maint, so that I can give you a hand more easily. Again, thanks for your work on the packaging. Reinhard -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0ccebc-oLaSS5F28=uP4SYCeJ5wZTiE_-Aku7zaD=khph...@mail.gmail.com
Re: RFS: libdc0 and valknut (ITA)
Maia Kozheva writes: > I am looking for a sponsor for my updates to the orphaned packages > libdc0 and valknut, taking over as the maintainer. > > libdc0 version 0.3.23-1 can be found here: > > http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libdc0 I've sponsored libdc0 yesterday. > valknut version 0.4.9-1 can be found here: > > http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=valknut > > Since valknut depends on the new version of libdc0, it should not be > uploaded until the former package is accepted and built. agreed. please ping me again if you get confirmation from the archive. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian and Patents
I was asked to comment on this as FFmpeg maintainer in Debian. On Tue, Aug 31, 2010 at 09:34:10 (CEST), Boyd Stephen Smith Jr. wrote: > In , Praveen A > wrote: >>I was reading through the wiki and found this, >> >>* Debian does not include software that is encumbered by software patents. >> >>This statement is correct for Fedora, but we have many *known* patent >>encumbered software in our repos like mp3 codec, ffmpeg etc. So I >>think, this item can be removed. Debian does not include software that is encumbered by *actively enforced* software patents. > I thought the patent encumbered software was banned from the repos due to > legal risk to SPI. I get my ffmpeg and mp3 stuff from the debian-multimedia > repositories which, while good, are not official. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522373 No need to further push on this bug right now, AFAIUI our DPL is working with ftpteam on it. Also there has been a related bit in his latest DebConf10 report to d-d-a on that topic. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwxu59ln@faui44a.informatik.uni-erlangen.de
Re: Debian and Patents
On Tue, Aug 31, 2010 at 17:30:28 (CEST), Sven Joachim wrote: > AFAIK Debian's ffmpeg package does not disable any decoders, only > encoders are stripped. So playing wmv/mp3/whatever works out of the > box, but to create your own mp3 files you need an uncrippled third-party > ffmpeg version. FFmpeg does not include an mp3 encoder, and never has. For creating mp3 files, you need lame, for which FFmpeg provides an wrapper. Unfortunately, lame turns out to have serious licensing problems: http://lists.debian.org/debian-legal/2010/08/msg00044.html -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hj659et@faui44a.informatik.uni-erlangen.de
Re: Debian and Patents
On Tue, Aug 31, 2010 at 17:00:16 (CEST), Matthias Klumpp wrote: > On Tue, 31 Aug 2010 13:12:37 +0530, Praveen A wrote: >> 2010/8/31 Boyd Stephen Smith Jr. : >>> I thought the patent encumbered software was banned from the repos due > to >>> legal risk to SPI. I get my ffmpeg and mp3 stuff from the >>> debian-multimedia >>> repositories which, while good, are not official. > It is. Debian Sid ships a version of FFMpeg which has disabled patented > codecs etc. This statement is wrong. We never disabled any decoder from ffmpeg. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp8i59iu@faui44a.informatik.uni-erlangen.de
RFS: pong2 -- Remake of old arcade classic in OpenGL
Package: wnpp Severity: normal * Package name : pong2 Version : 0.1.0-1 Upstream Author : Johannes Jordan <[EMAIL PROTECTED]> * URL : http://pong2.berlios.de/ * License : GPL Description : Pong2 is an up till now two player (networked) game inspired by the classical "Pong" from Amiga, which adds another dimension to the playing field. Crazy graphics, fast gameplay, great fun ;) . It also has multiplayer support! 2 players can play against each other. This is my first RFS. I checked my package with Matthew Palmers Checklist for sponsored uploads. It should be fine, but I'm open for any suggestions. Package builds cleanly within sarge and sid (tested with pbuilder) and has been tested on i386 and amd64. I think it is ready for inclusion in debian. You can get my source package from: http://siretart.tauware.de/pong2 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Shared library concern
On 4/16/05, François-Denis Gonthier <[EMAIL PROTECTED]> wrote: > I'm having a bit of a concern with a library target Code::Blocks produces > (It's a C/C++ IDE). > > Lintian currently reports: > > E: codeblocks: shlib-with-non-pic-code usr/lib/libcodeblocks.so > E: codeblocks: sharedobject-in-library-directory-not-actually-a-shlib > usr/lib/libcodeblocks.so Try compiling it with option "-fPIC". Some architectures like amd64 or ia64 require that for DSO. -- regards, Reinhard
RFS: londonlaw
I packaged the game londonlaw, it should be now ready for inclusion into debian, but I'm happy about any suggestions for improvment. The ITP is here: http://bugs.debian.org/306333 Description: london law game London Law is an online multiplayer adaptation of the classic Scotland Yard board game (also see Wikipedia), first published by Ravensburger in 1983. The game is unusually asymmetric; one player controls the movements of the criminal Mr. X as he tries to evade Scotland Yard, while another one to five players control five detectives trying to track him down. Mr. X has an advantage in access to transportation routes, and his precise location remains hidden for most of the game. The detectives have only the advantage of superior numbers, so they must work in concert to limit the criminal's options. London Law features an attractive map overlaid on high-resolution satellite imagery. It is a python application, packaged using CDBS. And great fun ;) As I'm not a DD, I'm currently looking for someone sponsoring this package for me. -- regards, Reinhard
Re: RFS: londonlaw
On 4/29/05, Nico Golde <[EMAIL PROTECTED]> wrote: > > I packaged the game londonlaw, it should be now ready for inclusion > > into debian, but I'm happy about any suggestions for improvment. > > > > The ITP is here: http://bugs.debian.org/306333 > Please provide a link to the source package. > Regards Nico Oh, I'm very sorry for forgetting the link, it was only in the ITP report. Sourcepackages are available here: http://siretart.tauware.de/debian/londonlaw -- regards, Reinhard
Re: Request for a sponsor for getwifi
On 5/8/05, martin f krafft <[EMAIL PROTECTED]> wrote: > also sprach Joshua D. Abraham <[EMAIL PROTECTED]> [2005.05.08.0212 +0200]: > > I am have not used waproamd, however, getwifi currently joins > > wireless networks with a similar configuration. It is meant to be > > run to join networks that you are using regularly. The updates > > I have been working on will include wep and wpa support. The next > > version will also include the ability to scan for networks that > > are being broadcast. It will use iwlist to scan for wireless > > networks but that isn't implemented yet. > > So why should we have getwifi in the archive in addition to > waproamd? Note that I know that waproamd has problems, so if you are > working to address those problems, that's great. However, please do > not just duplicate the functionality. I suggest you install waproamd > and check it out. wapraomd does not support wpa or manual configuration of the interface. I'm looking for a replacement for my hand crafted scan shellscript for quite some time, will have a look at this one. -- regards, Reinhard
Re: Bug#310994: ITP: openttd -- open source clone of the Microprose game "Transport Tycoon Deluxe"
On 5/27/05, Matthijs Kooijman <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: wishlist > Owner: Matthijs Kooijman <[EMAIL PROTECTED]> > > > * Package name: openttd > Version : 0.4.0.1 > Upstream Author : Various > * URL : http://www.openttd.org/ > * License : GPL > Description : open source clone of the Microprose game "Transport > Tycoon Deluxe" > > I am working on this package and would like to see it in debian. I am still > looking for a sponsor until I can apply as NM. As far as I understood it, it requires media files from the original game. Is this correct? Or are there free media files available? -- regards, Reinhard
Packaging Qube, Was: Looking for a sponsor
> I'd like to make new packages soon (Cube, libenet, etc.). Please note that cube has licensing issues. The game engine itself is zlib, but nearly all media files are not redistributable. The engine is itself will only run in i386, porting to amd64 (and other arches) is nontrivial. The author also refuses to accept any patches, because he considers cube as 'his baby'. A friend of mine has therefore forked cube, in order to get a real freely distributable version of the game out of the door with support for arches like amd64. It is however not really in a releasable state: http://wwwcip.informatik.uni-erlangen.de/~sibrklei/kg/ -- regards, Reinhard
Seeking for advice: Circular Build Dependencies.
Hi, I'm seeking for advice for how to handle this rather complicated solution. I'm packaging a large software base that builds a number of libraries and applications. In order to simplify things: - foo (source package) builds: - libfoo-dev, libfoo0, libfoo0-bin, ... - and build depends on libbar-dev - bar (source package) builds: - libbar-dev, libbar0, bar - and build depends on libfoo-dev Obviously, there are circular build dependencies, which means that neither package can be built without the other one. One solution would be to throw all sources into a big source package and build everything from that. This, however, is something that I'd really like to avoid, because one of the two packages is really large, takes hours to compile, and the whole thing would produce a really lot of binary packages. I'm therefore seeking for a solution that allows me to keep the sources separate. My first guess would be to use alternative build dependencies. However, this is problematic on the buildd network, because they will fail the build if the first alternative is not installable. Therefore, I've come up with this idea: - create a 'libbar-bootstrap' source package, which ship only headers - that builds a libbar-boostrap-dev, which in turn provides: libbar-dev - build foo against libbar-boostrap-dev - build bar against libfoo-dev - build foo again, this time against libbar-dev In my tests, it *seems* that apt indeed prefers a real package over a virtual package. I'm aware of the following drawbacks: - needs an additional source package (libbar-boostrap) and uploads - versioned depends on libbar-dev (probably?) won't work anymore My question now is: - has this approach been implemented in debian before? - do I miss something else here? Thanks for your thoughts. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa9581ka@faui43f.informatik.uni-erlangen.de
Re: Using d/copyright to exclude a directory EXCEPT certain files
I think I've implemented this feature here: https://salsa.debian.org/debian/devscripts/-/merge_requests/189 AFAIUI it needs someone to approve and merge it. -rt On Wed, Jul 22, 2020 at 12:15 AM Olek Wojnar wrote: > Hi mentors, > > I'm not the best with Perl and although I've looked through the source > code of mk-origtargz [1] I can't figure out how (if) it is possible to do > what I'm trying to accomplish. > > I think we're all familiar with the mk-origtargz function where one can > specify "Files-Excluded:" from the source tarball for various reasons. > Excluding a single file or a directory is trivial. Excluding a pattern of > files (e.g. *.jar) is just as easy. However, I can't figure out how to > exclude *all* of the files in a directory *except* for one or two that are > needed. > > Use case example: Upstream for Package A includes source/binaries for > Package B which is already packaged in Debian. The maintainer wants to > exclude Package B files from the processed tarball. However, upstream also > includes a configuration file or two required for Package A in a directory > containing several dozen Package B files. It would be much simpler to be > able to tell mk-origtargz to exclude the whole directory but leave the one > or two files that are needed. Otherwise, the maintainer would need to add > several dozen lines into the "Files-Excluded:" section which is more work > and more chance of making a mistake. > > So, is this currently possible? If not, is this something that's worth > filing a feature request bug for? > > Thanks in advance! > > -Olek > > [1] > https://salsa.debian.org/debian/devscripts/-/blob/master/lib/Devscripts/MkOrigtargz.pm > -- regards, Reinhard
Re: Clean-room build of deb package?
https://wiki.debian.org/sbuild On Thu, Dec 29, 2022 at 8:02 AM Barry Scott wrote: > On Fedora/RHEL I would use mock to build a RPM from source to ensure > that I have the RPM spec file correctly written. > > Mock ensures that no packages in my dev machine are used to build the RPM. > > What is the debian version of that tool? > > Barry > > > -- regards, Reinhard
Re: Bug#316503: ITP: istanbul -- Desktop session recorder
On 7/1/05, Luca Bruno <[EMAIL PROTECTED]> wrote: > * Package name: istanbul > Version : 0.1.0 > Upstream Author : Zaheer Abbas Merali <[EMAIL PROTECTED]> > * URL : http://live.gnome.org/istanbul > * License : GPL > Description : Desktop session recorder > > Istanbul is a desktop session recorder for the Free Desktop. > It records your session into an Ogg Theora video file. > To start the recording, you click on its icon in the > notification area. To stop you click its icon again. > .. > It works on Gnome, KDE, XFCE and others. you might be interested to learn that Daniel Holbach already packaged this for ubuntu, you may grab his sourcepackage from here: http://siretart.tauware.de/revu/details.py?upid=15 He will be glad to hear that you intend to maintain it for debian! -- regards, Reinhard
Re: new package
> Ok, I've taken another stab at it. There are no lintian or linda errors now. > All packages are located at clamtk.sourceforge.net/debian/2.01-3/ . > > Thank you for your time and help! Daniel Holbach packaged this one in the meantime for ubuntu. You can grab his package from here: http://siretart.tauware.de/revu/details.py?upid=14 Perhaps you can compare that work with yours? In either case, you should file an ITP against wnpp and close that bug in your changelog. For debian sponsoring, your package must be revision -1, i.e. 2.01-1. -- regards, Reinhard
Re: makefiles
On 7/7/05, PY LUYTEN <[EMAIL PROTECTED]> wrote: > i try to learn a bit as it seems i am not ready to develop any package. > I tryed the maintener guide but need more docs about makefiles, > makefiles.am and makefiles.in and could not find it - "man" being not > enough for me. > Did i miss a good doc (especially in french) ? For complete reference into GNU Make, you should have a look at the GNU Make manual [1]. These Makefile.am and Makefile.in are part of the autotools. autotut [2] is a nice tutorial into using them. Sorry, I'm not aware of french translations, though. [1] http://www.gnu.org/software/make/manual/make.html [2] http://seul.org/docs/autotut/ -- regards, Reinhard
Re: Dependencies and debconf configuration
On 9/25/05, Julien Valroff <[EMAIL PROTECTED]> wrote: > But installing a theme without installing the bootsplash utilities is > then possible, and totally useless. Don't you think this can mislead > users? Tell them, they rather want bootspash than the theme ;) -- regards, Reinhard
