Bug#625502: Inquiry re: adopting qt3
I'd like to ask to adopt Qt 3, entirely for the sake of the LSB. The LSB is working on removing Qt 3, but that effort won't be ready in time for wheezy, and I'd like for full LSB support to remain possible in Debian. What are your thoughts? I don't think this would take away from the release goal of ridding Qt 3 dependencies from Debian; it would be good, I think, to release with only LSB depending on Qt 3. I understand it's a C++ package of some complexity, and that I'd be responsible for analyzing security fixes, bugs, etc. on my own without upstream support from TrollTech. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc0532e.8080...@debian.org
Bug#616131: ITA: LSB package maintenance in Debian
On 02/16/2012 12:12 PM, Didier 'OdyX' Raboud wrote: I just noticed the worrying state of the LSB package in Debian: * Still in version 3.2 (released in January 2008) while 4.1 is out since a year (coincidently today); * RFA'd - #616131; * behind Ubuntu since at least Karmic (9.10) which already had 4.0. I would like to get the LSB package up to date before Wheezy's freeze, planned for June. For now, I just filled a Git repository [0] with all past Debian (at least those available on snapshot.debian.org) and Ubuntu releases (on the master-ubuntu branch). I think I mostly got authors and dates straight, but it was not fun. Now my intentions (despite limited available time) are: 1) put it under explicit team maintenance; Maintainer: debian-...@lists.debian.org ? [1] Uploaders: Myself + Chris ? 2) push the repository to collab-maint; 3) merge most of the current lsb (4.0) Ubuntu package into it, including dpkg-vendor magic to have both distros handled. 4) if needed, update it to 4.1; 5) upload a new version to experimental as soon as possible; 6) triage and if possible address all Debian bugs; 7) update the packaging to modern practices (short dh, etc) So, is anybody willing to join the fun ? Steve, Colin, Matthias: as the 3 last persons that uploaded the Ubuntu lsb package: would you be interested in merging the effort and (once done) try maintaining it in Debian first ? FWIW, this has been something the LSB has been discussing upstream, and we're willing to help with the work. If the project is willing, I'd appreciate having commit access and being an uploader. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f3d4498.7070...@debian.org
Bug#552568: getting synergy-plus into Debian
On 10/08/2010 08:25 AM, Mehdi Dogguy wrote: Please don't upload to unstable during the freeze and use experimental instead. 1.3.4-1 is now in experimental. Sorry for taking so long, everyone. I'll close this bug when the unstable upload is done (after squeeze). -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d04feb1.4040...@debian.org
Bug#522135: ITP: python-pip -- Alternative Python package installer
Package: wnpp Severity: wishlist Owner: Jeff Licquia licq...@debian.org * Package name: python-pip Version : 0.3.1 Upstream Author : Ian Bicking * URL : http://pip.openplans.org/ * License : MIT/X Programming Lang: Python Description : Alternative Python package installer This is Ian Bicking's easy_install replacement. It integrates with virtualenv, and does a number of things better. The package is pretty much done and is being tested. If you're impatient, my bzr repository should be here soon: http://bzr.licquia.org/pip/debian -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501257: ITA: cvsps -- Tool to generate CVS patch set information
retitle 501257 ITA: cvsps -- Tool to generate CVS patch set information owner 501257 Jeff Licquia [EMAIL PROTECTED] thanks I think I'll adopt this package, as it's still important for people converting their CVS repositories to other version control systems. I'm also in touch with upstream, and may adopt upstream as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482953: Orphan diald
retitle 482953 O: diald -- dial on demand daemon for PPP and SLIP thanks Well, no response. So, orphaned it is. I've already uploaded with the maintainer set to Debian QA Group. If anyone does want to work on the package, it might be worth looking at bzr.licquia.org; I have the version control for my package maintenance there. In particular, the work I had done to update to diald 1.0 is there. I'll leave it up for the foreseeable future, but it won't ever be updated; you're advised to branch off mine and go from there if you want to use it. As mentioned before, it might be worth considering whether to remove diald from the archive; it's old software that hasn't been maintained upstream in a long time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470186: Adopting synergy
retitle 470186 ITP: : synergy -- Share mouse, keyboard and clipboard over the network owner 470186 Jeff Licquia [EMAIL PROTECTED] thanks I use synergy at my workstation at home to control two computers. I've actually done the work to update the package; anyone interested can see the results here: http://bzr.licquia.org/loggerhead/synergy/debian/ If I hear no objections, I'll upload in a week or so. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470885: ITA: doclifter
retitle 470885 ITA: doclifter -- Convert troff to DocBook owner 470885 Jeff Licquia [EMAIL PROTECTED] thanks I actually have occasional need for this at work. I've already done some update work. The resulting source can be seen here: http://bzr.licquia.org/loggerhead/doclifter/debian If there are no objections, I'll upload in a week or so. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482953: RFA: diald
Package: wnpp Severity: normal It has been a long time since I've had dialup Internet, and even longer since this package has had an active upstream. I had thought I could become upstream, but this hasn't turned out to be the case. The last straw came when I decided to try and upgrade the package to the last version released by upstream, and couldn't figure out a way to test that the new build even worked. With the latest update, diald should still work, and continue to work for the foreseeable future. I suspect this package should just be dropped, but I get feedback on the package every so often, so I thought I'd give it one last chance. If I don't hear anything in two weeks, I'll orphan it. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444022: ITP: papi -- OpenPrinting PAPI suite
Package: wnpp Severity: wishlist Owner: Jeff Licquia [EMAIL PROTECTED] * Package name: papi Version : 1.0 beta Upstream Author : Norm Jacobs [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/openprinting * License : Mostly CDDL (some LGPL, some MIT-style) Programming Lang: C Description : OpenPrinting PAPI suite This is an implementation of OpenPrinting PAPI, a programming specification for cross-platform and cross-print-system printing. The package includes PAPI libraries, an implementation of the System V and BSD print utilities which use PAPI, and an Apache module for receiving IPP requests and passing them on via PAPI. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444022: ITP: papi -- OpenPrinting PAPI suite
Vincent Danjean wrote: For me, papi is a library with its tools to access hardware performance counters. It used a lot on some plateform (NUMA, ...) to analyze the performance of HPC programs. Google with papi give this link in first : http://icl.cs.utk.edu/papi/ This software is not packaged in Debian (yet ? but it needs a patched kernel). However, I think I would be better if you do not use 'papi' as the package name. Perhaps openprinting-papi or openprinting or ... What do you think ? I'm not particularly attached to the package name, but there will likely be issues with the library name. What's worse is that the OpenPrinting libpapi already appears in a few other distributions, and is already referenced in a published standard by the OpenPrinting group. So, perhaps, the hardware-counter PAPI group should consider a name change instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442394: ITP: virtualenv -- Python virtual environment creator
Package: wnpp Severity: wishlist Owner: Jeff Licquia [EMAIL PROTECTED] * Package name: virtualenv Version : 0.8.1 Upstream Author : Ian Bicking * URL : http://pypi.python.org/pypi/virtualenv/ * License : MIT-style Programming Lang: Python Description : Python virtual environment creator virtualenv creates custom Python virtual environments, each of which can contain their own modules and such which are incompatible with each other or with the system's installed modules. These are useful for running newer or older modules than are available, or for installing modules without requiring root access. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408118: sponsor? package?
Did you ever find a sponsor? Is your chessdb package available? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#222916: ITP: python-parted-rh -- Red Hat's Python bindings for parted
Martin Michlmayr wrote: * Jeff Licquia [EMAIL PROTECTED] [2003-12-04 15:47]: This is a port of Red Hat's python bindings to Debian. This package is needed by Anaconda. How does that differ from python-parted? Why are the -rh changes not merged in the former? Back in the day, Progeny wrote some Python bindings for parted. Those are the python-parted package. Several of our projects, including PGI and autoinstall, use those bindings. Afterwards, Red Hat wrote their own python-parted bindings. Both of us submitted our bindings to the parted maintainer, and he preferred the Red Hat bindings. However, he has yet (as far as I know) to merge those with upstream parted. Of course, Anaconda uses the RH bindings. When we went to do the Anaconda work, we realized we needed the RH bindings ported to Debian. So, we did them. I'm not averse to the python-parted-rh package replacing the python-parted one, but I want to make sure that projects using the other one aren't still relying on it.
Bug#222917: ITP: anaconda -- Red Hat's graphical installer
Package: wnpp Severity: wishlist This package will contain the runtime files for anaconda, Red Hat's award-winning graphical installer. This version has been modified to install using apt instead of rpm, and several other changes have been made to make it install Debian systems. The package consists of the runtime files and a picax module. The picax tool is actually used to create the install images. Packages are not available yet, but will soon be available at Progeny's Anaconda apt repository: deb[-src] http://archive.progeny.com/progeny/anaconda apt-repo/ A Subversion repository is also available at svn://svn.progeny.com/.
Bug#222918: ITP: pyxf86config -- Python bindings to libxf86config
Package: wnpp Severity: wishlist pyxf86config is a set of Python bindings to libxf86config. It provides an easy way to parse and write XF86Config files from Python. This package is needed by Anaconda. The module is packaged and tested already. The package can be found at Progeny's Anaconda apt repository: deb[-src] http://archive.progeny.com/progeny/anaconda apt-repo/ A Subversion repository is also available at svn://svn.progeny.com/.
Bug#222920: ITP: picax -- Progeny Installer Creator and Archive eXtractor
Package: wnpp Severity: wishlist picax is a utility for splitting apt repositories into chunks suitable for writing to removable media such as CDs. It is extensible, using external modules to write installers to those media. Packages are not available yet, but will soon be available at Progeny's Anaconda apt repository: deb[-src] http://archive.progeny.com/progeny/anaconda apt-repo/ A Subversion repository is also available at svn://svn.progeny.com/.
Bug#222919: ITP: booty -- Python modules for manipulating boot loaders
Package: wnpp Severity: wishlist booty is a set of Python modules written by Red Hat. It allows for manipulation of either LILO or GRUB configuration. Work has been done to enable these modules to conform to Debian standards. This package is needed by Anaconda. The module is packaged and tested already. The package can be found at Progeny's Anaconda apt repository: deb[-src] http://archive.progeny.com/progeny/anaconda apt-repo/ A Subversion repository is also available at svn://svn.progeny.com/.
Bug#222916: ITP: python-parted-rh -- Red Hat's Python bindings for parted
Package: wnpp Severity: wishlist This is a port of Red Hat's python bindings to Debian. This package is needed by Anaconda. The module is packaged and tested already. The package can be found at Progeny's Anaconda apt repository: deb[-src] http://archive.progeny.com/progeny/anaconda apt-repo/ A Subversion repository is also available at svn://svn.progeny.com/.
Bug#222928: ITP: firstboot -- Red Hat graphical second stage
Package: wnpp Severity: wishlist firstboot is the program set to load by Anaconda after installing a system. It performs some configuration tasks. A module is provided that plugs the configlets into firstboot. The module is packaged and tested already. The package can be found at Progeny's Anaconda apt repository: deb[-src] http://archive.progeny.com/progeny/anaconda apt-repo/ A Subversion repository is also available at svn://svn.progeny.com/.
Bug#122393: Packaging omni
retitle 122393 ITP: omni -- 300+ printer drivers using ghostscript engine thanks Things look like they work fine now. I've built the omni driver into gs-esp and built the omni code once. So, I think I'll take this one.
Bug#122393: How's omni coming?
On Wed, 2002-08-21 at 17:41, David D. Kilzer wrote: Unless I misunderstood the Debian BTS, I only filed a request for package (RFP) for Omni, not a full-fledged intent to package (ITP). No, you're right; I misread the bug report. Sorry about that. I was inquiring because there is interest elsewhere for the Omni drivers as well. I may ITP it. However, when I went to build Omni on my Debian Potato system, I ran into a gcc compiler bug. [ 487685 ] 0.5.1 fails to build w/link errors http://sourceforge.net/tracker/index.php?func=detailaid=487685group_id=18713atid=118713 trap when compiling file http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view+audit-trailpr=6316 This bug has since been fixed in gcc-3.1, but since I'm not using Woody yet at work (and I have a work-around for the Okidata ML-590 issue), I don't really have a need to build the package. Not to mention that gcc 3.1 isn't in woody, so you'd still be stuck. Unless the omni people did something to mitigate the problem, you'd likely be forced to stick with sid. OTOH, if I package it, I'll likely try to get it building for woody as well as sid. Besides, I'm not sure how Omni would fit into the linux printing architecture as currently set up on Debian. I'm still trying to figure out what to use (lprng versus cups). From what I can tell, the omni people have CUPS hooks working fairly well. I'd recommend using CUPS, but as the maintainer for cupsys in Debian, I'm biased. :-) I personally feel that the CUPS design is much better than the old BSD or SysV designs. The only caveat I'd have is that CUPS is still less mature than lprng; this is becoming less and less true over time, however.
Bug#122393: How's omni coming?
I noticed that you have an ITP open for IBM's omni printer driver suite. I was wondering whether you had made any progress, and when you thought the packages could be made available.
Bug#89036: gs-esp - still busy?
Just confirming, one last time, that you don't object to my picking up gs-esp. I have been working on it off and on, but the release of CUPS 1.1.15 has made it more important. CUPS 1.1.15 doesn't have pstoraster; instead, you're supposed to use ESP GhostScript with a small pstoraster script. So, people who use the stock PPDs with CUPS or people who use something like cupsys-driver-gimpprint will be out of luck with 1.1.15 until ESP GhostScript is available. I'm also coming up with a migration plan to CUPS 1.2, and would like to provide infrastructure to make pstoraster optional (since it appears that people will be forced to use gs-esp if they want pstoraster to work). If you object, I don't mind, but we will need gs-esp soon. I could even package it and then let you adopt it later, if you'd like to keep a hold of it but can't deal with it now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#141070: ITP: aptconf -- debconf infrastructure for setting up apt sources
Package: wnpp Severity: wishlist Aptconf will allow users to configure sources.list via debconf. It will also contain a configlet for setting up sources.list via the GNOME Control Center, in druids, and potentially other settings. The architecture will treat the existing sources.list as the canonical source for the current configuration; debconf will not be used as a registry. Additionally, every care will be taken to preserve user edits - comments, hand-edited repositories, and so forth. The primary user interface will consist of a list of repositories (with user-friendly descriptions, like Debian stable archive) and the ability to select which will be active. The list of repositories shown will be configurable via repository descriptions dropped in a directory. Repositories with description will provide the option of selecting mirrors and enabling deb-src lines. Custom repositories and CD-ROMs will also be supported. Long-term, editing pins may also be supported, although it is not planned for the first release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#138541: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material)
On Sat, 2002-03-16 at 15:39, Steve Langasek wrote: I object to using any subjective method (such as popular vote) for determining which packages should be conflicted with in such a package. OK; we can scratch the Conflicts: part unless someone else can give a good reason to have it. The package can act like vrms, and provide a report of some kind. Perhaps the package could also take configuration (adding or removing packages for personal preference), and could possibly produce a package via equivs or some such for those who want it. In addition, if you use the simple criterion of having Debian developers indicate whether they find a given package offensive, I think the only two packages you'll get a majority of developers to say they find offensive are vi and emacs. True. Unfortunately, when you're talking about something as subjective as offense, there aren't many good classification systems that won't themselves be offensive to someone. Democratic vote strikes me as one of the few that's hard to challenge. Also note my proposal to give the DPL special rights, which could allow for certain abuses to be curtailed. This is an experiment that relies on some assumptions: - Most developers, joking aside, are capable of distinguishing between technical preference and moral repugnance. - Most developers would like to avoid flamewars like this in the future, and punting to a package like this is a good way to stop them. - Most developers would prefer adding information to the system (these packages might be offensive to some people) to removing information (this code/output/data is offensive to some people, so I'll remove it in the diff). - Most developers will realize that trivializing the package by voting on technical grounds (emacs offends me) will render the package unusable for the purposes above. If it turns out I'm not right, I'll orphan the package and call the experiment a failure.
Bug#138541: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material)
On Sat, 2002-03-16 at 17:15, Manoj Srivastava wrote: I hereby request that the abomination known as Perl, be marked as objectionable, and be included in debian-sanitize. Sorry, but the voting process hasn't been instituted yet. Watch for the announcement when it is.
Bug#138541: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material)
On Sat, 2002-03-16 at 17:09, Manoj Srivastava wrote: Jeff == Jeff Licquia [EMAIL PROTECTED] writes: Jeff Generating the list of offensive packages is, of course, the hard Jeff part. I propose we do this with the following process. It has the Jeff advantages of not (necessarily) promoting the biases of one developer Jeff or group. You are assuming there is a common cultural background that shall determine what the broad community finds offensive. Unfortunately, with the spread of the internet, Debian is no longer a localized mostly european heritage distribution. We hae constituencies that find things offensive that you may hold dear, and vice versa. There are some things that can be classified as universally abhorrent. Advocating the murder of innocents would hold up anywhere, I would imagine. It seemed that most of the debate about the joke in irssi-scripts took it for granted that racism is offensive; objections to censoring the package seemed to arise from a general anti-censorship position or from a view that the joke really wasn't racist. I'm sure we can find other examples. I'm not looking for a package that will make Jerry Falwell happy. I'm looking for something that will allow people to weed out the most egregious stuff, like the famous BitchX taglines. Jeff - Offensiveness will be determined by vote. All Debian developers Jeffwill be allowed to vote on any or all binary packages in JeffDebian. Ah, so the only things that are offensive are those that the majority find offensive. I find this notion patently offensive, and ridiculous. No; the only things that are *noteworthy* in their offensiveness are determined by majority vote. You are free to be offended by anything else you find on the system without asking the Project's approval. One of the advantages of a voting system is that, in most cases, an offending package would have to be pretty bad to even garner enough votes to make a quorum. Jeff - After the quorum is reached, a majority (supermajority?) of Jeffoffensive votes will result in the package being labeled Jeffoffensive. Votes will be tallied on regular intervals, and Jeffpackages generated from the vote results. The interval will be Jeffdesigned to allow new versions of the package to propagate through JeffDebian. Which jurisdiction do you live in? Seems to me, by labelling something offensive, you are opening yourself to libel or other suits, espescially if this is widely publicized. I live in the USA, which doesn't seem to be as nutty over libel as some other countries (UK?). Besides, even in the UK it's possible to say I don't like McDonald's or some such in public without fear of libel. You are free to do as you please, of course, but I would object to any GR that tries to implement this censorship by majority. I think that the point here is that we're avoiding censorship by providing a way for people to evaluate what they want on their own. I would hope that no one would resort to a GR to change the classification of a package. It would seem to me to be somewhat self-defeating; if the Project can already vote on the status of a package, why call for another vote?
Bug#138541: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material)
On Sat, 2002-03-16 at 18:42, Evan Prodromou wrote: JL == Jeff Licquia [EMAIL PROTECTED] writes: JL The basic idea is that debian-sanitize will Conflict: with JL packages deemed to be offensive. With this package installed, JL therefore, offensive packages will not be installed without JL the admin's explicit consent. That's not that nutty an idea. Someone else made a good point about not putting Conflicts: up for popular vote. JL Generating the list of offensive packages is, of course, the JL hard part. I propose we do this with the following process. I suggest that you keep it much simpler. What about just letting people file bugs against debian-sanitize if they find content in a package to be insulting? Then the maintainer (you) evaluates, uses some good judgement, and either adds a Conflicts: line or doesn't. From reading this thread, I'm sure the Project wouldn't be interested in signing off on my particular set of prejudices as the Debian Conscience (or anyone else's, for that matter). If somebody doesn't like your judgement, they can always uninstall debian-sanitize. Badda bing, badda boom. Except that, given this package's purpose, I'm sure any disagreement with its content would start all kinds of flamewars, General Resolutions, and the like, which is the opposite of what I'm trying to do. At least, if you can vote, you feel you have some power over the situation, instead of having to beg to some Grand Poobah of Proper Piety or try to get the Poobah kicked off his throne. If anyone should have special privilege in determining this package's contents, it should be an elected official such as the DPL.
Bug#138541: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material)
Package: wnpp Severity: wishlist Various people have argued on debian-devel: people, you have to understand that at a government facility all of our traffic can be monitored and we can be held responsible for its content. I like the Debian distribution alot but without a policy statement it simply won't be worth the risk when I can use another distribution that is more careful about its content. I also don't have the time to look at every message that comes out of every package. As I said, the practical solution is that I will rely on the social contract. The long term trend of this is that repressive governments will damage their countries by blocking access to technology and governments that are more liberal will benefit. I disagree. Governments are much like businesses in this respect - they must establish some sort of standard of behavior within government facilities just like a business generally wants a standard of behavior followed by its employees (such as not surfing the web for porn at work). A government can regulate itself without repressing the populace in general. That's how it is in my country anyway :-) Perhaps a compromise is needed - something that can provide people with a content filter of sorts, while allowing us to package whatever we feel we need to. So, I propose to upload debian-sanitize. The basic idea is that debian-sanitize will Conflict: with packages deemed to be offensive. With this package installed, therefore, offensive packages will not be installed without the admin's explicit consent. As an option, we could use some less absolute method of determining offense, perhaps something like vrms. Generating the list of offensive packages is, of course, the hard part. I propose we do this with the following process. It has the advantages of not (necessarily) promoting the biases of one developer or group. - Offensiveness will be determined by vote. All Debian developers will be allowed to vote on any or all binary packages in Debian. Votes will be registered by sending a GPG-signed E-mail to a particular address. Only one vote per package per developer will be allowed, but developers will be allowed to change or retract their votes. Voting will be optional, and neither the package nor its maintainer will solicit votes from anyone who has not already chosen to participate. - There will be a sense of a quorum; a certain number of votes must be tallied before any action would be taken. Besides offensive and not offensive, developers may vote to abstain, which would count against the quorum but have no effect on the outcome. - After the quorum is reached, a majority (supermajority?) of offensive votes will result in the package being labeled offensive. Votes will be tallied on regular intervals, and packages generated from the vote results. The interval will be designed to allow new versions of the package to propagate through Debian. - The BTS entry for the package will be used for contesting classifications, notifying of changes in packages that might affect the vote, and so on. Depending on the results of these bugs, the package maintainer might contact voters or the entire project to alert developers about the situation with certain packages. Suggestions are welcome for a conflict resolution strategy that doesn't involve a General Resolution. - If an offensive package loses its offensive status, debian-sanitize will record its status as offensive previous to the current version in unstable. These records will be kept through one stable release cycle, and then dropped. (If offensiveness is recorded through Conflicts, then the package will gain a versioned conflict.) The package maintainer will reserve the right to modify such historical records as necessary. Packages that re-gain offensive status will have their historical records dropped. - If deemed appropriate, the DPL or his/her delegate may be accorded special status; for example, the DPL may have veto power, or have a vote that counts for more than others' votes. - Only packages in main would be eligible for voting; contrib and non-free are, in a sense, already considered disreputable by their status outside of main. - This maintainer, at least, would refrain from participation in the process to avoid a conflict of interest. I would probably implement this as a set of scripts and a database; at upload time, the scripts would produce a package for my manual approval, signature, and download. Comments?
Bug#90664: How's the foomatic package for Debian going?
On Fri, Dec 07, 2001 at 05:19:36AM +0100, Manfred Wassmann wrote: I have uploaded my current Debian packages to http://www.b.shuttle.de/ncc-1701/foomatic/ Well, it appears the shoe is on the other foot when it comes to activity :-). Sorry for taking so long; a sustained dose of real life around the holidays conspired to derail me. The latest packages as they appear on that site looked OK, except for the small problem that Defaults.pm wasn't getting installed in packages built from the source. In looking at that problem, I discovered a host of other problems in your debian/rules file, and one thing led to another... I've attached the patch; it amounts to changes in debian/rules only. If you approve, I'm ready to upload it. It's lintian clean and appears to work, though I did have some issues getting test pages printed with a foomatic-configure configured printer and CUPS. (I'll look into that later.) diff --unified --recursive foomatic-0.20011210-old/debian/rules foomatic-0.20011210/debian/rules --- foomatic-0.20011210-old/debian/rulesTue Dec 11 02:20:16 2001 +++ foomatic-0.20011210/debian/rulesSun Dec 30 02:46:29 2001 @@ -1,13 +1,12 @@ #!/usr/bin/make -f -DH_COMPAT=2 +export DH_COMPAT=2 PREFIX=/usr # CUPS_FILTERS=$(PREFIX)/sbin -ARCH_INSTALLPREFIX=$(CURDIR)/debian/tmp +ARCH_INSTALLPREFIX=$(CURDIR)/debian/foomatic-bin INDEP_INSTALLPREFIX=$(CURDIR)/debian/foomatic-db -export INSTALLPREFIX MAKEFLAGS:=$(MAKEFLAGS) PREFIX=$(PREFIX) PERL_INSTALLDIRS=vendor @@ -15,38 +14,25 @@ all: binary -install-indep: INSTALLPREFIX=$(INDEP_INSTALLPREFIX) -install-indep: - dh_clean -k -i +install-indep: +install-indep: build dh_installdirs -i + INSTALLPREFIX=$(INDEP_INSTALLPREFIX) $(MAKE) -ef Makefile install-db -install-arch: INSTALLPREFIX=$(ARCH_INSTALLPREFIX) -install-arch: - dh_clean -k -a +install-arch: +install-arch: build dh_installdirs -a + INSTALLPREFIX=$(ARCH_INSTALLPREFIX) $(MAKE) -ef Makefile install-bin # FIXME: Why doesn't this get installed through lib/Makefile - cp -pv lib/Foomatic/Defaults.pm $(INSTALLPREFIX)/usr/share/perl5/Foomatic + cp -pv lib/Foomatic/Defaults.pm $(ARCH_INSTALLPREFIX)/usr/share/perl5/Foomatic install: install-indep install-arch - dh_clean - dh_installdirs - - -build-indep: INSTALLPREFIX=$(INDEP_INSTALLPREFIX) -build-indep: - $(MAKE) -ef Makefile install-db - touch build-indep - - -build-arch: INSTALLPREFIX=$(ARCH_INSTALLPREFIX) -build-arch: - $(MAKE) -ef Makefile build install-bin - touch build-arch -build: build-indep build-arch +build: + $(MAKE) -ef Makefile build touch build @@ -58,50 +44,48 @@ dh_clean -binary-indep: DH_OPTIONS=-i INSTALLPREFIX=$(INDEP_INSTALLPREFIX) -binary-indep: - dh_installdirs - dh_installdocs - dh_installexamples - dh_installchangelogs - dh_installmenu - dh_installcron +binary-indep: install-indep + dh_installdirs -i + dh_installdocs -i + dh_installexamples -i + dh_installchangelogs -i + dh_installmenu -i + dh_installcron -i # No manpages for the data files yet # dh_installman -pfoomatic-db - dh_movefiles - dh_strip - dh_compress - dh_fixperms - dh_shlibdeps - dh_perl /usr/share/foomatic - dh_gencontrol - dh_makeshlibs - dh_installdeb - dh_md5sums - dh_builddeb - - -binary-arch: DH_OPTIONS=-a INSTALLPREFIX=$(ARCH_INSTALLPREFIX) -binary-arch: - dh_installdirs - dh_installdocs - dh_installexamples - dh_installchangelogs - dh_installmenu - dh_installcron - dh_installman - dh_movefiles - dh_strip - dh_compress - dh_fixperms - dh_suidregister - dh_shlibdeps - dh_perl /usr/share/foomatic - dh_gencontrol - dh_makeshlibs - dh_installdeb - dh_md5sums - dh_builddeb +# dh_movefiles -i + dh_strip -i + dh_compress -i + dh_fixperms -i + dh_shlibdeps -i + dh_perl -i /usr/share/foomatic + dh_gencontrol -i + dh_makeshlibs -i + dh_installdeb -i + dh_md5sums -i + dh_builddeb -i + + +binary-arch: install-arch + dh_installdirs -a + dh_installdocs -a + dh_installexamples -a + dh_installchangelogs -a + dh_installmenu -a + dh_installcron -a + dh_installman -a +# dh_movefiles -a + dh_strip -a + dh_compress -a + dh_fixperms -a + dh_suidregister -a + dh_shlibdeps -a + dh_perl -a /usr/share/foomatic + dh_gencontrol -a + dh_makeshlibs -a + dh_installdeb -a + dh_md5sums -a + dh_builddeb -a binary: binary-indep binary-arch
Bug#90664: How's the foomatic package for Debian going?
On Thu, Nov 29, 2001 at 02:24:07PM -0500, Grant Taylor wrote: Jeff Licquia [EMAIL PROTECTED] writes: I take it you'd be interested in a patch that does the right thing? I'll look to see how hard that would be. Yes, of course. Manfred has submitted a number of patches, which go right in. He also appears to have spoken up. I will respect his ITP if he gets a package into shape *now* and sends it on; the reason he hasn't uploaded yet is that he's still going through the new maintainer process. But he needs to do the heavy lifting, and soon. In that case, all of this might be moot. But oh well. (Manfred, if you're interested in any of this, let me know and I'll tell you how to do it.) You're actually welcome (nee encouraged) to put the debian/ stuff into our CVS. (Till, put your spec in!). We're also hoping to accumulate any GUI tools in it as well. That's not a problem - mostly. The one sticking point is the Debian changelog. This file isn't just documentation; it is the source of the package version, and maintaining it properly is crucial for ensuring that the famous Debian upgrade system works properly. The problem that we see is that, when the Debian changelog is part of upstream CVS, people will inevitably build packages with CVS. However, during development cycles, the changelog will inevitably get out of date. This will mean that packages built out of CVS will end up with the same version as the released packages; this makes apt unhappy, and will in some cases cause apt to install older packages over the shiny new CVS packages. This has been the cause of some heated debate within the project. The upshot is that there isn't a good solution to this problem that meets all the necessary criteria. However, I think we can avoid these problems with careful coordination between upstream and Debian maintainers. In particular, we could do something like this: - At midnight, a changelog entry could be tacked on and checked in automatically by the script that creates your nightly snapshots. This could be versioned with the current date and a Debian version of 0.1. - After the snapshots are built, another entry could be added to CVS, with a date and a version of 0.2. This would cover packages built by third parties from a direct CVS checkout. - On those (comparatively) rare occasions that an official upload is done, the two automatic entries would be removed and a real changelog entry, with a version numbered -1 (as usual), would be added and used for the build. Future versioning for a particular day would follow Debian norms. - Before the next run, the previous day's changelog entries would be removed (except for any official ones), to keep the changelog from infinite growth. In this scheme, official packages would automatically trump unofficial ones from the same day, and CVS checkouts mid-day would trump the nightly snapshot from that day (but not other checkouts; that's just too hard). People who wanted to be on the bleeding edge could add an apt repository to their sources.list, and admins wouldn't have to worry about custom-built third-party packages. The main problem with this is that the upstream people have to commit to helping maintain a scheme like this to really make it work. So, I ask you: does this sound doable? Cool. The major issue there is conffile sanctity; packages are forbidden by policy to mess with registered configuration files except through very tightly-controlled interfaces. (Not all configuration files have to be registered, though; for details - and a good sleep aid - check out the Debian policy manual.) I can tell you for certain that the cupsys maintainer won't mind accomodating. :-) For the other spoolers, I'll have to see how they manage their printer configs. /etc/printcap, in particular, is looking like a potential hot spot for trouble. Yes, this is a general issue. The original printcap code I wrote went to great pains to not molest existing printcap data while still letting you do some operations on it. This is different from, say, the new redhat thing where the printcap is merely a generated interim config file. To the extent that it doesn't disturb existing configuration, foomatic fits with the intent of policy, but not the letter. OTOH, to the extent that I didn't write all the code and don't trust even the parts I *did* write, I wouldn't count on it not scrambling someone someday ;( Well, I've done a little more research, and it turns out that /etc/printcap is a registered conffile - by lprng only. I'm fairly sure that there's an interface to modify it, though, as the magicfilter package does that at least. We'd therefore have some latitude to play with /etc/printcap as long as lprng isn't installed. We still have to be careful how we handle user data, but Debian places much less stringent guarantees down; screwing up might result in a high-priority
Bug#90664: How's the foomatic package for Debian going?
On Wed, 2001-11-28 at 17:13, Manfred Wassmann wrote: I can't upload to debian because my NM process is not yet finished, but it would be great if you sponsored my package. Ah! That's not a problem, if that's all that is holding things back. How's the package going? If you can get it in upload shape and send it to me (or a URL to download it), I can upload it for you.
Bug#90664: How's the foomatic package for Debian going?
Just wondering, since there's no package yet, and woody is starting to freeze. I understand if you aren't able to work on it. If you can't do it, perhaps I could take up the cause?
Bug#121425: ITP: gxxcompat - compatibility library for porting C++ code between g++ versions
Package: wnpp Severity: wishlist The new g++ 3.0 and libstdc++3 adhere more strictly to the C++ standard than have previous versions of g++, and many of the extensions in g++ are now gone. Consequently, there is a lot of C++ code that doesn't compile with g++ 3. Furthermore, some versions of g++ had bugs, missing library features, and the like, and some incompatible extensions have crept into g++ 3. This is already causing a problem with the hppa port, which is lagging on its build percentage because of its lack of a g++ 2.x (among other reasons). Furthermore, it could very easily cause a greater problem for whichever Debian release chooses to abandon gcc versions less than 3. Gxxcompat aims to help mitigate this problem. It consists of a set of autoconf macros and a library. The autoconf macros detect the state of various incompatibilities and extensions in g++ versions; the library provides implementations of some of those extensions for versions that don't have them. Use of the library in source code should go something like this: // Get your autoconf macros defined. #include config.h // Define what extensions this source file needs. #define GXXCOMPAT_NEEDS_FSTREAM_FD // Pull the extensions in. #include gxxcompat.h It's almost definitely incomplete, but the cases that are implemented all work. It's not going to get any more complete by me holding on to it, so I intend to upload it and let people start using it. A few small bugs, some more documentation, and Debian packaging are all that remain to finish before the first version can be uploaded. If I get time, I'd like to write an autoconf-style analysis tool that will do most of the heavy lifting for lazy maintainers and overworked porters. :-) I wrote the library, so I am both the upstream and Debian maintainer. The license is BSD-style (the changes amount to replacing the UCB-specific bits with references to me). It's not available yet; its official upstream release will be its installation into unstable.
Bug#90664: How's the foomatic package for Debian going?
On Tue, Nov 27, 2001 at 07:17:47PM -0500, Grant Taylor wrote: I dunno, Manfred was doing it, IIRC. Last I knew he had a tentative package done, but it's got some C code now, so the packaging will need some adjustment. Well, let's do this. I'm leaving Thursday on a vacation, and will be back a week from Friday. I'll stick the latest foomatic tarball on the laptop and see if I get inspired by the beach sand. Manfred, if you still want it, upload a package before I get back. If there's still no package when I get back, we'll move on.
