Thailand MiniDebCamp 2010 in March
Dear all, As a follow-up to Taiwan Mini-DebConf 2009 in Taipei [1], we will be arranging a mini-DebCamp in Khon Kaen, Thailand, during March 13-19, 2010 [2]. [1] http://wiki.debian.org/DebianTaiwan/MiniDebConf2009 [2] http://wiki.debian.org/DebianThailand/MiniDebCamp2010 The agenda is under discussion. So far, the wish list includes: * BSP Marathon for Squeeze * Discussing internationalization issues * Introducing how to join Debian to local prospectors * Debian Edu * Debian mirror setup (effective way) * How network administrators live together with Debian * DebConf in Thailand; yes/no, when, where, planning, etc. * Keysigning * Discussion of Linux and Debian use in Thailand * LinuxTLE/LinuxSIS (Thai local distros) and their relationship to Debian/Ubuntu; what can/should we merge * Eating/cooking Thai food! If you like to join, please be invited to add your name and your wished agenda to the Wiki page [2], and probably join debconf-thailand mailing list [3] to get updated and discuss. [3] http://lists.madduck.net/mailman/listinfo/debconf-thailand We are looking forward to welcoming you. Let's come and enjoy working together, as well as encourage Debian activities in Thailand and in the nearby countries. Any suggestions are welcome, as this will be the first Debian event in Thailand. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ signature.asc Description: Digital signature
Bug#566111: ITP: zkclient -- java helper library for zookeeper clients
Package: wnpp Severity: wishlist Owner: Thomas Koch * Package name: zkclient Version : 0.1.0 Upstream Author : Stefan Groschupf , Peter Voss , Johannes Zillmann * URL : http://github.com/sgroschupf/zkclient * License : Apache 2.0 Programming Lang: Java Description : java helper library for zookeeper clients Abstracts the interaction with zookeeper and allows permanent (not just one time) watches on nodes in ZooKeeper -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage
Norbert Preining writes: > Hi Goswin, > > thanks for the very interesing and profound answer. > > On Mi, 20 Jan 2010, Goswin von Brederlow wrote: >> The other thing is how to manage the source in version control now. >> Do you commit the source with all patches applied? Or all patches >> unapplied? Who makes sure that all patches are applied/unapplied and >> refresh for a commit? That was more retorical. For everyone to think about and decide for themself. :) It totaly depends on the kind of workflow you have. > I have all patches unapplied, and I want it that way. If I develop > and change something I do quilt push/pop/refresh myself. This can > NOT be automated anyway, becasue it needs often human intervention. > So I *really* like quilt for that, and I have converted long time > ago all packages from dpatch to quilt for that. > > Again, I keep all the source unpatches. Actually I don't see > *why* they should be patched in the repository. I prefer having > several quilt patches for different thigns, and an automatic system cannot > know which change in which file belongs to which patch. Unfortunately (for you) the 3.0 (quilt) format switched to have the patches applied by default. dpkg-source -x will apply them. clean will not unapply them. That works better for people that use feature branches and merge them into master to get a source with everything applied. Have you tried adding this to the clean target? QUILT_PATCHES=debian/patches quilt pop -a MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is tabular data in binary format acceptable for Debian ?
Le Wed, Jan 20, 2010 at 10:43:37AM -0800, Don Armstrong a écrit : > > It depends on the precise nature of the data. It is quite easy to > produce Rdata files which are not the prefered form for modification. > For example, the following temp.Rdata would not be the prefered form > for modification: > > temp <- data.frame(read.table(file="data_file_not_distributed.txt")) > model.lm <- lm(foo~bar,temp) > save(model.lm,file="temp.Rdata") It is technically true, but I think that we are drifting. To my knowledge, there is no such .Rdata file in R packages. The current subject of discussion is tables in binary format. On the other hand, I am sure that in Debian there are files that are similar in spirit to your example. For instance, I have seen PDF documents with PNG plots for which we have not the necessary material to regenerate or modify them, for instance Excel or OpenOffice spreadsheets, Gnuplot or R code, and source data data – which can be gigabytes big. This has been tolerated until now – and I am very happy of this. To come back to the original problem, I will consider the the .Rdata files in my packages free unless our archive administrators reject again a package that contains some, since in the case of tables, whatever Upstream uses (or not) to generate them, he is not holding up information that would give him an advantage over people willing to fork. Once again, I would like to remind how disproportionate is the time that we have to spend for this kind of issues (.Rdata files, PDF files, documenting copyrights of source files we do not use, repackaging to remove windows executables, …) in order to get free software accepted in our free distribution. It kills the fun, sometimes degrades our relations with Upstream, and I have not yet seen a user thanking us for doing this. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566125: ITP: zeromq -- Lightweight messaging library
Package: wnpp Severity: wishlist Owner: "Adrian 'Dagurashibanipal' von Bidder" -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: zeromq Version : 2.0~beta2 (right now) Upstream Author : iMartix Corp. * URL : http://www.zeromq.org/ * License : LGPL Programming Lang: C++ plus language bindings Description : Lightweight messaging library Very fast and very lightweight messaging library. Latency between hosts is measured in ms, and throughput in millions of messages per second. . Another outstanding feature is that 0MQ supports many common programming languages. . 0MQ does not deal with the content of messages but concentrates on getting those bytes around as fast as possible. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAktYaZFgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6EIEAnRVPPaCDMlrFX0WrpXcNEI9o NkHQAKClZ/jZg0JYRTjzzRK58x3guIyh4Q== =TiwO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566126: ITP: openpgm -- Implementation of the Pragmatic General Multicast protocol
Package: wnpp Severity: wishlist Owner: "Adrian 'Dagurashibanipal' von Bidder" -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Needed for zeromq library: * Package name: openpgm Version : 2.0.something Upstream Author : Have to check this * URL : http://code.google.com/p/openpgm/ * License : LGPL (dual with commercial :-( ) Programming Lang: C Description : Implementation of the Pragmatic General Multicast protocol OpenPGM is an open source implementation of the Pragmatic General Multicast (PGM) specification in RFC 3208 available at www.ietf.org. PGM is a reliable and scalable multicast protocol that enables receivers to detect loss, request retransmission of lost data, or notify an application of unrecoverable loss. PGM is a receiver-reliable protocol, which means the receiver is responsible for ensuring all data is received, absolving the sender of reception responsibility. PGM runs over a best effort datagram service, currently OpenPGM uses IP multicast but could be implemented above switched fabrics such as InfiniBand. PGM is appropriate for applications that require duplicate-free multicast data delivery from multiple sources to multiple receivers. PGM does not support acknowledged delivery, nor does it guarantee ordering of packets from multiple senders. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAktYasxgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6x8MAn0UVTQYVZWg3tQejXswScNEI XPAnAKCZIz+pEVKUh08r9W2UC4tgKVsQew== =v0SX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566155: ITP: softhsm -- a cryptographic store accessible through a PKCS #11
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: softhsm Version : 1.1.2 Upstream Author : Rickard Bellgrim, .SE (The Internet Infrastructure Foundation) * URL : http://trac.opendnssec.org/wiki/SoftHS * License : BSD Programming Lang: C Description : a cryptographic store accessible through a PKCS #11 OpenDNSSEC handles and stores its cryptographic keys via the PKCS#11 interface. This interface specifies how to communicate with cryptographic devices such as HSM:s (Hardware Security Modules) and smart cards. The purpose of these devices is, among others, to generate cryptographic keys and sign information without revealing private-key material to the outside world. They are often designed to perform well on these specific tasks compared to ordinary processes in a normal computer. . A potential problem with the use of the PKCS#11 interface is that it might limit the wide spread use of OpenDNSSEC, since a potential user might not be willing to invest in a new hardware device. To counter this effect, OpenDNSSEC is providing a software implementation of a generic cryptographic device with a PKCS#11 interface, the SoftHSM. SoftHSM is designed to meet the requirements of OpenDNSSEC, but can also work together with other cryptographic products because of the PKCS#11 interface. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktYhbgACgkQ9OZqfMIN8nNszgCfSOkrj3p6EicKIRGCLiNILCbm EVcAnRcrnnf9DAs0iTq2nRcKVkzKiII4 =a2SG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is tabular data in binary format acceptable for Debian ?
On Thu, 21 Jan 2010, Charles Plessy wrote: > It is technically true, but I think that we are drifting. To my > knowledge, there is no such .Rdata file in R packages. I haven't checked the archive exhaustively, so I don't know. It's certainly possible to generate, though. > The current subject of discussion is tables in binary format. That may be what you're discussing, but I'm talking about why it's unreasonable to expect the ftpmasters to know what a relatively specialized package's on-disk data format looks like, and in which cases it is a non-lossy transformation of the source, and in which cases it isn't. What you're discussing is entirely a non-issue, as far as I'm concerned, because a non-lossy transformation is just that. > On the other hand, I am sure that in Debian there are files that are > similar in spirit to your example. I'm certain as well, but I file bugs when I find them. > For instance, I have seen PDF documents with PNG plots for which we > have not the necessary material to regenerate or modify them, for > instance Excel or OpenOffice spreadsheets, Gnuplot or R code, and > source data data – which can be gigabytes big. In the vast majority of cases, the source is relatively small. No matter how large it is, it's always a bug[1] when we're not distributing it. That said, there are certainly specific cases where the actual source code can be prohibitively large for Debian to distribute. I wouldn't have a problem with not distributing such source, so long as it was publicly available somewhere, and Debian maintained a copy of it. [Just because it's a bug doesn't mean we have to (or even can!) fix it.] > To come back to the original problem, I will consider the the .Rdata > files in my packages free unless our archive administrators reject > again a package that contains some, since in the case of tables, > whatever Upstream uses (or not) to generate them, he is not holding > up information that would give him an advantage over people willing > to fork. In the case of epiR, that's correct. But again, I reiterate that it has to be clear on a case by case basis. Ftpmaster *should* REJECT packages when it's not clear to them whether source is being distributed (or otherwise contact the maintainer to get clarification.) > Once again, I would like to remind how disproportionate is the time > that we have to spend for this kind of issues (.Rdata files, PDF > files, documenting copyrights of source files we do not use, > repackaging to remove windows executables, …) in order to get free > software accepted in our free distribution. If we want to have a free distribution, we have to take the time to make sure it's free. When upstream has done due diligence, it's easy. When it's not, we have to. If that's not a goal we share any more, then it's time to revisit the statements in our foundation documents. > It kills the fun, sometimes degrades our relations with Upstream, > and I have not yet seen a user thanking us for doing this. Consider this email a user thanking everyone who spends time making sure their packages in main have source available. Many upstreams care more about making excellent software than they care about making a excellent free software, and that's something every maintainer of packages in Debian struggles with from time to time. Don Armstrong 1: There's some question whether its required under DFSG §2, so the bug may not be RC... but it's at least minor severity. -- When I was a kid I used to pray every night for a new bicycle. Then I realized that the Lord doesn't work that way so I stole one and asked Him to forgive me. -- Emo Philips. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Martin Koegler wrote: > I must admit, that I have not read anything about GNU maintainers, > but GNU has usually a bigger "philosophical overhead". Then I suggest you to read the appropriate documenation [1] before jumping to premature and possibly incorrect conclusions (what does the phrase "philosophical overhead" entail?). A fork is done when there is some kind of unresolvable conflict/disagreement (be it technical or not). Forking is a fundamental right, so there's nothing wrong in forking pth. But there are too many (forked) packages in Debian, and the Debian QA team would have to maintain the original pth package for some time at least, which is a burden. If there are people actively working to enhance pth, the best (for GNU, Debian, and literally everyone else) is to take over the package upstream. (OTOH, speaking generally, it is sad to see a package "reborn" under another name just because the prospective new maintainer cannot communicate successfully with the original one to negotiate the takeover. I once again urge you to write to to avoid this unpleasant scenario.) [1] The gnu-standards package in Debian (both documents available also online at http://gnu.org/prep). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [gmail] Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
> (OTOH, speaking generally, it is sad to see a package "reborn" under > another name just because the prospective new maintainer cannot > communicate successfully with the original one to negotiate the > takeover. I once again urge you to write to to > avoid this unpleasant scenario.) Don't read to much into this; pth is for sure a smaller effort in Martins' work. We just want to get over this small hurdle in order to get his really interesting stuff included (which depends on this). OK, sent a short note to maintain...@gnu.org. I'll keep the list updated about the progress. -- greetz, marc Kleeneness is next to Godelness. crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux signature.asc Description: Digital signature
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Marc Leeman wrote: > > (OTOH, speaking generally, it is sad to see a package "reborn" > > under another name just because > > Don't read to much into this; Well, as a matter of fact I don't. Probably I wouldn't have replied to the thread if pth wasn't a GNU package, but my opinion would be the same. A fork should be the last resort, when all efforts to prevent the fork have been tried and failed. The introduction of a forked package in a distro is a separate issue, but it naturally is something not to be taken lightly. > pth is for sure a smaller effort in Martins' work. We just want to > get over this small hurdle in order to get his really interesting > stuff included (which depends on this). Avoiding this "small hurdle" will result in a much bigger hurdle for every distribution, especially Debian when you take into account the number of packages and supported architectures. Every new package results in extra load on the infrastructure (which is not only machines), possible user confusion, possible and very likely further effort by QA/security/release teams, etc. > OK, sent a short note to maintain...@gnu.org. Thanks! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Thank you, Debian project, for working to make a free software operating system (was: Is tabular data in binary format acceptable for Debian ?)
Charles Plessy writes: > Once again, I would like to remind how disproportionate is the time > that we have to spend for this kind of issues (.Rdata files, PDF > files, documenting copyrights of source files we do not use, > repackaging to remove windows executables, …) in order to get free > software accepted in our free distribution. It kills the fun, > sometimes degrades our relations with Upstream, and I have not yet > seen a user thanking us for doing this. I've often expressly, and in public, thanked the specific people who put forth efforts to ensure free software in the Debian operating system. I encourage anyone else to do this too; it's a good way to increase the likelihood such work continues to be done. If you need it, consider this message yet another message of thanks for the work everyone does to make a free-software operating system, often in the face of indifference or hostility from upstream developers regarding the practice of free software. -- \ “To label any subject unsuitable for comedy is to admit | `\ defeat.” —Peter Sellers | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Work-needing packages report for Jan 22, 2010
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 619 (new: 7) Total number of packages offered up for adoption: 132 (new: 6) Total number of packages requested help for: 55 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: fdutils (#565466), orphaned 5 days ago Description: Linux floppy utilities Reverse Depends: bootcd ltp-disc-test Installations reported by Popcon: 4048 fortunes-ru (#566149), orphaned today Installations reported by Popcon: 105 kxstitch (#565753), orphaned 3 days ago Description: cross-stitch pattern creator and editor for KDE Installations reported by Popcon: 93 pam-passwdqc (#565649), orphaned 4 days ago Description: replacement for the pam_cracklib module Installations reported by Popcon: 338 polipo (#566150), orphaned today Description: a small, caching web proxy Installations reported by Popcon: 296 python-contract (#565754), orphaned 3 days ago Description: Programming by contract for python Installations reported by Popcon: 64 webcam-server (#565413), orphaned 6 days ago Description: a tool to share webcam streaming in www-browser Installations reported by Popcon: 345 612 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: duma (#565925), offered 2 days ago Description: library to detect buffer overruns and under-runs in C and C++ programs Installations reported by Popcon: 74 google-gadgets (#566194), offered today Description: Common files for QT and GTK+ versions of google-gadgets Reverse Depends: google-gadgets-common google-gadgets-gst google-gadgets-gtk google-gadgets-qt google-gadgets-xul libggadget-1.0-dev libggadget-gtk-1.0-0 libggadget-gtk-1.0-0a libggadget-gtk-1.0-dev libggadget-qt-1.0-0 (3 more omitted) Installations reported by Popcon: 4061 ipsec-tools (#565362), offered 6 days ago Description: IPsec tools for Linux Reverse Depends: openswan racoon strongswan-ikev1 strongswan-ikev2 Installations reported by Popcon: 1496 openslp-dfsg (#565361), offered 6 days ago Description: OpenSLP documentation Reverse Depends: cups libslp-dev nis slapd slptool Installations reported by Popcon: 52115 pam-passwdqc (#565649), offered 4 days ago Description: replacement for the pam_cracklib module Installations reported by Popcon: 338 ssed (#565360), offered 6 days ago Description: The super sed stream editor Installations reported by Popcon: 86 126 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-cross (#540341), requested 167 days ago Description: retrieve, build and install libraries for cross-compiling Reverse Depends: apt-cross emdebian-buildsupport emdebian-qa emdebian-rootfs emdebian-tools libemdebian-tools-perl Installations reported by Popcon: 315 ara (#450876), requested 802 days ago Description: utility for searching the Debian package database Installations reported by Popcon: 116 asymptote (#517342), requested 328 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 1167 athcool (#278442), requested 1913 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 166 boinc (#511243), requested 378 days ago Description: BOINC distributed computing Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg Installations reported by Popcon: 1643 cvs (#354176), requested 1428 days ago Description: Concurrent Versions System Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsservice (10 more omitted) Installations reported by Popcon: 25187 dctrl-tools (#448284), requested 817 days ago Description: Command-line tools to process Debian package information Reverse Depends: aptfs debian-goodies debtree dlocate haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo mlmmj simple-cdd (1 more omitted) Installations reported by Popcon: 13339 dietlibc (#544060), requested 146 days ago Description: diet libc - a libc o
Re: Thank you, Debian project, for working to make a free software operating system (was: Is tabular data in binary format acceptable for Debian ?)
On Fri, Jan 22, 2010 at 1:11 AM, Ben Finney wrote: > I've often expressly, and in public, thanked the specific people who put > forth efforts to ensure free software in the Debian operating system. I > encourage anyone else to do this too; it's a good way to increase the > likelihood such work continues to be done. > > If you need it, consider this message yet another message of thanks for > the work everyone does to make a free-software operating system, often > in the face of indifference or hostility from upstream developers > regarding the practice of free software. +1 Debian FTW! -Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is tabular data in binary format acceptable for Debian ?
Le Thu, Jan 21, 2010 at 11:10:25AM -0800, Don Armstrong a écrit : > > That may be what you're discussing, but I'm talking about why it's > unreasonable to expect the ftpmasters to know what a relatively > specialized package's on-disk data format looks like, and in which > cases it is a non-lossy transformation of the source, and in which > cases it isn't. > What you're discussing is entirely a non-issue, as far as I'm > concerned, because a non-lossy transformation is just that. This is also what I rant about. They do not know and asked, that is good. I spent the time to provide detailed answers and they are ignored, that's bad. Before the rejection there was no issue about the .Rdata files, and now they are in the limbo because of the archive team's silence, since they are ruling what is acceptable and what is not. As a maintainer of a package that contains such files, this disturbs my work, because if there is an issue with their fitness for the release, I prefer to know it in December rather than in February, one month before the freeze. > > On the other hand, I am sure that in Debian there are files that are > > similar in spirit to your example. > > I'm certain as well, but I file bugs when I find them. I am not filing bugs for all the defective packages I found, for instance: - Works distributed under the Artistic-2.0 license, but the license is not included in debian/copyright. - Works distributed under the Apache-2.0 license, but the NOTICE file is not redistributed in the binary packages. - Packages that do not detail *all* copyright notices of the conventient copy of the zlib that the upstream source contains but that is not used in Debian. (As an experimentation I filed a bug on zlib itself. The issue was solved by repackaging the upstream sources. That is an interesting approach, but I am still strongly prefering to ship a bitwise identical original upstream source tarball unless impossible.) - Source packages that contain RSA's md5.h header, but its license is not copied in debian/copyright. I chose the above examples to show again that it is not possible to take acceptance or rejection of packages to decide what is acceptable for Debian or not. All the packages with the above defects went through the NEW queue. So if we all agree that this tables in .Rdata format is a non-issue, why the archive administrators – who are the ones who raised the question – are not confirming that they agree with this, so that we can move on more important subjects? -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What criteria does ftpmaster use for the ‘cop yright’ file of a package?
Ben Finney writes: [summary: package in NEW was rejected, then accepted; the only difference was going from a ‘copyright’ file containing no duplication of original-source copyright notices, to one containing copyright notices that don't match the original source] > It's not the file I have in my packaging VCS, so by default it will be > overridden by any future upload; that's probably a matter for [the > package sponsor] and me to sort out between us. > > It also doesn't match the copyright notices as found in the original > source; those are rather more complex, and are different across > different files. But the *license* terms are correct as stated in the > file, as they always have been, since they are unchanged from the > original upload of the package. > > In other words, the only difference between a package that was > rejected and a package that was accepted is the addition to the > ‘copyright’ file of some copyright notices that don't match the > original source. > > So I don't understand the reasoning for rejecting a package that has > the copyright notices intact in the source, but not duplicated into > the ‘copyright’ file; and then accepting a package that is identical > except for additional copyright notices in ‘copyright’ that don't > match the original source. > > This isn't the first time I've been confounded by ftpmaster policy on > this file. Exactly what is it that needs to be in the copyright file > for ftpmaster to accept it, and what is the reasoning for that beyond > what is in Debian Policy? A little time after DebConf excitement has calmed down, I would still like to see answers, in the public record, from the ftpmasters on this issue. I'm well aware of the edicts given, but they don't answer the question of what criteria are being used, so we can have a chance of knowing beforehand what is acceptable and what is not. -- \ “Software patents provide one more means of controlling access | `\ to information. They are the tool of choice for the internet | _o__) highwayman.” —Anthony Taylor | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is tabular data in binary format acceptable for Debian ?
On Fri, Jan 22, 2010 at 10:07:29AM +0900, Charles Plessy wrote: > This is also what I rant about. They do not know and asked, that is good. I > spent the time to provide detailed answers and they are ignored, that's bad. > Before the rejection there was no issue about the .Rdata files, and now they > are in the limbo because of the archive team's silence, since they are > ruling what is acceptable and what is not. This seems to suggest that the ftp team was in the process of evaluating whether tabular data formats *can* be acceptable. I don't see that this was the case here at all; I only see that, as of Joerg's last question to the bug, it was not clear to him that the specific data files in this case met the criteria that were already being used. I draw the distinction here because reading your message made me worry that the ftp team were moving the line for archive acceptance without discussion, when reading the bug log shows that they're simply trying to determine on which side of the existing line these files fall. I would suggest that you add documentation to the source package in debian/copyright explaining either why these files constitute the "preferred form for modification" under the GPL, or why the files are not covered by the GPL (since the reject message seems to imply that GPLv2 was the only license you listed in debian/copyright), and reupload to the NEW queue once this and the other listed reject reasons are resolved. (Omitting, please, the digression that these files "are usually not modified", since this is irrelevant to the DFSG and to the GPL.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: What criteria does ftpmaster use for the ‘copyright’ file of a package?
On Fri, Jan 22, 2010 at 12:39:35PM +1100, Ben Finney wrote: > [summary: package in NEW was rejected, then accepted; the only > difference was going from a ‘copyright’ file containing no duplication > of original-source copyright notices, to one containing copyright > notices that don't match the original source] > > It's not the file I have in my packaging VCS, so by default it will be > > overridden by any future upload; that's probably a matter for [the > > package sponsor] and me to sort out between us. > > It also doesn't match the copyright notices as found in the original > > source; those are rather more complex, and are different across > > different files. But the *license* terms are correct as stated in the > > file, as they always have been, since they are unchanged from the > > original upload of the package. > > In other words, the only difference between a package that was > > rejected and a package that was accepted is the addition to the > > ‘copyright’ file of some copyright notices that don't match the > > original source. > > So I don't understand the reasoning for rejecting a package that has > > the copyright notices intact in the source, but not duplicated into > > the ‘copyright’ file; and then accepting a package that is identical > > except for additional copyright notices in ‘copyright’ that don't > > match the original source. > > This isn't the first time I've been confounded by ftpmaster policy on > > this file. Exactly what is it that needs to be in the copyright file > > for ftpmaster to accept it, and what is the reasoning for that beyond > > what is in Debian Policy? > A little time after DebConf excitement has calmed down, I would still > like to see answers, in the public record, from the ftpmasters on this > issue. > I'm well aware of the edicts given, but they don't answer the question > of what criteria are being used, so we can have a chance of knowing > beforehand what is acceptable and what is not. I am not an ftp master, but I think this follows from a straightforward set of principles: - Policy requires reproduction of the copyright notices for a work in debian/copyright. - It is not the responsibility of the Debian maintainer to correct incorrect copyright notices in the upstream source, but it is the responsibility of the maintainer to ensure that the copyright notices in debian/copyright are correct. - It is not the responsibility of the ftp team to audit the copyright statements in debian/copyright. - Since the copyright notices in debian/copyright may therefore not match the notices in the source for legitimate reasons, and nothing short of a full copyright audit will reconcile them, the sensible thing for the ftp team to do is take debian/copyright at face value. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: What criteria does ftpmaster use for the ‘cop yright’ file of a package?
Steve Langasek writes: > On Fri, Jan 22, 2010 at 12:39:35PM +1100, Ben Finney wrote: > > A little time after DebConf excitement has calmed down, I would > > still like to see answers, in the public record, from the ftpmasters > > on this issue. > > I am not an ftp master, but I think this follows from a > straightforward set of principles: Thanks for your response. (I am still very interested to get the ftpmasters to join this discussion with their positions.) > - Policy requires reproduction of the copyright notices for a work > in debian/copyright. This point in particular I don't think is clear. It has been argued several times in the past that it is the copyright *license* that is important, and needs to be reproduced in the package ‘copyright’ file. Especially in combination with your later points (that the copyright notices can't be “corrected”, which I take to imply that aggregation and re-phrasing of the notices is also verboten), there seems to be little point reproducing the verbatim copyright *notices*, especially since they're all in the source regardless. Either that, or there *is* benefit and justification for aggregating and re-phrasing copyright notices, not just verbatim duplication, when putting the extra copies in the package ‘copyright’ file. -- \ 德不孤、必有鄰。 (The virtuous are not abandoned, they | `\shall surely have neighbours.) | _o__) —孔夫子 Confucius, 551 BCE – 479 BCE | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What criteria does ftpmaster use for the ‘cop yright’ file of a package?
Ben Finney writes: > Steve Langasek writes: > > > On Fri, Jan 22, 2010 at 12:39:35PM +1100, Ben Finney wrote: > > > A little time after DebConf excitement has calmed down, I would > > > still like to see answers, in the public record, from the ftpmasters > > > on this issue. > > > > I am not an ftp master, but I think this follows from a > > straightforward set of principles: > > Thanks for your response. (I am still very interested to get the > ftpmasters to join this discussion with their positions.) > > > - Policy requires reproduction of the copyright notices for a work > > in debian/copyright. > > This point in particular I don't think is clear. It has been argued > several times in the past that it is the copyright *license* that is > important, and needs to be reproduced in the package ‘copyright’ file. Lest it appear that I didn't respond to Steve's point, I'll speak about the wording in current Debian policy: 12.5. Copyright information --- Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file `/usr/share/doc//copyright'. This file must neither be compressed nor be a symbolic link. In addition, the copyright file must say where the upstream sources (if any) were obtained. It should name the original authors […] So, the “copyright and distribution license” is required in the ‘copyright’ file; we also require “where the upstream sources (if any) were required”. Nothing about duplicating the copyright notices. Now, I understand that some people read “copyright and distribution license” as two separate things; but “a verbatim copy of its copyright” makes no sense, since copyright isn't a text that can be duplicated. A package doesn't have “a copyright”, except in the sense of a right that is held by a person. That's not a text that can be copied verbatim. The only sensible parsing of that wording, to my understanding, is that the policy requires a single thing: the package's license of copyright and distribution. So I see no policy justification for the requirement of duplicating copyright notices. -- \ “When I get new information, I change my position. What, sir, | `\ do you do with new information?” —John Maynard Keynes | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What criteria does ftpmaster use for the ‘copyright’ file of a package?
On Fri, Jan 22, 2010 at 02:48:39PM +1100, Ben Finney wrote: > > - Policy requires reproduction of the copyright notices for a work > > in debian/copyright. > This point in particular I don't think is clear. It has been argued > several times in the past that it is the copyright *license* that is > important, and needs to be reproduced in the package ‘copyright’ file. It has been argued *by you*. I have refuted this. > Especially in combination with your later points (that the copyright > notices can't be “corrected”, which I take to imply that aggregation and > re-phrasing of the notices is also verboten) This is not what I said. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage
On 2010年01月20日 23:39, Goswin von Brederlow wrote: Norbert Preining writes: On Mo, 28 Dez 2009, Raphael Hertzog wrote: Mind that git-buildpackage with normal 1.0 source format does NOT pollute the git repository, so my expectation is that the 3.0 format does the same, but alas, it doesn't. Well, if you have the usual quilt rules, you working copy is also modified until the next debian/rules clean. Here the clean doesn't unapply the I disagree: $ ls ~/.gbp.conf ls: cannot access /home/norbert/.gbp.conf: No such file or directory $ git status # On branch master nothing to commit (working directory clean) $ git-buildpackage -us -uc -rfakeroot -S ... dpkg-buildpackage: source only, diff-only upload (original source NOT included) Now running lintian... Finished running lintian. $ git status # On branch master nothing to commit (working directory clean) $ So please tell me *what* has changed? Doing the same with source format 3.0 git status reports hundreds of differences. So please do not spread things that are not correct! He did say that with 3.0 (quilt) format the "clean" state is with patches applied, like you get after dpkg-source -x. That part is different to 1.0 format where "clean" would have patches unapplied. So when you go from 1.0 to 3.0 you will get a ton of files changed after the first build + clean because now patches are applied. MfG Goswin why not apply the patches when build automatically, and make clean to unapply the patches? when I build the package, I must check quilt applied and quilt unapplied, It's very trouble. thanks best regards. ta...@lemote.com -- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBEpvrkcRBADSiXvtm3B3HO247hmhsRfKQ56yqTxAe1Fg/SiLRkDGR3Cmla4M I9P1C1WZA59OkPYMTQE45i4zKDwoaCsG6qUYV6gxBjL5czsYn7qPrJxRH7LuXyMy egxSWyIsPqlPYzSBzE/eLzDHs1q7ucpLx6HdqOzZ2ajPCpT2cG+cBWePLwCgkUfx cbkm6h2Tq1AAXIAwmueGDfcEAKjAACIWihubPSUX25/6ZWf528z736PEnCLcB1UT IE/tsYNZEyjVelSXJ1q0cUNjQalK6VYzrkv02daUtPby9Svvk3nSFNNrfpYrhOxT KXlE/PBjouQ1vxjoTFbSE1cWpUIbfW37BZ9Bjm1ERTfe8MMLlRGk2khdsyx6x359 JW4QA/9+7KF9xcg0ITJ5d48FS1b9h6NDTdm/ttjBLrQj+mHD0h8Y1xt6fka6/A1P BWXiJ8cmwSlW112Gs0caG44KISit8lDlTsDlXNnq9wrIZYgdyqRe2uowJZPlH6/N 4nYiVP3+3LwbXWD+Bpyv9vDcgPtEWBk27q8dx/V8q9mnohXqzLQbdGFuZ2tlIDxt dW11dG91dkBnbWFpbC5jb20+iGAEExECACAFAkpvrkcCGwMGCwkIBwMCBBUCCAME FgIDAQIeAQIXgAAKCRAsFraiOAWQA2RRAKCGK/cORhnCMI7bT34n04tTzG1wPQCf dw2L86uESYwGW4PUHJc0iv2coe25Ag0ESm+uRxAIAN+Se0IwVo0Hr5khx3lGIeYL j3ycZQMT3q+LnNtrgUNgmRLBziLwNu69KHXBRXXML23C9PqqGIQodtl07KAvttC3 G/CUdARCxtqVjT66HxM5875h+LX/XaytsCaqXHTte9bIakEYjRIJDYTY6Gza8LjY n/qz3TKDEmX7/Apqz4KCjcdyo0DwMptet4k71V0wulnTJwVwqfVAUsdtj/xL8MqD yuvuLNWN+AEXqOEs+Ilv8PN/TgQbJXxY+g7eD277jsxJ8njJuUzusKxHCiSx49Yh pSZC/r1mKICYJZszwrNU6CtOBXYK0Yz70O1/ZTcSOzn9EDtM5u/IKECZJWSUJ3MA AwUIAK1QWT5V1RbAhfoENapgF6T/F0nUdf9TjwkOgleo4yfqXymGXVWmp86JBn7J wTDS/GdzO77uiXZMHTCqhbmNYogAapHNeE++RAReiVT/iZjLvIbqOBFcGBqie5Ar SZTZfS20Mpzf2joLQfcWxQ5L3/ZtpUkiUrfVTdVldwwMob1pGknnrZNF4rpDE9Nk /kj+thaWKlvVrMj6e8nULbbYn1rT6iEqIS7Wfspn0DYe9YJLffFgIxybaRfPYd2l rsH6kY15F736mjhdWqgOfWgRgUKCh+VVU/5S2OBKihPdpXjn4CI+kVzmrkvQfftB WxBVgQuMMS44L/u8Te93EOOnybmISQQYEQIACQUCSm+uRwIbDAAKCRAsFraiOAWQ A8H6AJ9hlHl1flzNKd98UyqMBXvyx87/vwCfdrIk4TYsfYDDbrpZ5fLnsMetaXE= =koJk -END PGP PUBLIC KEY BLOCK- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
