Re: Let's write a system admin friendly mail server packaging system
Thomas Goirand wrote: > Mario 'BitKoenig' Holbe wrote: >> So far this is independent of third packages which is IMHO fine and >> desirable. So far, this could be solved by a postfix-conf.d-snippet >> shipped with the amavis package. > Quite not. You also need to configure the incoming and outgoing ports of > amavis the correct way. Which of course will also be done by the amavis package itself. Still, no dependency on third packages so far. >> * postfix ships to amavis >> * amavis ships back to postfix >> * postfix ships to dkimproxy >> * dkimproxy ships back to postfix > No, it's not any cleaner, and it's slower. As I wrote previously, we Cleaner from a dependency-perspective. Why isn't it? This way you are able to configure the whole integration within one package (i.e. amavis ships the amavis-postfix integration, dkimproxy ships the dkimproxy-postfix integration, etc. pp), you can just avoid any complex chaining-magic. And slower? What are we talking about? Whole two percent? > Are you trying to say that we shall ship a not performing configuration > by default, because big ISP are capable of reconfiguring? If you are, I'm trying to say that I would prefer a straight, clean dependency- minimizing approach over one that does and/or requires complex magic. And I'm aware that clean approaches are usually somewhat less performant than optimized setups, which, in turn, tend to be more complex. And I think that a clean and simple approach would help more users than one that tries to squeeze the last cpu cycles out of your system for the price of being hard to understand. Don't get me wrong: I totally agree with you that what we have now is neither the one nor the other. And yes, I think that somebody who tries to optimize a system for highest performance will write his own configurations anyways. Hey, if you really like to squeeze cpu cycles the first thing you do is to build architecture-specific binaries. Writing some optimized config- files doesn't matter then anymore. > I think we shall try to release the best distribution as we can, with > correct, performing values by default, and even, if possible, have a > default configuration that you never even need to edit, because it's > just right by default. We should at least have this goal in mind, "those goals" - you named three: correctness, performance and useful defaults. Choose two of them :) There are way more btw. - not only for users but also for maintainers, etc. > Maybe I'm being too idealistic here. What's your opinion? I don't think it's bad to be idealistic. We just have different ideals probably :) Well, most likely we just weigh conflicting goals different. regards Mario -- Um mit einem Mann gluecklich zu werden, muss man ihn sehr gut verstehen und ihn ein bisschen lieben. Um mit einer Frau gluecklich zu werden, muss man sie sehr lieben und darf erst gar nicht versuchen, sie zu verstehen. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhvurj0.m0q.mario.ho...@darkside.dyn.samba-tng.org
Re: test if primary group, with only implicit membership of the user?
On 28/05/2010 00:00, C. Gatzemeier wrote: 2) A special case is true: The group is set as the main group of the user (in /etc/passwd) while the user is NOT added to his group in /etc/groups. May pam_umask test this, for umask relaxation? Just IMHO, this is *exactly* what pam_umask should be doing, rather than comparing if uid==gid. The only valid test for UPG is if the user's primary group is *truly private*. Comparing the numbers doesn't get you that, it's just checking some user creation policy requirement that may or not be secure. Calling getgrgid/getgrnam and checking that the user list is empty is *ensuring* that it's private, at least at the point in time we check (we can't predict the future). This check would protect against adding other users to UPGs, at least from the POV of not relaxing the umask (it's still a bad idea). Regards, Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bff72a1.7000...@codelibre.net
Re: Looking for maintainers of Spacewalk packages
Am 28. Mai 2010 06:08:43 UTC+2 schrieb Miroslav Suchý : > BTW: our plan for summer, is to develop plugin for apt-get which allows you > to download packages from Spacewalk server directly using apt-get. That is > last missing piece for declaring support for Debian as complete. Feel free to join de...@lists.d.o for discussions/questions about APT. :) http://lists.debian.org/deity/ Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktil7jbbjexjzheqy2hkxduvv3m5glnevcb6ru...@mail.gmail.com
adduser or useradd (package passwd)?
Am Wed, 26 May 2010 08:40:26 +0100 schrieb Stephen Gran: > first useful argument I've heard for changing adduser's > behavior. Interoperability with other software is a useful goal, Would the change have to go into adduser or useradd (part of base-passwd)? 9.2.1: "Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100528112324.5c5a5f83c.gatzeme...@tu-bs.de@tu-bs.de
Re: test if primary group, with only implicit membership of the user?
Am Fri, 28 May 2010 08:37:05 +0100 schrieb Roger Leigh: > Calling getgrgid/getgrnam and > checking that the user list is empty is *ensuring* that it's private, > at least at the point in time we check (we can't predict the future). > > This check would protect against adding other users to UPGs, Yes, if we'd check for an empty user list, that would break the "sub-users" feature. Say if "me" wants to run iceweasel under the user "me-iceweasel", you can simply "adduser me me-iceweasel" without breaking the UPGs scheme (in contrary, benefitting from it when working with sub-user files, because me-iceweasel can still get umask 002) while not having to set a fixed relaxed umask. If there are other users in the users' private group, IMHO we just can and should assume they are there intentionally. So the test may only look for the fact that the user is _itself_ not an explicit member of his primary group. That would not be the case if the group was created as a regular group for collaboration (like the "users" group, or any other) and users are added to it. > at least > from the POV of not relaxing the umask (it's still a bad idea). I'm not sure yet, if I do properly understand the point when/why relaxing conditionally is a bad idea. To me, setting *fixed* umasks with group permissions equaling user permissions seems worse, especially because not all users of a system need to be set up with UPGs. I think for an inappropriate relaxations to occur, the user/group info would have to come from some external system. If we test username==groupname, and GUID==UID (it seems to be a standard among UPG systems to allocate cleanly alligned group IDs) and if we can add to this the test if the user is not an explicit member of his primary group (for all db backends?) that looks like a pretty firm while flexible test to me. It's only unfortunate that debian's "useradd", that it does not allays allign IDs, hasn't been seen as such earlier, but it is on its way to be solved. Kind regards, Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100528113025.7661e2cac.gatzeme...@tu-bs.de@tu-bs.de
Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol
retitle 529974 ITP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol owner 529974 ! stop I'm going to package rtmpdump next week. On Fr, Mai 22, 2009 at 16:33:44 (CEST), Sam Morris wrote: > * Package name: rtmpdump > * URL : [hidden obsolete url] > * License : GPL > Programming Lang: C++ > Description : download media streamed with the RTMP/RTMPE protocol > > A small dumper for media content streamed over the RTMP/RTMPE protocol. > Supplying an rtmp url will result in a dumped flv file, which can be > played/transcoded using ffmpeg/mplayer, etc. A download script for BBC's > iPlayer streams is included. As Howard already mentioned, the mplayer project hosting kindly offers hosting for rtmpdump these days, so I'll package that. Not only that, but that package also provides librtmp, which ffmpeg 0.6 can use. For this reason I'm going to take this package under the pkg-multimedia umbrella. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-devel
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Ludovic Brenta writes: > Stephen Leake wrote: >> Ludovic Brenta writes: >>> The reason for all this is that when a package libX2-dev Conflicts: > with >>> and Replaces: a package libX1-dev, aptitude does not remove libX1-dev >>> and install libX2-dev; instead, it marks libX1-dev as broken and leaves >>> libX2-dev uninstalled. >> >> This seems like a clear bug in aptitude. >> >> Debian policy 7.6.2 says that Replaces: with Conflicts: should cause the >> old package to be removed, and the new package to be installed, so why >> doesn't this work? > > That's because there is no conflict until the user asks for installation > of the new package; 7.6.2 says the old package must go only in case of a > conflict. So, I would not characterize the behavior of aptitude as a > bug, merely an annoyance. Ok. But it seems the best way to reduce the annoyance is to improve aptitude (or dpkg). Add an option that says "treat Replaces as the correct upgrade path". Or add a new control field Upgrades for that purpose. Currently, a package is upgraded only if its name does not change. Package names can change, either because of aliversions, or for other reasons. So an Upgrades control field to identify package name changes would be appropriate. Or maybe it should be a Renames control field. That could also allow uploading without going thru the new packages process. However, my reading of Debian policy gave me the impression that Replaces was supposed to be used for that purpose. Since the tools currently do not fully support that use, I think they are broken. Another option would be to teach dpkg to treat the aliversion in the same way it currently treats other version numbers; that is, not as part of the name, so it would know that libopentoken2-dev is the proper upgrade from libopentoken1-dev. We might have to add some separator syntax for the aliversion for that to work. -- -- Stephe -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/826328tf4y@stephe-leake.org
Re: test if primary group, with only implicit membership of the user?
On Fri, May 28, 2010 at 11:30:25AM +0200, C. Gatzemeier wrote: > I'm not sure yet, if I do properly understand the point when/why > relaxing conditionally is a bad idea. To me, setting *fixed* umasks with > group permissions equaling user permissions seems worse, > especially because not all users of a system need to be set up with > UPGs. Why would you create such a mixed system? I don't see a usecase for that. If the system is UPG it should be UPG for everyone. You can always add users to additional groups and use setgid directories. There is really no need to make some users non-UPG. So I don't think this needs to be supported out of the box. > I think for an inappropriate relaxations to occur, the user/group info > would have to come from some external system. And that is exactly the problem. If users are managed locally, you don't need any fancy auto-detection, because you know the system is UPG. The default for USERGROUPS is yes in /etc/adduser.conf. If the admin changes this, you can also expect him to change the default umask. But if users are managed externally, then nothing is guaranteed. All the assumptions about name or id equalities are nothing more than that: assumption. Therefore this autodetection will fail for all systems that don't conform to pam-umask's idea about user and group set-up. And in those cases where it fails, I'd expect it to fail only for specific cases that might go unnoticed for a long time and might be hard to analyse. So anyone with some conscience for security will immediately disable this source of indeterminism and set the umask to a fixed value. I know I will. So one thing is the change of the default value. I'd say keep the default at the most secure value. But the world won't end if it is changed. You just shouldn't forget to change it if you change USERGROUPS to no or use external user management. But the other thing is this auto detection that is only based on wishful thinking and just adds complexity and indeterminism. I'd really rather Debian wouldn't do this. Cheers, harry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100528125026.ga4...@sbs288.lan
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Stephen Leake wrote: Currently, a package is upgraded only if its name does not change. Good point. Is the hack then to introduce a new "lib-dev" package which is empty but depends on "lib-dev"? Lots of empty packages, just to get the upgrade to work, but if we have a plan for avoiding this in the future, then I think it is an acceptable (but far from perfect) solution to the immediate problem. Greetings, Jacob -- "Good enough for physics" -- Ridcully -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1005281432250.3...@hugsarin.sparre-andersen.dk
Re: Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol
On 05/28/2010 01:25 AM, Reinhard Tartler wrote: retitle 529974 ITP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol owner 529974 ! stop I'm going to package rtmpdump next week. On Fr, Mai 22, 2009 at 16:33:44 (CEST), Sam Morris wrote: * Package name: rtmpdump * URL : [hidden obsolete url] * License : GPL Programming Lang: C++ Description : download media streamed with the RTMP/RTMPE protocol A small dumper for media content streamed over the RTMP/RTMPE protocol. How will this be different from the rtmpdump (currently at v2.2d-0.0) in d-m.o? Some rights-restricted libraries stripped out? -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bffcc7b.7050...@cox.net
Re: Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol
On Fr, Mai 28, 2010 at 16:00:27 (CEST), Ron Johnson wrote: > On 05/28/2010 01:25 AM, Reinhard Tartler wrote: >> I'm going to package rtmpdump next week. >> >> On Fr, Mai 22, 2009 at 16:33:44 (CEST), Sam Morris wrote: >> >>> * Package name: rtmpdump >>> * URL : [hidden obsolete url] >>> * License : GPL >>>Programming Lang: C++ >>>Description : download media streamed with the RTMP/RTMPE protocol >>> >>> A small dumper for media content streamed over the RTMP/RTMPE protocol. > > How will this be different from the rtmpdump (currently at v2.2d-0.0) in > d-m.o? I didn't look inside the source package nor do I intend to do so. I note that it doesn't provide an librtmp-dev package, so it's useless for me. > Some rights-restricted libraries stripped out? I didn't spot any restricted libraries included. What are you referring to? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3wgkszn@faui44a.informatik.uni-erlangen.de
Re: lilo removal in squeeze (or, "please test grub2")
On Tue, 25 May 2010 13:12:27 -0400 (EDT), Stephen Powell wrote: > Boyd Stephen Smith Jr. wrote: >> No software is entirely without cost ... >> volunteers work on whatever they like ... >> your specific requirements may differ from their goals ... >> volunteers are rarely concerned with "market share" ... > > All excellent points, Boyd. Fortunately in this case, extlinux appears > to be a viable solution. I'll soon know ... Unfortunately, logical backups of a Linux machine using the extlinux boot loader do not work with our backup/restore software. The master boot record and partition boot sector are restored correctly, but /boot/extlinux/extlinux.sys will probably not be restored to the exact same sectors from which it was backed up, and the restore software has no special logic to remedy that situation. Therefore, after restore, the machine will not boot. It *does* recognize lilo and has special logic to patch lilo after the restore so that the machine will boot. The problem can be circumvented by taking an image backup instead of a logical backup, but that gets into special backup requirements. Until we get newer backup software I must either use lilo or ask for special backup procedures for my Linux servers. I choose the former. Logical (file by file) backups have many advantages, one of which is to avoid giving the Windows advocates an excuse to oppose further deployment of Linux servers. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1739612780.129666.1275057918173.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, "please test grub2")
Le vendredi 28 mai 2010 à 10:45 -0400, Stephen Powell a écrit : > Unfortunately, logical backups of a Linux machine using the extlinux > boot loader do not work with our backup/restore software. The master boot > record and partition boot sector are restored correctly, but > /boot/extlinux/extlinux.sys will probably not be restored to the exact > same sectors from which it was backed up, and the restore software has no > special logic to remedy that situation. Therefore, after restore, the > machine will not boot. It *does* recognize lilo and has special logic > to patch lilo after the restore so that the machine will boot. We have understood that your backup software is broken. It’s not the only one. There’s nothing we can do to fix broken, proprietary backup software. If you want to become the new upstream for lilo because you need to cope with broken backup software, please go ahead; I’m sure the effort will be welcome. If not, I think you have made your point by now. As a personal advice, I would recommend you to stop bothering with that broken backup software, it doesn’t seem good for your health. Set up a CIFS share on a backed-up Windows server, copy your data there using one of the numerous solutions in Debian, and get done with it. Or just state that you can’t backup modern Linux servers with it, and let them struggle with Windows servers if they really decide to use this instead. Cheers, -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1275063080.4783.14.ca...@meh
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/28 Stephen Leake : > Ludovic Brenta writes: > >> Stephen Leake wrote: >>> Ludovic Brenta writes: The reason for all this is that when a package libX2-dev Conflicts: >> with and Replaces: a package libX1-dev, aptitude does not remove libX1-dev and install libX2-dev; instead, it marks libX1-dev as broken and leaves libX2-dev uninstalled. >>> >>> This seems like a clear bug in aptitude. This seems like a bug in your understanding, not in apt(itude). The name libX1-dev suggests that it can be co-installed with libX2-dev and co as otherwise the version number wouldn't make much sense (yeah i know, in a few other cases… i said not much) - automatic updates in which libX1-dev is killed for good by libX2-dev is absolutely not what i would expect as packages will (build-)depend on libX1-dev which obviously can not be satisfied by libX2-dev -- if it could it would be called libX1-dev also or even libX-dev and only the real library is called libX2 … 2010/5/28 Stephen Leake : > But it seems the best way to reduce the annoyance is to improve aptitude > (or dpkg). Add an option that says "treat Replaces as the correct > upgrade path". Or add a new control field Upgrades for that purpose. Replaces form the correct upgrade path? I really thing Depends form the upgrade path - and all the negative ones just make it more complicated. ;) (or more serious: give additional hints) Negative Dependencies have a serious problem: A package manager can choose to retreat from upgrading a package because it would e.g. break to much - and that is in your interest! But do not only shoot into the dark, each manager has debugoptions to show you why it does certain things. Looking at these decisions can help a lot in understand how to express dependencies ((pre)depends, recommends, suggests, replaces, conflicts, provides, breaks, …) correctly (or it will lead you into insanity, depending on how pain resistant you are ;) ). > However, my reading of Debian policy gave me the impression that > Replaces was supposed to be used for that purpose. Since the tools > currently do not fully support that use, I think they are broken. No. Replaces is used to say to dpkg: It is okay that this package overrides files of the other package - otherwise dpkg would complain loudly for good reasons. It doesn't say something about the upgrade path. It also does not say that B will replaces A completely - this is maybe the case, maybe not (it replaces only a single file). Provides give the indication that B is a complete replacement for A, but in this case you should be sure that it is really a complete replacement. libX2-dev can't provide libX1-dev for example - or it could but only if all packages which work with libX1-dev can be built without a change with libX2-dev instead of libX1-dev. This also eliminates the idea to let libX1-dev be a dummy package only depending on libX2-dev as the packages building against libX1-dev will be (completely) broken. This is normally done for Package renames and described in e.g. http://wiki.debian.org/Renaming_a_Package Method B will in future (squeeze+1) take care of these dummy empty packages if the maintainer does it correct. Until then we need to handle them with autoremove and co - which is yet another "interesting" and complicated problem… So i would recommend to describe more what you actually want and your specific problem so people can help you (maybe the questions are a better fit in d-mentors) and not what you think is a bug in a package manager - if it is really a bug it should be expressed with a proper bugreport against the package manager in question… Best regards, David Kalnischkies (Debian APT GSoC student) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik96wdwal1imqqkm_fzkqyfb0vnsdnb6ywmp...@mail.gmail.com
Re: lilo removal in squeeze (or, "please test grub2")
[Stephen Powell] > It *does* recognize lilo and has special logic to patch lilo after > the restore so that the machine will boot. So can this software be fooled into thinking it is dealing with lilo? Would it be sufficient to rename /boot/extlinux/extlinux.sys to /boot/maps or something? -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100528204411.ge18...@p12n.org
Re: Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol
On 05/28/2010 09:20 AM, Reinhard Tartler wrote: On Fr, Mai 28, 2010 at 16:00:27 (CEST), Ron Johnson wrote: On 05/28/2010 01:25 AM, Reinhard Tartler wrote: I'm going to package rtmpdump next week. On Fr, Mai 22, 2009 at 16:33:44 (CEST), Sam Morris wrote: * Package name: rtmpdump * URL : [hidden obsolete url] * License : GPL Programming Lang: C++ Description : download media streamed with the RTMP/RTMPE protocol A small dumper for media content streamed over the RTMP/RTMPE protocol. How will this be different from the rtmpdump (currently at v2.2d-0.0) in d-m.o? I didn't look inside the source package nor do I intend to do so. I note that it doesn't provide an librtmp-dev package, so it's useless for me. Even when you need to reinvent the wheel, it's usually useful to see how others built their wheels, and maybe -- just maybe -- add to their well-debugged wheel. Some rights-restricted libraries stripped out? I didn't spot any restricted libraries included. What are you referring to? Christian created d-m.o for useful packages that can't be the official Debian repositories; mainly for licensing issues. That's why, for example, mplayer and ffmpeg are in both Debian and d-m.o. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c002c67.9050...@cox.net
Bug#583621: ITP: dasm -- macro assembler for 8-bit microprocessors
Package: wnpp Severity: wishlist Owner: Stephen Kitt Owner: Stephen Kitt * Package name: dasm Version : 2.20.11 Upstream Author : Peter H. Froehlich * URL : http://dasm-dillon.sf.net * License : GPL-2 Programming Lang: C Description : macro assembler for 8-bit microprocessors dasm is a macro assembler for the following 8-bit microprocessors: * MOS 6502 and 6507 * Motorola 6803, 68705 and 68HC11 * Hitachi HD6303 * Fairchild F8 . It also includes machine runtimes (support headers) for the Atari 2600 VCS and the Fairchild Channel F VES. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100528214509.10058.23101.report...@heffalump.sk2.org
Re: RFH: bashisms in configure script
Stefan Fritsch wrote: > On Tuesday 25 May 2010, Raphael Geissert wrote: >> 1. If your name is on the list at [2] please check at [3] the .dsc >> file that corresponds to the source packages you co-/maintain, >> review and fix. The .dsc files contain checkbashisms' output. > > Do you want to start a list with errors that can be ignored because > they are in unused scripts? Yes. I don't know how/where, but it sounds like a good idea. [...] > Since srclib/pcre/configure is never executed during the build of the > Debian package, I don't see any value in fixing it. Sure, that's ok, but please don't forget to report it upstream. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/htpksj$3t...@dough.gmane.org
Re: Meaning of the different “format” fields and files.
Le Fri, May 28, 2010 at 08:25:25AM +0200, Raphael Hertzog a écrit : > On Thu, 27 May 2010, Charles Plessy wrote: > > * In Debian changes files, Format is currently 1.8; I suppose that it > >defines the meaning and syntax of the other fields. Is there a place > > were the > >history of this file format is defined? Is it a general format number > > for what > >we call the “pseudo RFC-822”, “paragraph”, or “stanza” format? > > > > * In the Debian source control files, Format is 1.0 or 3.0 (variant). This > >defines the format of the source package. Is the format of the Debian > > source control > >file itself tied to the format of the source package, or is it > > independant as for > >the changes files? > > > > * §5.6.16 specifies a value of 1.5 for all Format fields. Is it a source > > package format > >version or a “pseudo RFC-822” format version. If yes should this number > > be updated to 1.8, > >or even to 1.9 to reflect that the Format field is deprecated in source > > package > >control files? > > > > Answer to those questions in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547272 Thanks for the pointer. I sent a patch for the Policy to this bug report. I agree with the comment of Manoj in message #15 that the Format field of the Debian source control files would have better been called Src-Format or something similar. Do you think that there is a chance to correct this in the future? The patch I sent indicates the meaning of the Format field for the Debian change files and source control files, and brings the Policy up to date with the format 1.8 for Debian changes files. I did not address the meaning of the Format field in source package control files, because I do not understand why the debian/source/format file was introduced to replace the use of that field. Have a nice week-end, -- 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 Archive: http://lists.debian.org/20100529045630.ga25...@kunpuu.plessy.org
