Re: Recent changes in dpkg
On Wed, 26 May 2010 23:44:52 +0200 Iustin Pop wrote: > On Wed, May 26, 2010 at 10:34:32PM +0100, Neil Williams wrote: > > I think the announcement is wrong, we cannot ever expect every > > single package to be touched for any single change. We don't even > > do that when libc changes SONAME - that only affects compiled > > packages, this theoretically affects all source packages which > > means huge numbers of rebuilds and transitions. > > Agreed. > > > There is nothing wrong with a source package that glides through > > several stable releases without needing a rebuild, especially if it > > only builds an Arch:all binary package. As long as it is bug free, > > an ancient standards version alone is not sufficient reason to > > change anything in the package or make any upload just for the sake > > of making an upload. > > But here I disagree. A couple of stable releases is, let's say, 4 > years? In the last four years, there have been significant changes > (advancements?) in the state of Debian packaging. As such, most, if > not all, nontrivial packages would be improved if they're brought up > to date. I can think of a few perl modules that won't need another upload until Perl6 is not only released but sufficiently stable that Perl5 is to be removed. That doesn't look like it will happen within a couple of stable releases, if at all. (It will take us longer to transition from Perl5 than it did for libgtk1.2 and that took more than two stable releases.) Other packages affected could be data packages etc. After Squeeze is released, I'll have half a dozen or more packages that will be the same version in oldstable through to unstable and none of those currently have any bugs or lintian warnings other than an old/ancient standards version or similarly minor issues. None of those would give any benefits *to users* by being "updated" with respect to the packaging. > > debian/source/format cannot become mandatory without causing every > > single source package to be modified. For what? Just to add 6 bytes? > > Mandatory? I agree it shouldn't be mandatory. I would rather propose a > 'W' lintian tag, nothing more, and which will only fire if the last > changelog date is after the date this proposal goes live. If dpkg errors out upon the absence of debian/source/format, then it becomes mandatory by definition - because dpkg would cause a FTBFS through no fault of the package. I don't see any point in threatening to cause so many bugs merely to satisfy the dpkg maintainers. If it is going to be possible for dpkg to consider the absence of debian/source/format as an error, it is SO far ahead into the future that it isn't worth consideration IMHO. So the lack of a debian/source/format file has to remain supported by dpkg for more than a couple of stable releases, maybe with a message but NOT with a failure. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpSzxVWuIH2n.pgp Description: PGP signature
Re: Recent changes in dpkg
On Thu, 27 May 2010 00:16:01 +0200 Emilio Pozuelo Monfort wrote: Putting the list back into the loop. > On 26/05/10 23:34, Neil Williams wrote: > > Declaring a format mandates touching every single package because > > the vast majority of packages are currently dpkg source format 1.0 > > ONLY because debian/source/format does NOT exist. The dpkg > > maintainers appear to want all packages to have a file that > > currently only exists in a fraction of packages. We cannot add a > > file to packages without touching them / rebuilding them, so as the > > lack of a file is proposed as being *against eventual policy* then > > Policy is being abused to do what it has been claimed Policy should > > never do - force a change that is NOT already implemented in most > > affected packages. > > No, the idea is that you add debian/source/format when you need to > upload the package (and not the other way round), so this will just > be an slow transition. There are packages that don't need uploads again. These packages are nor orphaned, not dead upstream, just very stable. > Policy is not going to require > debian/source/format anytime soon, so that's irrelevant. Not if the package then FTBFS. You seem to think that every package is going to be uploaded just for the sake of an upload. There is no way to guarantee that ALL packages in Debian will be uploaded again by some point in the future. If a package does not need an upload - e.g. the only "issue" is an ancient standards version - then dpkg cannot change behaviour in a way that makes that package FTBFS. > > The ABSENCE of debian/source/format needs to be explicitly retained > > as a de facto declaration of dpkg source format 1.0. i.e. unless > > explicitly specified, 1.0 needs to BE the default. > > No, it doesn't. It is now but at some point there won't be any > default, meaning that if you don't have debian/source/format, dpkg > will error out. Nothing wrong with that. If, eventually, dpkg fails with an error when debian/source/format does not exist, dpkg is causing the package to FTBFS and therefore dpkg is causing an unnecessary upload due to the changed behaviour of dpkg. There is A LOT wrong with that. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpeqIh49OXii.pgp Description: PGP signature
Re: Recent changes in dpkg
On 2010-05-26, Holger Levsen wrote: > On Mittwoch, 26. Mai 2010, Philipp Kern wrote: >> ETOPIC. You have to specify the format in the package. Nowhere they >> write that 1.0 will disappear. And they say "in the long term" too, so >> "debian/source/format" should be propagating naturally into most of the >> packages due to the lintian tag. > And I haven't heard of a single reason, why the lack of > debian/source/format *shouldn't* be interpreted as, well, source/format > 1.0. As far as I understood it, it's not that much about unpacking, because the format is pretty clear then, but about packing (or in this case repacking) the source package. There you should be explicit in what you mean because future versions of dpkg might abort if the source version is not explicitly specified in the package. Now I think the maintainers did outline why they want that in the past. :P Kind regards, Philipp Kern -- 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/slrnhvs38n.k0b.tr...@kelgar.0x539.de
Meaning of the different “ format” fields and files.
Dear all, I am getting confused by the different meanings of the Format fields and the format file in the Debian source packages and their accompanying files. [In the paragraphs below, I name the files according to Policy 3.8.4 §5] * 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? * A Format field in source package control files used to determine the Format field of the Debian source control files, but in the latest Policy, this field is not listed in §5.2, that defines source package control files. However, other fields, like the VCS-* fields are not listed there, so it does not mean that the Format field is disallowed. Nevertheless it seems to be deprecated. Should the policy be updated to reflect this? * §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? * Lastly, there is the new debian/source configuration directory, that is used by the latest dpkg-dev, but also by lintian. Is the structure of this directory described somewhere? Is it versionned? Needless to say, I volunteer to send a patch to the Policy that will summarise the answers to this email. Have a nice day, -- 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/20100527050522.gb13...@kunpuu.plessy.org
Re: lilo removal in squeeze (or, "please test grub2")
Paul Vojta, le Thu 27 May 2010 00:47:14 +, a écrit : > In article , > Ferenc Wagner wrote: > > > >Sorry, I don't trust in the future of LILO myself. If there's anything > >which only LILO can do, I recommend you start complaining on the > >Syslinux and the Grub mailing lists. I suppose it will be heard. > > Does either grub2 or syslinux allow for single-key booting? It is available in the experimental branch of grub2. Samuel -- 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/20100527013126.gr4...@const.famille.thibault.fr
Re: Let's write a system admin friendly mail server packaging system
"Jaldhar H. Vyas" wrote: >Scott Kitterman kitterman.com> writes: > >> >> Additionally, Ubuntu ships a distro specific binary called dovecot-postfix >> that implements part of this >> vision already. We'd love to see it in Debian if the dovecot maintainer is >> interested. >> > >The dovecot maintainer might be interested if someone told him about it. Like >with a wishlist bug to the BTS maybe? > Excellent. It's only been recently it's gotten to the point that I think it might be worth looking at for Debian. Scott K -- 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/91519a0b-55e1-4c06-b3b0-4f48c6efa...@email.android.com
Re: Let's write a system admin friendly mail server packaging system
Scott Kitterman kitterman.com> writes: > > Additionally, Ubuntu ships a distro specific binary called dovecot-postfix > that implements part of this > vision already. We'd love to see it in Debian if the dovecot maintainer is > interested. > The dovecot maintainer might be interested if someone told him about it. Like with a wishlist bug to the BTS maybe? -- Jaldhar H. Vyas -- 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/loom.20100527t030124-...@post.gmane.org
Re: lilo removal in squeeze (or, "please test grub2")
In article , Ferenc Wagner wrote: > >Sorry, I don't trust in the future of LILO myself. If there's anything >which only LILO can do, I recommend you start complaining on the >Syslinux and the Grub mailing lists. I suppose it will be heard. Does either grub2 or syslinux allow for single-key booting? (For example, if in lilo.conf I have the command "single-key" near the beginning of the file, "alias=w" in the stanza for Windows, and no labels begin with w or W, then at boot time the single key "w" will cause lilo to start booting Windows.) --Paul Vojta, vo...@math.berkeley.edu -- 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/htkfei$3r...@news.eternal-september.org
Re: Let's write a system admin friendly mail server packaging system
"Roberto C. Sánchez" wrote: >On Wed, May 26, 2010 at 06:42:50PM +0200, Michael Banck wrote: >> On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: >> > Mario 'BitKoenig' Holbe wrote: >> > > I'm installing apache2 and have a web server - more or less working, >> > > I'm installing dhelp and ... magic, magic ... it extends the running >> > > web-server to serve the dhelp content as well. I'm installing smb2www >> > > and it extends the running web-server to act as smb client as well. >> > > How do they do this? There is some conf.d directory which contains >> > > config snippets for each of the packages. >> > >> > Yes, which feature I requested from the upstream of postfix. I got a >> > stunning reply that it was a stupid idea, that it would be slow to >> > parse, and that postconf wouldn't work anymore. So forget about having >> > this in postfix, we must find another way. >> >> Eh, Debian can patch upstream software if it thinks it is necessary for >> inter-operation, that's the one of the major points of having a >> distribution. >> >That is true. However, it must be balanced with making the software >different than it is on every other platform. I'm not saying that it >cannot be done. Rather, there needs be a discussion as to whether that >is something that Debian wants to do. It is not as simple as just >patching a high profile package like postfix. > FWIW, dovecot supports config.d too. For postfix, as I understand the design, it would be as non-trivial effort to move to a similar cascading config directory approach. Fortunately it's not needed. In postfix you need to be able to programmatically modify both main.cf and master.cf. I believe that the upstream supported postconf tool supports making all needed changes to main.cf. The Debian package also ships some Debian (and derivative) specific scripts to allow smtp filters and policy services to be added to master.cf by other packages in a policy compliant way. They are simplistic, but should serve this use case (it's the one I wrote them for). Additionally, Ubuntu ships a distro specific binary called dovecot-postfix that implements part of this vision already. We'd love to see it in Debian if the dovecot maintainer is interested. Scott K -- 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/aa1a35fd-a1de-4e9f-b4ac-a8795379b...@email.android.com
Re: Recent changes in dpkg
Hi, On Mittwoch, 26. Mai 2010, Philipp Kern wrote: > ETOPIC. You have to specify the format in the package. Nowhere they write > that 1.0 will disappear. And they say "in the long term" too, so > "debian/source/format" should be propagating naturally into most of the > packages due to the lintian tag. Yes, I agree. "most". But .deb is used in a lot of environments. And I haven't heard of a single reason, why the lack of debian/source/format *shouldn't* be interpreted as, well, source/format = 1.0. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: The story behind UPG and umask.
Am Tue, 25 May 2010 16:43:21 -0700 schrieb Steve Langasek : > I am not willing to diverge from upstream on this as this > would mean admins coming from other systems may get an unpleasant > surprise when they find that Debian gives a more relaxed umask than > they were expecting in some corner cases. Would you, or somebody else, be willing to write a patch for pam_umask to read the USERGROUPS_ENAB option from /etc/login.defs or /etc/default/login, just as it is reading the UMASK option from there? Cheers, 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/20100527010259.4fe10b74c.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
This one time, at band camp, Tollef Fog Heen said: > The problem is when you then run addgroup foo, every user created > after that will not be considered to be a UPG user. Perhaps addgroup > shouldn't use the same gid range as what we are using for users, to > make this problem at least smaller, if not make it go away. I've been unhappy for one reason or another with ideas like this in the past (gids below 100 are reserved, then there come system groups, then usergroups starting at 1000, unless you want to interoperate with RHEL and derivatives in which case they start at 500. You also don't want to pick a high range because large sites will have uids creep up from behind, etc. Blech) The current arrangement isn't brilliant, but it's at least clear that if a gid is >= 1000, it is not the gid of a system account (unless of course it's nobody/nogroup ... :) ), although you can't necessarily say much more than that. I suspect it will be simplest to just add a bit of logic to adduser to make it 'skip ahead' until it can get matching uids/gids. This will leave holes in both passwd and group, but that's not exactly a problem. FWIW, I tend to agree with Roger that the added step of uid == gid doesn't actually buy us all that much, but if other software we are currently shipping depends on that behavior, we might as well not deliberately break it. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: The story behind UPG and umask.
This one time, at band camp, Michael Banck said: > In light of UPG, we might want to revisit the default here as well, > maybe it makes sense to have your $HOME not world-readable be the > default? That is already trivailly settable and not a debate likely to bring much new to the table on either side. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: The story behind UPG and umask.
This one time, at band camp, Roger Leigh said: > How will adduser cope with group addition; does it skip UIDs until > it finds an unused unique UID/GID pair? That certainly is the only approach that makes sense - it has the benefit of simplicity, if not elegance. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: The story behind UPG and umask.
Wed, 26 May 2010 23:26:37 +0200, Tollef Fog Heen: > Perhaps addgroup > shouldn't use the same gid range as what we are using for users, to > make this problem at least smaller, if not make it go away. Hm, that may be another option to allign UIDs and GIDs, you'd create split max. UID/GID amounts though, and would still need adduser/useradd to skip any available GIDs with old/manually taken UIDs to ensure UID==GUID UPG accounts. -- 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/20100527004121.6b029358c.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Wed, 26 May 2010 14:25:58 +0200 schrieb Michael Banck : > On Wed, May 26, 2010 at 02:36:53AM +0200, C. Gatzemeier wrote: > > Am Tue, 25 May 2010 22:47:51 +0200 > > schrieb Harald Braumann : > > > On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote: > > > > The path into your home directory is not restricted, just as the > > > > path others can take to ring your bell at home is not > > > > restricted. > > > > > > Depends on adduser settings. Both, world readable and private home > > > directories are common. > > > > Thanks! Adding ...the path to your home *is by default* not > > restricted,... seems to be more precise. > > In light of UPG, we might want to revisit the default here as well, > maybe it makes sense to have your $HOME not world-readable be the > default? Just making a list of consequences to consider here. Users can not modify the permissions of their home on their own, but they can manage everything within their home. The UPG scheme works directory based. So for private things, there should be a ready to use and set up ~/priv directory by default. That is a place where a user may keep much of his stuff, if he does not want to change permissions of other subdirs. As world readable is a largely used default programs with really privacy relevant config files should take care of their config file permissions already. If the $HOME however is not world accessible you can not have your ~/incoming or ~/Public directory within your home. More importantly users can not create new group directories on their own in their home, and they can not be allowed write access to a separate place like /home/group for this. When I'd set up an ISP/hosting system where users are not supposed to collaborate and work on their own, I'd change the default home permissions in adduser.conf. There is also some discussion about the home permission on https://wiki.ubuntu.com/MultiUserManagement Cheers, 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/20100527001837.6bfdd866c.gatzeme...@tu-bs.de@tu-bs.de
GID/UID algorithm? (Re: The story behind UPG and umask.)
Am Wed, 26 May 2010 18:05:32 +0100 schrieb Roger Leigh : > How will adduser cope with group addition; does it skip UIDs until > it finds an unused unique UID/GID pair? Maybe just skip taken GIDs by default? (every user has one, less gap more likely to be usable for a user account), starting +1 from the highest GID that was ever created without specifying specific IDs on the system (to avoid giving possibly remaining old files from deleted users/groups to new users/groups). Set that search start pointer back to MIN_GID if it points to MAX_GID. If the admin hasn't manually created any users/groups with higer IDs, the first (+1) GID should already be an available slot. The UIDs and GIDs match nicely, occasionally (where a regular group has been created) some UIDs will stay unused. There shouldn' be any drawback. Does adduser rely on useradd? -- 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/20100526232358.17ffb67fc.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Wed, 26 May 2010 18:05:32 +0100 schrieb Roger Leigh : > What, exactly, does comparing the UID and GID get you? I.e. what > is is protecting you against? If you're using a system such as > Debian, which has created a group by the same name for many years, > you're in no danger AFAIU it is meant for cases where you connect a debian box to an existing LDAP etc. environment, where a user and group might exits but not be related. Like a user that is called admin and an admin system group etc. Having alligned UIDs==GIDs makes UPGs systems more distinguishable from other systems. The check will also recognize RH, f, ... UPGs systems, and the allignment will make those other systems also recognized a debian server as an UPG system. Cheers, 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/20100526232212.1047deefc.gatzeme...@tu-bs.de@tu-bs.de
Re: Recent changes in dpkg
On Wed, May 26, 2010 at 10:34:32PM +0100, Neil Williams wrote: > On Wed, 26 May 2010 22:59:25 +0200 > Iustin Pop wrote: > > > On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: > > > On 05/24/2010 11:05 AM, Raphael Hertzog wrote: > > > > * The plan concerning dpkg-source and the default source format > > > > has been clarified. In the long term, the default format will > > > > disappear and debian/source/format will become mandatory. The > > > > lintian tag missing-debian-source-format[2] will help us track > > > > that. > > > > > > Which will force developers to touch most of the packages in the > > > archive just to realize this? Sorry, but that's insane. You should > > > not try to force people into migrating to some new format because > > > *you* think it is better. This is not a decision which should be > > > decided by the dpkg maintainers - instead it needs to be discussed > > > within the developers and maintainers. While the new format > > > provides some advantages when it comes to the handling of patches, > > > the 1.0 format is still much more flexible to use - for example it > > > does not require an existing tarball to build a package, which is > > > very useful for testing. You know that there are a lot of arguments > > > against the 3.0 format out there, so please do not enforce such > > > changes without discussing them first. > > > > I think you're misreading the announcement. What will change is that > > declaring the format (either 1.0 or 3.0 in whatever variant) will be > > required, not migrating to the new formats. > > Declaring a format mandates touching every single package because the > vast majority of packages are currently dpkg source format 1.0 ONLY > because debian/source/format does NOT exist. […] I was only responding to Bernd's email which sounded like he misread the change. Whether the actual change is good or not, it's another issue, on which I'm disagreeing (but not very strongly, i.e. I could live with it): > I think the announcement is wrong, we cannot ever expect every single > package to be touched for any single change. We don't even do that when > libc changes SONAME - that only affects compiled packages, this > theoretically affects all source packages which means huge numbers of > rebuilds and transitions. Agreed. > There is nothing wrong with a source package that glides through several > stable releases without needing a rebuild, especially if it only > builds an Arch:all binary package. As long as it is bug free, an ancient > standards version alone is not sufficient reason to change anything in > the package or make any upload just for the sake of making an upload. But here I disagree. A couple of stable releases is, let's say, 4 years? In the last four years, there have been significant changes (advancements?) in the state of Debian packaging. As such, most, if not all, nontrivial packages would be improved if they're brought up to date. > debian/source/format cannot become mandatory without causing every > single source package to be modified. For what? Just to add 6 bytes? Mandatory? I agree it shouldn't be mandatory. I would rather propose a 'W' lintian tag, nothing more, and which will only fire if the last changelog date is after the date this proposal goes live. iustin -- 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/20100526214452.gb2...@teal.hq.k1024.org
Re: Let's write a system admin friendly mail server packaging system
]] Michael Banck | On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: | > Mario 'BitKoenig' Holbe wrote: | > > I'm installing apache2 and have a web server - more or less working, | > > I'm installing dhelp and ... magic, magic ... it extends the running | > > web-server to serve the dhelp content as well. I'm installing smb2www | > > and it extends the running web-server to act as smb client as well. | > > How do they do this? There is some conf.d directory which contains | > > config snippets for each of the packages. | > | > Yes, which feature I requested from the upstream of postfix. I got a | > stunning reply that it was a stupid idea, that it would be slow to | > parse, and that postconf wouldn't work anymore. So forget about having | > this in postfix, we must find another way. | | Eh, Debian can patch upstream software if it thinks it is necessary for | inter-operation, that's the one of the major points of having a | distribution. Wouldn't it be easier to generate a configuration directory in /var from snippets in /etc/postfix, if that was what you desired? The init script could do that easily enough. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87fx1el4xf@qurzaw.linpro.no
Re: Recent changes in dpkg
On Wed, 26 May 2010 22:59:25 +0200 Iustin Pop wrote: > On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: > > On 05/24/2010 11:05 AM, Raphael Hertzog wrote: > > > * The plan concerning dpkg-source and the default source format > > > has been clarified. In the long term, the default format will > > > disappear and debian/source/format will become mandatory. The > > > lintian tag missing-debian-source-format[2] will help us track > > > that. > > > > Which will force developers to touch most of the packages in the > > archive just to realize this? Sorry, but that's insane. You should > > not try to force people into migrating to some new format because > > *you* think it is better. This is not a decision which should be > > decided by the dpkg maintainers - instead it needs to be discussed > > within the developers and maintainers. While the new format > > provides some advantages when it comes to the handling of patches, > > the 1.0 format is still much more flexible to use - for example it > > does not require an existing tarball to build a package, which is > > very useful for testing. You know that there are a lot of arguments > > against the 3.0 format out there, so please do not enforce such > > changes without discussing them first. > > I think you're misreading the announcement. What will change is that > declaring the format (either 1.0 or 3.0 in whatever variant) will be > required, not migrating to the new formats. Declaring a format mandates touching every single package because the vast majority of packages are currently dpkg source format 1.0 ONLY because debian/source/format does NOT exist. The dpkg maintainers appear to want all packages to have a file that currently only exists in a fraction of packages. We cannot add a file to packages without touching them / rebuilding them, so as the lack of a file is proposed as being *against eventual policy* then Policy is being abused to do what it has been claimed Policy should never do - force a change that is NOT already implemented in most affected packages. The ABSENCE of debian/source/format needs to be explicitly retained as a de facto declaration of dpkg source format 1.0. i.e. unless explicitly specified, 1.0 needs to BE the default. Any other proposal tries to abuse Policy to implement a (trivial) change affecting every single source package in Debian. I find that unacceptable. If dpkg eventually causes FTBFS due to the lack of this file, then dpkg will be buggy, not the package. This is especially true when nothing has changed in the package; the only change would be in dpkg behaviour. > > > has been clarified. In the long term, the default format will > > > disappear and debian/source/format will become mandatory. The I think the announcement is wrong, we cannot ever expect every single package to be touched for any single change. We don't even do that when libc changes SONAME - that only affects compiled packages, this theoretically affects all source packages which means huge numbers of rebuilds and transitions. There is nothing wrong with a source package that glides through several stable releases without needing a rebuild, especially if it only builds an Arch:all binary package. As long as it is bug free, an ancient standards version alone is not sufficient reason to change anything in the package or make any upload just for the sake of making an upload. debian/source/format cannot become mandatory without causing every single source package to be modified. For what? Just to add 6 bytes? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpvYmN5ux453.pgp Description: PGP signature
Re: The story behind UPG and umask.
]] "C. Gatzemeier" | So yes, you can setup UPGs with UID!=GID, but then you'll also | have to set the umask manually to make it work (globally or in gecos or | ldap etc.). | | The UID==GID and username==groupname restriction of the | pam_umask's "usergroups" option ensures that the umask is only relaxed | automatically in very specific defined cases. | | That's why I'am thinking the UID==GID restriction pam_umask makes (and | login made before) can be sane choice. (Others seem to use it also, | and it is upstream.) The problem is when you then run addgroup foo, every user created after that will not be considered to be a UPG user. Perhaps addgroup shouldn't use the same gid range as what we are using for users, to make this problem at least smaller, if not make it go away. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87k4qql5gy@qurzaw.linpro.no
Re: SRWare Iron: Chromium without the data-mining
]] Josselin Mouette | Le samedi 22 mai 2010 à 08:43 +0200, Tollef Fog Heen a écrit : | > | I don't see what you mean by "iffy" tabbed browsing, what's wrong with | > | tabbed browsing in Epiphany? | > | > For me, at least two things: | > | > - C-TAB/C-S-TAB doesn't work for switching tabs, I have to use | > C-PgUp/PgDn. | | This is the default GTK+ shortcut for that. I realise that, but it's not default in various web browsers. (Well, most I've used seem to support both C-PgUp/C-PgDn and C-TAB/C-S-Tab). This is probably the major gripe for me each time I end up using epiphany for anything. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87ocg2l5s2@qurzaw.linpro.no
Re: Recent changes in dpkg
On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: > On 05/24/2010 11:05 AM, Raphael Hertzog wrote: > > Hello, > > > > The versions 1.15.6 and 1.15.7 of dpkg introduced several important changes. > > Let's skim over them: > [...] > > * dpkg-dev provides a new script called dpkg-buildflags that packages > > should use in debian/rules to retrieve the default value of various > > compilation flags. Bug #578597[1] has been submitted against > > debian-policy. When generalized this offer us centralized archive-wide > > control of the default build flags as well as the possibility for > > end-users to try out easily new flags. > > So you plan to enforce something which resulted in a lot of FTBFS due to the > fact that buildflags, which were written into a Makefile by configure or > similar > tools, were overridden by the default values from dpkg again as they were > still > present in the environment? [...] Environment variables do not override variable definitions in a makefile. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20100526210731.ge5...@decadent.org.uk
Re: Recent changes in dpkg
On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: > On 05/24/2010 11:05 AM, Raphael Hertzog wrote: > > * The plan concerning dpkg-source and the default source format has been > > clarified. In the long term, the default format will disappear and > > debian/source/format will become mandatory. The lintian tag > > missing-debian-source-format[2] will help us track that. > > Which will force developers to touch most of the packages in the archive just > to > realize this? Sorry, but that's insane. You should not try to force people > into > migrating to some new format because *you* think it is better. This is not a > decision which should be decided by the dpkg maintainers - instead it needs to > be discussed within the developers and maintainers. While the new format > provides some advantages when it comes to the handling of patches, the 1.0 > format is still much more flexible to use - for example it does not require an > existing tarball to build a package, which is very useful for testing. > You know that there are a lot of arguments against the 3.0 format out there, > so > please do not enforce such changes without discussing them first. I think you're misreading the announcement. What will change is that declaring the format (either 1.0 or 3.0 in whatever variant) will be required, not migrating to the new formats. regards, iustin signature.asc Description: Digital signature
Re: Recent changes in dpkg
On 2010-05-26, Bernd Zeimetz wrote: >> * The plan concerning dpkg-source and the default source format has been >> clarified. In the long term, the default format will disappear and >> debian/source/format will become mandatory. The lintian tag >> missing-debian-source-format[2] will help us track that. > Which will force developers to touch most of the packages in the archive just > to > realize this? Sorry, but that's insane. You should not try to force people > into > migrating to some new format because *you* think it is better. ETOPIC. You have to specify the format in the package. Nowhere they write that 1.0 will disappear. And they say "in the long term" too, so "debian/source/format" should be propagating naturally into most of the packages due to the lintian tag. Kind regards, Philipp Kern -- 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/slrnhvr2ff.hvt.tr...@kelgar.0x539.de
Re: Recent changes in dpkg
On 05/24/2010 11:05 AM, Raphael Hertzog wrote: > Hello, > > The versions 1.15.6 and 1.15.7 of dpkg introduced several important changes. > Let's skim over them: [...] > * dpkg-dev provides a new script called dpkg-buildflags that packages > should use in debian/rules to retrieve the default value of various > compilation flags. Bug #578597[1] has been submitted against > debian-policy. When generalized this offer us centralized archive-wide > control of the default build flags as well as the possibility for > end-users to try out easily new flags. So you plan to enforce something which resulted in a lot of FTBFS due to the fact that buildflags, which were written into a Makefile by configure or similar tools, were overridden by the default values from dpkg again as they were still present in the environment? > * The plan concerning dpkg-source and the default source format has been > clarified. In the long term, the default format will disappear and > debian/source/format will become mandatory. The lintian tag > missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. This is not a decision which should be decided by the dpkg maintainers - instead it needs to be discussed within the developers and maintainers. While the new format provides some advantages when it comes to the handling of patches, the 1.0 format is still much more flexible to use - for example it does not require an existing tarball to build a package, which is very useful for testing. You know that there are a lot of arguments against the 3.0 format out there, so please do not enforce such changes without discussing them first. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4bfd87f8.90...@bzed.de
Re: Let's write a system admin friendly mail server packaging system
On 05/26/2010 02:29 PM, Thomas Goirand wrote: [snip] Anyway, postfix is NOT the only package that we shall consider modifying here. As per my original post, there's loads of other components that are to configure as well. The question is: is there a will to do this job by other maintainers. I am myself strongly motivated for this, but I wont be able to do it alone. As was mentioned earlier, this can't be a Debian-only task. It's just too big and complicated. Upstream of all the relevant packages must buy in. -- 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/4bfd86c6.7080...@cox.net
Re: Let's write a system admin friendly mail server packaging system
Ron Johnson wrote: > On 05/26/2010 11:42 AM, Michael Banck wrote: >> On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: >>> Mario 'BitKoenig' Holbe wrote: I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. >>> >>> Yes, which feature I requested from the upstream of postfix. I got a >>> stunning reply that it was a stupid idea, that it would be slow to >>> parse, and that postconf wouldn't work anymore. So forget about having >>> this in postfix, we must find another way. >> >> Eh, Debian can patch upstream software if it thinks it is necessary for >> inter-operation, that's the one of the major points of having a >> distribution. >> > > That would be some *serious* patching. > > Maybe, though, LaMont Jones (the Postfix DD) has a better relationship > with upstream and could convince them that conf.d is a good idea. I have to admit that I didn't insist so much, given the type of response I had when I asked. I also agree that it would be much better if upstream were happily accepting such patch, even if one of us is doing the job. I didn't really dive into the postfix code to know how hard it would be to add the feature, and I hope that LaMont Jones can talk about it. Anyway, postfix is NOT the only package that we shall consider modifying here. As per my original post, there's loads of other components that are to configure as well. The question is: is there a will to do this job by other maintainers. I am myself strongly motivated for this, but I wont be able to do it alone. Thomas -- 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/4bfd7686.4030...@goirand.fr
Re: Let's write a system admin friendly mail server packaging system
Thomas: Sorry for the private mail, I hit the wrong reply button. On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: > Mario 'BitKoenig' Holbe wrote: > > I'm installing apache2 and have a web server - more or less working, > > I'm installing dhelp and ... magic, magic ... it extends the running > > web-server to serve the dhelp content as well. I'm installing smb2www > > and it extends the running web-server to act as smb client as well. > > How do they do this? There is some conf.d directory which contains > > config snippets for each of the packages. > > Yes, which feature I requested from the upstream of postfix. I got a > stunning reply that it was a stupid idea, that it would be slow to > parse, and that postconf wouldn't work anymore. So forget about having > this in postfix, we must find another way. The packaging of Exim optionally supports a setup in which the config file is split into several conf.d-like directories. Whenever Exim is restarted all files in those directories are concatenated into a single file somewhere under /var which is then fed to the Exim daemon. Couldn't the postfix package be modified to do something similiar? Andreas signature.asc Description: Digital signature
Re: Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
On Wed, May 26, 2010 at 14:59:41 -0300, Marco Túlio Gontijo e Silva wrote: > Hi Brian. > > Excerpts from brian m. carlson's message of Qua Mai 26 14:53:48 -0300 2010: > > On Wed, May 26, 2010 at 02:07:22PM -0300, Marco Túlio Gontijo e Silva wrote: > > > Package: wnpp > > > Severity: wishlist > > > Owner: "Marco Túlio Gontijo e Silva" > > > > > > * Package name: haskell-gnomevfs > > > Version : 0.11.0 > > > Upstream Author : Duncan Coutts > > > * URL : http://www.haskell.org/gtk2hs/ > > > * License : LGPL-2.1+ > > > Programming Lang: Haskell > > > Description : Binding to the GNOME Virtual File System library > > > > It's my understanding that gnome-vfs is deprecated upstream and is going > > away. Most GNOME components no longer use it or include support for it. > > Do you really want to package a binding for unsupported software? > > This is a good point. But I'm not going to introduce this package in Debian. > The new version of gtk2hs split the source package in a lot of source > packages, > so I'm filling ITPs to new source packages, but the binary packages are the > same. Therefore, I'm only updating the version of the binary package. > Doesn't seem necessary to file ITP bugs in such a case... Cheers, Julien signature.asc Description: Digital signature
Bug#583272: ITP: haskell-gtkglext -- Binding to the GTK+ OpenGL Extension
Package: wnpp Severity: wishlist Owner: "Marco Túlio Gontijo e Silva" * Package name: haskell-gtkglext Version : 0.11.0 Upstream Author : Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the GTK+ OpenGL Extension This package provides a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . GtkGLExt provides the GDK objects to support OpenGL rendering in GTK+, and GtkWidget API add-ons to make GTK+ widgets OpenGL-capable. -- 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/20100526181318.4905.4039.report...@zezinho
Re: extlinux
On 05/26/2010 10:45 AM, Bjørn Mork wrote: > That's the single feature I misseded. Thanks. welcome. > Although it would be even better if it was possible to include some > fixed part in it, while keeping most of it auto updated. I tested the > extlinux package after reading about it yesterday, and the missing > feature that immediately hit me was the ability to use a serial console. > This is of course as easy as with sys-/pxe-/mem-linux: just add > "serial 0 9600 0" or something similar to the config file. But running > update-extlinux would remove it on every kernel upgrade. Anyway, I > understand that this issue is now solved. how about adding your parameters to EXTLINUX_PARAMETERS in /etc/default/extlinux? then they will be used for all images in the config automatically. in case that's not what you were looking for: as stated in another mail, i've added update-extlinux/extlinux-install and it fits my setups well - but any suggestions are welcome, please feel encouraged to submit bug reports against extlinux. > It has puzzled me for a while that grub2 has been chosen over extlinux > as the default x86 bootloader extlinux doesn't support as many filesystems to read the kernels from as grub does (extlinux basically only supports extlinux, and in 4.0 also btrfs; and syslinux would support fat, though). while i really like extlinux for the reasons outlined earlier[0], i don't think it's a good default for everyone and anything. > HPA has been an active upstream maintainer all > this time AFAIK. indeed, he's an excellent upstream in every aspect. Regards, Daniel [0] http://blog.daniel-baumann.ch/2009/11/30#20091130_extlinux-as-alternative-bootloader -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- 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/4bfd692b.1010...@debian.org
Re: Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
Hi, - "brian m. carlson" wrote: > On Wed, May 26, 2010 at 02:07:22PM -0300, Marco Túlio Gontijo e Silva > wrote: > > Package: wnpp > > Severity: wishlist > > Owner: "Marco Túlio Gontijo e Silva" > > > > * Package name: haskell-gnomevfs > > Version : 0.11.0 > > Upstream Author : Duncan Coutts > > * URL : http://www.haskell.org/gtk2hs/ > > * License : LGPL-2.1+ > > Programming Lang: Haskell > > Description : Binding to the GNOME Virtual File System > library > > It's my understanding that gnome-vfs is deprecated upstream and is > going > away. Most GNOME components no longer use it or include support for > it. > Do you really want to package a binding for unsupported software? Indeed. GVFS has replaced GnomeVFS in the GNOME platform. William -- 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/9514770.3811274896715696.javamail.r...@ifrit.dereferenced.org
Re: Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
Hi Brian. Excerpts from brian m. carlson's message of Qua Mai 26 14:53:48 -0300 2010: > On Wed, May 26, 2010 at 02:07:22PM -0300, Marco Túlio Gontijo e Silva wrote: > > Package: wnpp > > Severity: wishlist > > Owner: "Marco Túlio Gontijo e Silva" > > > > * Package name: haskell-gnomevfs > > Version : 0.11.0 > > Upstream Author : Duncan Coutts > > * URL : http://www.haskell.org/gtk2hs/ > > * License : LGPL-2.1+ > > Programming Lang: Haskell > > Description : Binding to the GNOME Virtual File System library > > It's my understanding that gnome-vfs is deprecated upstream and is going > away. Most GNOME components no longer use it or include support for it. > Do you really want to package a binding for unsupported software? This is a good point. But I'm not going to introduce this package in Debian. The new version of gtk2hs split the source package in a lot of source packages, so I'm filling ITPs to new source packages, but the binary packages are the same. Therefore, I'm only updating the version of the binary package. Greetings. (...) -- marcot http://wiki.debian.org/MarcoSilva signature.asc Description: PGP signature
Re: Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
On Wed, May 26, 2010 at 02:07:22PM -0300, Marco Túlio Gontijo e Silva wrote: > Package: wnpp > Severity: wishlist > Owner: "Marco Túlio Gontijo e Silva" > > * Package name: haskell-gnomevfs > Version : 0.11.0 > Upstream Author : Duncan Coutts > * URL : http://www.haskell.org/gtk2hs/ > * License : LGPL-2.1+ > Programming Lang: Haskell > Description : Binding to the GNOME Virtual File System library It's my understanding that gnome-vfs is deprecated upstream and is going away. Most GNOME components no longer use it or include support for it. Do you really want to package a binding for unsupported software? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Let's write a system admin friendly mail server packaging system
On 05/26/2010 11:42 AM, Michael Banck wrote: On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: Mario 'BitKoenig' Holbe wrote: I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. Eh, Debian can patch upstream software if it thinks it is necessary for inter-operation, that's the one of the major points of having a distribution. That would be some *serious* patching. Maybe, though, LaMont Jones (the Postfix DD) has a better relationship with upstream and could convince them that conf.d is a good idea. -- 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/4bfd5ff6.8020...@cox.net
Bug#583261: ITP: haskell-gstreamer -- Binding to the GStreamer open source multimedia framework
Package: wnpp Severity: wishlist Owner: "Marco Túlio Gontijo e Silva" * Package name: haskell-gstreamer Version : 0.11.0 Upstream Author : Peter Gavin, Axel Simon * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the GStreamer open source multimedia framework This package provides a library for the Haskell programming language, compiled for profiling. See http://www.haskell.org/ for more information on Haskell. . This package provides a wrapper around the GStreamer C library. GStreamer is a library for constructing graphs of media-handling components. The applications it supports range from simple OggVorbis playback, audiovideo streaming to complex audio (mixing) and video (non-linear editing) processing. -- 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/20100526172923.16161.81853.report...@zezinho
Re: Let's write a system admin friendly mail server packaging system
On Wed, May 26, 2010 at 06:42:50PM +0200, Michael Banck wrote: > On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: > > Mario 'BitKoenig' Holbe wrote: > > > I'm installing apache2 and have a web server - more or less working, > > > I'm installing dhelp and ... magic, magic ... it extends the running > > > web-server to serve the dhelp content as well. I'm installing smb2www > > > and it extends the running web-server to act as smb client as well. > > > How do they do this? There is some conf.d directory which contains > > > config snippets for each of the packages. > > > > Yes, which feature I requested from the upstream of postfix. I got a > > stunning reply that it was a stupid idea, that it would be slow to > > parse, and that postconf wouldn't work anymore. So forget about having > > this in postfix, we must find another way. > > Eh, Debian can patch upstream software if it thinks it is necessary for > inter-operation, that's the one of the major points of having a > distribution. > That is true. However, it must be balanced with making the software different than it is on every other platform. I'm not saying that it cannot be done. Rather, there needs be a discussion as to whether that is something that Debian wants to do. It is not as simple as just patching a high profile package like postfix. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
Package: wnpp Severity: wishlist Owner: "Marco Túlio Gontijo e Silva" * Package name: haskell-gnomevfs Version : 0.11.0 Upstream Author : Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the GNOME Virtual File System library This package provides a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . GNOME VFS is the GNOME virtual file system. It is the foundation of the Nautilus file manager. It provides a modular architecture and ships with several modules that implement support for local files, http, ftp and others. It provides an URI-based API, a backend supporting asynchronous file operations, a MIME type manipulation library and other features. -- 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/20100526170722.3466.90528.report...@zezinho
Re: The story behind UPG and umask.
On Wed, May 26, 2010 at 02:22:43PM +0200, Michael Banck wrote: > Hi, > > On Wed, May 26, 2010 at 01:00:49PM +0100, Roger Leigh wrote: > > > This one time, at band camp, Steve Langasek said: > > > > pam_umask requires both username == primary group name and uid == gid > > > > before it will assume UPG are in place when using its 'usergroups' > > > > option, > > > > I'd be interested to understand the upstream POV here--with current > > Debian systems, assuming UID==GID without additionally checking > > that the names match is horribly insecure. > > See the text you quoted yourself, or am I missing something? The UID==GID scheme works initially, but any call to addgroup to add a group will get the two out of sync. Because historically we haven't enforced the two to be equal, on any system with >=1 groups added, the UID is guaranteed to not equal the GID. In consequence, the UID==GID check will fail with these historical passwd/group files, and that's not even counting databases coming from NIS or LDAP sources where it's not under our control. What, exactly, does comparing the UID and GID get you? I.e. what is is protecting you against? If you're using a system such as Debian, which has created a group by the same name for many years, you're in no danger of accidentally creating a group with the same name of a user, since it will already exist. Additionally, adding a new user will fail if the group already exists. Are there any other corner cases this prevents problems with? How will adduser cope with group addition; does it skip UIDs until it finds an unused unique UID/GID pair? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Let's write a system admin friendly mail server packaging system
On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: > Mario 'BitKoenig' Holbe wrote: > > I'm installing apache2 and have a web server - more or less working, > > I'm installing dhelp and ... magic, magic ... it extends the running > > web-server to serve the dhelp content as well. I'm installing smb2www > > and it extends the running web-server to act as smb client as well. > > How do they do this? There is some conf.d directory which contains > > config snippets for each of the packages. > > Yes, which feature I requested from the upstream of postfix. I got a > stunning reply that it was a stupid idea, that it would be slow to > parse, and that postconf wouldn't work anymore. So forget about having > this in postfix, we must find another way. Eh, Debian can patch upstream software if it thinks it is necessary for inter-operation, that's the one of the major points of having a distribution. Michael -- 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/20100526164250.gf2...@nighthawk.chemicalconnection.dyndns.org
Re: The story behind UPG and umask.
On Wed, May 26, 2010 at 02:36:53AM +0200, C. Gatzemeier wrote: > Am Tue, 25 May 2010 22:47:51 +0200 > schrieb Harald Braumann : > > On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote: > > > The path into your home directory is not restricted, just as the > > > path others can take to ring your bell at home is not restricted. > > > > Depends on adduser settings. Both, world readable and private home > > directories are common. > > Thanks! Adding ...the path to your home *is by default* not > restricted,... seems to be more precise. In light of UPG, we might want to revisit the default here as well, maybe it makes sense to have your $HOME not world-readable be the default? Michael -- 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/20100526122558.gc2...@nighthawk.chemicalconnection.dyndns.org
Re: The story behind UPG and umask.
Hi, On Wed, May 26, 2010 at 01:00:49PM +0100, Roger Leigh wrote: > > This one time, at band camp, Steve Langasek said: > > > pam_umask requires both username == primary group name and uid == gid > > > before it will assume UPG are in place when using its 'usergroups' > > > option, > > I'd be interested to understand the upstream POV here--with current > Debian systems, assuming UID==GID without additionally checking > that the names match is horribly insecure. See the text you quoted yourself, or am I missing something? Michael -- 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/20100526122243.gb2...@nighthawk.chemicalconnection.dyndns.org
Bug#583236: ITP: haskell-glade -- Binding to the glade library
Package: wnpp Severity: wishlist Owner: "Marco Túlio Gontijo e Silva" * Package name: haskell-glade Version : 0.11.0 Upstream Author : Manuel M T Chakravarty * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2+ Programming Lang: Haskell Description : Binding to the glade library This package provides a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . This library allows to load externally stored user interfaces into programs. This allows alteration of the interface without recompilation of the program. -- 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/20100526160222.13556.23403.report...@zezinho
Re: Let's write a system admin friendly mail server packaging system
Mario 'BitKoenig' Holbe wrote: > I'm installing apache2 and have a web server - more or less working, > I'm installing dhelp and ... magic, magic ... it extends the running > web-server to serve the dhelp content as well. I'm installing smb2www > and it extends the running web-server to act as smb client as well. > How do they do this? There is some conf.d directory which contains > config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. > Why would you like to go another way with mail servers? Because upstream doesn't want a conf.d folder, unfortunately, and that the issue is NOT ONLY with postfix, but with so many package that have to understand each other. Let me give an example. If you setup postfix + amavis, then postfix must relay emails to the incoming port of amavis, and amavis got to give the email back to postfix on another port. Both postfix and amavis have to be configured so they can talk to each other. Now, add dkimproxy in the loop. You have to configure dkimproxy to receive from postfix, relay to amavis, and amavis forwards to postfix. This is a LOT less trivial than what you pretend. > Get maintainer support for such conf.d directories, maybe get upstream > support for such conf.d mimics (sendmail most likely won't need it - > some m4 magic and triggers will just do it, dunno how it is for the less > flexible ones like postfix, exim, whatever), change the depending > packages to put their config snippets in there, everything is fine. > >> argument a list of packages that it should use. But the MTA is not the >> only one to modify here, for example we might have to change the listen >> and relay port of dkimproxy and amavis, depending if each others are >> present on the system or not. I am quite in the favor of this system, > > I don't think this is really necessary. It would probably be a bit more > efficient to have one component forwarding the stuff it processed to the > next one, but I'm sure there is a less efficient but more generic way to > just bounce it back to the MTA which continues forwarding it to the next > components. ... And who cares about efficiency in generic approaches. OF COURSE we do care about the performances of a mail server. Some ISP are running servers that are managing 100s of thousands of mail a day. But anyway, this was just an example, there's many use case where you must configure one of the elements of your mail server. Thomas -- 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/4bfd4522.4080...@goirand.fr
Re: RFH: bashisms in configure script
On Wednesday 26 May 2010 03:00:58 Michael Meskes wrote: > Don't you think we should run the test *after* the patches got applied? That's done if the package uses format 3.0 (quilt). Regards, -- 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/201005261053.40241.geiss...@debian.org
Bug#583228: ITP: haskell-gconf -- Binding to the GNOME configuration database system
Package: wnpp Severity: wishlist Owner: "Marco Túlio Gontijo e Silva" * Package name: haskell-gconf Version : 0.11.0 Upstream Author : Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : GPL Programming Lang: Haskell Description : Binding to the GNOME configuration database system This package provides a library for the Haskell programming language, compiled for profiling. See http://www.haskell.org/ for more information on Haskell. . GConf is a configuration database system for storing application preferences. It supports default or mandatory settings set by the administrator, and changes to the database are instantly applied to all running applications. It is written for the GNOME desktop but doesn't require it. -- 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/20100526143956.12135.39756.report...@zezinho
Bug#583225: ITP: haskell-gtk -- Binding to the Gtk+ graphical user interface library
Package: wnpp Severity: wishlist Owner: "Marco Túlio Gontijo e Silva" * Package name: haskell-gtk Version : 0.11.0 Upstream Author : Axel Simon, Duncan Coutts and many others * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the Gtk+ graphical user interface library This package provides the documentation for a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . This is the core library of the Gtk2Hs suite of libraries for Haskell based on Gtk+. Gtk+ is an extensive and mature multi-platform toolkit for creating graphical user interfaces. -- 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/20100526142952.8910.74554.report...@zezinho
Re: Let's write a system admin friendly mail server packaging system
On Wednesday 26 May 2010 15:58:51 Mario 'BitKoenig' Holbe wrote: > Why would you like to go another way with mail servers? > Get maintainer support for such conf.d directories, maybe get upstream > support for such conf.d mimics (sendmail most likely won't need it - > some m4 magic and triggers will just do it, dunno how it is for the less > flexible ones like postfix, exim, whatever), change the depending > packages to put their config snippets in there, everything is fine. Amavis already has conf.d it's a start :) Bye -- Salvo Tomaselli signature.asc Description: This is a digitally signed message part.
Bug#583220: ITP: haskell-pango -- Binding to the Pango text rendering engine
Package: wnpp Severity: wishlist Owner: "Marco Túlio Gontijo e Silva" * Package name: haskell-pango Version : 0.11.0 Upstream Author : Axel Simon, Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the Pango text rendering engine This package provides a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . This package provides a wrapper around the Pango C library that allows high-quality rendering of Unicode text. It can be used either with Cairo to output text in PDF, PS or other documents or with Gtk+ to display text on-screen. -- 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/20100526141240.23244.35956.report...@zezinho
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Jacob Sparre Andersen wrote:
> Ludovic Brenta wrote:
>
>> Over the last two weeks I have been testing upgrades of
>> Ada packages from Lenny to Sid and Squeeze in a chroot.
>> The picture is not as pretty as it should be. In a
>> nutshell, when you change /etc/apt/sources.list from lenny
>> to squeeze (unstable, actually) and do "aptitude update",
>> you end up with a lot of broken packages and must
>> intervene manually to resolve the problem (i.e. remove the
>> broken packages, install new versions).
>
> A long-term, partial solution is to introduce a
> "build-essential-ada" package, which depends on gnat and all
> the current development packages. That would also make it
> quicker to prepare a new system for developing Ada programs.
> (As a teacher, it is a package I have missed a lot.)
OK, since there is user demand, it seems reasonable. Note that
the "build-essential-ada" package really is the "gnat" package;
a new package that brings in the whole shebang would rather be
called "complete-ada-development-environment-with-bells-and-
whistles" :)
>> In the case of libgnat{vsn,prj}4.3-dev, this is only
>> because I recently added dummy transition packages,
>> libgnat{vsn,prj}-dev in gnat-4.4 (= 4.4.4-4).
>
> Could you create such dummy transition packages for all
> development packages? (Again only a long-term solution.)
No; the whole point of the package name changes is to break
the Depends: of third-party programs before they FTBFS for
reasons mysterious to the programmer but obvious to the
Debian Ada maintainers :)
> I think a short-term solution might be to make gnat suggest
> the new versions of the development packages. (Or the
> above-mentioned transition packages?)
That seems quite reasonable but a Recommends: would be needed
to force automatic package upgrades (i.e. deletion of the old
packages and installation of new ones). The other drawback is
that it would be necessary to change the "gnat" package each
time a new -dev package appears in Debian :) I think we can
live with such a drawback for the time being.
Thanks for the feedback.
--
Ludovic Brenta.
--
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/af6b1e49e807b6fdf4d1fadd814dd...@localhost
Re: Packaging Gzstream?
Le Fri, May 21, 2010 at 10:58:05AM +0200, Adam Borowski a écrit : > On Fri, May 21, 2010 at 04:00:56PM +0900, Charles Plessy wrote: > > > > A quick apt-file search indicates that at least two other packages (CCed) > > may > > be using the gzstream library, k3d and freecad. So it seems that it would > > make sense to package the gzstream library separately. > > It appears to be just a single file less than four pages long. It does > nothing but translate zlib's API to C++ iostream API. While generally > avoiding duplicated code is a very good idea, it doesn't have to be done > with any small snippet. Heck, I've written three zlib wrappers myself (two > of them had bzip2 support as well), and it never came to me that it's a task > big enough to be worth a whole library. Since nobody contradicted Adam, I will go for the simplest way and package the software with its convenience copy of gzstream. When contacting upstream, I will nevertheless recommed them the boostiostream library. Thanks everybody for your answers, and have a nice day, -- Charles Plessy Debian Med packaging team 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/20100526141714.gc13...@kunpuu.plessy.org
Re: Let's write a system admin friendly mail server packaging system
Thomas Goirand wrote: > What happens here is that, if you take a normal Debian system, then > install postfix, then let's say amavis, they don't talk to each other. ... > much spams. It is also totally unrealistic to say that it's up to the > system administrator to configure everything by hand. If, like me, you > do at least one setup a day, it takes too much time for no reason, and > it has to be automated in some way. There are lots of examples out there where already works what you are requesting for mail servers. Let's have a look at web servers (well, apache... okay) and how they deal with it. I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Let's have a look at DHCP and how they deal with it. I'm installing dhcp3-client and my machine's network settings are configured automagically. I'm installing resolvconf and my name servers become configured automagically via DHCP. I'm installing samba and it's also getting configured automagically via DHCP. I'm installing ntp and my ntp-server is configured automagically via DHCP. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Let's have a look at SysV boot mimics and how they deal with it. I'm installing the sysvinit packages ... well, you can imagine the rest: ... There is some conf.d directory which contains config snippets for each of the packages. Why would you like to go another way with mail servers? Get maintainer support for such conf.d directories, maybe get upstream support for such conf.d mimics (sendmail most likely won't need it - some m4 magic and triggers will just do it, dunno how it is for the less flexible ones like postfix, exim, whatever), change the depending packages to put their config snippets in there, everything is fine. > argument a list of packages that it should use. But the MTA is not the > only one to modify here, for example we might have to change the listen > and relay port of dkimproxy and amavis, depending if each others are > present on the system or not. I am quite in the favor of this system, I don't think this is really necessary. It would probably be a bit more efficient to have one component forwarding the stuff it processed to the next one, but I'm sure there is a less efficient but more generic way to just bounce it back to the MTA which continues forwarding it to the next components. ... And who cares about efficiency in generic approaches. regards Mario -- who | grep -i blonde | talk; cd; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; true; gasp; umount; make clean; sleep -- 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/slrnhvqa8s.m0q.mario.ho...@darkside.dyn.samba-tng.org
Bug#583217: ITP: libconfig-mvp-reader-ini-perl -- Perl module providing a MVP config reader for .ini files
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt * Package name: libconfig-mvp-reader-ini-perl Version : 1.101450 Upstream Author : Ricardo Signes * URL : http://search.cpan.org/dist/Config-MVP-Reader-INI/ * License : Artistic or GPL-1+ (like perl) Programming Lang: Perl Description : Perl module providing a MVP config reader for .ini files Config::MVP::Reader::INI implements a reader for .ini files for use with Config::MVP. Config::MVP::Reader::INI has moved to a different distribution upstream (was included in libconfig-ini-mvp-perl before). -- 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/20100526132301.31379.64616.report...@marvin.43-1.org
Re: lilo removal in squeeze (or, "please test grub2")
On Wed, 26 May 2010 00:23:04 -0400 (EDT), Daniel Baumann wrote: > On 05/26/2010 03:36 AM, Stephen Powell wrote: >> ... >> That works for now; but if a package upgrade for extlinux is ever >> downloaded, I'm afraid that new versions of the hook scripts will >> be copied into these directories which are marked executable, and >> my hand-made configuration file will get wiped out. >> ... > > as of current git, you can now use EXTLINUX_UPDATE=false in > /etc/default/extlinux to prevent having update-extlinux do anything. That's good to know, thanks. I'm looking forward to that feature migrating into squeeze. >> Second, it is important that any script run as a hook script not >> produce any output at all to standard output. I found that out the >> hard way when I was writing my own hook scripts for use with lilo. >> That's because they run under debconf, which has redirected standard >> output for its own purposes. Thus, anything written to standard >> output is (1) never seen by the user and (2) has a good chance of >> messing up debconf, which is examining the output. The invocation >> of update-extlinux should have a redirection on it to redirect >> output to standard error. For example, >> >>update-extlinux >&2 > > none of the hooks is doing this (initramfs-tools, grub, etc), might > needs further convincing. It is a little-known requirement, and often you can get away with it, but not always. I'm going from memory here, but I believe that debconf redirects standard output, then calls the maintainer script for the kernel, which calls the run-parts utility, which then calls the hook script. If the standard output produced by the hook script matches something that debconf is looking for it can mess things up. Sometimes the failure will occur for one type of call, such as a purge, but not for another type of call, such as a configure or a remove. Manoj Srivastava, author and Debian package maintainer of the kernel-package package, mentions it in the man page for kernel-img.conf, and I have personally been burned by it with one of my own hook scripts that I wrote for use with lilo. The hook script failed with a non-zero return code, which caused the kernel installation process to fail. I could not figure out for the life of me what was wrong. The script ran fine when invoked stand-alone, but not as a hook script. Redirecting lilo output to standard error solved the problem. It ran perfectly after that. But even if the stuff written to standard output does not mess up debconf, the user still won't see it. The safe (and informative) thing to do is for all hook scripts to write all output to standard error. -- .''`. 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/375009335.66290.1274880285294.javamail.r...@md01.wow.synacor.com
Let's write a system admin friendly mail server packaging system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear everyone, 1/ Briefly, who am I My first Debian package was for the web hosting control panel (a web interface) that my company released in open source. I'm the main programmer of it. The first time I tried to have it enter in Debian, it created a huge controversy, with (I heard) a 70 post thread in -private after it got sponsored. The reason was that my package goal is to have an over-simplified system, so that the user of it doesn't have to touch anything to the system configuration, everything has to be automated (which is the goal of my app). In Debian, by policy, a package cannot touch another package's configuration file. While I believe this policy is a good one, but it prevented me from having my postinst to do a successful setup without breaking the policy. The result is that what should have been sent to the postinst of my package has then been sent to a userland script (with often, users not starting the script an complaining about it in my forum). It doesn't make this script less ugly if running in userland rather than in the maintainer scripts (it is REALLY an ugly script, and I'm quite not proud of it), but at least it respects the policy. As I am soon to become a Debian Developer (if the DAM accepts me, after my AM wrote his report), I believe it is now time to get even more involved in Debian, and try to solve that issue once and for all. Even if for a reason or another, I'm rejected (which I don't think will happen), I still want to start the below discussion. 2/ The problematic == What happens here is that, if you take a normal Debian system, then install postfix, then let's say amavis, they don't talk to each other. In the same way, if you add dkimproxy (that I maintain), or clamsmtp, or tumgreyspf (that I maintain as well), you end up with a system that is not configured at all. None of these mail server components are aware of each other, and a system administrator has to spend a great deal of time to make it work. Truth is, in today's world, it is totally unrealistic to believe that just postfix is enough for setting up a mail system. There's just too much spams. It is also totally unrealistic to say that it's up to the system administrator to configure everything by hand. If, like me, you do at least one setup a day, it takes too much time for no reason, and it has to be automated in some way. There's loads of howtos available in many places that describe in 10 pages or more how to have a successful setup. This is really a pain. This is the reason why I'm writing this today: I want to (with the help of other maintainer of the concerned packages, if they agree) change that fact. 3/ Goal description === In the ideal world, a command like this: apt-get install postfix-mysql clamav clamav-daemon clamav-freshclam spamassassin tumgreyspf would create a mail toaster with postfix and all the above apps configured correctly so that the mail system would do like this: 1- postfix gets a mail, does some basic domain checkings (domain MX existance, etc.) 2- postfix asks tumgreyspf to check for SPF and greylisting 3- (see later) 4- postfix forwards the email to amavis 5- amavis does clamav and spamassassin checks with header tagging 6- amavis forwards the email to postfix 7- postfix sends the email to maildrop for delivery Let's say now that I add dkimproxy, I would do: apt-get install dkimproxy and then the sequence would become: 3- postfix sends the email to dkimproxy for DKIM signature checkings 4- dkimproxy forwards the email to amavis I don't see any reason why it shouldn't be as easy to use as what I wrote above. The complexity of this kind of setup MUST be done on our side, and not rely on the system administrator knowledge. The above is what we currently use, but of course, this could be extended to DSPAM (I read it's better than spamassassin), clamsmtp, some milter checks, some alternative MDA, etc. And of course, this could be extended as well to other mail servers (exim4 anyone?). That's for the problematic. Now, how to achieve this, I'm not sure how to do it yet, but I have couples of ideas. 4/ Few ideas, and what I believe should happen == First thing we could do, would be a special postfix package that would have the above packages as dependency. Let's say we call it postfix-toaster, and it would have the configuration already made so that it would be already configured for using other packages. But that's not really idealistic, because of so many possibilities that we have. The second idea would be to have some kind of triggers, a bit like we have for generating the mandb and others. The trigger would ask the MTA scripts to do the reconfiguration process, for example, giving it as argument a list of packages that it should use. But the MTA is not the only one to modify here, for example we might have to change the lis
Bug#583215: ITP: haskell-cairo -- Binding to the Cairo library
Package: wnpp Severity: wishlist Owner: "Marco Túlio Gontijo e Silva" * Package name: haskell-cairo Version : 0.11.0 Upstream Author : Axel Simon, Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : BSD3 Programming Lang: Haskell Description : Binding to the Cairo library This package provides a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . Cairo is a library to render high quality vector graphics. There exist various backends that allows rendering to Gtk windows, PDF, PS, PNG and SVG documents, amongst others. -- 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/20100526124833.3990.55818.report...@zezinho
Re: RFH: bashisms in configure script
On mercredi 26 mai 2010 02:39:52 Raphael Geissert wrote: [SNIP] > > Yes, $BASH_SOMETHING is just used to make it easier to see that the > following code (probably a bashism) is only executed after checking the > shell is actually bash. That and the other FP are the most common ones, yet > not that easy to fix (the latter, of course, the former is not a FP.) > > > I'm seeing only these for gxine, xine-lib and xine-ui, which is slightly > > odd because testing with dash has shown up an actual bashism in > > xine-lib's configure.ac (which I've just fixed upstream): use of "test x > > == y". > > Could you please send me by email the files with false negatives? those are > very likely bugs in checkbashisms' quotes handling code. Among other false positive there is warning about scripts removed in clean target of debian/rules. Anyway, thanks for the massive run of checkbashism, it made me discover a few bashism in 2 upstream scripts in my packages. > > Thanks. > > Cheers, Best regards signature.asc Description: This is a digitally signed message part.
Re: The story behind UPG and umask.
On Wed, May 26, 2010 at 08:40:26AM +0100, Stephen Gran wrote: > This one time, at band camp, Steve Langasek said: > > On Tue, May 25, 2010 at 11:30:49PM +0100, Stephen Gran wrote: > > > This one time, at band camp, Michael Banck said: > > > > > > Seems worthwhile to change adduser how you suggest to me, is there > > > > a bug filed to this end? > > > > > adduser has had bugs filed in the past asking for uid to be equal to > > > gid by default, and I have so far rejected them as not worth the > > > complexity for the aesthetic pleasure of having numbers match. Is > > > there some problem with username == primary group name? > > > > pam_umask requires both username == primary group name and uid == gid > > before it will assume UPG are in place when using its 'usergroups' > > option, and I am not willing to diverge from upstream on this as this > > would mean admins coming from other systems may get an unpleasant > > surprise when they find that Debian gives a more relaxed umask than > > they were expecting in some corner cases. > > > > So either someone should convince Linux-PAM upstream to change the > > behavior of pam_umask, or adduser should enforce the same rules as > > other implementations, if pam_umask is to be involved here. Beyond > > that, I have no particular opinion on this question. > > That's the first useful argument I've heard for changing adduser's > behavior. Interoperability with other software is a useful goal, and > when I was arguing it wasn't worth the complexity, either pam_umask > didn't exist or I was unaware of it. I don't agree with the upstream or Steve here. The UID==GID mapping breaks with just one call to addgroup which gets them out of sync. UIDs and GIDs are just a convenient mapping from the actual names to numbers; so long as they are constant and unique, the actual numerical values are unimportant. For UPG, comparing the names of the user and group makes sense; comparing the UID/GID does not. While interoperability is important, this UID==GID concept is not something we have ever guaranteed and makes little sense from a security POV--the name is the only part that matters. It's akin to arguing that the index offset into a table is more important than the content at that index. We also need to consider interoperability with ourselves, and the current pam_umask is broken on Debian systems where the numbers are not in sync. I'd be interested to understand the upstream POV here--with current Debian systems, assuming UID==GID without additionally checking that the names match is horribly insecure. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#583209: ITP: haskell-smtpclient -- Simple Haskell SMTP client library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: mascell...@poisson.phc.unipi.it Package name: haskell-smtpclient Version: 1.0.2 Upstream Author: Stephen Blackheath URL: http://hackage.haskell.org/package/SMTPClient License: BSD Description: Simple Haskell SMTP client library This Haskell library is a simple SMTP client, making the task of sending an email as easy as calling a function. Rationale: it is a dependency of happstack (bug #569501). Regards, Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70) -- 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/7760e8bf9f0ba4baed83f1c20231e...@poisson.phc.unipi.it
Bug#583207: RFA: fusecompress -- transparent filesystem compression using FUSE
Package: wnpp Severity: normal I request an adopter for the fusecompress package. Overall the packaging is in pretty good shape. There are a couple of bugs (forwarded upstream) that need some love. Upstream also has support for lzma in the git repo but I have not bothered backporting that. The package description is: FuseCompress provides a mountable Linux filesystem which transparently compress its content. Files stored in this filesystem are compressed on the background and Fuse allows to create a transparent interface between compressed files and user applications. -- 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/20100526113145.15288.79161.report...@champaran.hq.netapp.com
Re: RFH: bashisms in configure script
On 26/05/10 13:14, Lucas Nussbaum wrote: > On 26/05/10 at 11:55 +0200, Emilio Pozuelo Monfort wrote: >> Right. That's exactly why I suggested debdiffing the resulting binary >> packages >> from a new and an old dash. > > Are you volunteering? :-) No. I'm not volunteering on adding LINENO support back to dash either though :-) Emilio -- 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/4bfd04a9.2070...@debian.org
Re: RFH: bashisms in configure script
On 26/05/10 at 11:55 +0200, Emilio Pozuelo Monfort wrote: > On 26/05/10 08:07, Lucas Nussbaum wrote: > > On 25/05/10 at 23:10 +0100, Neil Williams wrote: > >> 124 source packages. Bad, but not as crazy as 1,540. > >> > >> (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a > >> stretch.) > > > > No. 124 is the number of packages that failed to build. Not the number > > of source packages that silently generated incorrect binary packages. > > Right. That's exactly why I suggested debdiffing the resulting binary packages > from a new and an old dash. Are you volunteering? :-) Just debdiffing doesn't work, since some source packages generate different things by design (think of html converters that generate random identifiers for html and images). Generally, I am interested in the idea of comparing rebuild results to find problems (not only old dash vs new dash, but also current archive vs freshly rebuilt). But I don't have the time to work on that myself. - Lucas -- 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/20100526111416.ga19...@xanadu.blop.info
Re: RFH: bashisms in configure script
On 26/05/10 08:07, Lucas Nussbaum wrote: > On 25/05/10 at 23:10 +0100, Neil Williams wrote: >> 124 source packages. Bad, but not as crazy as 1,540. >> >> (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a >> stretch.) > > No. 124 is the number of packages that failed to build. Not the number > of source packages that silently generated incorrect binary packages. Right. That's exactly why I suggested debdiffing the resulting binary packages from a new and an old dash. Emilio -- 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/4bfcf029.4040...@debian.org
Re: RFH: bashisms in configure script
On Tue, May 25, 2010 at 11:55:58PM +0200, Frans Pop wrote: > For example, almost all udebs are listed. Why? Because udebs execute > busybox shell as /bin/sh, which happens to be fairly compatible with bash. The busybox /bin/sh is also a dash, but a different version than the dash package. Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 -- 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/20100526091546.ga14...@wavehammer.waldi.eu.org
Re: Translations copyrights/licences
Hello, On Tue, May 25, 2010 at 06:41:09PM +0100, Darren Salt wrote: > I demand that Helge Kreutzmann may or may not have written... > > Speaking both with my translator and my Debian Maintainer hat on, I can > > state the following: > > > a) There are lots of "drive by" translators. Systems like launchpad or > >DDTP even *encourage* this. In this case, it is most likely not > >possible at all to contact individual translators. > > > b) In structured projects (Debian, Fedora, OOo, KDE, GNOME) there are > >often language teams. In this case, translations are often > >"channeled" via the team. So if you want, you can try to collect > >the names in the copyright, but a team adress is more valuable. > > To me, this all doesn't matter so long as who changed what is recorded and I > can get (or generate) a series of diffs which I can then commit where > appropriate. If I can't, then I'm not really interested. From my experience the workflow is as follows: Either the "Last Translator" or someone else notices or becomes noticed that a translation is out of date. She then updates it (or asks on the list for an update), the translation is reviewed (more or less formally) and in the end the translation is sent to the package / upstream. Hopefully the copyright statements in the header are updated, and the "Last Translator" address is working. If the "Last Translator" actually was the last translator I'm not always sure, he might be the language coordinator or the field might simply not be up to date anymore. The German team takes both license as well as "Last Translator" seriously. So if you are in doubt, contact the mentioned translation list (which unfortunately might be out of sync as well). In essence: Take the translation and the "Last Translator" for your records as stated. There is not much more you can do if you don't want to go into the nitty gritty details of each language team. (I personally ask the submitter, however, if the headers are obviously wrong, but I don't believe this scales if you happen to have lots of translations). Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: Digital signature
Re: extlinux (was: Re: lilo removal in squeeze (or, "please test grub2"))
Bjørn Mork, le Wed 26 May 2010 10:45:49 +0200, a écrit : > Just comparing http://git.kernel.org/?p=boot/syslinux/syslinux.git with > http://bzr.savannah.gnu.org/r/grub/trunk/grub/ should IMHO give more > than enough information to choose extlinux over grub2 I don't understand what you mean here. Samuel -- 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/20100526085116.gw5...@const.bordeaux.inria.fr
extlinux (was: Re: lilo removal in squeeze (or, "please test grub2"))
Daniel Baumann writes: > as of current git, you can now use EXTLINUX_UPDATE=false in > /etc/default/extlinux to prevent having update-extlinux do anything. That's the single feature I misseded. Thanks. Although it would be even better if it was possible to include some fixed part in it, while keeping most of it auto updated. I tested the extlinux package after reading about it yesterday, and the missing feature that immediately hit me was the ability to use a serial console. This is of course as easy as with sys-/pxe-/mem-linux: just add "serial 0 9600 0" or something similar to the config file. But running update-extlinux would remove it on every kernel upgrade. Anyway, I understand that this issue is now solved. It has puzzled me for a while that grub2 has been chosen over extlinux as the default x86 bootloader, but didn't know until this discussion came up that extlinux now was packaged separately from syslinux, with the nice helper scripts. I guess we all know syslinux and pxelinux very well from Linux installation procedures over the last 15 years (for syslinux at least), and HPA has been an active upstream maintainer all this time AFAIK. This makes me very confident in extlinux. While grub2 has already bitten me too much to be considered at all on the important boxes... Just comparing http://git.kernel.org/?p=boot/syslinux/syslinux.git with http://bzr.savannah.gnu.org/r/grub/trunk/grub/ should IMHO give more than enough information to choose extlinux over grub2 Thanks a lot for packaging extlinux! Bjørn -- 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/87k4qrjbk2.fsf...@nemi.mork.no
Re: RFH: bashisms in configure script
> > This doesn't necessarily mean that we are drowned by bashisms, as some of > > those may already be fixed by Debian- provided packages or might affect > > unused code > > s/packages/patches/ Don't you think we should run the test *after* the patches got applied? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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/201005261000.58635.mes...@debian.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Ludovic Brenta wrote:
Over the last two weeks I have been testing upgrades of
Ada packages from Lenny to Sid and Squeeze in a chroot.
The picture is not as pretty as it should be. In a
nutshell, when you change /etc/apt/sources.list from lenny
to squeeze (unstable, actually) and do "aptitude update",
you end up with a lot of broken packages and must
intervene manually to resolve the problem (i.e. remove the
broken packages, install new versions).
A long-term, partial solution is to introduce a
"build-essential-ada" package, which depends on gnat and all
the current development packages. That would also make it
quicker to prepare a new system for developing Ada programs.
(As a teacher, it is a package I have missed a lot.)
In the case of libgnat{vsn,prj}4.3-dev, this is only
because I recently added dummy transition packages,
libgnat{vsn,prj}-dev in gnat-4.4 (= 4.4.4-4).
Could you create such dummy transition packages for all
development packages? (Again only a long-term solution.)
I think a short-term solution might be to make gnat suggest
the new versions of the development packages. (Or the
above-mentioned transition packages?)
Greetings,
Jacob
--
"There are only two types of data:
Data which has been backed up
Data which has not been lost - yet"
--
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.1.10.1005260705510.8...@munin.nbi.dk
Re: The story behind UPG and umask.
This one time, at band camp, Steve Langasek said: > On Tue, May 25, 2010 at 11:30:49PM +0100, Stephen Gran wrote: > > This one time, at band camp, Michael Banck said: > > > > Seems worthwhile to change adduser how you suggest to me, is there > > > a bug filed to this end? > > > adduser has had bugs filed in the past asking for uid to be equal to > > gid by default, and I have so far rejected them as not worth the > > complexity for the aesthetic pleasure of having numbers match. Is > > there some problem with username == primary group name? > > pam_umask requires both username == primary group name and uid == gid > before it will assume UPG are in place when using its 'usergroups' > option, and I am not willing to diverge from upstream on this as this > would mean admins coming from other systems may get an unpleasant > surprise when they find that Debian gives a more relaxed umask than > they were expecting in some corner cases. > > So either someone should convince Linux-PAM upstream to change the > behavior of pam_umask, or adduser should enforce the same rules as > other implementations, if pam_umask is to be involved here. Beyond > that, I have no particular opinion on this question. That's the first useful argument I've heard for changing adduser's behavior. Interoperability with other software is a useful goal, and when I was arguing it wasn't worth the complexity, either pam_umask didn't exist or I was unaware of it. I'll try to get this change into squeeze. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
