Re: extlinux
26.05.2010 22:32, Daniel Baumann wrote: [] 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. Thank you Daniel for doing that. I use extlinux for several years already, but never bothered submitting my local scripts for doing the same. And now yours are superior anyway :) Just one question: why /boot/extlinux/ ? Why can't it be placed directly to /boot, so that all kernel images may be referenced using relative paths? Thanks! /mjt -- 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/4bfe1713.5010...@msgid.tls.msk.ru
Re: Recent changes in dpkg
On Thu, 27 May 2010 06:11:36 + (UTC) Philipp Kern wrote: > 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. The lack of debian/source/format should be a de facto declaration of source format 1.0. > >> 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 dpkg should not abort - that will cause a FTBFS through no fault of the package. First thing dpkg-buildpackage does is pack up the unpacked source. The archive is regularly rebuilt from the existing source packages; dpkg must not change the behaviour in a way that breaks such rebuilds. Let's not get into making that a special case, there are lots of situations where third parties need to rebuild packages outside Debian and there can be no justification for making such rebuilds impossible merely for the convenience of dpkg. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpTysZGamMNu.pgp Description: PGP signature
Re: Recent changes in dpkg
On 2010-05-27, Neil Williams wrote: >> 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. People, calm down. It's "failed to build from source", which implies there is a source package already. It won't fail on unpack to cause FTBFS, it might fail when preparing the source upload. From the infrastructure side I'm ok with that, TBH. (Iff there are valid reasons for it, that is. But I guess we already determined that automatic detection of various things isn't always the best choice. Making 1.0 non-native and 1.0 native explicit wouldn't sound too wrong. :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/slrnhvs6e3.kdb.tr...@kelgar.0x539.de
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 07:54:03AM +0100, Neil Williams wrote: > On Wed, 26 May 2010 23:44:52 +0200 > Iustin Pop wrote: > > > 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. Data packages are a good point, to which I reply: how will they take advantages of new compression formats? > 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. To users? Probably not. But to fellow developers? Do those packages already have Vcs-* fields so that I can retrieve them easily with debcheckout? Do the patches already come in DEP-3 format, so that tracking where they originate is easy for automated tools? I agree that we don't *have* to update the packages. All I'm saying, to me it seems that the world of packaging standards is not sitting, and not doing an update once per release seems a bit (just a bit) strange to me. But I understand your point, and I'm not saying it is a wrong point. Just trying to express why I believe doing a rebuild per release helps more than hurts. regards, iustin signature.asc Description: Digital signature
Re: extlinux
On 05/27/2010 08:54 AM, Michael Tokarev wrote: > Just one question: why /boot/extlinux/ ? Why can't it be > placed directly to /boot, so that all kernel images may be > referenced using relative paths? there's more than one file used for the config, so putting them into an own directory is better to not clutter /boot with several .conf files. additionally, if ftp-masters ever happen to process syslinux-themes-debian in NEW, we would have a nice graphical menu for extlinux (and for syslinux/pxelinux etc.). having those in /boot is kind of a requirement, and having those in /boot too would be seriously unreasonable, but having the activated theme in /boot/extlinux/theme/ is. Hope that explains it, feel free to if you want more information. Regards, Daniel -- 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/4bfe1b9e.1040...@debian.org
Re: Recent changes in dpkg
Neil, am Thu, May 27, 2010 at 08:04:25AM +0100 hast du folgendes geschrieben: > dpkg should not abort - that will cause a FTBFS through no fault of the > package. First thing dpkg-buildpackage does is pack up the unpacked > source. no, it does not for '-B', which is what our infrastructure uses. Even when we build arch:all also this doesn't repack the source package neither, which is what I wanted to say with my last mail. Ciao 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/20100527072735.gb21...@kelgar.0x539.de
Bug#583335: ITP: python-django-photologue -- Powerful image management for the Django web framework
Package: wnpp Severity: wishlist Owner: Ihor Kaharlichenko * Package name: python-django-photologue Version : 2.2 Upstream Author : Justin Driscoll * URL : http://code.google.com/p/django-photologue/ * License : BSD Programming Lang: Python Description : Powerful image management for the Django web framework Photologue is a reusable Django application that provides powerful image management and manipulation functionality as well as a complete photo gallery solution. Photologue embraces the Django admin and smoothly integrates with photo thumbnails and effect previews. -- 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/20100527073057.9256.37484.report...@localdomain.localhost
Re: Recent changes in dpkg
On Thu, 27 May 2010 09:12:24 +0200 Iustin Pop wrote: > Data packages are a good point, to which I reply: how will they take > advantages of new compression formats? No need - just because these are data packages doesn't mean they are even tens of kilobytes in size. These are source packages, not data binary packages split out from other compiled binaries. A new compression format won't save more than a few bytes on a small data package - why bother? We cannot restrict ourselves to only the .deb files in Debian. There are plenty of situations where the .deb format is used to package a specific configuration tweak or a little snippet of data. In many cases, the contents vary slightly across lots of different use cases, so the source builds dozens of tiny data packages and the devices pick and choose which configurations to support. Think along the lines of xorg-xserver-video-* where you don't want -all, you want specific devices to cherry-pick only the drivers that are needed for that specific chipset. The packages themselves are tiny but there are a LOT of them. You don't want to rebuild and reupload dozens and dozens merely to add debian/source/format to every single one. You also cannot allow every device to install every variant, even if you remove most later, because of all the unwanted dependencies. > > 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. > > To users? Probably not. But to fellow developers? Do those packages > already have Vcs-* fields so that I can retrieve them easily with > debcheckout? Do the patches already come in DEP-3 format, so that > tracking where they originate is easy for automated tools? Some have no VCS - they are downloaded from CPAN or are my own upstream, I have the debian/ directory on my own systems and that's all that's needed. There are no patches (especially when I am upstream). There really are packages out there which are so simple and trivial to package that the enhancements in Debian packaging methods since Etch have no benefit to anyone, including other DD's. Again, this is also applicable to uses of .deb outside Debian where thinks like VCS- and DEP3 are meaningless, even lintian is ignored. Emdebian automatically drops all VCS- fields, indeed all debian/control fields which are absolutely mandatory to get the package accepted into a random reprepro archive. We cannot go around assuming that everyone using dpkg is only using it within the confines of Debian Policy, let alone "Debian Best Practice". Why do we assume that every package should automatically use the latest whizz-bang-feature merely because that feature exists? Some packages do not need a VCS of any kind and some never need patches or even debhelper >> 5. .deb is a useful format in it's own right - Debian should not make changes that undermine the usefulness of .deb outside Debian, if only because it undermines the maintenance of some packages within Debian where packaging life really is that simple. > I agree that we don't *have* to update the packages. All I'm saying, to > me it seems that the world of packaging standards is not sitting, and > not doing an update once per release seems a bit (just a bit) strange to > me. Not to me. One release to last from oldstable to unstable is actually very appealing, for packages where life is sufficiently simple. One day, I might even get a package where it gets into oldstable at the very first upload. > But I understand your point, and I'm not saying it is a wrong point. > Just trying to express why I believe doing a rebuild per release helps > more than hurts. I think you're seeing complexity where none exists. I have some very simple packages and I like them like that. :-) Changing the packaging merely because the maintainer is "bored" of using debhelper 5 etc. is just sad. (I remember someone in the Debian release team - at the time, no names but he knows who he is - saying that DD's should consider every upload to unstable to be the version that will get into stable.) -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpDQ0ZaBmpag.pgp Description: PGP signature
Re: lilo removal in squeeze (or, "please test grub2")
In gmane.linux.debian.devel.general Stephen Powell wrote: > But like lilo it stays out of unallocated (and therefore not backed up) > sectors. The boot block of extlinux is installed in the boot sector > of a partition, and the second stage loader occupies a file within the > partition. It does not use the master boot record. It relies on a > master boot record program to chain load it from the partition boot > sector. (I use the mbr package for that.) BTW, you can install grub exactly the same way. I usually do this because I absolutely don't like the idea to install something as important as a boot loader into unallocated sectors. Just do "grub-install /dev/sda1" and Grub will adapt its installation procedure accordingly. It's a pity that this isn't documented more prominently... Martin -- 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/htl90g$hu...@dough.gmane.org
Re: Recent changes in dpkg
Hi, On Wed, 26 May 2010, Bernd Zeimetz wrote: > > * 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? I'm sorry I don't understand you. When Frank merged the initial change from Ubuntu it created lot of concerns that dpkg-buildpackage was not the right place to set such default values because calling debian/rules directly would not have them. For various reasons the discussion stalled and it's only way later that I restarted the discussion to find a solution that suits everybody. Following that discussion, we decided to build this new interface that packages must explicitly call (much like they call dpkg-architecture) to retrieve the default values. Until most packages have been converted to use this new interface, dpkg-buildpackage will continue to export the environment variables but it gets the values exported ouf of dpkg-buildflags. > > * 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 Yeah! You managed to start yet another useless thread on the topic. My sole response will be this one. Yes, we're starting a long-term migration that will require every package to be modified. The reasons are that the dpkg maintainers consider the format 1.0 to no longer be a desirable default for dpkg-source given the availability of improved formats. We also acknowledge the fact that there's no longer a single format that suits all cases and as such we want the maintainer to be explicit about the choice they make. No, we won't break packages, it's a migration and dpkg-source will be switched only when all packages have been modified. There are warnings in place both in dpkg-source and in lintian. We are fully aware that it will take very long and README.feature-removal-schedule of dpkg says this: What: fallback of dpkg-source to source format "1.0" without explicit debian/source/format Status: deprecated When: 1.17.x Warning: program and lintian (missing-debian-source-format) Why: With the support of multiple source formats, the user should be explicit about the desired source format. The fallback to "1.0" is there only for backwards compatiblity but will be removed once all packages have the debian/source/format file. This is unlikely to happen before 1.17.x. And 1.17.x means squeeze+2. And at that time, 1.0 will still be supported, it's just that it won't be assumed if debian/source/format is absent. > 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. Testing requires binary packages only. Use "dpkg-buildpackage -b" and it will work even without any upstream tarball. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100527080551.gd11...@rivendell
Re: SRWare Iron: Chromium without the data-mining
Le mercredi 26 mai 2010 à 23:19 +0200, Tollef Fog Heen a écrit : > 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. I guess you can change that by building your own GTK+ key theme. Cheers, -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1274949653.16173.0.ca...@meh
Re: Recent changes in dpkg
On 05/26/2010 11:07 PM, Ben Hutchings wrote:
> Environment variables do not override variable definitions in a makefile.
You can't believe how messy upstream stuff can be. Messing with $(LDFLAGS) and
$${LDFLAGS} and simmilar stuff just happens
--
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/4bfe3965.4020...@bzed.de
Re: Recent changes in dpkg
Hi! * Philipp Kern [2010-05-27 08:11:36 CEST]: | 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. Why is that needed? It always was explicit that 1.0 is meant, what's the need for the change? | Now I think the maintainers did outline why they want that in the past. :P Why they want it unfortunately is a wrong reasoning - the actual pending and still unanswered question is "why it is needed". They want people to switch to 3.0. By forcing to put something into debian/source/format people start putting 1.0 in there for no gain. I still fail to have received any real answer why debian/source/format "1.0" containing is better than no debian/source directory at all. Making it mandatory does break existing behavior, even though I was told that it won't happen "before all packages do have it". Fortunately, there isn't only packages in our pool, so that point will never be reached, and forcing people to put it in there out of principle with no actual outlined reason on *why* doesn't help. Thanks, Rhonda -- 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/20100527092602.ga28...@anguilla.debian.or.at
correctly using other packages in postrm
Hi, piuparts has discovered a problem with one of my packages [1] and while analyzing it, Holger and I came to the result, that piuparts *may* be working wrong here - it removes the depends before purging my (the tested) package. Thus we are seeking for your opinion and suggestions. For those who do not want to read the maintainer-scripts of my package, here is what you need to know (src:bley, using dbconfing-common for database configuration): Depends: ... dbconfig-common ... postrm: ... if [ -f /usr/share/dbconfig-common/dpkg/postrm ]; then . /usr/share/dbconfig-common/dpkg/postrm dbc_go bley $@ fi ... This means that we *try* to execute the postrm-hook of dbconfig-common in our postrm, but only if it's there. Policy 7.2 says "The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. Note, however, that the postrm cannot rely on any non-essential packages to be present during the purge phase.", which allows dbconfig-common to be gone *before* our postrm is executed. If it is gone, the hook isn't called, /etc/dbconfig-common/bley.conf isn't removed and piuparts warns about it. That's perfectly correct, we leave a stale config file here, so how to fix it? Trivial solution would be something like: if [ -f /usr/share/dbconfig-common/dpkg/postrm ]; then . /usr/share/dbconfig-common/dpkg/postrm dbc_go bley $@ else rm -f /etc/dbconfig-common/bley.conf if which ucf >/dev/null 2>&1; then ucf --purge /etc/dbconfig-common/bley.conf ucfr --purge bley /etc/dbconfig-common/bley.conf fi fi Everyone using dbconfig-common would have to add something like this to his/her postrm. (And everyone using other packages in a similar way too) Alternatively, we could modify piuparts not to remove dbconfig-common before the tested package isn't gone (or actually: not to try to remove any deps before the tested package isn't gone) and thus ignore this problem, defining it as "not usual usecase" (who tries to remove deps before removing the package itself?). What do you think? piuparts is correct and we should fix all affected packages? Or make the piuparts check less strict/more real-world like? Regards Evgeni Golov [1] http://piuparts.debian.org/sid/source/b/bley.html -- Bruce Schneier can read and understand Perl programs. -- 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/20100527093206.gc32...@dorei.kerker.die-welt.net
Re: Recent changes in dpkg
* Philipp Kern [2010-05-27 09:05:39 CEST]: > But I guess we already determined that automatic detection of various > things isn't always the best choice. Making 1.0 non-native and 1.0 > native explicit wouldn't sound too wrong. :P) Unfortunately, dpkg doesn't support that - thus adding debian/source/format "1.0" is no gain at all over leaving the file out completely. Making the file mandatory thus doesn't gain anything, at all. Thanks, Rhonda -- 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/20100527093513.ga1...@anguilla.debian.or.at
Re: Recent changes in dpkg
Hi! * Raphael Hertzog [2010-05-27 10:05:51 CEST]: > Yes, we're starting a long-term migration that will require every > package to be modified. The reasons are that the dpkg maintainers > consider the format 1.0 to no longer be a desirable default for > dpkg-source given the availability of improved formats. We also > acknowledge the fact that there's no longer a single format that suits > all cases and as such we want the maintainer to be explicit about the > choice they make. Requiring the file won't get rid of format 1.0 but will make people put 1.0 into debian/source/format. Planing to make the file mandatory might indeed make more people think about it, though having the file won't make the format 1.0 go away. There are already quite some packages in the pool which explicitly have put 1.0 into the file - thus stating that your approach to deprecate 1.0 with making the file mandatory is on the losing end. So what is the real goal of making the file mandatory, your above stated reason is unfortunately not working out? > No, we won't break packages, it's a migration and dpkg-source will be > switched only when all packages have been modified. What do you include in the set of "all packages"? All packages in the Debian pool? All packages that derivates might have? All packages that commercial software developers offer? You are hopefully very well aware that Debian isn't the only distribution or development body that uses the .deb format. > And 1.17.x means squeeze+2. And at that time, 1.0 will still be supported, > it's just that it won't be assumed if debian/source/format is absent. And again, explicitly, I would like to know what the real benefit of this change is that would *then* break building source packages, when 1.0 itself isn't planned to get deprecated. Thanks, Rhonda -- 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/20100527094702.gb1...@anguilla.debian.or.at
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 11:26:02AM +0200, Gerfried Fuchs wrote: > Hi! > > * Philipp Kern [2010-05-27 08:11:36 CEST]: > | 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. > > Why is that needed? It always was explicit that 1.0 is meant, what's > the need for the change? > > | Now I think the maintainers did outline why they want that in the past. :P > > Why they want it unfortunately is a wrong reasoning - the actual > pending and still unanswered question is "why it is needed". They > want people to switch to 3.0. By forcing to put something into > debian/source/format people start putting 1.0 in there for no gain. I > still fail to have received any real answer why debian/source/format > "1.0" containing is better than no debian/source directory at all. There is one possible benefit: impossibility to create a native package when the .orig.tar.gz is missing, which happens much too often. Mike -- 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/20100527100047.ga4...@glandium.org
Re: Recent changes in dpkg
On Donnerstag, 27. Mai 2010, Mike Hommey wrote: > There is one possible benefit: impossibility to create a native package > when the .orig.tar.gz is missing, which happens much too often. in my world (which doesnt consist entirely out of Debian main on ftp.debian.org) this is a regression. signature.asc Description: This is a digitally signed message part.
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Ludovic Brenta writes: > Over the last two weeks I have been testing upgrades of Ada packages > from Lenny to Sid and Squeeze in a chroot. Thanks for looking at this. > ... > The reason for all this is that when a package libX2-dev Conflicts: with > and Replaces: a package libX1-dev, aptitude does not remove libX1-dev > and install libX2-dev; instead, it marks libX1-dev as broken and leaves > libX2-dev uninstalled. This seems like a clear bug in aptitude. Debian policy 7.6.2 says that Replaces: with Conflicts: should cause the old package to be removed, and the new package to be installed, so why doesn't this work? -- -- Stephe -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/82ljb5u0au@stephe-leake.org
Re: The story behind UPG and umask.
On Wed, May 26, 2010 at 23:43 +0100, Stephen Gran wrote: > 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. Agreed, but why not make the decision to use UPG explicit by setting "UPG = True" in a suitable configuration file in addition to each of the discussed heuristics? -- .''`. Wolodja Wentland : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 12:00:47PM +0200, Mike Hommey wrote: > > Why they want it unfortunately is a wrong reasoning - the actual > > pending and still unanswered question is "why it is needed". They > > want people to switch to 3.0. By forcing to put something into > > debian/source/format people start putting 1.0 in there for no gain. I > > still fail to have received any real answer why debian/source/format > > "1.0" containing is better than no debian/source directory at all. > There is one possible benefit: impossibility to create a native package > when the .orig.tar.gz is missing, which happens much too often. Now you need to be more verbose. The dpkg-source manpage still lists 1.0 as supporting both patched and native. Bastian -- Either one of us, by himself, is expendable. Both of us are not. -- Kirk, "The Devil in the Dark", stardate 3196.1 -- 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/20100527102740.ga26...@wavehammer.waldi.eu.org
Re: Recent changes in dpkg
On Thu, 27 May 2010, Gerfried Fuchs wrote: > * Philipp Kern [2010-05-27 09:05:39 CEST]: > > But I guess we already determined that automatic detection of various > > things isn't always the best choice. Making 1.0 non-native and 1.0 > > native explicit wouldn't sound too wrong. :P) > > Unfortunately, dpkg doesn't support that - thus adding > debian/source/format "1.0" is no gain at all over leaving the file out > completely. I would accept patches implementing this. But from my point of view, 1.0 is to be avoided so I don't see the need to implement this. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100527103152.gb...@rivendell
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 12:27:40PM +0200, Bastian Blank wrote: > On Thu, May 27, 2010 at 12:00:47PM +0200, Mike Hommey wrote: > > > Why they want it unfortunately is a wrong reasoning - the actual > > > pending and still unanswered question is "why it is needed". They > > > want people to switch to 3.0. By forcing to put something into > > > debian/source/format people start putting 1.0 in there for no gain. I > > > still fail to have received any real answer why debian/source/format > > > "1.0" containing is better than no debian/source directory at all. > > There is one possible benefit: impossibility to create a native package > > when the .orig.tar.gz is missing, which happens much too often. > > Now you need to be more verbose. The dpkg-source manpage still lists 1.0 > as supporting both patched and native. Let's replace "possible" with "hypothetical", then. That's the only benefit i can find. Mike -- 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/20100527103541.ga4...@glandium.org
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 12:00:47PM +0200, Mike Hommey wrote: > On Thu, May 27, 2010 at 11:26:02AM +0200, Gerfried Fuchs wrote: > > Hi! > > > > * Philipp Kern [2010-05-27 08:11:36 CEST]: > > | 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. > > > > Why is that needed? It always was explicit that 1.0 is meant, what's > > the need for the change? > > > > | Now I think the maintainers did outline why they want that in the past. :P > > > > Why they want it unfortunately is a wrong reasoning - the actual > > pending and still unanswered question is "why it is needed". They > > want people to switch to 3.0. By forcing to put something into > > debian/source/format people start putting 1.0 in there for no gain. I > > still fail to have received any real answer why debian/source/format > > "1.0" containing is better than no debian/source directory at all. > > There is one possible benefit: impossibility to create a native package > when the .orig.tar.gz is missing, which happens much too often. Hrm, I was under the impression that native packages with an existing source/format of "1.0" would still be allowed? Maybe people could live with the change that 1.0 native packages need to explain themselves as "1.0 (native)" in debian/source/format (if that file is present, otherwise assume "1.0" as before, but that's a side issue), or dpkg-source would fail. 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/20100527104829.ge1...@nighthawk.chemicalconnection.dyndns.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Stephen Leake wrote: > Ludovic Brenta writes: >> The reason for all this is that when a package libX2-dev Conflicts: with >> and Replaces: a package libX1-dev, aptitude does not remove libX1-dev >> and install libX2-dev; instead, it marks libX1-dev as broken and leaves >> libX2-dev uninstalled. > > This seems like a clear bug in aptitude. > > Debian policy 7.6.2 says that Replaces: with Conflicts: should cause the > old package to be removed, and the new package to be installed, so why > doesn't this work? That's because there is no conflict until the user asks for installation of the new package; 7.6.2 says the old package must go only in case of a conflict. So, I would not characterize the behavior of aptitude as a bug, merely an annoyance. -- 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/f1b376860d7dbf4f911f1fc54baeb...@localhost
Re: The story behind UPG and umask.
On Thu, May 27, 2010 at 11:35:34AM +0200, Wolodja Wentland wrote: > On Wed, May 26, 2010 at 23:43 +0100, Stephen Gran wrote: > > 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. > > Agreed, but why not make the decision to use UPG explicit by setting > "UPG = True" in a suitable configuration file in addition to each of the > discussed heuristics? Or, just set umask to a fixed value. Cheers, harry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527111454.ga20...@sbs288.lan
Bug#583368: please support .orig.tar.bz2 for source format 1.0
Package: ftp.debian.org Severity: wishlist Hi! It would be very helpful if the dpkg source format 1.0 could also allow .orig.tar.bz2 packages in the archive. The reason for the request should be quite obvious - more and more upstream packages are shipped in bzip2 compressed tarballs. Given that conversion to 3.0 might not always be the best idea just for the benefit of being able to use .orig.tar.bz2 it would be great if the same could be allowed for source v1, too. Thanks in advance for considering, Rhonda -- 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/20100527122942.ga12...@anguilla.debian.or.at
Re: Recent changes in dpkg
]] Neil Williams | 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. You make it sound like a package upload is a big deal. Sometimes, you upload for small things, there's 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. How is this different to other changes in the toolchain which sometimes deprecate and remove functionality which then makes packages FTBFS? -- 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/87sk5djyiu@qurzaw.linpro.no
Re: Let's write a system admin friendly mail server packaging system
Thomas Goirand wrote: > Mario 'BitKoenig' Holbe wrote: >> Why would you like to go another way with mail servers? > Because upstream doesn't want a conf.d folder, unfortunately, and that Well, you can have something equal without upstream support by concatenating conf.d snippets into one huge conf-file, like modutils did (Andreas did describe this for exim already), and today we can also trigger this on package upgrades. > 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. So far this is independent of third packages which is IMHO fine and desirable. So far, this could be solved by a postfix-conf.d-snippet shipped with the amavis package. > Now, add dkimproxy in the loop. You have to configure dkimproxy to > receive from postfix, relay to amavis, and amavis forwards to postfix. That's pain, indeed, and should IMHO be avoided at all. A clean way to conf this would be * postfix ships to amavis * amavis ships back to postfix * postfix ships to dkimproxy * dkimproxy ships back to postfix I don't know if this is possible with postfix yet. The sendmail milter approach is way cleaner regarding such stuff. > This is a LOT less trivial than what you pretend. That's not just less trivial, it's horrible :) And this is probably one of the reasons why newer amavis is now able to perform DKIM signing on it's own. So, this specific chaining should be historic sooner or later. Do you have another example where such a chaining is unavoidable? > 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. And of course they use distribution-default configured mail servers for that :) scnr. regards Mario -- () Ascii Ribbon Campaign /\ Support plain text e-mail -- 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/slrnhvss71.m0q.mario.ho...@darkside.dyn.samba-tng.org
Re: Recent changes in dpkg
* Mike Hommey [2010-05-27 12:00 +0200]: > There is one possible benefit: impossibility to create a native package > when the .orig.tar.gz is missing, which happens much too often. Doesn't look like it's impossible: | dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file found | dpkg-source: info: using source format `1.0' Carsten -- 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/20100527134440.ga28...@foghorn.stateful.de
Re: Recent changes in dpkg
* Carsten Hey [2010-05-27 15:44 +0200]: > * Mike Hommey [2010-05-27 12:00 +0200]: > > There is one possible benefit: impossibility to create a native package > > when the .orig.tar.gz is missing, which happens much too often. > > Doesn't look like it's impossible: > > | dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file > found > | dpkg-source: info: using source format `1.0' You're right if a newer dpkg is used: | dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found Carsten -- 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/20100527134738.gb8...@foghorn.stateful.de
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 03:44:40PM +0200, Carsten Hey wrote: > * Mike Hommey [2010-05-27 12:00 +0200]: > > There is one possible benefit: impossibility to create a native package > > when the .orig.tar.gz is missing, which happens much too often. > > Doesn't look like it's impossible: > > | dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file > found > | dpkg-source: info: using source format `1.0' That's supposed to have been fixed. Mike -- 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/20100527134741.ga13...@glandium.org
Bug#583385: ITP: ibus-table-chinese -- provide chinese input method tables for IBus-Table
Package: wnpp Severity: wishlist Owner: Asias He * Package name: ibus-table-chinese Version : 1.3.0.20100527 * URL : http://code.google.com/p/ibus/ * License : GPLv3 Programming Lang: Python Description : provide chinese input method tables for IBus-Table ibus-table-chinese provide the following input method tables for IBus-Table, one of input method engines on IBus framework: Cang Jie 3 (倉頡輸入法第三代) Cang Jie 5 (倉頡輸入法第五代) Cang Jie Big (倉頡輸入法大字集) Canton HK (港式廣東話輸入法) Cantonese Pinyin (廣東拼音輸入法) Easy Big (輕鬆輸入法大字集) Erbi (二笔) Erbi QS (二笔青松) Jyutping (粵語拼音輸入法) Quick 3 (速成輪入法第三代) Quick 5 (速成輪入法第五代) Quick Classic (速成輪入法古典版) Smart Cang Jie 6 (快速倉頡輸入法六代) Stroke5 (筆順五碼) Wu (五笔) Wubi86 (五笔86) Xinhua (新华) Yong (永码) ZhuYin (注音) ZhuYin Big (注音大字集) Zhengma (郑码) ZiRanMa (自然码) -- 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/20100527135617.6247.54321.report...@localhost
Re: Recent changes in dpkg
* Gerfried Fuchs [100527 11:47]: > Requiring the file won't get rid of format 1.0 but will make people put > 1.0 into debian/source/format. Planing to make the file mandatory might > indeed make more people think about it, though having the file won't > make the format 1.0 go away. There are already quite some packages in > the pool which explicitly have put 1.0 into the file - thus stating that > your approach to deprecate 1.0 with making the file mandatory is on the > losing end. > > So what is the real goal of making the file mandatory, your above > stated reason is unfortunately not working out? Not ignoring errors is an important part of software quality. There are mostly three possibilities: 1) not require the file but work properly without -> not possible as there are many packages that still need 1.0 and changing the default to 3.0 would annony developers not liking it too much. 2) not require the file but choose old format in that case -> in case of error people silently get the old deficit format 2) require the file in the long run -> everyone can chose their own, noone will get an old deficit format without requesting it in the future, noone will get the new format without requesting it. Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- 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/20100527143747.ga1...@pcpool00.mathematik.uni-freiburg.de
Re: correctly using other packages in postrm
* Evgeni Golov [100527 11:32]: > Alternatively, we could modify piuparts not to remove dbconfig-common > before the tested package isn't gone (or actually: not to try to remove > any deps before the tested package isn't gone) and thus ignore this > problem, defining it as "not usual usecase" (who tries to remove deps > before removing the package itself?). I would have thought most people do this most of the time. Most commands only remove stuff, unless you tell them explicitly. (So you keep the config files and only later when you know you have not removed anything you need, you can purge it, so reinstalling would now mean reconfiguring). Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- 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/20100527150107.gb1...@pcpool00.mathematik.uni-freiburg.de
Re: RFH: bashisms in configure script
On Wed, May 26, 2010 at 08:05:32AM +0200, Lucas Nussbaum wrote: > I'm still feeling uneasy about this whole bash->dash thing. We sacrified > a lot of usability in the name of POSIX compliance (only a minority of > users care) and a few seconds spared during boot (who cares? I only boot > my laptop for kernel upgrades). "boot"? It's hardly because of boot, it's mostly because of scripts that keep getting run on your system all the time. They make up ~16% of files in /usr/bin/, and, unlike programs in other languages, they tend to be very short-lived and thus get started a lot. And shell is not just for proper separate-file scripts. Let's glance at what gets done during a build: │ ├─sshd───sshd───bash───make───5*[sh───x86_64-linux-gn─┬─as] │ │ └─cc1plus] You have a separate bash/dash/posh process for every single command run by make. With bash's insane startup time, that makes a significant difference. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20100527152458.ga26...@angband.pl
Re: mini-dinstall possibly leading to lots of 'Failed to fetch http://xyx/abd_1.2-3.deb Size mismatch'
On 25 May 2010 at 06:59, Goswin von Brederlow wrote: | Dirk Eddelbuettel writes: | > Every now and then mini-dinstall throws us a curve ball. Right now I am | > seeing the errors below on my testing box (which is otherwise current). | > | > What can we do to fix the index file? I have removed Packages*, Release*, [...] | | Maybe just avoid the problem by using reprepro. So to continue: I got two votes for reprepro and am looking into it. As with so many things, not that hard once one sits down and fiddles with it. One think I could not answer was: can it do what mini-dinstalled called archive_style = flat so that we could cook-up an in-place substitution? The answer seems to be "No" and pools have advantages, esp as we are at 2300+ packages and growing. So maybe this is the time to have users switch their sources.list entries. -- Regards, Dirk -- 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/19454.35562.678982.103...@ron.nulle.part
Re: lilo removal in squeeze (or, "please test grub2")
Samuel Thibault writes: > 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. To quote upstream: hpa: It's trivial to add support for it (just another MENU directive) So if you really need it, it'll be in the next version. And I assume that's why you asked, right? :) -- Cheers, Feri. -- 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/87vda9tnrx@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, May 24, 2010 at 07:10:37PM +0200, Stefano Zacchiroli wrote: > On Mon, May 24, 2010 at 06:13:13PM +0200, Jordi Mallach wrote: > > Colin added himself to the Uploaders field when I requested him to do so, > > as he's been in charge of Ubuntu's switch to GRUB2 for Ubuntu and after > > the "disappearance" of Felix and Robert, he's the Debian person with more > > experience to do uploads of the package. He did know he wouldn't be able > > to track upstream as Felix and Robert were (ie, uploading several > > snapshots every two weeks or so). > > > > I can try to work with Vladimir and Colin to get things shaped out a > > little, but honestly I don't think I'd be in a position to do this before > > the 22th of June, when exams finish. > > In the meantime, it would be terribly useful if some of you can inform > us of whether you think things can get in shape for Squeeze or not, > considering the currently available manpower. If not, we probably ought > to be more "communicative" on the fact we really need help on grub2 > (e.g. Colin can blog about that *g*). I think grub2 is in a slightly less awful state than it looks just from its RC bug count. Boot loaders do tend to attract RC bugs - if it doesn't boot in some corner case, people understandably crank the severity up rather high even if it doesn't indicate that it's broken for most people. That said, this is a reason and not an excuse. I've certainly been neglecting the bug list - Robert and Felix were doing a much better job of keeping up with it than I seem to have managed. I'm in the process of preparing a new upstream snapshot now, and have spent most of the day trying to tidy things up a bit. I've downgraded a couple of RC bugs as corner-case and unreproducible, and closed several more since they were already fixed in the current package. Of the rest, they mostly fall into a few main categories with the odd outlier: * upgrade-from-grub-legacy problems * an assortment of problems with complex block devices (LVM/RAID) * unstable device naming in grub-pc/install_devices I haven't tackled the first yet, but they're hopefully fairly tractable; that code is just a little unrefined as yet. Fixing the LVM/RAID cases is very likely a matter of sitting down with a sequence of test installs in a VM, which I'm going to attack over the next couple of days. The last is nearly done, but I want to fix some known problems in it first and will probably upload a snapshot without it to start with in order to make it easier to bisect any new bugs. In short: my apologies that it's ended up in such a state. However, I think I will have time to at least deal with the RC bugs, and hopefully a number more (including e.g. the btrfs probing bug). I wouldn't complain about help though! (CCs welcome on replies if you want to get my attention a bit faster.) -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527160709.gy12...@riva.ucam.org
Re: lilo removal in squeeze (or, "please test grub2")
2010/5/26 Joachim Wiedorn : > Harald Braumann wrote on Tue, 25 May 2010: >> >> On simple standard system -- one disk, one kernel in /boot, no fancy >> stuff -- it works quite well. > > This is enough to use grub2 for new installing of Debian. > >> On other systems it often breaks miserably. Updates leave my system >> unbootable every other time. One major problem are incompatible >> versions of the boot loader installed in the MBR and grub.cfg. not strictly a grub2 issue, but os-prober creates unbootable menu's when you have dual boot systems with same /boot. Even during a new installation if the system already have another GNU/Linux it will create unbootable entries for that. See #580736 Earlier with grub I remember these are correctly configured. Plus without a single configuration file, it is much more difficult to get it to work as you like. Praveen -- പ്രവീണ് അരിമ്പ്രത്തൊടിയില് I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) -- 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/aanlktiki7z6_yww2eyduexw6vofd55aldmcu-2kdq...@mail.gmail.com
Re: mini-dinstall possibly leading to lots of 'Failed to fetch http://xyx/abd_1.2-3.deb Size mismatch'
On Thu, 27 May 2010 10:08:26 -0500, Dirk Eddelbuettel wrote: [reprepro] > One think I could not answer was: can it do what mini-dinstalled called > archive_style = flat > so that we could cook-up an in-place substitution? I don't think so. > The answer seems to be > "No" and pools have advantages, esp as we are at 2300+ packages and growing. > So maybe this is the time to have users switch their sources.list entries. I've added some mod_rewrite magic to my apache config when I switched from mini-dinstall to reprepro, maybe this could help in your case too. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Eric Clapton: You Can Leave Your Hat On signature.asc Description: Digital signature
Bug#583395: ITP: libversion-perl -- Perl extension for Version Objects
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt * Package name: libversion-perl Version : 0.82 (upstream), 0.8200 (Debian package) Upstream Author : John Peacock * URL : http://search.cpan.org/dist/version/ * License : Artistic or GPL-1+ (like perl) Programming Lang: Perl, C (XS) Description : Perl extension for Version Objects The version module implements version objects and provides Perl's version object API. This module is also available in perl, but a newer version is required by other modules. Perl 5.12 would include a version recent enough, but as far as I know it has not yet been decided which version Squeeze will ship with. For this reason I plan to have a separate package for now. -- 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/20100527161638.15205.30842.report...@marvin.43-1.org
Bug#583476: ITP: openscad -- script file based graphical CAD environment
Package: wnpp Severity: wishlist Owner: chrysn * Package name: openscad Version : 2010.05 Upstream Author : Clifford Wolf * URL : http://www.openscad.org/ * License : GPL-2+ with exception for CGAL (libcgal) Programming Lang: C++ and own domain specifc OpenSCAD (examples) Description : script file based graphical CAD environment OpenSCAD is a software for creating solid 3D CAD objects. It focuses on CAD aspects rather than artistic ones. OpenSCAD is not an interactive modeller. Instead it is something like a 3D-compiler that reads in a script file that describes the object and renders the 3D model from this script. This gives the designer full control over the modelling process and enables him to easily change any step in the modelling process or make designes that are defined by configurable parameters. notable dependencies of this software are libcgal (which is non-free, but it's just some QPL parts, so openscad will go to contrib) and opencsg, which is not yet packaged (RFP/ITP will follow). i have a more-or-less ready package at [1], but as this is both the first package of software i didn't write myself and the first package i use with platform dependent binaries (ie not python), i'll need some feedback on whether i'm doing it right (everything works quite ootb, but i'm not sure if it works everywhere). the only left over lintian complaint is binary-without-manpage, and it can be built in cowbuilder with the opencsg packages from [2]. [1] http://archive.amsuess.com/pool/contrib/o/openscad/ [2] http://archive.amsuess.com/pool/main/o/opencsg/ -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Bug#583468: ITP: libcpan-meta-perl -- Perl module to access distribution metadata for a CPAN distribution
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt * Package name: libcpan-meta-perl Version : 2.101461 Upstream Author : David Golden , Ricardo Signes * URL : /usr/share/common-licenses/Artistic * License : Artistic or GPL-1+ (like perl) Programming Lang: Perl Description : Perl module to access distribution metadata for a CPAN distribution Software distributions released to the CPAN include a META.json or, for older distributions, META.yml which describes the distribution, its contents, and the requirements for building and installing the distribution. The data structure stored in the META.json file is described in CPAN::Meta::Spec. . CPAN::Meta provides a simple class to represent this distribution metadata (or distmeta), along with some helpful methods for interrogating that data. This module is required by a new upstream release of Dist::Zilla (libdist-zilla-perl). -- 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/20100527171849.24364.90108.report...@marvin.43-1.org
Bug#583474: ITP: libmoosex-types-perl-perl -- Moose types that check against Perl syntax
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt * Package name: libmoosex-types-perl-perl Version : 0.101340 Upstream Author : Ricardo SIGNES * URL : http://search.cpan.org/dist/MooseX-Types-Perl/ * License : Artistic or GPL-1+ (like perl) Programming Lang: Perl Description : Moose types that check against Perl syntax MooseX::Types::Perl provides Moose types for checking things (mostly strings) against syntax that is, or is a reasonable subset of, Perl syntax. This module is required by a new upstream release of Dist::Zilla (libdist-zilla-perl). -- 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/20100527172108.24417.62657.report...@marvin.43-1.org
Re: Recent changes in dpkg
[Gerfried Fuchs] > Requiring the file won't get rid of format 1.0 but will make people put > 1.0 into debian/source/format. Planing to make the file mandatory might > indeed make more people think about it, though having the file won't > make the format 1.0 go away. It's pretty clear that this is social engineering. The dpkg maintainers want to force every package maintainer to _think_ about which source format they wish to use. To ensure that, in the long run, you no longer have the choice to simply ignore the format war. I am puzzled by one thing, however. The dpkg maintainers chose not to add tar.bz2 support to format 1.0 (the only real advantage many of us can see to format 3.0) on the grounds that it would change the format, and thus format 1.0 would effectively become format 1.1 or something. Which, for a deprecated format, was too much effort. ...And here we are now, talking about an incompatible change to format 1.0. Yay? So _now_ can we get tar.bz2 format support in there, while we're at it? Peter -- 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/20100527183829.gd18...@p12n.org
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 02:54:17PM +0200, Tollef Fog Heen wrote: > ]] Neil Williams > | 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. > You make it sound like a package upload is a big deal. Sometimes, you > upload for small things, there's nothing wrong with that. No, he's saying that 16,000 package uploads are a big deal, which is the number of source packages that have to be uploaded in order to complete this transition. I understand better Raphaël's position after the last thread - that a source package is a .dsc + related files, not an unpacked tree, so refusing to create a 1.0 source package out of an unpacked tree isn't a redefinition of the format. Even so, transitions that require sourceful changes to every single package in the archive are a bad idea, and almost always translate as "busywork". > | 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. > How is this different to other changes in the toolchain which sometimes > deprecate and remove functionality which then makes packages FTBFS? Can you point to such a toolchain change that required changes to even 20% of the packages in th archive? -- 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 -- 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/20100527185530.ga5...@dario.dodds.net
Re: Recent changes in dpkg
]] Steve Langasek | On Thu, May 27, 2010 at 02:54:17PM +0200, Tollef Fog Heen wrote: | > ]] Neil Williams | | > | 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. | | > You make it sound like a package upload is a big deal. Sometimes, you | > upload for small things, there's nothing wrong with that. | | No, he's saying that 16,000 package uploads are a big deal, which is the | number of source packages that have to be uploaded in order to complete this | transition. (There are about 12.3k 1.0 packages, not 16k, but that's a fairly minor detail. :-) How many of those would have been uploaded anyway over two cycles? I don't have firm numbers, but my suspicion is «most of them». This would then just be one of those minor things you do when you update to a newer standards-version and fix various lintian nits. In fact, according to http://upsilon.cc/~zack/stuff/dpkg-v3/, we're looking at about 480 packages being converted to 3.0 per month, meaning that at the current rate we'll probably be at something like 120% of the archive converted for squeeze+1. ;-) [...] | > How is this different to other changes in the toolchain which sometimes | > deprecate and remove functionality which then makes packages FTBFS? | | Can you point to such a toolchain change that required changes to even 20% | of the packages in th archive? I wasn't around for the libc5 => libc6 transition, but my understanding is it was larger than 20% of the archive. I would guesstimate the removal of /usr/X11R6 at being around the 20% mark (including binNMUs and all). So while they're uncommon, they're not unheard of. -- 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/87k4qpdui7@qurzaw.linpro.no
Re: Recent changes in dpkg
Bernhard R. Link wrote: > There are mostly three possibilities: > 2) not require the file but choose old format in that case >-> in case of error people silently get the old deficit format That problem can easily be avoided by adding deprecation warnings. Debhelper does this for packages that don't specify a compatability level and get the bad old v1 level by default. So I don't think that is a serious problem. -- see shy jo signature.asc Description: Digital signature
Re: Recent changes in dpkg
On 27/05/2010 21:17, Tollef Fog Heen wrote: > I wasn't around for the libc5 => libc6 transition, but my understanding > is it was larger than 20% of the archive. I would guesstimate the > removal of /usr/X11R6 at being around the 20% mark (including binNMUs > and all). So while they're uncommon, they're not unheard of. There is also the /usr/doc => /usr/share/doc transition. -- Jean-Christophe Dubacq -- 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/4bfec9b1.7080...@free.fr
Re: Recent changes in dpkg
Peter Samuelson wrote: > It's pretty clear that this is social engineering. The dpkg > maintainers want to force every package maintainer to _think_ about > which source format they wish to use. To ensure that, in the long run, > you no longer have the choice to simply ignore the format war. I wonder if anything can be learned from debhelper's history of compatability levels. numpkgs compat levelintroduced deprecated 1 8 Jun 2010 6625 7 Apr 2008 675 6 Jan 2008 5398 5 Nov 2005 1638 4 Apr 2002Mar 2009 156 3 Feb 2001Nov 2005 25 2 Jul 2000Jun 2005 25 1 Sep 1997Jun 2005 557 unknown[1] Sep 1997Jun 2005 [1] No debian/compat or DH_COMPAT currently means compat level 1 is used. A few hundred of these packages do not use debhelper at all; I don't have the exact number handy. Some points I'd draw from this data and what I remember about how the numbers used to look: * About 50% of packages switched to the newest version in just a couple of years, without me being too annoying with deprecation messages, or making any changes that forced the switch. * Deprecation warnings seem to do a good job of gradually eroding the number of holdouts after the initial switch rush. (The relatively large number of packages still using v4 is probably because it was the "best" level for a long period (2002-2005), and only started deprecation warnings a year ago.) * After a certian point, one has to take action to get rid of the last few packages in the long tail. It would be pretty easy at this point for me to get rid of v2 and v3 entirely. But still probably not worth the effort, as it would only remove a few dozen lines of code from debhelper. The time is better spent getting rid of individual deprecated debhelper commands. * At this point, mandating a version number at the cost of breaking a few hundred packages might be worth it, though mostly because it would probably cause half of them to update away from v1. * If I had mandated a version when v2 was introduced, I would have caused many long threads on debian-devel, and would probably now have to contend with a lump of packages using v2 (or yada) instead of the current lump at v1. -- see shy jo signature.asc Description: Digital signature
Bug#583500: ITP: libfsoresource -- freesmartphone.org resource library
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: libfsoresource * URL : http://wiki.freesmartphone.org/index.php/Implementations/libfsoresource * License : GPL Programming Lang: C Description : freesmartphone.org resource library This C library contains classes useful for interfaceing with the FSO resource system. This package is part of the freesmartphone.org software stack and is targeted for smartphones. -- 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/20100527204004.6525.42136.report...@toshiba.siemens
Re: Recent changes in dpkg
Joey, first of all thanks for the data... :) On 2010-05-27, Joey Hess wrote: > I wonder if anything can be learned from debhelper's history of > compatability levels. > > numpkgs compat level introduced deprecated > 1 8 Jun 2010 You really are from the future, then. ;-) > * After a certian point, one has to take action to get rid of the last > few packages in the long tail. It would be pretty easy at this point > for me to get rid of v2 and v3 entirely. But still probably not worth > the effort, as it would only remove a few dozen lines of code from > debhelper. The time is better spent getting rid of individual > deprecated debhelper commands. But then v2 and v3 support might have bitrotten and FTBFS could have been introduced in the meantime due to the toolchain? Sometimes dropping support for old levels might make sense if almost nobody uses it and wouldn't notice breakage... (Not to say that this applies to debhelper in any way...) 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/slrnhvtmb4.od3.tr...@kelgar.0x539.de
Bug#583501: RFA: xserver-xorg-video-openchrome -- display driver for VIA Unichrome video chipsets
Package: wnpp Severity: normal X-debbugs-cc: debia...@lists.debian.org, debian-devel@lists.debian.org Hi, I no longer have time and working hardware to maintain and test the package. I'm therefore looking for somebody who wants to adopt it. Anyone willing to maintain it please contact the Debian X Strike Force (debia...@lists.d.o). Some info about the package: Description: X.Org X server -- VIA display driver OpenChrome is a project for the development of free and open-source drivers for the VIA UniChrome video chipsets. . Originally called the 'snapshot' release, since it was a snapshot of an experimental branch of the unichrome cvs code, this is a continued development of the open source unichrome driver (from http://unichrome.sf.net) which also incorporates support for the unichrome-pro chipsets. . Support for hardware acceleration (XvMC) for all chipsets has subsequently been ripped out of the unichrome.sf.net driver. Therefore your only option if you wish to make use of the acceleration features of your VIA chip with free and open-source drivers is to use this version of the driver. Homepage: http://www.openchrome.org Vcs-Browser: http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video- openchrome.git Vcs-Git: git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video- openchrome I'm going to make one, hopefully last, upload to reflect some changes to the xorg packages build system. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005271551.39887.geiss...@debian.org
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: > > 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. So, we are talking about packages that have a) no (fixed) bug reports b) no new upstream version in 4 years. How many packages are we talking about here? Is there a way to get the number of packages that have the same version in Lenny and Squeeze? Anyway, I don't think asking for an upload once every 4 years is so much of a burden. 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/20100527204747.ga12...@atlan
Re: RFH: bashisms in configure script
On Tuesday 25 May 2010, Raphael Geissert wrote: > 1. If your name is on the list at [2] please check at [3] the .dsc > file that corresponds to the source packages you co-/maintain, > review and fix. The .dsc files contain checkbashisms' output. Do you want to start a list with errors that can be ignored because they are in unused scripts? For example in apache2: possible bashism in ./srclib/pcre/configure line 3915 (should be 'b = a'): enableval=$enable_ebcdic; if test "$enableval" == "yes"; then Since srclib/pcre/configure is never executed during the build of the Debian package, I don't see any value in fixing 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/201005272241.57985...@sfritsch.de
Bug#583506: ITP: python-setproctitle -- A setproctitle implementation for Python
Package: wnpp Severity: wishlist Owner: "Örjan Persson" * Package name: python-setproctitle Version : 1.0 Upstream Author : Daniele Varrazzo * URL : http://code.google.com/p/py-setproctitle/ * License : BSD Programming Lang: Python Description : A setproctitle implementation for Python The library allows a process to change its title (as displayed by system tools such as ps and top). Changing the title is mostly useful in multi-process systems, for example when a master process is forked: changing the children's title allows to identify the task each process is busy with. The technique is used by PostgreSQL and the OpenSSH Server for example. -- 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/20100527215338.21288.76552.report...@bender.fobie.net
Re: Let's write a system admin friendly mail server packaging system
Mario 'BitKoenig' Holbe wrote: > So far this is independent of third packages which is IMHO fine and > desirable. So far, this could be solved by a postfix-conf.d-snippet > shipped with the amavis package. Quite not. You also need to configure the incoming and outgoing ports of amavis the correct way. > That's pain, indeed, and should IMHO be avoided at all. > A clean way to conf this would be > * postfix ships to amavis > * amavis ships back to postfix > * postfix ships to dkimproxy > * dkimproxy ships back to postfix > I don't know if this is possible with postfix yet. The sendmail milter > approach is way cleaner regarding such stuff. No, it's not any cleaner, and it's slower. As I wrote previously, we really don't want to have lower performances on a mail server if we want to do things seriously. And by the way, you wrote: postfix -> amavis -> dkimproxy -> postfix when what we really want to do is: postfix -> dkimproxy -> amavis -> postfix for obvious performance reasons. >> This is a LOT less trivial than what you pretend. > > That's not just less trivial, it's horrible :) > > And this is probably one of the reasons why newer amavis is now able to > perform DKIM signing on it's own. So, this specific chaining should be > historic sooner or later. I do not agree, for a very simple reason. Amavis is a dog, and you might want to remove it completely (depending on your setup/needs/mood). As much as I could see, each amavis instance is taking about 80MB of RAM! Back running sarge, it was a way smaller. I am quite stunned about the fact that, under Lenny, running amavis + clamav + spamassassin is taking about 6/700 MB of RAM when the server is idle. I quite don't understand what happened between Sarge and Lenny (or even, between Etch and Lenny). We used to run these 3 plus apache, mysql and others with just under 200MB of RAM + same amount of swap, on small footprint VMs. Currently, 512MB of RAM + same amount of swap is hardly enough. Also, running amavis is slow, very slow. So that's the one you want to run the last, after all other checks have been performed. To what I could see, dkimproxy performs very well. Others reported that it ran very well under such heavy load as 100k+ email a day (which is the type of traffic we always should keep in mind). > Do you have another example where such a chaining is unavoidable? Sure. clamsmtp for example. That makes 3 software that are used as SMTP proxies, and that could be chained. All of them would need dynamic configuration depending what is installed on the system. And this is only the one that I know/use. There must be more than this in the archive. The current situation in Debian, is that not even the default incoming and relaying ports are set correctly so the components can work together. This is quite a real mess. >> 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. > > And of course they use distribution-default configured mail servers for > that :) scnr. Are you trying to say that we shall ship a not performing configuration by default, because big ISP are capable of reconfiguring? If you are, sorry, I don't agree. I think we shall try to release the best distribution as we can, with correct, performing values by default, and even, if possible, have a default configuration that you never even need to edit, because it's just right by default. We should at least have this goal in mind, otherwise it slowly leads to an unusable default system, which is really not wanted here (and which I believe is the current state of many of the mail components in Debian, and that is the reason of my original post). Maybe I'm being too idealistic here. What's your opinion? 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/4bfeec27.1070...@goirand.fr
Re: The story behind UPG and umask.
Am Thu, 27 May 2010 11:35:34 +0200 schrieb Wolodja Wentland: > why not make the decision to use UPG explicit by setting > "UPG = True" I would say UPGs are already explicitly used. If your UPG = True means that newly created users are created with user private groups, than that is "USERGROUPS=yes" in adduser.conf. This UPG usage prerequisite, has been a debian default since 94' according to an old thread that was mentioned. If by UPG = True you refer to being conservative and relaxing the umask only for users that are created with certain characteristics that indicate that they really have been created with private user groups, thatn that used to be "USERGROUPS_ENAB yes" in login.defs until PAM was introduced whithout support for it, at that time, and broke it. Now pam_umask is available and takes the option "usergroups" when called from a pam.d/ config file (it could probably be patched to read login.defs). If by UPG = True you refer to setting a system wide default (relaxed) umask 002 (and risking to do to much to exsiting users or users on other systems authenticating agains the debian system), that used to be UMASK 002 in login.defs before PAM, with PAM "umask 002" had to be called from each shell rc file used, but now, if we activate pam_umask, it will read UMASK 022 from login.defs again (and relax it conditionally). -- 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/20100528001517.29cea841c.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Fri, 28 May 2010 00:15:17 +0200 schrieb "C. Gatzemeier" : > but now, if we > activate pam_umask, it will read UMASK 022 from login.defs again (and > relax it conditionally). err, that is the case if you keep the UMASK 022 and "usergroups" option (the defaults). Of course you can set a fixed UMASK 002 and remove "usergroups" from the pam_umask call, and there will be no umask relaxation. -- 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/20100528002702.7b5741a4c.gatzeme...@tu-bs.de@tu-bs.de
Re: Recent changes in dpkg
On Thu, 27 May 2010 10:05:51 +0200, Raphael Hertzog wrote: > Yes, we're starting a long-term migration that will require every package > to be modified. [..] > No, we won't break packages, it's a migration and dpkg-source will be > switched only when all packages have been modified. There are warnings > in place both in dpkg-source and in lintian. We are fully aware that it will > take very long [..] > And 1.17.x means squeeze+2. And at that time, 1.0 will still be supported, > it's just that it won't be assumed if debian/source/format is absent. Thanks for the clear summary of the plans. FWIW: I think that's a reasonable approach. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Dire Straits: Sultans Of Swing signature.asc Description: Digital signature
test if primary group, with only implicit membership of the user?
> > 2) A special case is true: The group is set as the main group of the >user (in /etc/passwd) while the user is NOT added to his group >in /etc/groups. May pam_umask test this, for umask relaxation? -- 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/20100528010045.653c9121c.gatzeme...@tu-bs.de@tu-bs.de
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 10:47:47PM +0200, Thomas Weber wrote: > How many packages are we talking about here? Is there a way to get the > number of packages that have the same version in Lenny and Squeeze? According to a quick query on UDD, there are 3169 source packages which have the same source version in Lenny and Squeeze. 746 when comparing Etch and Squeeze. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Work-needing packages report for May 28, 2010
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 630 (new: 8) Total number of packages offered up for adoption: 123 (new: 3) Total number of packages requested help for: 65 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: bbdate (#583241), orphaned yesterday Description: Date tool for the blackbox window manager Installations reported by Popcon: 83 fbpanel (#583245), orphaned yesterday Description: A lightweight X11 desktop panel Installations reported by Popcon: 356 glipper (#583244), orphaned yesterday Description: Clipboard manager for the GNOME panel Reverse Depends: brdesktop-gnome Installations reported by Popcon: 396 myspell-sv (#583250), orphaned yesterday Description: Swedish (SE) dictionary for myspell Installations reported by Popcon: 554 obmenu (#583246), orphaned yesterday Description: A graphical menu editor for openbox Installations reported by Popcon: 412 odyssey (#583249), orphaned yesterday Description: PIC microcontroller programming application Installations reported by Popcon: 72 usermode (#583242), orphaned yesterday Description: Graphical tools for certain user account management tasks Reverse Depends: mock Installations reported by Popcon: 349 xmame (#583240), orphaned yesterday (non-free) Description: Multiple Arcade Machine Emulator Reverse Depends: xmame-common xmame-gl xmame-sdl xmame-svga xmame-x xmess-sdl xmess-x Installations reported by Popcon: 783 622 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: fusecompress (#583207), offered yesterday Description: transparent filesystem compression using FUSE Reverse Depends: fusecompress-dbg Installations reported by Popcon: 99 php-versioncontrol-svn (#583117), offered 2 days ago Description: Wrapper interface for the Subversion command-line client Installations reported by Popcon: 6 xserver-xorg-video-openchrome (#583501), offered today Description: display driver for VIA Unichrome video chipsets Reverse Depends: xserver-xorg-video-all xserver-xorg-video-via Installations reported by Popcon: 34996 120 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-cross (#540341), requested 293 days ago Description: retrieve, build and install libraries for cross-compiling Reverse Depends: apt-cross emdebian-buildsupport emdebian-qa emdebian-tools libemdebian-tools-perl Installations reported by Popcon: 350 apt-xapian-index (#567955), requested 115 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: adept ept-cache Installations reported by Popcon: 11757 ara (#450876), requested 928 days ago Description: utility for searching the Debian package database Installations reported by Popcon: 116 asymptote (#517342), requested 454 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 1295 athcool (#278442), requested 2039 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 144 boinc (#511243), requested 504 days ago Description: BOINC distributed computing Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg Installations reported by Popcon: 1632 cvs (#354176), requested 1554 days ago Description: Concurrent Versions System Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsservice (11 more omitted) Installations reported by Popcon: 25079 dctrl-tools (#448284), requested 943 days ago Description: Command-line tools to process Debian package information Reverse Depends: aptfs debian-goodies debtree dlocate haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo simple-cdd ubuntu-dev-tools Installations reported by Popcon: 13410 debtags (#567954), requested 115 days ago Description: Enables support for package tags Reverse Depends: debtags-edit goplay packagesearch Installations reported by Popcon: 2661 dietlibc (#5440
Source packages: standard formats and interfaces as an alternative to centralisation.
Dear all, binary packages are built from unpacked sources through a simple interface that combines targets of the debian/rules file and environment variables, to build packages whose structure is documented in our Policy. What about applying the same logic for building source packages? This would require to specify the formats 1.0 (and its minor updates), 3.0 (quilt) and 3.0 (native) in a more formal way, but I think that it would be a good to have them documented anyway, and it would solve the controversy about debian/source/format: either this file is necessary for a source package to conform to the format 1.0, or it is not. It would also clarify the logic in the 3.0 (variant) name scheme. For instance, if the 3.0 (native) format is updated to 3.1 (native), will the quilt variant stay 3.0 or become 3.1 with no changes? With a simple debian/rules target, for instance ‘source’, the conflict about the source package formats can be made much milder, because it will be the choice of the maintainer to use or not dpkg-dev, debian/source/format, and the automatic patch production system. This solution would bring do-o-cracy back in the loop, with the dpkg-dev maintainers free to implement a solution that respects documented standards (that they are in the first line to shape), and the package maintainers free to use another way if they dislike the approach taken by dpkg-dev. While the Debian infrastructure does not build source packages, such a switch from ‘dpkg-buildpackage’ to ‘debian/rules source’ would be quite distruptive in the maintainers workflows, so it would probably need some time to adapt the toolchains, but apparently the mood is on a mass-transition of our packages anyway… 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/20100528011316.gb21...@kunpuu.plessy.org
Looking for maintainers of Spacewalk packages
Hi, I'm developer of Spacewalk [1,2]. Spacewalk is an open source (GPLv2) Linux systems management solution. It is the upstream community project from which the Red Hat Network Satellite product is derived. Recently we added initial support for Debian [3,4]. We even build packages for Debian [5]. However - I'm not sure if we have capacity and resources for maintaining Debian packages properly. I mean: to follow all the best practices of Debian, to become Debian maintainer... So I'm looking for Debian developer/maintainer who would like to maintain those 10 packages. I will be glad even if you are willing to maintain even some package(s). Volunteers? If you have questions, I'm ready to help you as best as I can. BTW: our plan for summer, is to develop plugin for apt-get which allows you to download packages from Spacewalk server directly using apt-get. That is last missing piece for declaring support for Debian as complete. [1] http://www.redhat.com/spacewalk/ [2] https://fedorahosted.org/spacewalk/ [3] https://fedorahosted.org/spacewalk/wiki/Deb_support_in_spacewalk [4] https://www.redhat.com/archives/spacewalk-list/2010-May/msg00208.html [5] https://build.opensuse.org/project/show?project=home%3Axsuchy%3Adebian-spacewalk Miroslav Suchy -- ,,, (o o) =oOO==(_)==OOo=== ) mailto:miros...@suchy.cz ( ICQ: #70802630 tel:+420-603-775737 skype:MiroslavSuchy )echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc (Oooo._ .oooO ( ) ( )) / \ ((_/ \_) -- 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/4bff41cb.6020...@suchy.cz
Re: Looking for maintainers of Spacewalk packages
On Fri, May 28, 2010 at 06:08:43AM +0200, Miroslav Suchý wrote: > Hi, > I'm developer of Spacewalk [1,2]. Spacewalk is an open source > (GPLv2) Linux systems management solution. It is the upstream > community project from which the Red Hat Network Satellite product > is derived. > > Recently we added initial support for Debian [3,4]. We even build > packages for Debian [5]. However - I'm not sure if we have capacity > and resources for maintaining Debian packages properly. I mean: to > follow all the best practices of Debian, to become Debian > maintainer... > > So I'm looking for Debian developer/maintainer who would like to > maintain those 10 packages. I will be glad even if you are willing > to maintain even some package(s). Volunteers? If you have questions, > I'm ready to help you as best as I can. > As a Red Hat and Centos sysadmin and user, primarily at work, and a very rusty Debian developer, I'd be willing to help if needed, even if only in testing. > BTW: our plan for summer, is to develop plugin for apt-get which > allows you to download packages from Spacewalk server directly using > apt-get. That is last missing piece for declaring support for Debian > as complete. > > [1] http://www.redhat.com/spacewalk/ > [2] https://fedorahosted.org/spacewalk/ > [3] https://fedorahosted.org/spacewalk/wiki/Deb_support_in_spacewalk > [4] https://www.redhat.com/archives/spacewalk-list/2010-May/msg00208.html > [5] > https://build.opensuse.org/project/show?project=home%3Axsuchy%3Adebian-spacewalk > > > Miroslav Suchy > AndyC -- 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/20100528050152.ga23...@galactic.demon.co.uk
Bug#583524: ITP: marave -- A text editor that helps you focus on writing
Package: wnpp Severity: wishlist Owner: Chris Silva * Package name: marave Version : 0.7 Upstream Author : Roberto Alsina * URL : http://code.google.com/p/marave/ * License : GPL-2 Programming Lang: Python, Python-QT4 Description : A text editor that helps you focus on writing Inspired by ommwriter and other similar projects, marave (it means "nothing" or "it doesn't matter" in guaraní) aims to be a simple, clean text editor that doesn't distract you from your writing. * Clean interface. Most of the time: NO interface * Pretty * Customizable You can have a nice background, or just a color. You can have a realtime spellchecker or not. Syntax highlighting or not. You can have background music, keyboard feedback, or silence. Marave will try to be the way you want it to be. -- 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/20100528044544.25382.1.report...@chris.makeworld.com
Re: Recent changes in dpkg
Le jeudi 27 mai 2010 à 13:38 -0500, Peter Samuelson a écrit : > It's pretty clear that this is social engineering. The dpkg > maintainers want to force every package maintainer to _think_ about > which source format they wish to use. To ensure that, in the long run, > you no longer have the choice to simply ignore the format war. > > I am puzzled by one thing, however. There is another thing that puzzles me: that people think there is a format war. We have a new format that is better in all respects. Let’s just migrate to it. We can take 2, even 3 releases if it’s what it takes, but there’s just one day when it becomes pointless to support an old format. Face it: in a few years, no one will care about the 1.0 format anymore, regardless of how much virulent they are today. Raphaël didn’t always do a good communication job around this format and maybe not all changes were introduced in the right order. But now people are using this as an excuse for something I know very well from work: change resistance. Whatever change you implement, some people will actively work against it, generally with no rational reason. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Meaning of the different “format” fields and files.
On Thu, 27 May 2010, Charles Plessy wrote: > * In Debian changes files, Format is currently 1.8; I suppose that it >defines the meaning and syntax of the other fields. Is there a place were > the >history of this file format is defined? Is it a general format number for > what >we call the “pseudo RFC-822”, “paragraph”, or “stanza” format? > > * In the Debian source control files, Format is 1.0 or 3.0 (variant). This >defines the format of the source package. Is the format of the Debian > source control >file itself tied to the format of the source package, or is it independant > as for >the changes files? > > * §5.6.16 specifies a value of 1.5 for all Format fields. Is it a source > package format >version or a “pseudo RFC-822” format version. If yes should this number be > updated to 1.8, >or even to 1.9 to reflect that the Format field is deprecated in source > package >control files? > Answer to those questions in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547272 > * 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? You mean updated to say that the Format: field has no place in debian/control? I don't think we have to say where it's not allowed, only what the proper place is for the given information. > * 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? That directory is not covered by a global version number. Individual tools putting/using files there are responsible of the format of the files and their evolution. It's mainly dpkg-source though as the name suggests. As usual, it's a good idea to prefix filenames if you're going to create new files that reside there (some *-buildpackage tools might want to use it) to avoid namespace collisions. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100528062525.ga4...@rivendell
Re: Source packages: standard formats and interfaces as an alternative to centralisation.
On Fri, 28 May 2010, Charles Plessy wrote: [ Skipping the part that makes no sense to me ] > With a simple debian/rules target, for instance ‘source’, the conflict about > the source package formats can be made much milder, because it will be the > choice of the maintainer to use or not dpkg-dev, debian/source/format, and the > automatic patch production system. That's going further than for the binary package building, even if the process is controlled by debian/rules, it's always the dpkg-dev scripts that are underlying and dpkg-deb -b. Taking entirely dpkg-dev out of the story for building source packages is not a desirable outcome IMO. And in any case you need at least support of dpkg-buildpackage to call whatever new interface that you design for that purpose. > This solution would bring do-o-cracy back in the loop, with the dpkg-dev I don't think we have ever lost do-o-cracy... > (that they are in the first line to shape), and the package maintainers free > to > use another way if they dislike the approach taken by dpkg-dev. That's counter-productive. We have far more flexibility in dpkg-source than we ever had before, people could even invent new source formats outside of dpkg-source and gain traction before getting them merged officially. I'm also not a dictator imposing my view (although some people like to think that) I have changed my mind several times based on the feedback that I got. I'd rather have further changes on the topic backed by a DEP to avoid the miscommunication that we had concerning the new source formats. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100528064023.gb4...@rivendell
