Maybe the vxl package should be rather removed?
Hi Mathieu, I've just came across your bug report that requests to have the vxl package orphaned. AFAIUI, there are no packages in debian that link against it. If this is true, I would argue to have the package removed. It seems to be inside debian, providing this software as system library serves little value and that interested users are much better off compiling from upstream sources directly. Do you agree? In this case, we should reassign this bug to ftp.debian.org and ask for its removal. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0ccebK+VmuQe-vzxRZP04_XNSySNR2sW9=j9+ruqvgg2n...@mail.gmail.com
Re: Monitoring debian/shlibs.local files?
Cyril Brulebois writes:
> xine-lib:
> =
> libxine 1 libxine1-bin (= ${binary:Version})
this is totally done on purpose to avoid circular dependencies, see bug
#454267.
moreover we are considering introducing an shlibs.local file for ffmpeg
for tightening internal dependencies in the generated binary package
from the source.
both packages have the same motivation: Make dpkg-shlibdeps behave
differently for generated binary packages compared to packages linking
against the library. I acknowledge that this is rather rare and should
be used in general, but for these two cases, I find shlibs.local a
totally reasonable approach.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian upload monitor
Enrico Zini <[EMAIL PROTECTED]> writes: > Whether it belongs to QA or ftp-master, is what I'm trying to find > out. May I suggest that each ACCEPTED mail sent by dak could include a list of the last n accepted packages. This way no extra active service would need to be established. n is either fixed (I feel 5 might be a reasonable value), or configurable somewhere. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
oops is pretty unmaintained and has RC bug: #406491
Hello dear QA Team, I'm having a hard time with a package I'm co-maintaining. It is a small proxy server called oops. It currently doesn't work with glibc > 2.5, see #406491 for details. I cannot reach the original Maintainer Michael Zehrer (his mailserver refuses to accept mails), and upstream seems to be dead for years. I'm no longer using the package and there have no longer interest in maintaining it. Popcon reports about 20 users for the package. I wanted to ask if someone from the QA team thinks this package was worthwile to keep. If yes, I'll orphan the package. If not, I'd like to ask for its removal. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: 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 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
