ITP: comix -- GTK Comic Book Viewer
Package: wnpp Severity: wishlist Owner: Emfox Zhou <[EMAIL PROTECTED]> * Package name: comix Version : 2.9.3 Upstream Author : Pontus Ekberg <[EMAIL PROTECTED]> * URL : http://comix.sourceforge.net/ * License : GPL Description : GTK Comic Book Viewer Comix views comic book archives (often called .cbz, .cbt or .cbr) as well as plain image files. . Right-click the window to get a menu of operations to perform. Most of these are also available as hotkeys. -- GnuPG Public Key: 0xF7142EC2
What do you do if a package is built and not uploaded?
I'm thinking of python2.1, which is a key element in some testing transitions. It's out of date on alpha, mips, mipsel, and powerpc -- *yet the buildd logs indicate successful builds on all of them on August 30*. I have already emailed debian-mips@lists.debian.org, and the listed maintainers of the relevant alpha and powerpc buildds. -- Nathanael Nerode <[EMAIL PROTECTED]> [Insert famous quote here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: g-wrap -- Scripting interface generator for C
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Andreas Rottmann <[EMAIL PROTECTED]> writes: > >> To clarify the situation: I've included mininimal wrappers for GLib >> that work with both GLib 1.x and GLib 2.x in G-Wrap, mainly to support >> GnuCash. These wrappers are built against GLib 1.x, since currently >> GnuCash/GNOME2 is not ready for prime-time, and GNOME2 programs >> written in Guile should use the bindings of GLib in guile-gnome >> anyway, since these are much more complete. When GnuCash/GNOME2 >> finally arrives, either G-Wrap has to build the GLib bindings against >> GLib 2.x, or GnuCash has to switch to use guile-gnome. > > It is simply not important to me to "get rid of things" for its own > sake. > Well, G-Wrap 1.3 has no upstream anymore, and its functionality is replicated in G-Wrap 1.9 - you know, I didn't add the compatibility layer for the fun of it. > I don't want to make potentionally destabilizing changes, and I > *especially* don't want to make changes like this which result in > upstream saying "you're totally on your own now." > Does upstream actually say that? I've been talking with Derek Atkins (warlord) on IRC, and from what I gathered, they are trying to use G-Wrap 1.9, and mostly suceeding modulo a few buglets, all of which should be fixed in the Debian packaging. > I'm happy maintaining gwrapguile right now. It's extremely stable and > isn't causing any problems that I know of. > Of course GnuCash is your package, and you are free to maintain it as you like; I was merely suggesting that switching to G-Wrap 1.9 should be a viable option. Regards, Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com It's *GNU*/Linux dammit! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you do if a package is built and not uploaded?
[Nathanael Nerode] > I'm thinking of python2.1, which is a key element in some testing transitions. > It's out of date on alpha, mips, mipsel, and powerpc -- *yet the buildd logs > indicate successful builds on all of them on August 30*. I have already > emailed debian-mips@lists.debian.org, and the listed maintainers of the > relevant alpha and powerpc buildds. What to do? Well, you curse the lack of transparecy in the buildd maintainence process, and hope the problem will be fixed soon. I've not been able to find any other procedure that work better that this simple approach. I've tried to emailing Ryan Murray using the address listed at the bottom of all the buildd web pages, but do not remember if I ever got a reply. I've tried emailing the porters list, but most often this is either met with silence or I get a reply saying that the buildd admins for the given arhc are not reading the porters list. I've tried asking on IRC, and actually once got feedback from someone claiming to be the buildd maintainer of the arch in question (no way to verify this, have not found the list of maintainers), and some times one of the porters are willing to do a manual build. So, good luck, I hope your problem will be fixed soon. I'll help you with the cursing, and perhaps the problem is fixed sooner. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
* Thomas Bushnell: > What do you think "orig" means in "orig.tar.gz"? At the moment, it's a sequence of four ASCII characters without any particular meaning. Many maintainers use repackaged sources because they want to include multiple tarballs in their source packages, even though there's no need to do this as far as the DFSG are concerned. On the other end are Debian-specific packages for which there is no real upstream and which were made non-native packages nevertheless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
On Fri, 30 Sep 2005, Thomas Bushnell BSG wrote: > The lintian warning source-contains-CVS-dir is bogus. > > I agree that upstream should not put CVS in their tarballs. But > sometimes they do. > > So, it's a bogus warning. It should be removed from lintian. It's not really a bogus warning; the point of it is so that you're aware so that you can remind upstream not to distribute CVS files in their tarballs. You may decide that removing the CVS files from the orig is worse than having them there,[1] but it doesn't excuse the fact that having them there is bad (or at least stupid.) Don Armstrong 1: In which case you can always put in an override... -- You could say she lived on the edge... Well, maybe not exactly on the edge, just close enough to watch other people fall off. -- hugh macleod http://www.gapingvoid.com/batch8.htm http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you do if a package is built and not uploaded?
Petter Reinholdtsen wrote:
> [Nathanael Nerode]
> > I'm thinking of python2.1, which is a key element in some testing
> > transitions.
> > It's out of date on alpha, mips, mipsel, and powerpc -- *yet the buildd logs
> > indicate successful builds on all of them on August 30*. I have already
> > emailed debian-mips@lists.debian.org, and the listed maintainers of the
> > relevant alpha and powerpc buildds.
>
> What to do? Well, you curse the lack of transparecy in the buildd
> maintainence process, and hope the problem will be fixed soon. I've
> not been able to find any other procedure that work better that this
> simple approach. I've tried to emailing Ryan Murray using the address
> listed at the bottom of all the buildd web pages, but do not remember
> if I ever got a reply. I've tried emailing the porters list, but most
> often this is either met with silence or I get a reply saying that the
> buildd admins for the given arhc are not reading the porters list.
> I've tried asking on IRC, and actually once got feedback from someone
> claiming to be the buildd maintainer of the arch in question (no way
> to verify this, have not found the list of maintainers), and some
> times one of the porters are willing to do a manual build.
Mailing {alpha,mips,[EMAIL PROTECTED] is my best guess. There
is usually no reply, but from some cases I conclude the mailboxes are
read. I don't know if those addresses are documented anywhere.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: a place for a package directory in root
Hello Thomas, Thomas Hood <[EMAIL PROTECTED]> wrote: > http://panopticon.csustan.edu/thood/readonly-root.html > > I won't summarize the whole discussion here. I will just say that > I see good reasons for adopting /run as a standard location for the > storage of state information that needs to be stored prior to the > availability of networking. I see no good reasons for not adopting > it. Then, why not create it and show it works? If it fails, you have a good reason, why not do it. Otherwise its feasibility is proved. But I've a question on it: How can I use it? How can I set up /run before init runs the init script that is responsible for it? This script should be resistant to multiple start calls. Bye, Jörg. -- Macht besitzen und nicht ausüben ist wahre Größe. (Friedl Beutelrock) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please have a look guys
On Wednesday 28 September 2005 17.36, you wrote: > Please have a look at this guys. [word document attached] [silly disclaimer to finish it] Please, do not post word documents on this list. For several reasons: - we're reading email here. Why should I need to start an additional application to read your document? - many people read mail over an ssh connection in a text-based mail program, and it's not easy for them to start openoffice or kword to read the word document. - .doc is a document format used by the MS Office application suite, which runs on MS Windows only. It may surprise you, but many people who read this list do not use a Windows machine to do so. - The .doc document format has been repeatedly used to spread trojans/viruses in the past, and so many people will not open .doc documents from unknown people. Finally: the subject of your email and the introductory text do not give any information why we should be reading what you wrote. The Debian project (or rather, the individual developers - most of them, in any case) usually welcome input in form of good ideas, constructive ciriticism, whatever. But with more than 100 emails on this mailing list per day, you will need to make us *want* to read your text - usually, when I can't figure our what somebody is trying to tell me within the first three lines of text, I'll just ignore the email. Oh, and: using some disclaimer in legalese at the end of your email just makes you look stupid, it doesn't make anyone happy. greetings -- vbi -- Wie man sein Kind nicht nennen sollte: Perry Ode pgp2Yuvk5P65P.pgp Description: PGP signature
Re: mass bug filing on packages that are blocking use of cdebconf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 En/na Joey Hess ha escrit: mydms package now has been corrected and now depends on debconf | debconf-2.0. > Joey Hess wrote: > >>Just a reminder that these maintainers still have packages that depend >>on debconf by itself without an alternate dependency on | debconf-2.0. >>As I mentioned in my original post, I plan to file bugs on all of these >>soon, which, omitting all the lg-issue* packages, comes to about 550 >>bugs. > > (Original post here: > http://lists.debian.org/debian-devel/2005/08/msg00136.html) > > This is your third and final reminder. I count 542 packages remaining, > down only 9 from last month. I assume most of the people below do not > read debian-devel, so I've taken the librerty of BCCing you all. :-P > > apt-cache dumpavail | grep-dctrl -FDepends,Pre-Depends debconf | \ > grep-dctrl -FDepends,Pre-Depends -v '| debconf-2.0' | \ > dd-list --dctrl > Wesley W. Terpstra (Debian) <[EMAIL PROTECTED]> >bidentd > > Loic Dachary (OuoU) <[EMAIL PROTECTED]> >poker-network > > Stefan Hornburg (Racke) <[EMAIL PROTECTED]> >amavis-ng >courier >debaux >dhelp >interchange >pure-ftpd >sympa > > Maurizio Lemmo (Tannoiser) <[EMAIL PROTECTED]> >mailreader > > Marco Presi (Zufus) <[EMAIL PROTECTED]> >linesrv >pointless > > Masayuki Hatta (mhatta) <[EMAIL PROTECTED]> >gs-common >gtktrain >ndtpd > > Peter De Schrijver (p2) <[EMAIL PROTECTED]> >libgcr410 > > Clint Adams <[EMAIL PROTECTED]> >posh > > Joel Aelwyn <[EMAIL PROTECTED]> >zope-quotafolder > > OHASHI Akira <[EMAIL PROTECTED]> >initz >riece > > Jan Alonzo <[EMAIL PROTECTED]> >ispell-tl > > Pierre Ancelot <[EMAIL PROTECTED]> >hwtools > > Micah Anderson <[EMAIL PROTECTED]> >bamboo > > Osamu Aoki <[EMAIL PROTECTED]> >ipmasq > > Hakan Ardo <[EMAIL PROTECTED]> >ftpwatch > > Richard Atterer <[EMAIL PROTECTED]> >udftools > > Ernesto Nadir Crespo Avila <[EMAIL PROTECTED]> >flowscan > > Thomas Bushnell, BSG <[EMAIL PROTECTED]> >ifhp >miscfiles > > Sebastien Bacher <[EMAIL PROTECTED]> >pango1.0 > > Jeff Bailey <[EMAIL PROTECTED]> >diffmon > > Michael Banck <[EMAIL PROTECTED]> >exult > > Roland Bauerschmidt <[EMAIL PROTECTED]> >colormake > > Christian Bayle <[EMAIL PROTECTED]> >gforge-theme-starterpack >php4-mcrypt > > Ian Beckwith <[EMAIL PROTECTED]> >ckermit > > Cord Beermann <[EMAIL PROTECTED]> >jove >nn > > Bradley Bell <[EMAIL PROTECTED]> >razzle > > Hilko Bengen <[EMAIL PROTECTED]> >drupal >mantis > > Edward Betts <[EMAIL PROTECTED]> >joystick > > Michael Biebl <[EMAIL PROTECTED]> >lksctp-tools >partimage > > Bastian Blank <[EMAIL PROTECTED]> >zope-loginmanager > > Blars Blarson <[EMAIL PROTECTED]> >hinfo > > Eduard Bloch <[EMAIL PROTECTED]> >durep >shfs >sl-modem > > Jeremy T. Bouse <[EMAIL PROTECTED]> >acidlab > > Cyril Bouthors <[EMAIL PROTECTED]> >drbd > > Markus Braun <[EMAIL PROTECTED]> >tpb > > Adrian Bridgett <[EMAIL PROTECTED]> >tgif > > James Bromberger <[EMAIL PROTECTED]> >libapache-mod-backhand > > Phil Brooke <[EMAIL PROTECTED]> >yiff > > Philip Brown <[EMAIL PROTECTED]> >kdrill > > Luis Bustamante <[EMAIL PROTECTED]> >acct > > Chris Butler <[EMAIL PROTECTED]> >wu-ftpd > > Patrick Caulfield <[EMAIL PROTECTED]> >dnprogs >lvm10 >mopd > > Petr Cech <[EMAIL PROTECTED]> >ispell-czech > > Emmanuel le Chevoir <[EMAIL PROTECTED]> >icecast-server > > Pierre Chifflier <[EMAIL PROTECTED]> >websvn > > Volker Christian <[EMAIL PROTECTED]> >synce-serial > > Ashley Clark <[EMAIL PROTECTED]> >bottlerocket > > David Coe <[EMAIL PROTECTED]> >libsafe > > Ben Collins <[EMAIL PROTECTED]> >libraw1394 > > Carlo Contavalli <[EMAIL PROTECTED]> >wipl > > Jereme Corrado <[EMAIL PROTECTED]> >faqomatic > > Matthew Danish <[EMAIL PROTECTED]> >oftpd > > Julien Danjou <[EMAIL PROTECTED]> >apt-build > > Frederik Dannemare <[EMAIL PROTECTED]> >motion > > Vivek Dasmohapatra <[EMAIL PROTECTED]> >dbishell > > Debian Apache Maintainers >apache2 > > Eric Delaunay <[EMAIL PROTECTED]> >scsitools >xtel > > Cédric Delfosse <[EMAIL PROTECTED]> >darkstat > > Murat Demirten <[EMAIL PROTECTED]> >ettercap > > Grzegorz Prokopski (Debian Developer) <[EMAIL PROTECTED]> >pimppa > > Sven Dowideit <[EMAIL PROTECTED]> >twiki > > Joe Drew <[EMAIL PROTECTED]> >lxdoom > > Benjamin Drieu <[EMAIL PROTECTED]> >dacode > > Ludovic Drolez <[EMAIL PROTECTED]> >atftp >backuppc >swish-e > > Steve Dunham <[EMAIL PROTECTED]> >x-symbol > > Free Ekanayaka <[EMAIL PROTECTED]> >ams > > Nick Estes <[EMAIL PROTECTED]> >mserv > > Bartosz Fenski <[EMAIL PROTECTED]> >fuse > > Agney Lopes Roth Ferraz <[EMAIL PROTECTED]> >gkdebconf >
Re: curl status update
On Thu, 29 Sep 2005 the mental interface of Steve Langasek told: [...] > There isn't? I saw some arguments that explain why it's not possible to > convert all curl-using applications from OpenSSL to GNUTLS without a > recompile due to unavailable ABI changes, but I thought it was pretty clear > that the default going forward should be the one whose license is maximally > compatible with that of applications using libcurl (i.e., GNUTLS). libcurl3-gnutls-dev 7.14.1-3 works well ;-) The only challange we have to solve is: Which curl deps have to be the default? IMHO the gnutls one. Elimar -- >what IMHO then? IMHO - Inhalation of a Multi-leafed Herbal Opiate ;) --posting from alex in debian-user-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Advices needed for moving {add|remove}-shell from passwd to debianutils
The bugs #208514, #268656, #269573, #29317 all finally suggest moving add-shell and remove-shell out of the passwd package. These utilities are use to "register" shells in /etc/shells and they obviously do no belong to the passwd package. Having them in passwd enforces shells to depend on it just because they need the utilities to register shells. So, moving them out of passwd finally seems logical and was discussed with Clint Adams, maintainer of debianutils. So Clint and us (shadow maintainers) have to deal with the transition and make it as smooth as possible. We discussed the issue yesterday on #shadow on freenode. However, the conclusion we draw probably need some peer review. See #269573 for the whole discussion. The goal is having a system which always has the two utilities...and of course avoid the removal of passwd (debianutils is Essential while passwd isn't). The plan we draw is the following: 1) shadow package maintainers upload passwd which "Depends: debianutils (<= 2.14.3)" this version *still* includes the utilities 2) we warn Clint 3) He uploads debianutils 2.15 with the utilities 4) He warns us..:-) 5) We upload passwd *without* the utilities and "Depends: debianutils (>= 2.15)" 6) we might need to later warn maintainers of shell packages which maybe depend on passwd just because they need the utilities The purpose of 1) is to avoid the removal of passwd during new systems installs between 3) and 5) in case both do not happen at the same time. A simpler solution could be merging 3) and 5) in a single upload. Then the "Depends" in 1) would not be needed. Are there any comments about this? I must admit I'm not familiar with such transitions so I humbly request you folks to accept apologies if something above is stupid. My knowledge of the subtleties of package interdependencies is not that deepeven after reading the DR and the Policy...especially when it comes at Essential packages. In short, don't flame us, pals..:) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
> You may decide that removing the CVS files from the orig is worse than > having them there,[1] but it doesn't excuse the fact that having them > there is bad (or at least stupid.) It also helps a lot when *we*, as upstream for native packages, inadvertently include a CVS or .svn directory in an upload. It already happened to me on D-I packages and I appreciate that either lintian and linda tell me that I'm a moron...:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331072: ITP: cinelerra-cvs -- non-linear video editor and compositor for Linux.
Package: wnpp Severity: wishlist Owner: Riccardo Setti <[EMAIL PROTECTED]> * Package name: cinelerra-cvs Version : 2.0-cvs Upstream Author : * URL : http://www.example.org/ * License : GPL Description : non-linear video editor and compositor for Linux. Cinelerra, the first Linux based real-time editing and special effects system is a revolutionary Open Source HD media editing system. It has a number of effects built into the system including numerous telecine effects, video special effects including compositing, and a complete audio effects system. This is a branched version of Cinelerra sometimes called Cinelerra-CVS . Please visit cvs.cinelerra.org for more information regarding this duality. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#331072: ITP: cinelerra-cvs -- non-linear video editor and compositor for Linux.
On Sat, Oct 01, 2005 at 03:05:08PM +0200, Riccardo Setti wrote: > Package: wnpp > Severity: wishlist > Owner: Riccardo Setti <[EMAIL PROTECTED]> > > > * Package name: cinelerra-cvs > Version : 2.0-cvs > Upstream Author : > * URL : http://www.example.org/ > * License : GPL > Description : non-linear video editor and compositor for Linux. > > Cinelerra, the first Linux based real-time editing and special effects > system is a revolutionary Open Source HD media editing system. You know there has been an RFP on cinelerra itself for a very long time, almost 5 years. See bugs.debian.org/78209, 156614, 239570. Why do you want to have a CVS version from the package if there even isn't a normal version of it in the archive? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#331072: ITP: cinelerra-cvs -- non-linear video editor and compositor for Linux.
On Sat, Oct 01, 2005, Riccardo Setti wrote: > Cinelerra, the first Linux based real-time editing and special effects > system is a revolutionary Open Source HD media editing system. > It has a number of effects built into the system including > numerous telecine effects, video special effects including compositing, > and a complete audio effects system. > This is a branched version of Cinelerra sometimes called > Cinelerra-CVS Be careful, more than 1000 Cinelerra source files do not have a proper license, a dozen are copyrighted by the MPEG group, another dozen are under the old ugly OpenDivX license, and you have many additional strange licensing terms in some files (such as free to copy and modify, but not to redistribute). Are you in touch with Holger Levsen <[EMAIL PROTECTED]>? We talked about Cinelerra at the QA miniconf and I sent him a list of problematic source files I had gathered. He is in touch with other people interested in packaging Cinelerra. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#331072: ITP: cinelerra-cvs -- non-linear video editor and compositor for Linux.
Am Samstag, 1. Oktober 2005 15.31 schrieb Kurt Roeckx: Morning > On Sat, Oct 01, 2005 at 03:05:08PM +0200, Riccardo Setti wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Riccardo Setti <[EMAIL PROTECTED]> > > > > > > * Package name: cinelerra-cvs > > Version : 2.0-cvs > > Upstream Author : > > * URL : http://www.example.org/ > > * License : GPL > > Description : non-linear video editor and compositor for Linux. > > > > Cinelerra, the first Linux based real-time editing and special effects > > system is a revolutionary Open Source HD media editing system. > > You know there has been an RFP on cinelerra itself for a very > long time, almost 5 years. See bugs.debian.org/78209, 156614, > 239570. > > Why do you want to have a CVS version from the package if there > even isn't a normal version of it in the archive? cinelerra-cvs is not really a cvs version but a version of cinelerra with is targeted at new users and not professionel video cutter. > Kurt Hope to help Mario -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#331072: ITP: cinelerra-cvs -- non-linear video editor and compositor for Linux.
* Kurt Roeckx <[EMAIL PROTECTED]> [2005-10-01 15:31:54 +0200]: > You know there has been an RFP on cinelerra itself for a very > long time, almost 5 years. See bugs.debian.org/78209, 156614, > 239570. > > Why do you want to have a CVS version from the package if there > even isn't a normal version of it in the archive? The information at http://cvs.cinelerra.org/about.html seems to indicate that the two codebases are at least somewhat separate, so I don't think the distinction is quite as clear-cut as you make out. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature
Re: curl status update
On Sat, Oct 01, 2005 at 02:43:32PM +0200, Elimar Riesebieter wrote: > On Thu, 29 Sep 2005 the mental interface of > Steve Langasek told: > [...] >> There isn't? I saw some arguments that explain why it's not possible to >> convert all curl-using applications from OpenSSL to GNUTLS without a >> recompile due to unavailable ABI changes, but I thought it was pretty clear >> that the default going forward should be the one whose license is maximally >> compatible with that of applications using libcurl (i.e., GNUTLS). > libcurl3-gnutls-dev 7.14.1-3 works well ;-) The only challange we > have to solve is: > Which curl deps have to be the default? > IMHO the gnutls one. What do you mean by default? a) The -dev to use if you don't use the OpenSSL callback, and you're not GPL, modulo relevant bugs? I think this was pretty clearly gnuTLS. Is _anyone_ suggesting OpenSSL for this? b) The version that should be in libcurl3? Has to be OpenSSL, to not break Sarge upgrades. And this will be true for the life of the package, unless we manage to get every package in Etch to not use it, at which point post-etch can do whatever. Including removing it in favour of libcurl4. ^_^ -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpDCuaw1OF9z.pgp Description: PGP signature
Bug#331079: ITP: hscurses -- Haskell binding to the ncurses library
Package: wnpp Severity: wishlist Owner: Jérémy Bobbio <[EMAIL PROTECTED]> * Package name: hscurses Version : 0.ds-20050830 Upstream Author : Stefan Wehr <[EMAIL PROTECTED]> * URL : http://www.stefanheimann.net/haskell/ * License : GPL Description : Haskell binding to the ncurses library hscurses provides interface for Haskell programmers to ncurses, a library of functions that manage an application's display on character-cell terminals. hscurses also provides some basic widgets implemented on top of the ncurses binding, such as a text input widget and a table widget. -- Jérémy pgpM3CWHpQ7Md.pgp Description: PGP signature
Re: Re: watch file for SourceForge packages
i want to watch free flim please sen to me thanhs Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort.
Re: Bug#331072: ITP: cinelerra-cvs -- non-linear video editor and compositor for Linux.
Kurt Roeckx wrote: >You know there has been an RFP on cinelerra itself for a very >long time, almost 5 years. See bugs.debian.org/78209, 156614, >239570. > >Why do you want to have a CVS version from the package if there >even isn't a normal version of it in the archive? > > cinelerra is forked. To repeat what Riccardo has written: "This is a branched version of Cinelerra sometimes called Cinelerra-CVS . Please visit cvs.cinelerra.org for more information regarding this duality." But your reaction proves that the name "cinelerra-cvs" is misleading. Cheers, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: g-wrap -- Scripting interface generator for C
Andreas Rottmann <[EMAIL PROTECTED]> writes: > Well, G-Wrap 1.3 has no upstream anymore, and its functionality is > replicated in G-Wrap 1.9 - you know, I didn't add the compatibility > layer for the fun of it. I know. > Does upstream actually say that? I've been talking with Derek Atkins > (warlord) on IRC, and from what I gathered, they are trying to use > G-Wrap 1.9, and mostly suceeding modulo a few buglets, all of which > should be fixed in the Debian packaging. Yes, certainly! This is for the gnome-2 gnucash under development. Your work making that functional is definitely appreciated, very helpful, and important. I'm speaking now of the gnome-1 gnucash, the one that currently lives in Debian. That version, I want to make as few destabilizing changes as I can, because I don't have any interest in things which might end up distracting upstream from the gnome-2 version. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
On Fri, 30 Sep 2005, Thomas Bushnell BSG wrote: > Laszlo Boszormenyi <[EMAIL PROTECTED]> writes: > >> When they do, it is a violation of Debian standards to remove it from > >> the orig.tar.gz file. So there is no question of doing that. > > > Where do you read that? May be true, but can't remember any place ATM. > > What do you think "orig" means in "orig.tar.gz"? We make a necessary It is a strong hint that one should muck as little as possible with the .orig* tarballs. Anyway, it is pretty much the current best practice that: 0. You don't add OR change anything to .orig.tar.gz other than tarball metadata (except filenames -- don't touch those!). 1. You are free to fix permission and other utter breakages of the kind (devices and other special inodes, relative paths, etc) which for some reason cannot be fixed by debian/rules. Nowadays I doubt you can get permission problems that debian/rules can't fix because dpkg-source will fix the absolute minimum to get debian/rules to work for you, but still... 2. You are free to remove stuff for technical or DFSG-compliance reasons. BUT you are to document any and ALL .orig changes in debian/copyright. > >> If you remove the CVS files from your unpacked build directory, that's > >> well and good, but dpkg-source refuses to honor this, printing helpful > >> messages like > >> dpkg-source: warning: ignoring deletion of directory stylesheet/CVS > > > That's correct. You should remove it from .orig.tar.gz . > > Hogwash. It should not be removed at all. It *can* be removed, but there is little reason to. In fact, unless a developer is using an utterly braindamaged VC-enabled Debian packaging toolset, he will be notified by the toolset of the potential problems and he will be able to remove the CVS/svn/whatever crap before it hoses his VC system. > Next will you be saying that other bugs in upstream packaging should > be marked by lintian? IF they are going to cause major blowups on someone else, yes. But I can't think of any. And lintian does pester about outdated config.sub/guess, etc. These warnings are useful from time to time. > It does make sense to warn against Debian developers who have *added* > a CVS directory not present in the upstream source, but that's a > different matter. Or those who screw up and add it to a non-orig .orig.tar.gz (and by that I do NOT mean a modified upstream one, I mean a re-generated tarball during build because someone screwed up). 99.9% of the time, one just ignores these lintian warnings as one knows it comes from the upstream tarball. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
can someone reproduce Bug #325971 (slapd + gnutls)
Hi, I hope this is the right list to ask. If not, please give me a hint where to post this otherwise. We run Debian Sarge on our institutes ldap server and our clients and have problems with slapd + applications using libgnutls11. See the bug report #325971 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325971). I posted this bug 1 month ago but, until now, got no response. It would be really helpful for me if someone could try to reproduce the bug (see my second e-mail in the bug report) and tell me whether it appears or not. Since I'm sure many people on this list (successfully?) use Sarge on the LDAP server + Sarge gnutls-clients (like libnss-ldap) on some clients, it would help me a lot to hear your experiences to track down this problem. The reproduction of the bug only involves a default installation of slapd on a Sarge test machine and running gnutls-cli on the same machine. Thanks in advance for any help. regards Daniel -- - Daniel Hermann, Institut fuer Theorie der Kondensierten Materie Universitaet Karlsruhe Tel: ++49 (0)721 608-7328 Postfach 6980 Fax: ++49 (0)721 608-7779 76128 Karlsruhe, Germany email: [EMAIL PROTECTED] - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > And lintian does pester about outdated config.sub/guess, etc. These > warnings are useful from time to time. Those problems can be fixed without violating Debian rules too. :) >> It does make sense to warn against Debian developers who have *added* >> a CVS directory not present in the upstream source, but that's a >> different matter. > > Or those who screw up and add it to a non-orig .orig.tar.gz (and by that I > do NOT mean a modified upstream one, I mean a re-generated tarball during > build because someone screwed up). > > 99.9% of the time, one just ignores these lintian warnings as one knows it > comes from the upstream tarball. I'd rather not have warnings that must be ignored 99.9% of the time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: g-wrap -- Scripting interface generator for C
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: >> Does upstream actually say that? I've been talking with Derek Atkins >> (warlord) on IRC, and from what I gathered, they are trying to use >> G-Wrap 1.9, and mostly suceeding modulo a few buglets, all of which >> should be fixed in the Debian packaging. > > Yes, certainly! This is for the gnome-2 gnucash under development. > Your work making that functional is definitely appreciated, very > helpful, and important. > > I'm speaking now of the gnome-1 gnucash, the one that currently lives > in Debian. > > That version, I want to make as few destabilizing changes as I can, > because I don't have any interest in things which might end up > distracting upstream from the gnome-2 version. > Ok, thanks for the clarification! Let's hope the G2 port will release in time for etch ;). Cheers, Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com Software Patents: Where do you want to stifle inovation today? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > >>> It does make sense to warn against Debian developers who have *added* >>> a CVS directory not present in the upstream source, but that's a >>> different matter. >> >> Or those who screw up and add it to a non-orig .orig.tar.gz (and by that I >> do NOT mean a modified upstream one, I mean a re-generated tarball during >> build because someone screwed up). >> >> 99.9% of the time, one just ignores these lintian warnings as one knows it >> comes from the upstream tarball. > > I'd rather not have warnings that must be ignored 99.9% of the time. You could add a lintian override. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mass bug filing on packages that are blocking use of cdebconf
Junichi Uekawa wrote: > I've tried to search for what debconf-2.0 specification is; > and how it's different from debconf, but it's not obvious. > What's missing from the picture is the changelog of debconf > specification (presumably from 1.0), and what's changed. Please see Debian policy. -- see shy jo signature.asc Description: Digital signature
Re: pbuilder status update
Junichi Uekawa wrote: > Yes, I don't have --resolve-deps, in the hope that > priorities are fixed by ftp-masters. > > There needs to be a decision somewhere: > 1. ignore priorities and go back to what it was before > and make --resolve-deps the default in debootstrap > 2. try to fix priorities/section AFAIK the plan is to not constantly bother the ftp masters with override changes, and only get them updated just before the stable release. Then stable will be installable without --resolve-deps. However, unstable will still need it. -- see shy jo signature.asc Description: Digital signature
Re: mass bug filing on packages that are blocking use of cdebconf
Joey Hess <[EMAIL PROTECTED]> writes: > Junichi Uekawa wrote: >> I've tried to search for what debconf-2.0 specification is; >> and how it's different from debconf, but it's not obvious. >> What's missing from the picture is the changelog of debconf >> specification (presumably from 1.0), and what's changed. > > Please see Debian policy. Or, more helpfully, please see section 3.10.1 of Debian policy. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
Don Armstrong wrote: > It's not really a bogus warning; the point of it is so that you're > aware so that you can remind upstream not to distribute CVS files in > their tarballs. Isn't getting nasty CVS directories in the source tree that you work on while maintaining the package reminder enough that upstream neads a cluebatting? -- see shy jo signature.asc Description: Digital signature
Re: curl status update
On Sun, 02 Oct 2005 the mental interface of Paul TBBle Hampson told: > On Sat, Oct 01, 2005 at 02:43:32PM +0200, Elimar Riesebieter wrote: > > On Thu, 29 Sep 2005 the mental interface of > > Steve Langasek told: > > > [...] > >> There isn't? I saw some arguments that explain why it's not possible to > >> convert all curl-using applications from OpenSSL to GNUTLS without a > >> recompile due to unavailable ABI changes, but I thought it was pretty clear > >> that the default going forward should be the one whose license is maximally > >> compatible with that of applications using libcurl (i.e., GNUTLS). > > libcurl3-gnutls-dev 7.14.1-3 works well ;-) The only challange we > > have to solve is: > > Which curl deps have to be the default? > > IMHO the gnutls one. > > What do you mean by default? libcurl has to point to gnutls by default! Elimar -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: > > The lintian warning source-contains-CVS-dir is bogus. > > I agree that upstream should not put CVS in their tarballs. But > sometimes they do. > > When they do, it is a violation of Debian standards to remove it from > the orig.tar.gz file. So there is no question of doing that. If you want to maintain a package using cvs-buildpackage, you *have* to remove those files from the orig.tar.gz. > If you remove the CVS files from your unpacked build directory, that's > well and good, but dpkg-source refuses to honor this, printing helpful > messages like > dpkg-source: warning: ignoring deletion of directory stylesheet/CVS > > Of course dpkg-source ignores these because the packaging manual says > that the .diff.gz can't specify deletions. (Never mind that patch is > perfectly capable of handling deletions.) > > So, it's a bogus warning. It should be removed from lintian. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
ITP: dares -- rescue files from damaged CDs and DVDs
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: dares Version : 0.6.5 Upstream Author : Oliver Diedrich <[EMAIL PROTECTED]> * URL : ftp://ftp.heise.de/pub/ct/ctsi/dares.tgz * License : GPL Description : rescue files from damaged CDs and DVDs Dares scans a CD/DVD image or a CD/DVD for files. This also works when the filesystem (ISO-9660 or UDF) on the disc is damaged and cannot be mounted anymore. . Dares can use H2cdimage (ftp://ftp.heise.de/pub/ct/ctsi/h2cdimage.zip) files to rescue data from heavily damaged optical discs. I'm looking for a sponsor for this package. It is ready for inspection and available from http://mentors.debian.net. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.11-9-amd64-k8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
On Sat, 01 Oct 2005, Eric Dorland wrote: > If you want to maintain a package using cvs-buildpackage, you *have* > to remove those files from the orig.tar.gz. This is false. cvs-upgrade -F and cvs-inject -F solves your problem. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder status update
On Sat, Oct 01, 2005 at 02:12:14PM -0400, Joey Hess wrote: > AFAIK the plan is to not constantly bother the ftp masters with override > changes, Which makes the whole packages buggy according to the policy. Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3 signature.asc Description: Digital signature
Re: bogus lintian warning
Joey Hess <[EMAIL PROTECTED]> writes: > Don Armstrong wrote: >> It's not really a bogus warning; the point of it is so that you're >> aware so that you can remind upstream not to distribute CVS files in >> their tarballs. > > Isn't getting nasty CVS directories in the source tree that you work > on while maintaining the package reminder enough that upstream neads > a cluebatting? But lintian is not there to warn about unfixable problems with upstream. It is there to warn about *packaging mistakes*. It is not a packaging mistake to leave upstream's bogus CVS directories there; it is actually *required* by the tools. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: curl status update
On Saturday 01 October 2005 02:49 pm, Elimar Riesebieter wrote: > On Sun, 02 Oct 2005 the mental interface of > > Paul TBBle Hampson told: > > On Sat, Oct 01, 2005 at 02:43:32PM +0200, Elimar Riesebieter wrote: > > > On Thu, 29 Sep 2005 the mental interface of > > > Steve Langasek told: > > > > > > [...] > > > > > >> There isn't? I saw some arguments that explain why it's not > > >> possible to convert all curl-using applications from OpenSSL to > > >> GNUTLS without a recompile due to unavailable ABI changes, but I > > >> thought it was pretty clear that the default going forward should be > > >> the one whose license is maximally compatible with that of > > >> applications using libcurl (i.e., GNUTLS). > > > > > > libcurl3-gnutls-dev 7.14.1-3 works well ;-) The only challange we > > > have to solve is: > > > Which curl deps have to be the default? > > > IMHO the gnutls one. > > > > What do you mean by default? > > libcurl has to point to gnutls by default! Look, once the new packages hit unstable, everyone building against libcurl will need to choose libcurl-openssl-dev or libcurl-gnutls-dev to build against. If they build against the former, the binary packages will depend on the openssl libcurl, if the latter, they will depend on the gnutls libcurl. The openssl libcurl is still called libcurl3 so that packages that *already built* against the openssl libcurl won't be broken. For new package builds, there will be no "default" libcurl. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you do if a package is built and not uploaded?
Thiemo Seufer wrote:
> Mailing {alpha,mips,[EMAIL PROTECTED] is my best guess. There
> is usually no reply, but from some cases I conclude the mailboxes are
> read. I don't know if those addresses are documented anywhere.
They're not. Perhaps they could be? :-) That would be a big help.
--
Nathanael Nerode <[EMAIL PROTECTED]>
"(Instead, we front-load the flamewars and grudges in
the interest of efficiency.)" --Steve Lanagasek,
http://lists.debian.org/debian-devel/2005/09/msg01056.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you do if a package is built and not uploaded?
* Nathanael Nerode ([EMAIL PROTECTED]) [051001 22:42]:
> Thiemo Seufer wrote:
> > Mailing {alpha,mips,[EMAIL PROTECTED] is my best guess. There
> > is usually no reply, but from some cases I conclude the mailboxes are
> > read. I don't know if those addresses are documented anywhere.
> They're not. Perhaps they could be? :-) That would be a big help.
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-porter-automation
| The buildds admins of each arch can be contacted by the mail address
| [EMAIL PROTECTED]
Cheers,
Andi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
On Sat, 1 Oct 2005 14:55:18 -0400, Eric Dorland <[EMAIL PROTECTED]> wrote: >If you want to maintain a package using cvs-buildpackage, you *have* >to remove those files from the orig.tar.gz. Does that hold for debian/ only setups as well? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Important news
We (Deep blue media technology) is engaged in web hosting and website design as well as multimedia company, company is located LA. We pass through long time arrangement and diligently officially provide service in January, 2005. Printing as multimedia from graphic design as web hosting, all in ours range of service, our end aim is provides comprehensive and satisfactory service for customer. Hot deals: Business card 1/0 1000 $25 NCR 3 Set 1/0 1000 $125 Web design $99 Many kind service avaliable You can visit our web site http://www.deepbluemediatech.com/ Or get a qouta http://www.deepbluemediatech.com/Quote/ Thank you
Re: Apt, custom packages, and package dependencies
"Michael S. Peek" <[EMAIL PROTECTED]> writes: > Hello developers, I'm a n00b. > > I've got my own little http debian package repository. It shows up with apt > and dselect. > > In this repository I've got a custom package that I'm working on that depends > on a bunch of ldap stuff, and contains configuration files and installation > scripts to install and configure ldap for me. > > In this package's control file are the following lines: > > Package: tiem.ldap-server-config > Architecture: all > Depends: slapd ldap-utils libnss-ldap libpam-ldap > Pre-Depends: slapd ldap-utils libnss-ldap libpam-ldap Why repeat each package? Pick one line or the other. > My problem is, according to dselect, there are no dependencies or > pre-dependencies listed, and apt won't try to install any of the depencies > before installing my package. What is listed in the Packages file? That is the only thing dselect looks at. On the other hand dpkg should complain about missing depends. > Other custom packages that I have built have their dependencies listed in > dselect, but not this one. And I have both completely erased and rebuilt my > repository on the server and run "apt update" on the client several times. > > I figure the problem is in one of two places. Either: > > a) There's a cache file somewhere that apt isn't updating when I type "apt > update", or Nope. > b) There's a file that needs to be updated on my repository -- even though > I've totally deleted and rebuilt the repository several times. Nope. c) The Packages file gets misgenerated. :) > Anybody have any idea where I would go about finding out what's wrong? > > Thanks for your help, > > Michael Peek MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you do if a package is built and not uploaded?
Nathanael Nerode <[EMAIL PROTECTED]> writes:
> Thiemo Seufer wrote:
>> Mailing {alpha,mips,[EMAIL PROTECTED] is my best guess. There
>> is usually no reply, but from some cases I conclude the mailboxes are
>> read. I don't know if those addresses are documented anywhere.
> They're not. Perhaps they could be? :-) That would be a big help.
That makes it request number 324 for that documentation to happen.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder status update
On Sat, Oct 01, 2005 at 02:12:14PM -0400, Joey Hess wrote: > Junichi Uekawa wrote: > > Yes, I don't have --resolve-deps, in the hope that > > priorities are fixed by ftp-masters. > > > > There needs to be a decision somewhere: > > 1. ignore priorities and go back to what it was before > > and make --resolve-deps the default in debootstrap > > 2. try to fix priorities/section > > AFAIK the plan is to not constantly bother the ftp masters with override > changes, and only get them updated just before the stable release. Then > stable will be installable without --resolve-deps. However, unstable > will still need it. Fwiw, it's quite fine to get overrides changed throughout the release cycle -- it's even preferred because *if* there are issues, they are discovered early instead of last-minute. That said, I think it's good to use --resolve-deps by default for testing/unstable, so that override changes aren't that urgent (they don't break daily builds etc every other day), and can be batched up a bit, and processed when the dependency graph is a bit stable. Which may very well be only possible in the second half of a release cycle, but doing it really last-minute seems unwise to me. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#142164: Packages files should be in UTF-8
Kurt Roeckx <[EMAIL PROTECTED]> writes: > On Thu, Sep 29, 2005 at 11:32:13PM -0500, Manoj Srivastava wrote: >> reassign 142164 general >> thanks >> >> Hi, >> >> Just because a topic has been discussed on the policy >> discussion list is not reason enough to assign the bug to >> policy. > > Note that bug has been reassigned to the policy in 2003. Spam > closed it, and it was just reopened. > >> This has nothing to do with creating a package, and certainly >> not the place of policy to lead out by mandating stuff. Again, this >> problem needs to be worked out abd put into effect by the bits that >> put the Package ile together, and once we have a working solution, we >> can start examing the bits of policy that may need to be changed for >> the solution. > > I agree that the policy shouldn't mandate that the Packages > file should be encoded in UTF-8. But I think it should say > the the control and changelog files are, and I believe that is in > the scope of the policy. This would of course have as side > effect that the Packages file ends up as UTF-8 too. > > Note it says that is is "recommended" to encode the changelog in > UTF-8 (C.2.2), it does not say any such thing about the control > file. I think we should say that both should be encoded in > UTF-8, or maybe a must. But we can change that to a must at a > later date. > > > Kurt I think all six, dsc, changes, changelog, control, Packages and Sources files, must be UTF-8 for three simple reasons: - They all interconnect through tools that preserve / ignore the encoding. - They can't have different encodings since guessing the right conversions would be hell. - UTF-8 is the only practical format covering all cases. If policy has something to say about one of them then it has to say something about all of them. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advices needed for moving {add|remove}-shell from passwd to debianutils
[Christian Perrier] > The goal is having a system which always has the two utilities...and > of course avoid the removal of passwd (debianutils is Essential while > passwd isn't). passwd effectively is Essential because bash depends on it. So I'm pretty sure you don't have to worry about it being removed. Just coordinate two uploads to happen in the same dinstall cycle: shadow 1:4.0.12-6 where passwd Depends: debianutils (>= 2.15) debianutils 2.15 Conflicts and Replaces: passwd (<< 1:4.0.12-6) I think the passwd versioned dep on debianutils will have to stay until etch is released. Peter signature.asc Description: Digital signature
Re: Advices needed for moving {add|remove}-shell from passwd to debianutils
On Sat, Oct 01, 2005 at 03:05:30PM +0200, Christian Perrier wrote: > The plan we draw is the following: > 1) shadow package maintainers upload passwd which >"Depends: debianutils (<= 2.14.3)" >this version *still* includes the utilities > The purpose of 1) is to avoid the removal of passwd during new systems > installs between 3) and 5) in case both do not happen at the same > time. Is that actually likely to happen? If this is coordinated, surely uploading the new passwd and debianutils within a day of each other is as easy as uploading shadow twice? > A simpler solution could be merging 3) and 5) in a single upload. Then > the "Depends" in 1) would not be needed. Yeah, that's one way to ensure the uploads are coordinated. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Advices needed for moving {add|remove}-shell from passwd to debianutils
On Sunday 02 October 2005 00:09, Peter Samuelson wrote: > Just coordinate two uploads to happen in the same dinstall cycle: > > shadow 1:4.0.12-6 where passwd Depends: debianutils (>= 2.15) > debianutils 2.15 Conflicts and Replaces: passwd (<< 1:4.0.12-6) Hmm. That will cover i386 I guess. What about other arches that are autobuilt? (Assuming of course that both maintainers upload for i386.) pgpcykoH1Emgz.pgp Description: PGP signature
Re: Debian GNU/Darwin
Ritesh Raj Sarraf wrote: > Mac OSX's open source version, Darwin, Does it qualify under DFSG ? Not if its under the ASPL. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: a place for a package directory in root
Joerg Sommer wrote: > But I've a question on it: How can I use it? How can I set up /run before > init runs the init script that is responsible for it? I'd assume you'd make the mounting of /run be the first script init runs. So, it'd be /etc/rcS.d/S00mountrun (under SysV-style init, of course). Or maybe it'd become part of S02mountvirtfs. If this is still too late, init itself would have to do it. > This script should > be resistant to multiple start calls. S02mountvirtfs already is. Or at least so say the comments. > > Bye, Jörg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Everyone go test aptitude 0.3.4!
I've just uploaded aptitude 0.3.4 to experimental. This is basically a release candidate for 0.4 -- if no nasty bugs crop up, it will be uploaded as 0.4 in unstable once the translators catch up with all the string changes. So, everyone go find bugs in it! A few of the major changes relative to 0.2 (unstable) are: - UTF-8 support - A new dependency resolution algorithm - Threading (downloads run in the background to keep the program responsive) Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "This is too absurd! The world can't end this stupidly!" | | "Oh, sure it can. Have some faith." | | -- Fluble | \ The Turtle Moves! -- http://www.lspace.org ---/ pgpYGSa08xVjE.pgp Description: PGP signature
Re: Everyone go test aptitude 0.3.4!
On Sat, Oct 01, 2005 at 05:48:14PM -0700, Daniel Burrows wrote: > I've just uploaded aptitude 0.3.4 to experimental. This is basically a > release candidate for 0.4 -- if no nasty bugs crop up, it will be uploaded as > 0.4 in unstable once the translators catch up with all the string changes. > So, everyone go find bugs in it! Am I missing something here? baby:~> LANG=C sudo aptitude -t experimental install aptitude (...) E: Unable to resolve some dependencies! Some packages had unmet dependencies. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following packages have unmet dependencies: aptitude: Depends: libapt-pkg-libc6.3-5-3.9 which is a virtual package. Depends: libsigc++-2.0-0 (>= 2.0.2) but it is not installable /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gal0.x not being added to archive?
Why is gal0.x not being added to the archive on alpha, i386, mips, and mipsel? According to the buildd logs, it compiled successfully on all those archs over ten days ago. It was uploaded for all the other archs. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Everyone go test aptitude 0.3.4!
Steinar H. Gunderson wrote: > On Sat, Oct 01, 2005 at 05:48:14PM -0700, Daniel Burrows wrote: >> I've just uploaded aptitude 0.3.4 to experimental. This is basically a >> release candidate for 0.4 -- if no nasty bugs crop up, it will be uploaded >> as >> 0.4 in unstable once the translators catch up with all the string changes. >> So, everyone go find bugs in it! > > Am I missing something here? > > baby:~> LANG=C sudo aptitude -t experimental install aptitude > (...) > E: Unable to resolve some dependencies! > Some packages had unmet dependencies. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > > The following packages have unmet dependencies: > aptitude: Depends: libapt-pkg-libc6.3-5-3.9 which is a virtual package. > Depends: libsigc++-2.0-0 (>= 2.0.2) but it is not installable > > /* Steinar */ That's the stale 0.3.3 aptitude, looks like the new one won't hit the archives til tomorrow[or it needs to be autobuilt]... Been using 0.3.3 for a while and the new interactive dependency resolution is pretty cool, if a little confusing at first. Travis signature.asc Description: OpenPGP digital signature
Re: Everyone go test aptitude 0.3.4!
On Saturday 01 October 2005 05:57 pm, Steinar H. Gunderson wrote: > On Sat, Oct 01, 2005 at 05:48:14PM -0700, Daniel Burrows wrote: > > I've just uploaded aptitude 0.3.4 to experimental. This is basically a > > release candidate for 0.4 -- if no nasty bugs crop up, it will be > > uploaded as 0.4 in unstable once the translators catch up with all the > > string changes. So, everyone go find bugs in it! > > Am I missing something here? The operative word is "just" :-). Newly uploaded packages have to go live in the incoming ghetto until the next dinstall run lets them into the archive. The binary packages are currently available at http://incoming.debian.org/aptitude_0.3.4-1_i386.deb http://incoming.debian.org/aptitude-doc-cs_0.3.4-1_all.deb http://incoming.debian.org/aptitude-doc-en_0.3.4-1_all.deb http://incoming.debian.org/aptitude-doc-fr_0.3.4-1_all.deb Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "You mean, you'll drop your rock and | | I'll drop my sword and we'll just try to | | kill one another like civilized people?" | | -- "The Princess Bride" | \ Got APT? -- Debian GNU/Linux http://www.debian.org ---/ pgpe8sA3dwGDD.pgp Description: PGP signature
Re: Everyone go test aptitude 0.3.4!
On Sat, Oct 01, 2005 at 05:48:14PM -0700, Daniel Burrows wrote: > I've just uploaded aptitude 0.3.4 to experimental. This is basically a > release candidate for 0.4 -- if no nasty bugs crop up, it will be uploaded as > 0.4 in unstable once the translators catch up with all the string changes. > So, everyone go find bugs in it! Would it perhaps be a good idea to hold off on uploading to unstable until the current version of the apt packages reach testing? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Everyone go test aptitude 0.3.4!
On Saturday 01 October 2005 07:07 pm, Steve Langasek wrote: > On Sat, Oct 01, 2005 at 05:48:14PM -0700, Daniel Burrows wrote: > > I've just uploaded aptitude 0.3.4 to experimental. This is basically a > > release candidate for 0.4 -- if no nasty bugs crop up, it will be > > uploaded as 0.4 in unstable once the translators catch up with all the > > string changes. So, everyone go find bugs in it! > > Would it perhaps be a good idea to hold off on uploading to unstable until > the current version of the apt packages reach testing? I suppose so -- it'll probably take a while before the translations are ready anyway. When do you think apt 0.6.41 and its related packages will go in? Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Of course you can't see the guards. They DON'T EXIST!" | | "Oh my god, we're surrounded!" "Run away, run away!" | | -- Fluble| \ The Turtle Moves! -- http://www.lspace.org ---/ pgpkDXsdTWiNM.pgp Description: PGP signature
Re: Everyone go test aptitude 0.3.4!
On Sat, Oct 01, 2005 at 07:18:32PM -0700, Daniel Burrows wrote: > On Saturday 01 October 2005 07:07 pm, Steve Langasek wrote: > > On Sat, Oct 01, 2005 at 05:48:14PM -0700, Daniel Burrows wrote: > > > I've just uploaded aptitude 0.3.4 to experimental. This is basically a > > > release candidate for 0.4 -- if no nasty bugs crop up, it will be > > > uploaded as 0.4 in unstable once the translators catch up with all the > > > string changes. So, everyone go find bugs in it! > > Would it perhaps be a good idea to hold off on uploading to unstable until > > the current version of the apt packages reach testing? > I suppose so -- it'll probably take a while before the translations are > ready anyway. When do you think apt 0.6.41 and its related packages will go > in? Not until gcc-4.0 and perl are both updated in testing, which block much of the archive from being updated right now. gcc-4.0 is blocked mainly by kaffe at this point; perl is blocked by the yet-unresolved testsuite failures on arm and m68k. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Accepted aptitude 0.3.4-1 (source all i386)
Just a couple of comments: Daniel Burrows wrote: > - New command-line option --schedule-only that just records the >requested actions in the state file without actually performing them. >(Closes: #312249) Hmm, I have a feeling it should be possible to use this in tasksel to let a task be selected but still start aptitude in interactive mode at the main pckage browser rather than the install screen. > - aptitude now cleanly handles being suspended while dpkg is running. >(Closes: #137311, #169479) Hurrah! > - The password database is used instead of $HOME to determine where >aptitude's configuration file goes, so people using sudo don't end up >with root-owned mode 0700 files in their home directory. >(Closes: #272429, #274216, #285334, #272409) Well, aptitude and debconf both it seems. Which suggests to me this is a larger problem. Also note that I got just as many bugs reports after I made debconf do this as I was able to close by doing it. :-/ -- see shy jo signature.asc Description: Digital signature
Re: Advices needed for moving {add|remove}-shell from passwd to debianutils
[Frans Pop] > > shadow 1:4.0.12-6 where passwd Depends: debianutils (>= 2.15) > > debianutils 2.15 Conflicts and Replaces: passwd (<< 1:4.0.12-6) > > Hmm. That will cover i386 I guess. What about other arches that are > autobuilt? (Assuming of course that both maintainers upload for i386.) Good point, might it be better to upload shadow first and get it autobuilding everywhere, then debianutils? The one will be uninstallable for a day or two, but having something uninstallable for a day is quite normal for unstable. signature.asc Description: Digital signature
Re: pbuilder status update
Hi, > That said, I think it's good to use --resolve-deps by default for > testing/unstable, so that override changes aren't that urgent (they don't > break daily builds etc every other day), and can be batched up a bit, and > processed when the dependency graph is a bit stable. Which may very well be > only possible in the second half of a release cycle, but doing it really > last-minute seems unwise to me. I don't want to have to use different options for different distributions, like switching to --resolve-deps for sid only. From QA point of view, we are distributing something that is only lightly tested as a stable release; which means it will inevitably be broken in subtle ways on architectures that are more lightly tested. If Priorities aren't going to be updated in a timely manner within sid distribution, it might be time to rethink about its usefulness. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
On Sat, 01 Oct 2005, Thomas Bushnell BSG wrote: > But lintian is not there to warn about unfixable problems with You cannot reliably determine wether the maintainer is doing something stupid, or upstream is. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
On Sat, 01 Oct 2005, Marc Haber wrote: > On Sat, 1 Oct 2005 14:55:18 -0400, Eric Dorland <[EMAIL PROTECTED]> > wrote: > >If you want to maintain a package using cvs-buildpackage, you *have* > >to remove those files from the orig.tar.gz. > > Does that hold for debian/ only setups as well? It does *NOT* hold for any setup. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you do if a package is built and not uploaded?
On Sat, 01 Oct 2005, Andreas Barth wrote:
> * Nathanael Nerode ([EMAIL PROTECTED]) [051001 22:42]:
> > Thiemo Seufer wrote:
> > > Mailing {alpha,mips,[EMAIL PROTECTED] is my best guess. There
> > > is usually no reply, but from some cases I conclude the mailboxes are
> > > read. I don't know if those addresses are documented anywhere.
> > They're not. Perhaps they could be? :-) That would be a big help.
>
> http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-porter-automation
Not good enough. Please add it to the central place we all go hunting for
buildd issues: buildd.debian.org.
Oh wait, I forgot that buildd.d.o is effectively read-only, as it has
already reached perfection. Never mind.
The most effective way to do it is IMHO a BTS entry for each ARCH port, to
track down all porting issues with a damn good memory. THAT's transparency,
and it is much more manageable than trying to contact a number of mailing
lists (which are often quite effective) and email addresses (which aren't
_apparently_). The PTS takes care of keeping whichever email addresses
informed.
And the history we get from the BTS can definately help track which arches
are boggling down the rest of Debian, and how often that happens.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder status update
On Sun, 02 Oct 2005, Junichi Uekawa wrote: > If Priorities aren't going to be updated in a timely manner within > sid distribution, it might be time to rethink about its usefulness. Agreed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > On Sat, 01 Oct 2005, Thomas Bushnell BSG wrote: >> But lintian is not there to warn about unfixable problems with > > You cannot reliably determine wether the maintainer is doing something > stupid, or upstream is. In which case, it certainly can't be reported as an error. But say more: what are the ambiguous cases? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advices needed for moving {add|remove}-shell from passwd to debianutils
> > A simpler solution could be merging 3) and 5) in a single upload. Then > > the "Depends" in 1) would not be needed. > > Yeah, that's one way to ensure the uploads are coordinated. :) BUT one should have the dependencies (and eventually build dependencies) in there ANYWAY. People often do partial upgrades, so keep the dependencies there. And the buildds often screwup transitions if you don't clamp it in build dependencies, so if it affects the build, clamp it with versioned build dependencies and conflicts. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bogus lintian warning
On Sat, 01 Oct 2005, Thomas Bushnell BSG wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > > On Sat, 01 Oct 2005, Thomas Bushnell BSG wrote: > >> But lintian is not there to warn about unfixable problems with > > > > You cannot reliably determine wether the maintainer is doing something > > stupid, or upstream is. > > In which case, it certainly can't be reported as an error. But it can as a warning. That's what they are for. > But say more: what are the ambiguous cases? dpkg-buildpackage in a cvs-checkout directory with strange things in the parent dir, for example, because of test builds leaving weird shit on the parent directory + lack of coffee + typing dpkg-buildpackage instead of cvs-buildpackage. It gets "I was too sleepy to think straight" type of errors. And it also tells you when upstream screwed up their dist-clean target, which is quite useful too. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advices needed for moving {add|remove}-shell from passwd to debianutils
Short summary of answers Our plan seems correct. Some (Peter Samuelson, Steve Langasek) suggest it is a bit overflated and synced uploads of fixed packages should be enough. However, Frans mentioned autobuilders which will not guarantee that both packages will reach unstable at the same dinstall run for all arches. Of course, if uploaded at the same time, that should be OK but we have to deal with Murphy's law: this is why I prefer keeping both packages installable at all moments...even if it complicates the process. So, up to now, no change to our plans..:-) Peter Samuelson mentioned passwd being Essential because it depends on passwd. This is actually right. However this dependency is just the consequence of bash needing the add-shell and remove-shell utilities...so, in the future, bash shouldn't depend on passwd anymore. Other contributors, please continue commenting... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
