Re: leftover /usr/X11R6 references
Twas brillig at 03:00:27 21.11.2009 UTC+01 when ni...@debian.org did gyre and gimble: >> There are probably more references total than can be sensibly removed, >> but perhaps it would be worth adding some targeted lintian checks to warn >> about >> uses in places, like libraries, where it probably indicates the library is >> doing unnecessary work of including the directory in a search path? MČ> Is this really worth of diversion from upstream? It worth reporting to upstream and sending patches. -- http://fossarchy.blogspot.com/ pgp2yPnpBTIog.pgp Description: PGP signature
Re: leftover /usr/X11R6 references
Hi Dne Sat, 21 Nov 2009 15:10:54 +0600 Mikhail Gusarov napsal(a): > > Twas brillig at 03:00:27 21.11.2009 UTC+01 when ni...@debian.org did gyre and > gimble: > > >> There are probably more references total than can be sensibly removed, > >> but perhaps it would be worth adding some targeted lintian checks to warn > about > >> uses in places, like libraries, where it probably indicates the library is > >> doing unnecessary work of including the directory in a search path? > > MČ> Is this really worth of diversion from upstream? > > It worth reporting to upstream and sending patches. Is really /usr/X11R6 deprecated everywhere? I'm afraid it's just FHS. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: leftover /usr/X11R6 references
Quoting "Michal Čihař" : Hi Dne Sat, 21 Nov 2009 15:10:54 +0600 Mikhail Gusarov napsal(a): Twas brillig at 03:00:27 21.11.2009 UTC+01 when ni...@debian.org did gyre and gimble: >> There are probably more references total than can be sensibly removed, >> but perhaps it would be worth adding some targeted lintian checks to warn about >> uses in places, like libraries, where it probably indicates the library is >> doing unnecessary work of including the directory in a search path? MČ> Is this really worth of diversion from upstream? It worth reporting to upstream and sending patches. Is really /usr/X11R6 deprecated everywhere? I'm afraid it's just FHS. it is FHS, but it is optional. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: possible MBF about Policy 8.2 (Shared library support files)
Steve Langasek writes: > On Thu, Nov 19, 2009 at 05:41:11AM +0100, Goswin von Brederlow wrote: >> >> I detected 1063 possible violations with some percentage of false >> >> positives. Since those are too many to go through by hand I filtered a >> >> bit for the location of the violating files: > >> >> /etc/ : 137 packages >> >> /bin/ or /usr/bin : 285 packages >> >> /sbin/ or /usr/sbin/: 47 packages > >> >> Still too many for one go and a huge overlap between the 3 cases so I >> >> picked just packages that contained a shared library (as witnessed by >> >> a shlibs file in the control.tar.gz) and files in /etc/. I considered >> >> any file in /etc/ that does not contain a version in its path or name >> >> that would make it distinct from a future SOVERSION in violation of >> >> 8.2. I (hopefully) removed all false positives (leaving 126 packages). > >> This is true. On its own none of them are a policy violation if you >> want to nit-pick. Only when a new SONAME is uploaded with the same >> files is the policy really violated. > >> For that I have 2 things to consider: > >> 1) How sure are you the SONAME never changes? How sure are you the >> file will be obsolete in the next SONAME? How sure are you that you >> will remember to rename all files on a SONAME change? If there is even >> the slightest doubt the name should be changed now to a safe name so >> the package is prepared for all eventualities. > >> With a verry few exceptions (like libc6) the risk of a future >> collision is just to big. If that means you have to add a version to >> the conffile or split the package now instead of in a year or two that >> is regrettable but something I hope can be lived with. > > In the case of certain libraries: *very* sure. If you aren't sure which > ones are sure, then I think a mass bugfiling is premature. I have no way of knowing which sources will be sure to never change the soname. That is something maintainer might and upstream should know. My best guess would be to check if the soname already changed once. But that would still catch e.g. libc6, which we assume won't change again. If anyone can suggest something better please speak up. >> 2) Multiarch (are you hating that word yet?) is a release goal for squeeze > >> With multiarch the library should be installable for multiple >> architectures so that (different) binaries from multiple architectures >> that depend on it can be installed. E.g. /usr/bin/bar and /usr/bin/baz >> both depending on libfoo. > >> If libfoo contains conffiles then they will give a file collision in >> dpkg preventing the installation of more than one architecture. Having >> the conffile in libfoo-common (Arch: all) avoids that. Using the arch >> tripplet in the path or name avoids it too but should be only used >> when conffiles are architecture specific. > > The present aim for dpkg multiarch support in squeeze is to allow reference > counting of conffiles provided by multiarch packages, precisely so that we > don't have to have gratuitous splits of packages for conffiles that can > reasonably be shared between the libraries on multiple architectures. > Furthermore, in the event that a conffile *can't* reasonably be shared > between architectures, it's at least as appropriate for the path of the > conffile to be qualified with the *architecture*, *instead of* with the > version. The multiarch specs are unclear on this: | Debian/Ubuntu policy already states that files whose names do not | change with each soname change should not be included in the | shared library package; so in general it is already wrong to ship | config files and data files in a shared library package, though | the practical impact of this varies. (For instance, the soname of | glibc is not expected to change any time in the future, so the | libc6 package currently unapologetically ships helper binaries, | config files, and man pages in the shared library package.) | However, /usr/share/doc/ is expected to be provided by | every package installed on the system, so a general solution is | needed for multiarch packages that must be co-installable while | shipping architecture-independent files. This can easily be read that only for /usr/share/doc/ a general solution is to be provided. (And the libc6 example is partially outdated) It goes on: | In addition, dpkg will implement an internal checksum database | for files it installs, and reference counting for files shared by | multiarch packages. Multiarch packages with differing versions of | any file will also be treated as declaring reciprocal Breaks. This can be read that a package of one arch can never have a file conflict with the same of another arch. Any overwrite errors will just be reference counted. I would not want /usr/bin/foo reference counted if it is contained in libfoo and I would hope only identical files will be allowed. So please clarify this in the specs. What files are
Re: ITP: mercurial-buildpackage (for those who care about Mercurial)
2009/11/21 Goswin von Brederlow : > Jens Peter Secher writes: >> As I see it, there is no need for using Mercurial Queues (mq) with >> mercurial-buildpackage because dpkg-source format "3.0 (quilt)" has >> the same purpose as mq, namely to wrap around quilt to achieve >> automatic patch handling. > > Not quite. The Mecurial Queues are under version control. That means > I can check out last months patch series, bisect changes, see who > changed what when and so on. Hmm, the debian/patches/ are also under version control. I am afraid I still do not see a real difference... > All in a way mercurial users are use to. ...except for the above (assuming Mercurial really are used to MQ). > > That means people have to use quilt and mercurial. With mercurisl > queues you would have only mercurial and the quilt part is hidden. > > I'm not saying mercurial queues should be forced onto the user but I > think it would be nice to support them. Sure, but I do not know how to do that at the moment. :-) > > pristine-tar does not put the tarball into the repository. It only > stores the delta between taring up the upstream branch and the actual > upstream orig.tar.gz. That way you can clone a repository and build > without first having to go hunting around for the orig.tar.gz. > > Please look at it and look how git-buildpackage uses pristine-tar. Heh, I started implementing support for pristine tarballs yesterday, but now I realise that pristine-tar is a package. Well, that makes things a lot easier. I will incorporate it. Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITP: mercurial-buildpackage (for those who care about Mercurial)
Jens Peter Secher writes: > 2009/11/21 Goswin von Brederlow : >> pristine-tar does not put the tarball into the repository. It only >> stores the delta between taring up the upstream branch and the actual >> upstream orig.tar.gz. That way you can clone a repository and build >> without first having to go hunting around for the orig.tar.gz. >> >> Please look at it and look how git-buildpackage uses pristine-tar. > > Heh, I started implementing support for pristine tarballs yesterday, > but now I realise that pristine-tar is a package. Well, that makes > things a lot easier. I will incorporate it. > > Cheers, Hehe, it sure does. Didn't mean you should invent the wheel again. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFH: fluxbox -- Highly configurable and low resource X11 Window manager
Hi, I would like to help fluxbox as I do have some experience in writing code and developing applications in various languages etc. Could you give me some pointers to hit on or any good/easy hacks you use? Sincerely , Andreas Marschke. On Sunday 25 October 2009 16:22:53 Dmitry E. Oboukhov wrote: > Package: wnpp > Severity: normal > > Unfortunately, now I do not have enough time to maintain this package > properly, so help/comaintain would be appreciated. > > I adopted fluxbox when it had more than 120 bugs. Now it has 34 bugs, > i think that the most part of them (or of the last of them) is > unreproducible. But I couldn't find time to separate/fix its. > > If anybody wants we also could create pkg-fluxbox team :) > > -- > ... mpd is off > > . ''`. Dmitry E. Oboukhov > > : :’ : email: un...@debian.org jabber://un...@uvw.ru > > `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 > `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITP: mercurial-buildpackage (for those who care about Mercurial)
I demand that Jens Peter Secher may or may not have written...
> 2009/11/21 Goswin von Brederlow :
>> Jens Peter Secher writes:
>>> As I see it, there is no need for using Mercurial Queues (mq) with
>>> mercurial-buildpackage because dpkg-source format "3.0 (quilt)" has
>>> the same purpose as mq, namely to wrap around quilt to achieve
>>> automatic patch handling.
>> Not quite. The Mecurial Queues are under version control. [...]
*May* be under version control. If so, it's a separate repository; and if you
want it to be public, you have to push it separately (I don't see equivalents
of 'push', 'pull', 'in' and 'out' there short of using --cwd).
[snip]
> Hmm, the debian/patches/ are also under version control.
That directory *will* be, yes.
> I am afraid I still do not see a real difference...
It looks like something like the following will work:
* make .hg/patches a symlink to debian/patches;
* add debian/patches/status and debian/patches/guards to .hgignore;
* require that .hg/patches/series is quilt-compatible (no guards);
* require that .hg/patches/guards is empty or non-existent;
* deapply patches at build time ("hg qpop --all"; abort build on failure).
(No, I don't have a patch for this.)
>> All in a way mercurial users are use to.
> ...except for the above (assuming Mercurial really are used to MQ).
I've made some use of that where I use mercurial; better that than quilt,
given the integration into mercurial.
>> That means people have to use quilt and mercurial. With mercurisl
>> queues you would have only mercurial and the quilt part is hidden.
Agreed.
>> I'm not saying mercurial queues should be forced onto the user but I
>> think it would be nice to support them.
I'm not sure that quilt should be forced onto the user unless it's properly
integrated into the VCS; and where the VCS has its own patch queue
management, that should be preferred.
> Sure, but I do not know how to do that at the moment. :-)
See above (probably). :-)
[snip]
--
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | Army
| + http://wiki.debian.org/DebianEeePC/
Happiness adds and multiplies as we divide it with others.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Hi! Some few comments. * Raphael Hertzog [2009-11-21 16:54:36 CET]: > * even if you don't have any upstream patch right now, next time that >someone must NMU your package, they can cleanly add a patch (with a >proper DEP-3 header) without having to modify the build system This is nothing new for the 3.0 (quilt) format, this is a reason for any patch system format, so this feels a bit like false-advertising, sorry. Don't get me wrong, I use quilt where I have to touch upstream sources myself and totally like it, I just don't see the need to use this as advertising for the 3.0 format because that doesn't buy you much more in that respect. > * in the long run it's best to standardize on a single patch system (new >contributors need to learn a single system, more people can help you, >etc.) and quilt appears to be that patch system. That part feels also a bit strange - I don't think it should be the decision of the dpkg team to force people to use a specific patch system. Again, I use quilt myself. Though, Debian (and free software in general) always was about choice. And yes, I know, there's 3.0 (native), but that wasn't mentioned. > When you switch to "3.0 (quilt)", there are other changes that you might > want to do: > * You can remove everything related to quilt in debian/rules >(patch/unpatch logic, cleanup of quilt stamp file and its .pc >directory). Unfortunately, I can't follow that "can remove". It sounds like it would work if you keep it in. Unfortunately that's not the case. Please take a look at the build logs for wesnoth 1:1.7.8-1. The story is easy: -) The buildd does a debian/rules clean. -) quilt doesn't find any applied patches (because dpkg doesn't create the .pc/ directory structure) -) The buildd then starts with the building. -) quilt likes to apply the patches and failes because they already *are* applied but quilt doesn't know about it. So pretty please, change that "can remove" into a "MUST remove", otherwise you will stumble into problems. > === Does a 3.0 (quilt) source package need to build-depend on quilt? === > > If you drop the quilt usage in debian/rules (patch/unpatch logic), then no. You *HAVE* to drop the quilt usage in debian/rules, otherwise it will fail. So long, and thanks for the work involved, but this minor issues should still be addressed, in one way or the other. :) *waves* Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Hi, On Sat, 21 Nov 2009, Gerfried Fuchs wrote: > * Raphael Hertzog [2009-11-21 16:54:36 CET]: > > * even if you don't have any upstream patch right now, next time that > >someone must NMU your package, they can cleanly add a patch (with a > >proper DEP-3 header) without having to modify the build system > > This is nothing new for the 3.0 (quilt) format, this is a reason for > any patch system format, so this feels a bit like false-advertising, > sorry. Currently a package without a patch system needs heavy modifications in debian/rules to setup the patch system. So when you want to add a patch in debian/patches and not in the .diff.gz, you have to choose a patch system in place of the maintainer. With 3.0 (quilt), you don't need to do any such modification... the patch system is already available even if not used. That's what this point means. > > * in the long run it's best to standardize on a single patch system (new > >contributors need to learn a single system, more people can help you, > >etc.) and quilt appears to be that patch system. > > That part feels also a bit strange - I don't think it should be the > decision of the dpkg team to force people to use a specific patch > system. We're not forcing anyone, we make it easier for people to use that patch system and we explain why we think it's a wise choice to consider quilt as the default patch system to use when you don't have any specific reason to pick one over the other. > > * You can remove everything related to quilt in debian/rules > >(patch/unpatch logic, cleanup of quilt stamp file and its .pc > >directory). > > Unfortunately, I can't follow that "can remove". It sounds like it > would work if you keep it in. In general it should work, but you're right that we have a problem here with the buildds running an old version of sbuild (there are still many buildd in that situation) because they do "dpkg-source -x" outside of the buildd chroot where quilt is not installed even if you added quilt in your build-depends. AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is installed due to build-depends and the .pc directory is then created at unpack time. > -) quilt doesn't find any applied patches (because dpkg doesn't create > the .pc/ directory structure) dpkg-source -x uses quilt if it's installed, so if it's here the .pc structure is created. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog wrote: > Currently a package without a patch system needs heavy modifications in > debian/rules to setup the patch system. So when you want to add a patch in > debian/patches and not in the .diff.gz, you have to choose a patch system > in place of the maintainer. If there is no patch system when you are NMUing, why would you want to add one ? > We're not forcing anyone, we make it easier for people to use that patch > system and we explain why we think it's a wise choice to consider quilt > as the default patch system to use when you don't have any specific reason > to pick one over the other. Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0 (native), which kind of suggests 3.0 (quilt) is being forced down. That's maybe not what you are thinking, but it's how it feels. > In general it should work, but you're right that we have a problem > here with the buildds running an old version of sbuild (there are still > many buildd in that situation) because they do "dpkg-source -x" outside > of the buildd chroot where quilt is not installed even if you added > quilt in your build-depends. > > AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is > installed due to build-depends and the .pc directory is then created > at unpack time. OTOH, "dpkg-source -x" should result in the same tree (including the .pc directory), whatever the status of quilt installation is on the system. Or if that is not possible without quilt, then dpkg-dev should depend on quilt. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
* Raphael Hertzog [2009-11-21 20:51:51 CET]: > Hi, > > On Sat, 21 Nov 2009, Gerfried Fuchs wrote: > > * Raphael Hertzog [2009-11-21 16:54:36 CET]: > > > * even if you don't have any upstream patch right now, next time that > > >someone must NMU your package, they can cleanly add a patch (with a > > >proper DEP-3 header) without having to modify the build system > > > > This is nothing new for the 3.0 (quilt) format, this is a reason for > > any patch system format, so this feels a bit like false-advertising, > > sorry. > > Currently a package without a patch system needs heavy modifications in > debian/rules to setup the patch system. So when you want to add a patch in > debian/patches and not in the .diff.gz, you have to choose a patch system > in place of the maintainer. Heavy modification? What's so heavy on three entries there? include /usr/share/quilt/quilt.make clean: [...] unpatch build-stamp: patch Sorry, but these additions are next to nowhere "heavy modifications", that's a bit over overrating, to say the least. > With 3.0 (quilt), you don't need to do any such modification... the patch > system is already available even if not used. That's what this point > means. The modifications are implied, but it means that the source format is already this "heavy modification", on a similarly heavy modification scale. Additionally, if someone wants to sepearte the patches into feature-patches instead of one-modification-patch-per-upload they will have to additionally pull in quilt anyway to work on it properly, without having it implied through the build-depends and being guided in the right direction through README.Source. > In general it should work, but you're right that we have a problem > here with the buildds running an old version of sbuild (there are still > many buildd in that situation) because they do "dpkg-source -x" outside > of the buildd chroot where quilt is not installed even if you added > quilt in your build-depends. > > AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is > installed due to build-depends and the .pc directory is then created > at unpack time. > > > -) quilt doesn't find any applied patches (because dpkg doesn't create > > the .pc/ directory structure) > > dpkg-source -x uses quilt if it's installed, so if it's here the .pc > structure is created. Alright, thanks for explaining the issue - so for the time, what do you suggest? Remove the quilt handling? Actually ignore the error that quilt gives (like you suggested on IRC)? Or wait until the sbuild fix is applied everywhere? Thanks, Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sa, 21 Nov 2009, Gerfried Fuchs wrote: > Heavy modification? What's so heavy on three entries there? > > include /usr/share/quilt/quilt.make > > clean: > [...] > unpatch > > build-stamp: patch Besides that that snippet is broken? It made me nuts that quilt people are changing that snippet and breaking many packages, like all of mine. It should be: build-stamp: $(QUILT_STAMPFN) ... and as far as I see: clean: unpatch DOn't get me wrong, I am already using quilt, but the interface with quilt.make should not change (again, hopefully). Best wishes Norbert --- Dr. Norbert PreiningAssociate Professor JAIST Japan Advanced Institute of Science and Technology prein...@jaist.ac.jp Vienna University of Technology prein...@logic.at Debian Developer (Debian TeX Task Force)prein...@debian.org gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- ABERBEEG (vb.) Of amateur actors, to adopt a Mexican accent when called upon to play any variety of foreigner (except Pakistanis - from whom a Welsh accent is considered sufficient). --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: nexuiz-data does not fit on a single CD
]] Mike Hommey | On Fri, Nov 20, 2009 at 01:33:29PM -0200, Gustavo Noronha Silva wrote: | > On Fri, 2009-11-20 at 15:23 +0100, Bernd Zeimetz wrote: | > > Ack. People which use computers which did not came with a DVD reader built in | > > are probably not able to play nexuiz anyway as it needs a pretty fastCPU and | > > graphics card to be fun :) | > | > Well, you see, my current computer (Lenovo x200s) does not have an | > optical drive at all. I had to install Debian using an usb stick. It | > does have a fast enough CPU and graphics card to play nexuiz though, | > mind you. | > | > My point is that the fact that our packages are showing the age of the | > media we still want to support should not be a bug. | | It surely is a bug for those who care about CDs. But Zack's point is: | should it be RC, normal, minor, or wontfix ? I disagree with it being a bug in the package; if the data needs to be so big because of quality of textures or number of levels or whatever, that's just how the world is. It's not like it's a bug in linux-image-2.6.31-1-amd64 that it doesn't fit on a 16MB USB stick, which is a similar case albeit with a scale difference. -- 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
Bug#557430: ITP: gummi -- simple latex editor written in Python/PyGTK
Package: wnpp Severity: wishlist Owner: Cristian Greco * Package name: gummi Version : 0.4.2 Upstream Author : Alexander van der Mey * URL : http://gummi.midnightcoding.org * License : MIT Programming Lang: Python Description : simple latex editor written in Python/PyGTK Gummi is a LaTeX editor written in the Python programming language using the PyGTK interface toolkit. It was designed with simplicity and the novice user in mind, but also offers features that speak to the more advanced user. Gummi is still under active development and is released under the open-source MIT license. Thanks, -- Cristian Greco GPG key ID: 0xCF4D32E4 (old: 0x0C095825) signature.asc Description: PGP signature
Bug#557431: general: there is no package to install all POSIX utilities at once
Package: general Severity: wishlist Currently no package exists that would allow installation of all utilities specified by the POSIX `Shell and utilities' volume: http://www.opengroup.org/onlinepubs/9699919799/idx/utilities.html It is considered useful to have such a package, and one such package was actually created: https://edge.launchpad.net/~codedot/+archive/ppa/+sourcepub/870564/+listing-archive-extra This bug is to suggest inclusion of this or a similar package into Debian operating system. -- System Information: Debian Release: squeeze/sid APT prefers karmic-updates APT policy: (500, 'karmic-updates'), (500, 'karmic-security'), (500, 'karmic-proposed'), (500, 'karmic-backports'), (500, 'karmic') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-15-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#557431: general: there is no package to install all POSIX utilities at once
On Sun, Nov 22, 2009 at 03:41:39AM +0200, Dmitri Vorobiev wrote: > Currently no package exists that would allow installation of all > utilities specified by the POSIX `Shell and utilities' volume: > > http://www.opengroup.org/onlinepubs/9699919799/idx/utilities.html > > It is considered useful to have such a package, and one such > package was actually created: > > https://edge.launchpad.net/~codedot/+archive/ppa/+sourcepub/870564/+listing-archive-extra > > This bug is to suggest inclusion of this or a similar package > into Debian operating system. Such a package would be of little use since by default, these utilities are not POSIX-compliant. For example, patch is not POSIX-compliant by default and most patch systems rely on this non-POSIX behavior. Debian does not have a POSIX-compliant vi, since none of the implementations have open mode. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: New source package formats now available
Gerfried Fuchs writes: > Hi! > > Some few comments. > > * Raphael Hertzog [2009-11-21 16:54:36 CET]: >> * even if you don't have any upstream patch right now, next time that >>someone must NMU your package, they can cleanly add a patch (with a >>proper DEP-3 header) without having to modify the build system > > This is nothing new for the 3.0 (quilt) format, this is a reason for > any patch system format, so this feels a bit like false-advertising, > sorry. Don't get me wrong, I use quilt where I have to touch upstream > sources myself and totally like it, I just don't see the need to use > this as advertising for the 3.0 format because that doesn't buy you much > more in that respect. The BIG difference is that you (as NMUer) can just apt-get source foo cd foo*/ dch -i $EDITOR file debuild and a new patch will be created automatically. You work on the source as if there is no patch system involved and it will do the right thing. If you do happen to know about quilt and the package already has patches you can take advantage of quilt features. You can edit patches or annotate files to find the guilty patch and so on. But if you don't know or don't like quilt you can also totaly ignore it. So what you get is a free (as in nothing needs to be in debian/rules or Build-Depends) patch system that is also free to anyone using the source. There is no required learning curve. >> * in the long run it's best to standardize on a single patch system (new >>contributors need to learn a single system, more people can help you, >>etc.) and quilt appears to be that patch system. > > That part feels also a bit strange - I don't think it should be the > decision of the dpkg team to force people to use a specific patch > system. Again, I use quilt myself. Though, Debian (and free software in > general) always was about choice. And yes, I know, there's 3.0 (native), > but that wasn't mentioned. And the choice is still there. As you say yourself there is 3.0 (native) even if it wasn't advertized. Also things like topgit can be used and the resulting source package can still use 3.0 (quilt) format. That will allow for the maintainer to use his/her favourite environment while everybody else still has to option to use the resulting source package with or even without quilt. Again, no learning curve to modify the source. Maybe think of 3.0 (quilt) more as an interchange format of debian patches. >> When you switch to "3.0 (quilt)", there are other changes that you might >> want to do: addressed in other mails MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sun, Nov 22, 2009 at 01:16:47AM +0100, Norbert Preining wrote: > Besides that that snippet is broken? It made me nuts that quilt people > are changing that snippet and breaking many packages, like all of mine. > It should be: > build-stamp: $(QUILT_STAMPFN) > ... > and as far as I see: > clean: unpatch Well, the latter is wrong - this breaks if you're patching the build system. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
