Huh, gcc 2.95.3?
Happy new year to everyone! gcc 2.95.3 appeared in Sid, but it hasn't been announced by the GCC steering committee yet. Is this some kind of early access version? Regards Harri
Re: Huh, gcc 2.95.3?
Ben Collins wrote: > > On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote: > > Happy new year to everyone! > > > > gcc 2.95.3 appeared in Sid, but it hasn't been announced by the > > GCC steering committee yet. Is this some kind of early access > > version? > > It's based on the CVS branch, which is noted in the changelog if you had > bothered to read it. To read the changelog I have to download and install it. But I don't like to install unknown compilers on my development machines. Especially since there is no undo operation for dpkg -i. > There's no such thing as "early access", this is > open source you know :) > My (personal) definition for 'Early Access Software' is that somebody has grabbed a more or less stable version with the knowledge of the maintainers before the official release date. I cannot see why this definition shouldn't be applicable to GPL software. Regards Harri
why do I need EMail to install some debs?
Hi folks, Would it be possible to get rid of the need to install EMail (e.g. exim or sendmail) by default? I think it is pretty ugly that the installation from scratch of Sid on my PC got stuck several times, because EMail is not correctly configured. I would prefer to avoid installing a local SMTP service at all. To do EMails I am using a POP, IMAP, or SMTP connection to a remote host. Regards Harri
Re: why do I need EMail to install some debs?
Hi Simon, Simon Richter wrote: Harald, Would it be possible to get rid of the need to install EMail (e.g. exim or sendmail) by default? A lot of packages need at least the /usr/sbin/sendmail program, to be able to send email to the admin, for example cron or at, which send the Sure. I am not talking about runtime, but installation time. AFAIR the interface to use is called debconf. Obviously some packages want to be very sure that I get some important messages, and try to send me an EMail instead (or in addition). The sendmail package told me at installation time that I could skip configuration now, and do the configuration later by calling sendmailconfig. Exim provides a similar option. Obviously this option leads into a conflict with some subsequent packages relying upon a working EMail configuration within the same installation session. My suggestion would be to use debconf only. output of the program they ran. You should install the ssmtp package, which is just what you need (a simple MTA that does not offer SMTP service but follows the standard local calling conventions and can thus be used as a replacement for a full-featured mailer). I have to admit, I haven't tried ssmtp yet. I am using sendmail for years. Regards Harri
Re: Dependency problems with Xorg
Goswin von Brederlow wrote: > yes > > welcome to the c++ abi transition > > Maybe this has been suggested before, but... Probably more C++ abi changes will follow. To support a smooth migration I would like to suggest to create empty packages describing the C++ abis. A package maintainer could add the C++ abi package to the dependency list. When a new C++ abi gets introduced, and the first packages with a dependency to the new abi package appear, then these packages are automagically put on hold till all packages in the whole dependency chain have been migrated. Surely the package name or the version number are the wrong place to describe the C++ abi. Just an idea. Regards Harri signature.asc Description: OpenPGP digital signature
Re: Dependency problems with Xorg
Goswin von Brederlow wrote: > > A single C++-ABI package would just mean that all c++ packages are > kept back (or removed) from the very start of the c++ transition up to > the very end. There will be a lot of packages at the end of the > dependency chains that you don't have installed and that will take > long to fix. Do you realy want to wait for every last one to get > fixed? > The dependencies are verified just for the installed packages, plus the newly selected, minus the packages to be deinstalled, AFAIK. To avoid waiting I could remove packages sticking to the old abi. > Even worse you couldn't install g++-3.3 and g++-3.4/4.0 in parallel as > the libstdc++s would depend on conflicting C++-ABI packages. > But the ABIs conflict, anyway, regardless whether there is yet another package or not. A clean way to create packages for the new abi is to debootstrap a new chroot without references to the old abi, and use this environment for building and testing. But I can follow your argument. Dpkg should allow installing different C++ abis on the same machine. Only within each dependency chain the abi version number must be unique, so it should become some kind of package attribute. This would allow dpkg to verify the abi version. I just want to avoid that somebody else breaks the dependencies of my package by dropping the old name and introducing a new one for the same library, just because we changed a low level interface that usually should be transparent to everybody. Regards Harri signature.asc Description: OpenPGP digital signature
Re: Dependency problems with Xorg
Goswin von Brederlow wrote: > Harald Dunkel <[EMAIL PROTECTED]> writes: > >> >>But I can follow your argument. Dpkg should allow installing >>different C++ abis on the same machine. Only within each >>dependency chain the abi version number must be unique, so >>it should become some kind of package attribute. This would >>allow dpkg to verify the abi version. > > > And that is what the c102 / c2 is about. :) > I know, but as written before, IMHO the abi version number should not be encoded in the package name. Usually you just get a new abi, but no new functionality, so why introduce a new name? Just to work around the limitations of dpkg? It is my suggestion to extend dpkg instead. Some packages don't follow this naming convention, anyway (e.g. libglu1-xorg, libstdc++-4.0, others?). > Say every package provides libfoobar-c++abi2 that would mean you would > double the depends of every c++ package. Vou need versioned depends on > libs and provides can't be versioned. So you need to depend on both > the lib and the abi. Doesn't appending c2 sound better? > No. Of course it is more difficult for dpkg to verify both package dependencies and package attributes. But there are some differences between the package dependency list and the package attributes: The attributes must match exactly, and there is no recursion. It is still a string compare, as with the package name. > >>I just want to avoid that somebody else breaks the dependencies >>of my package by dropping the old name and introducing a new one >>for the same library, just because we changed a low level >>interface that usually should be transparent to everybody. > > > The break you get anyway. If the library provides a different c++ abi > dpkg must not allow it to be used for your old package, no matter how > you implement this. > If the abi version gets a package attribute, then chances are high that I just have to rebuild my package to support a new abi. If the abi version gets encoded in the package name, then everybody with a C++ package has to - introduce a renamed package for the new abi - change the dependencies of his package to catch the other new package names - build the new package - make the old package obsolete sometimes Seems to be a lot of effort for something that should be hidden deep inside. > Hey, lets hope this is the last C++ transition ever. At least until > g++ 4.1 :) > What will happen if the abi changes just for one platform, lets say for the Arm cpu? Does everybody have to rename his packages again? Regards Harri signature.asc Description: OpenPGP digital signature
question: bugfixes in experimental?
Hi folks, I've got a problem with marking broken packages as fixed. If there is (lets say) a grave functionality bug for package "M" in unstable or testing, then a bugfix in experimental doesn't help me. (I made very bad experiences with experimental, e.g. broken version numbers, currupted apt system, etc., so this stuff won't be installed on my PC.) Shouldn't it be some kind of policy to mark a bug as fixed, only if the fix is available on the same level as the previous broken package? Regards Harri signature.asc Description: OpenPGP digital signature
ignoring upstream's version number?
Hi folks, What happens if a package maintainer ignores upstream's version number (either on purpose, or by accident, e.g. a typo)? Is this allowed? Regards Harri signature.asc Description: OpenPGP digital signature
Re: ignoring upstream's version number?
Jose Carlos Garcia Sogo wrote: > El dom, 31-07-2005 a las 19:13 +0200, Harald Dunkel escribió: > >>Hi folks, >> >>What happens if a package maintainer ignores upstream's >>version number (either on purpose, or by accident, e.g. >>a typo)? Is this allowed? > > > If it is done on purpose and for a given reason, it can be perfectly > valid. If not, you can consider that a bug, as usually package should > have the same version than upstream's distributed sources. > And how is this going to be fixed? The broken version number might be much higher than upstream's version number. AFAIK there is no way to turn it back, is it? The package I have in mind (fvwm) introduced a broken version number 2.5.130.CVS.2005.07.19.01-1 instead of 2.5.13-0.CVS.2005.07.19.01-1 Creating a bug report (#319386) did not help. Regards Harri signature.asc Description: OpenPGP digital signature
Re: ignoring upstream's version number?
Philipp Kern wrote: > > The maintainer could use an epoch to fix it. (It's like a 1: prefix.) > > >> 2.5.130.CVS.2005.07.19.01-1 >> 2.5.13-0.CVS.2005.07.19.01-1 > > > Is it really important to have the 0 split away? I think while dashes > are perfectly valid when there is a Debian revision they are not really > loved by the maintainers. > I'm running my own fvwm package for several years. Now it appears to be always out-of-date, since the broken upstream version number part of fvwm in the official repository seems to have jumped from 2.5.12 to 2.5.130.xxx instead of 2.5.13. The epoch number is not supported in the official fvwm sources. Annoying. Regards Harri signature.asc Description: OpenPGP digital signature
Re: ignoring upstream's version number?
Jose Carlos Garcia Sogo wrote: > > You can also add the epoch number to your own packages. Thus, they will > be always newer than those coming from Debian, so they won't be > upgraded. Of course you don't have to add epochs to upstream sources. > That is not the goal of an epoch. > Upstream provides a debian build environment, of course without epoch. Its just a little bit strange: After running configure you can run "make deb-dist". It will call dpkg-buildpackage to build *.deb files. Regards Harri signature.asc Description: OpenPGP digital signature
"Mozilla" plugins to depend upon virtual "mozilla-plugin-browser"?
Hi folks, Would it be possible that the "Mozilla" plugins depend upon a virtual mozilla-plugin-browser package? All browsers with the same plugin interface could provide this feature, and foreign browsers would not be kept out. Many thanx in advance Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
many packages FTBFS, if $TAPE is set
Hi folks, Many packages FTBFS (silently!) if an environment variable TAPE is set. That happens if your rules script uses something like tar -c modules | bzip2 -9 > omfs.tar.bz2 for example. If $TAPE is set, then tar writes to $TAPE instead of stdout (possibly corrupting the tape you had inserted). bzip succeeds (regardless whether a tape is in), rules succeeds, but your *.deb file is bad. I am sure you agree that this is a fatal failure in the package. It should be tar cf - modules | bzip2 -9 > omfs.tar.bz2 But most people simply don't know that their rules file corrupts tapes. First thing would be to detect these packages. This could be done in the autobuild procedure done on the debian hosts, e.g. by setting $TAPE to point to some kind of "watchdog file". If the build succeeded, but the watchdog file contains some data, then obviously something went wrong. Regards Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: many packages FTBFS, if $TAPE is set
Hi Bas, You could write 'tar cfz file.tgz files' instead of 'tar -c -f file.tgz -z files'. Seems that looking for a missing '-f' or 'f' would be pretty error-prone and much more difficult than a simple "test ! -s watchdog.tar" after building the package. My point is: We need some central quality check here, however it is done. Many packages use 'tar' in their rules file. Surely every maintainer should verify his/her own package. But in this case a central check would be cheap and easy to implement. Almost zero effort compared to the damage done by corrupting tapes. Regards Harri Bas Zoetekouw wrote: Hi Harald! It should also be possible to detect with with lintian, I would think. Simply checking for a tar invocation without -f option should do the trick. Regards, Bas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: many packages FTBFS, if $TAPE is set
Hi Eduard, Eduard Bloch wrote: verify his/her own package. But in this case a central check would be cheap and easy to implement. Almost zero effort compared to the damage done by corrupting tapes. Oh, come on. People who put $TAPE into the default environment may also link /dev/null to /dev/hda (or /dev/sda) and complain to the coretutils maintainer because ln isn't unable to think for them. Its a weird analogy, but I can guess your meaning. $TAPE was set by default for historical reasons. I just did not expect that rebuilding a package would corrupt my tape, and when I noticed it was too late. I was pissed. Sorry for that. Regards Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
problem with /etc/kernel scripts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi folks,
I am using upstream's build procedure for creating Linux kernel packages
("make deb-pkg"). For 2.6.38 it gives you these packages:
linux-firmware-image_2.6.38-1_amd64.deb
linux-headers-2.6.38_2.6.38-1_amd64.deb
linux-image-2.6.38_2.6.38-1_amd64.deb
linux-libc-dev_2.6.38-1_amd64.deb
Problem: The run-parts scripts in /etc/kernel/postinst.d are run
by the linux-image postinst script before the header files are
installed. Of course this fails for the dkms script on the first
installation of a new kernel version.
Obviously the dkms script should not be run by the postinst script
of linux-image, but of linux-headers. Shouldn't we distinguish
between the hooks for linux-image and for linux-headers somehow?
Any helpful comment would be highly appreciated. Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2GIesACgkQUTlbRTxpHjeRFgCff7rgJ6FfpLYHdbWlrR/yxuT8
8tEAoITgOAI5Rosk4+3aP2xzQoomveKC
=nl77
-END PGP SIGNATURE-
--
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/4d8621ec.2020...@afaics.de
Re: problem with /etc/kernel scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/20/11 18:23, Ben Hutchings wrote: > On Sun, 2011-03-20 at 16:49 +0100, Harald Dunkel wrote: >> >> Obviously the dkms script should not be run by the postinst script >> of linux-image, but of linux-headers. Shouldn't we distinguish >> between the hooks for linux-image and for linux-headers somehow? > > The headers package should invoke hook scripts in > /etc/kernel/header_postinst.d (etc). dkms already installs a hook > script there. > Sorry, I missed that. Do you think that dkms should drop its /etc/kernel/postinst.d/dkms script? AFAICS this script might be called before the headers are installed. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2G31kACgkQUTlbRTxpHje7SwCgjFI42b9NNVRRFpcNzLUi5yLE H+MAnjvERqxcaPe1aPdSxaXamzdorhJF =yiES -END PGP SIGNATURE- -- 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/4d86df5f.3020...@afaics.de
Re: g++ 3.2 on woody ?
Hi Nikita, Nikita V. Youshchenko wrote: Hello. I wanted to install g++ 3.2 (instead of 3.1 that is buggy) on our server running woody with several packages from unstable. I noticed that g++ 3.2 depends on recent libc6. Is it safe to install libc6 from unstable now? Are libdb problems resolved? I would guess its more safe to build and install gcc 3.2 in your /usr/local directory tree than upgrading glibc. 3.2 is not yet released, but thats just a matter of some days (hopefully). You can find the latest snapshot in ftp://gcc.gnu.org/pub/gcc/ . Please note that the C++ ABI has been changed with gcc 3.2. The "old" libraries compiled with g++ 3.0.x or 3.1.x can't be used with 3.2 anymore. And you might want to check this page: http://gcc.gnu.org/gcc-3.2/c++-abi.html Good luck Harri
Re: FVWM 2.5.x debs
Hi Alex, Alexander Kotelnikov wrote: Hello. Recently I was reported [1] by Marco d'Itri that FVWM from stable branch (2.4.x) does not work with GNOME2, so he requested 2.5.x packages from me. Olivier Chapuis clarified the situation in his reply [2] to my question in fvwm-workers mailing list. FVWM packages are ready and apt'able now for stable and unstable on 386 architecture. Sources are provided in unstable branch only (since stable package is just a rebuild). Would it be possible to add these packages to the official pool for Sid? fvwm 2.5.6 is surely stable enough for daily use, but I can speak just for i386 here. Regards Harri
package servers inconsistent?
Hi folks, Is it possible to keep an eye upon package consistency on the hosts 'http.us.debian.org'? Each time I run 'apt-get update', some of the package lists on my machine seem to be outdated, even if the last update has been done just a few jiffies ago. But usually the following 'apt-get ugrade' fails due to missing packages. I have to repeat this procedure several times until the upgrade can be completed successfully. Sometimes this doesn't work at all. I tried to install a caching proxy, but this did not help. Regards Harri
Re: package servers inconsistent?
Matt Zimmerman wrote: > > On Mon, Apr 30, 2001 at 08:50:06PM +0200, Harald Dunkel wrote: > > > Is it possible to keep an eye upon package consistency on the > > hosts 'http.us.debian.org'? > > > > Each time I run 'apt-get update', some of the package lists on my > > machine seem to be outdated, even if the last update has been done > > just a few jiffies ago. But usually the following 'apt-get ugrade' > > fails due to missing packages. > > > > I have to repeat this procedure several times until the upgrade can > > be completed successfully. Sometimes this doesn't work at all. > > I tried to install a caching proxy, but this did not help. > > This happens because the Packages files on the mirrors are updated before all > of the .debs have been transferred. The errors are transient, and only happen > during the mirror updates. It is probably more trouble than it is worth to > try > to fix this. Maybe its too difficult to provide consistent package files for the short window while the mirror updates are running. No cons. But is it possible to set some kind of flag to indicate that I am probably downloading just some inconsistent files and that I should wait till the update of the mirror is complete? I have no problem with waiting, but currently I can just try and check whether there was an error. > The solution would involve syncing all new .debs (without > deleting any), then updating the Packages files, then removing the old .debs. > This has the nice side effect of ensuring that things are consistent even if > the update is interrupted, but would consume a lot of additional mirror space > during the updates, and complicate the process. > > Another "solution" would be to remove the Packages files during the update, > but > I think almost everyone would rather have an inconsistent Packages file than > none at all. > Sorry, but this is not true. An inconstistent package file (i.e. a database of packages that might be no longer available) is of no use. If the package file doesn't exist I know that something is going on and that I should try again later. Regards Harri
Re: package servers inconsistent?
Matt Zimmerman wrote: > > On Wed, May 02, 2001 at 10:33:27PM +0200, Harald Dunkel wrote: > > > Matt Zimmerman wrote: > > > [...] > > > > Maybe its too difficult to provide consistent package files for the short > > window while the mirror updates are running. No cons. > > > > But is it possible to set some kind of flag to indicate that I am probably > > downloading just some inconsistent files and that I should wait till the > > update of the mirror is complete? I have no problem with waiting, but > > currently I can just try and check whether there was an error. > > It would be pretty simple to create a file to indicate this condition, which > could be tested for when doing an update. However, I don't see how it would > provide any additional information over the error messages from missing > packages. I guess it is obvious that downloading several MBytes to get an error message is not very efficient. The bandwidth could be better used to speed up the upgrade of your mirrors. > After all, if the user's upgrade will only fetch a few packages, > it's likely that the packages they want are already in place, and their > upgrade > would be successful (especially if these packages happen to fall at the > beginning of the alphabet). > Like the XWindow packages? :-) Please remember that the complete upgrade fails even if the very last package is missing. > I disagree; a packages file (even without any associated .debs) is useful; it > gives a list of packages, descriptions, dependencies, and other information. > It can be used to determine whether there are any new packages to download, or > to find whether a package exists. It would be annoying to lose this > functionality during a mirror update. Sure, but all this information is already in the Package files I have downloaded from a consistent server on the previous run. The new Package files might contain information about some *.deb files that I am not yet allowed to download, which is very frustrating. > > What about stable? Removing the stable Packages file during an update would > make it impossible to do a network install. > Not impossible. But the client would have to wait till the *.deb files have been mirrored completely and the new Package files are in place again. Removing the Package files is just one way to indicate that the mirror is in an inconsistent state. As written before, I would suggest to set a small flag file. If this file exists, then an mirror upgrade is running. It even might contain a message to be displayed at the client. Probably you haven't made the experience yet, what happens during the upgrade over a small ISDN line (which is _not_ free here in Germany, even if its a local call). Downloading the Package files takes about 4 minutes. If I do an upgrade once per week, then I have to download (lets say) 50 MBytes or 150 packages, which takes about 2 hours. Currently I have no way to check whether all *.deb files are available on the server, i.e. I have to wait up to 2 hours for an error message. Regards Harri
Caching Proxy for apt-get via http?
Hi folks, To reduce network load and speed up upgrades I have installed a caching proxy on one of my machines (using Apache). But it doesn't work very well. Packages are downloaded from http.us.debian.org, even if they should have been taken from the cache due to an upgrade of another machine just a few minutes ago. The cache size is 300 MByte, so I doubt that this happens due to lack of space. And cheating Round Robin by using an IP address instead of 'http.us.debian.org' didn't help either. Does anybody out there know what is the problem here? Maybe its the failure of Apache. What are your suggestions for running a cache for apt-get? Regards Harri
Re: Caching Proxy for apt-get via http?
Brian May wrote: > > Have you told squid that it can use greater then 100MByte (the > default)? > I haven't tried Squid yet, cause Apache was already in place. Of course I will try it. Many thanx for your configuration hints. Regards Harri
Re: Caching Proxy for apt-get via http?
Harald Dunkel wrote: > > Brian May wrote: > > > > Have you told squid that it can use greater then 100MByte (the > > default)? > > > > I haven't tried Squid yet, cause Apache was already in place. > Of course I will try it. > I've got the same effect using Squid. When I tried to install Xpilot (just for testing of course :-), then some files (not all!) were not cached, as it seems. Of course I checked the cache size, the maximum file size, etc. ??? Regards Harri
how to install KDE or Gnome on Sid
Hi folks, What is the recommended way to install Gnome or KDE? The task-XXX packages are gone for some time now, without appropriate replacement, as it seems. Regards Harri
Re: how to install KDE or Gnome on Sid
"Francesco P. Lovergine" wrote: > > On Tue, Sep 11, 2001 at 10:06:13AM +0200, Harald Dunkel wrote: > > Hi folks, > > > > What is the recommended way to install Gnome or KDE? The task-XXX > > packages are gone for some time now, without appropriate replacement, > > as it seems. > > > > apt-get install kde > Ahh. There are thousands of packages with the string 'kde' inside, so I must have missed this one. But there is no 'gnome' meta package (or I am still blind). It would be nice to get an option for dselect to list the meta packages only. The old task-XXX packages were easier to look for. Many thanx for your help Harri
Re: how to install KDE or Gnome on Sid
Ola Lundqvist wrote: > > On Tue, Sep 11, 2001 at 10:06:13AM +0200, Harald Dunkel wrote: > > Hi folks, > > > > What is the recommended way to install Gnome or KDE? The task-XXX > > packages are gone for some time now, without appropriate replacement, > > as it seems. > > tasksel may help you > Tasksel doesn't list KDE or Gnome. Regards Harri
Re: how to install KDE or Gnome on Sid
"Francesco P. Lovergine" wrote: > > Did you try > > apt-get install gdm ? > gdm is just the display manager. It's not the head of a task as kde is. > It install all libraries and binaries. Moreover, it not so clear what > a GNOME wm should be... Ximinian? Gnome 1.4BETA? > What's the current status of that strange object? > On request I have installed RedHat on several machines in the last 3 weeks. The Gnome stuff looks really great, and the inital installation was very easy. Of course RedHat cannot provide the much advanced package installation tools of Debian. But the users don't care; they want to have that nice desktop. Regards Harri
Re: sid: libc6-2.2.5-4 kills vmware workstation 3.0
May you should consider VMware's current beta of 3.1? Good luck Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
new bug severity "new upstream"
Hi folks, would it be reasonable to introduce a new bug severity "new upstream"? Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/539adccd.9040...@aixigo.de
say goodbye to network-manager-strongswan?
Hi folks, how comes that network-manager-strongswan has been dropped from testing? This package is extremely important for road- warrior setups using IPsec. Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c6514c.1030...@aixigo.de
Re: say goodbye to network-manager-strongswan?
Hi Thijs, On 07/16/14 12:35, Thijs Kinkhorst wrote: > > As it turns out, this package got removed because it has an unfixed > release critical bug (which interestingly enough you yourself reported). > When this bug is fixed, the package will transition back to testing. > Of course I know that I reported this bug (without "grave"). Did you notice that the bug report also shows how to _fix_ the problem? Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c65c76.2060...@aixigo.de
Re: say goodbye to network-manager-strongswan?
Hi Simon, On 07/16/14 12:36, Simon McVittie wrote: > > If the change you proposed works correctly, an NMU seems appropriate. > I am using the fix in a private package since I created the bug report. Seems to work fine (using strongswan 5.x). I have appended a diff to the bug report. Hope this helps. Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c6602b.6040...@aixigo.de
Re: say goodbye to network-manager-strongswan?
On 07/16/14 15:17, Holger Levsen wrote: > > Especially if the NMU is properly done (eg documented in the BTS, uploaded to > DELAYED-foo, etc) I've hardly seen any complaints in recent years. > Surely I could have done better in providing a "clean" fix to #741415, making it more easy for the Debian folks to create an NMU. Sorry. I have included a real patch in the bug report today. I also tried to set the "patch" tag, but its not clear if this succeeded. Hope this helps Harri signature.asc Description: OpenPGP digital signature
Re: Transition plan for changing the default init system
On 07/16/14 23:22, Tollef Fog Heen wrote: > So we are proposing the following scheme: > > a/ Upload a new "init" package. This is a new, essential package that > will replace sysvinit as the package that ensures your system has an > init system. We want to build this binary package from a package which > is not tied to an actual init system, so we chose the > init-system-helpers source package. Patch for init-system-helpers is > available at [2]. > > b/ Demote sysvinit to Priority: optional and install an extra copy of > the sysvinit binary into /lib/sysvinit/ so you can recover if your > system fails to boot with systemd. This can be achieved by booting with > init=/lib/sysvinit/init on the kernel command line. Patch for sysvinit > is available at [3]. > > c/ Upload a new version of the init package which does the actual switch > and changes the order via Pre-Depends: systemd-sysv | > sysvinit-core. Diff[4] > I am not sure if this matters, but it seems to me that this procedure depends upon a specific sequence of package uploads and system upgrades in the field. How do you make sure that the init from step a/ was installed, when the user sees the new init from step c/ in his favorite repository? Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c76ecb.4030...@aixigo.de
Re: nmudiff enhancements
Hi folks, On 07/17/14 03:16, Christian Hofstaedtler wrote: > * Wookey [140716 23:48]: > >> I do think there is plenty more room for soialising more NMUing. There >> are piles of bugs in the archive that mostly just need uploading, and >> many packages with a backlog of minor bugs, or packaging that frankly >> just needs updating. But a lot of this quickly gets into 'updating' >> and 'de-crufting' rather than simply minimally-bug-fixing. I suspect >> that would see more pushback if one did much of it. > > Maybe these things need to happen in teams, basically sets of people > agreeing on the same packaging principles (i.e. "we all use gbp and > single-debian-patch and dh and ...") and everybody sharing the same > goals could work on the "team" packages in collab-maint. > Maybe we should drop the current source package concept completely and provide the package sources in git repositories instead. This would allow everybody to work on a common codebase, push code into the BTS, etc. It would even be possible to push code to upstream or to the Ubuntu folks. Just dreaming. Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c77288.30...@aixigo.de
Re: say goodbye to network-manager-strongswan?
On 07/16/14 17:56, Thomas Goirand wrote: > > To try to kill your frustration, I have sponsored the upload of your fix > to the delayed/10 queue. If everything goes well, then in 15 days, > network-manager-strongswan will be back in Jessie. > Thanx very much for your help Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c7a104.20...@aixigo.de
Re: say goodbye to network-manager-strongswan?
On 07/16/14 17:56, Thomas Goirand wrote: > > BTW, it feels weird that the package build-depends on debhelper when it > really is using CDBS. The debian/copyright is also quite wrong, as it > doesn't include the copyright notice for the GPL v2 (and I believe > that's mandatory, right?). Not commenting on the fact that it's still > using the format 1.0 without debian/source/format file, etc. In other > words, I agree that this package is in the need for a bit more care. > I can send you another NMU, if you are interested? There is also a new upstream version, but I would guess this is beyond scope for an NMU? The copyright file containes a pointer to /usr/share/common-licenses/GPL-2. Is this insufficient? Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c7a83a.3030...@aixigo.de
Re: [Pkg-swan-devel] say goodbye to network-manager-strongswan?
On 07/28/14 11:38, Yves-Alexis Perez wrote: > > I don't currently use the network-manager strongSwan plugin but that's > mostly because it doesn't work. AFAICT it didn't work due to #741415. Today its broken again. It says Could not find VPN plugin service for 'org.freedesktop.NetworkManager.strongswan'. when I try to edit the strongswan configuration in the GUI. :-( It still connects using the existing IPsec configuration, though. I wonder what this is about. The n-m openVPN plugin has no such problem. > Should it work, I'm unsure I would use > it, but I do use network-manager on one laptop so I should be able to at > least test it, so I'm ok to put it under pkg-swan umbrella. But I would > also welcome anyone interested to join the team :) > Surely I would be glad to help. But there is a problem: The network-manager-strongswan package for Debian is currently maintained by upstream. I would guess a NMU is no problem, but it might lead to irritations if we hijack the package. Regards Harri signature.asc Description: OpenPGP digital signature
Re: question about versioned dependencies in debian/control
PS: The error message is: Setting up git-man (1:2.1.2-0~xgo70+1) ... dpkg: dependency problems prevent configuration of git: git depends on git-man (>> 1:2.1.2); however: Version of git-man on system is 1:2.1.2-0~xgo70+1. Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5447b995.4010...@aixigo.de
question about versioned dependencies in debian/control
Hi folks,
I am building local git packages for Wheezy derived from the
official source package. Problem with debian/control:
:
Package: git
Architecture: any
Multi-Arch: foreign
Depends: ${shlibs:Depends}, perl-modules, liberror-perl,
git-man (>> ${source:Upstream-Version}), git-man (<<
${source:Upstream-Version}-.)
:
If the top changelog line says
git (1:2.1.2-0~xgo70+1) unstable; urgency=low
then I get an unresolvable conflict for the git-man package.
Using
git (1:2.1.2-1~xgo70+1) unstable; urgency=low
^^^
there is no such problem.
How comes? Both git and git-man are built from the same
source package.
Every helpful comment is highly appreciated.
Harri
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5447b819.9010...@aixigo.de
Re: question about versioned dependencies in debian/control
On 10/22/14 16:57, Simon McVittie wrote: > > 1:2.1.2-0~xgo70+1 is less than 1:2.1.2, because 1:2.1.2 is equal to > 1:2.1.2-0 in version number order, and 0~x is less than 0. > > You can confirm this: > > % dpkg --compare-versions 2-0~x lt 2-0 && echo yes > yes > > I would suggest 1:2.1.2-0+xgo70+1 instead. > > ...2-1~xgo70+1 would be appropriate if you were backporting Debian's > release ...2-1, which is not what you're doing here. > All makes sense now :-). Thanx very much Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5447c94...@aixigo.de
question about "Conflicts:"
Hi folks, How can I tell a Debian package to conflict with a real package "foo", but not with other packages providing "foo"? Regards Harri -- 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/4f950206.8080...@aixigo.de
download of source packages alarmed clamav
Hi folks, I am running a transparent http proxy integrated with clamav. Problem: If I run "apt-get source pymilter", then I get # apt-get source pymilter Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'pymilter' packaging is maintained in the 'Svn' version control system at: svn://svn.debian.org/python-modules/packages/pymilter/trunk/ Need to get 100 kB of source archives. Get:1 http://ftp.de.debian.org/debian/ squeeze/main pymilter 0.9.3-2 (dsc) [1318 B] Err http://ftp.de.debian.org/debian/ squeeze/main pymilter 0.9.3-2 (tar) 500 Missing Content-Length Get:2 http://ftp.de.debian.org/debian/ squeeze/main pymilter 0.9.3-2 (diff) [2756 B] Fetched 4074 B in 2s (1614 B/s) Failed to fetch http://ftp.de.debian.org/debian/pool/main/p/pymilter/pymilter_0.9.3.orig.tar.gz 500 Missing Content-Length E: Failed to fetch some archives. Using a web browser for download I see a message generated by my proxy: Virus Alarm The URL http://ftp.de.debian.org/debian/pool/main/p/pymilter/pymilter_0.9.3.orig.tar.gz contains the following virus: Exploit.IFrame.Gen(4c4d77c2301e1afcbf40714b924aff6d:96362) Access denied. Powered by SquidClamAv 5.4 The same happens for a few other source packages as well. I doubt that sending a virus complies to the DFSG, so the question is whether these source packages have been compromised? Harri -- 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/51c93d1c.9030...@aixigo.de
Re: download of source packages alarmed clamav
On Tue, 25 Jun 2013 10:46:23 +0300 Marius Gavrilescu wrote: > > That package contains a directory named test/ with emails with spam, viruses > and similar. This might have caused the clamav warning. > Its not a warning. The download failed. Regards Harri -- 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/20130625095226.604b1...@dpcl082.ac.aixigo.de
Re: download of source packages alarmed clamav
On Tue, 25 Jun 2013 10:54:53 +0300 Marius Gavrilescu wrote: > On Tue, Jun 25, 2013 at 09:52:26AM +0200, Harald Dunkel wrote: > > Its not a warning. The download failed. > > Yes, I should have said failure. Anyway, the probable cause > is the existence of emails with viruses as tests in the package. These are real-life viruses that should not be distributed using Debian's FTP server (IMHO). Eicar is a test virus. -- 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/20130625101946.12b98...@dpcl082.ac.aixigo.de
usb sata docking station: backup button?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, Does anybody know some way to bind an action to the button most usb sata docking stations come with? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6RoQ4ACgkQUTlbRTxpHjdm5wCfdR2NfA3vIp48ydehS/IddLpT EVYAn24DQ3DaX3NAVUwv1d0y4rCeCP+a =/HYC -END PGP SIGNATURE- -- 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/4e91a116.9040...@afaics.de
Re: problem with /etc/kernel scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/21/11 14:22, Ben Hutchings wrote: > On Mon, 2011-03-21 at 06:17 +0100, Harald Dunkel wrote: >> >> Do you think that dkms should drop its /etc/kernel/postinst.d/dkms >> script? AFAICS this script might be called before the headers are >> installed. > > It presumably should not rebuild modules unless both the image and > header packages are installed. Depending on the order those packages > are installed, either hook may trigger this. Also, it may be useful to > warn the user when only the image package is upgraded. > Doesn't this mean that the modules are built twice? I don't see that the kernel itself would be necessary to build a kernel module. linux-headers should be installed before linux-image (if selected). The header's postinst scripts in /etc/kernel/header_postinst.d should do their job building all necessary modules, and when the kernel is installed the scripts in /etc/kernel/postinst.d should update the initrd using the new modules. Of course I understand that this is highly complex. Maybe it would help to introduce some scheme to register event handlers to run after the installation of all packages has been completed? linux-image could register a task "build a new initrd, if there are new modules", for example. Grub2 could register a task "update the grub config file, if there is a new kernel or a new initrd". And so on. The advantages would be that these actions would be run only once, and the installation sequence might be different from the sequence of postinst scripts to run. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2UQlsACgkQUTlbRTxpHjf+JACbBrFzGebg9iR2m+4PAjauA/3+ 1PYAnifK0pmhSadbybkbq7sBYOJsZmuC =cTZh -END PGP SIGNATURE- -- 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/4d94425b.70...@afaics.de
Re: problem with /etc/kernel scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ben, On 03/31/11 15:22, Ben Hutchings wrote: > On Thu, 2011-03-31 at 10:59 +0200, Harald Dunkel wrote: > [...] >> Of course I understand that this is highly complex. Maybe it would help to >> introduce some scheme to register event handlers to run after the >> installation >> of all packages has been completed? > [...] > > We had an extensive discussion defining a policy for the kernel and > initramfs builder hooks only last year. It's a little late to comment > now. > Two points about this: - - this is not a comment. Check my first message in this thread: Something tries to build a kernel module before the headers are installed. This is a bug. See #574758. - - last year was Squeeze. Now we are working on Wheezy. In 12 months when it is close to code freeze it will be too late. Today is the right time to clean this up. I would be glad to help. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2YvQ4ACgkQUTlbRTxpHjdC3wCggmPZ1xTtgupDUhBHN9/U4dcD CSEAnRepWt8Ut5y6+YJ5Z1XjcV9R1VlB =dGjg -END PGP SIGNATURE- -- 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/4d98bd0e.5020...@afaics.de
distinguish between "core" and "main"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, Having 3+ packages within a single "main" repository is pretty bulky. Would it be possible to distinguish between the "core" Debian and "main" somehow? I don't want to keep anybody out. I just would like to use the core packages of Debian release xyz (all the essential packages, for example) together with more up-to-date packages in testing (kernel & drivers, development tools, eye candy, games, etc). I checked Google for this, but I didn't find it mentioned before. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3pxoAACgkQUTlbRTxpHjfBMgCfecRKDdPb3QZZriyZiMEY8IYx 3QEAn2AOCNFqAudYrBxNeFzQJ5gIvIe4 =GseN -END PGP SIGNATURE- -- 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/4de9c680.70...@afaics.de
Re: distinguish between "core" and "main"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/04/11 07:56, Paul Wise wrote: > Sounds like you are looking for backports.debian.org? > Backports for Squeeze contains just about 400 package, AFIACS. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3p1pIACgkQUTlbRTxpHje1AwCdE1Wv9qw7wawoyZaUErkPrITg wAMAoIaw5gbjlYsdUvFmrTkInqkwsTqs =lS8N -END PGP SIGNATURE- -- 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/4de9d692.3000...@afaics.de
Re: distinguish between "core" and "main"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/04/11 09:05, Paul Wise wrote: > Alternatively you might want to install from testing directly. Not > everything from testing is installable on stable, which is where > backports comes in. Installing testing for the whole system is no option. The base system (the core packages) should be provided by the most recent release. I don't want to get an unbootable system. > > If you install from testing directly you will need some apt pinning: > > http://wiki.debian.org/AptPreferences > > Set your /etc/apt/preferences to the below and cherry-pick packages > from testing (or squeeze-backports/unstable/experimental). You will > probably encounter dependency issues, conflicts and compatibility > bugs, but apt-get upgrade will where installed, upgrade packages > within testing. Switch to a backport to avoid those issues. > This sounds like a lot of manual work. I can do that for my own desktop PC, but not for all the desktops and servers in the office. I would prefer if Debian distinguishes between core and main instead. This means splitting the current main repository. In the new system the main/testing packages should be _guaranteed_ to work together with the most recent core/stable packages. Of course they should also work together with core/testing, as they do now. Making this scheme work would imply more frequent releases for the core packages, but I am sure this can be done. I would expect that we would get <1000 core packages. Hopefully its OK if I post my ideas here? Actually this is about release management, not about development. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3p6PYACgkQUTlbRTxpHjdidwCfYWqYYAQIL8oiGrxb+psVX8nf 2PwAnR15E6Juy3N0p/mtbYV8y34CLw98 =Kalf -END PGP SIGNATURE- -- 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/4de9e8fa.3060...@afaics.de
Re: distinguish between "core" and "main"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/04/11 07:26, Andrei POPESCU wrote: > > This is one of those recurrent discussions coming up on debian-devel. It > is my impression (as a lurker) that most Debian Developers do not want > to have second-class packages and it is a feature that all packages in > main get (more or less) the same treatment regarding release and > security support. We already have priorities in Debian packages, so this would be no big difference. Looking at security: In the suggested scheme it would be easier to update an insecure package hosted in main. An explicit backport from testing to stable wouldn't be necessary, since the packages in main/testing are supposed to be backward compatible to stable on binary level. Its 1 source package to update, not 2. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3qOWwACgkQUTlbRTxpHjfcvwCfd2XAZ0Ca3YPM9aGR4dCAA4co wOsAn3TT/kY3ZVqq1ztN/8jA1/RCzZRa =AJSB -END PGP SIGNATURE- -- 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/4dea396c.3070...@afaics.de
Re: distinguish between "core" and "main"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 06/04/11 12:36, Neil Williams wrote: > On Sat, 04 Jun 2011 10:12:42 +0200 > Harald Dunkel wrote: > >> Installing testing for the whole system is no option. The base >> system (the core packages) should be provided by the most recent >> release. I don't want to get an unbootable system. > > You are more likely to get a problematic system by MIXING versions than > you are by sticking just to stable or just to testing. Unbootable is > fairly unlikely (boot loader bugs aside). > About the package set dependencies: The core package sets would be self contained, i.e. they would not depend upon packages outside of their own core set. The new main/testing repository would be meant to work with both core/stable and core/testing. Using some very rough numbers: Instead of main repositories for stable and testing with 3 packages each we would have core repositories for stable and testing with 1000 packages each, and a common non-core repository with 29000 packages, to be used together with both core/stable and core/testing. That would be 6 packages vs 31000 packages. Of course this means testing and fixing things for some packages. Compatibility is a quality criteria. >> In the new system the main/testing packages should be _guaranteed_ > > NOTHING in Debian is guaranteed. Not even in a stable release is > it guaranteed that all packages will work together. Fairly likely, yes. > Our best effort to achieve as good as we can make it - definitely. > Guarantee? Impossible. Dreamland. Tell you what, you do all the testing > and maybe Debian might refund the cost of the software - oh wait > Surely "guaranteed" was the wrong word. Please excuse this mistake. I didn't mean to upset you. > If you sincerely want the Debian system which has had the most testing > of all possible variants and which Debian can honestly describe as "the > most likely candidate for a system where packages work together as > nicely as it is practical to achieve" you MUST use stable and then keep > that up to date with the stable point releases and security updates. > The problem with this is Debian's long release cycle (+2 years, as it seems). Its difficult to get help from upstream if the source code in stable is 2 years old. Drbd, libvirt and other virtualization solutions, third party software, etc. are examples. Not to mention hardware dependencies. Not to mention that the users would like to use the most shiny new eye candy system of their dreams, and yet assume to get a stable XWindow server. >> Making this scheme work would imply more frequent releases for the core >> packages, but I am sure this can be done. I would expect that we would >> get <1000 core packages. > > No, it would require huge numbers of testers to use each possible > permutation as their daily use systems across all of the fields in > which Debian is currently used. If not, then the alternative can never > be as good as the current stable release and the whole exercise is > pointless. > Looking at today's testing and stable repositories with about 6 binary packages per platform, and the suggested core/stable, core/testing and main/testing repositories with about 31000 binary packages per platform, how many permutations would you expect for each scheme? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3qSi4ACgkQUTlbRTxpHjdsfACfblEVtn1XYthjGZrKgKp2F14l 17EAn2cFQxIdZ8yvzgWB6tOSP9PPr0oV =xrGC -END PGP SIGNATURE- -- 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/4dea4a2e.5060...@afaics.de
Re: distinguish between "core" and "main"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 06/04/11 19:01, Neil Williams wrote: > > Testing compatibility is the larger problem. Automated tests can only > go so far. Dependencies are one thing, bugs which arise because one > setup is using a version which has already been replaced in testing. > As a consumer I would like to get a system that keeps up to date (as today's testing does), but with a stable core package set. I would like to install the most recent stable core system, and use testing for everything else. All these APIs and dynamic libraries are meant to provide backward compatibility. We also have versioned package names to work around compatibility problems. But we don't really rely on this, except for updates within testing or unstable. >>> If you sincerely want the Debian system which has had the most testing >>> of all possible variants and which Debian can honestly describe as "the >>> most likely candidate for a system where packages work together as >>> nicely as it is practical to achieve" you MUST use stable and then keep >>> that up to date with the stable point releases and security updates. >> >> The problem with this is Debian's long release cycle (+2 years, as it >> seems). Its difficult to get help from upstream if the source code in > > Then use chroots, as explained in my first message but which you appear > to have ignored. > Probably I had misunderstood your "Building stuff then takes place in chroots, e.g. using pbuilder". I had associated pbuilder with "building packages". > I do this every single working day. I run a number of boxes using > stable - each has pbuilder support for sid and most have pdebuild-cross > support for cross-building for armel based on stable or unstable. > Instead of pbuilder I am using virtual machines (kvm & vserver) with testing today. Their biggest advantages (as with pbuilder I would guess) are hiding the real hardware and keeping things separate from each other. The downside is that everything gets more complex, but not necessarily more stable. You've got even more systems to run and more packages to install, not to mention that updates of the virtualization server are more difficult to do. My virtualization servers themselves were running testing, too, but since Squeeze has been released testing is changing rapidly. Currently I cannot rely upon testing for server installations. > The long release cycle arises from the very thing you appear to cherish > - the quality and stability of the stable release. It takes time and > people to generate quality. That's the entire problem - there are not > enough people to do that testing twice over. > > > Testers = people. There are as many permutations as there are testers - > or if you really want the figures, work out how many possible > permutations there are for installing 1,500 packages out of a total > selection of 31,000. Then find people to test each permutation on a > daily, regular usage basis - ensuring that each person fully tests > EVERY application in their particular set. > Understood. If you reduce the number of packages to be released by focusing on a core package set with 1000 or 1500 packages instead of +3, then your can do more rapid releases because there are fewer packages to wait for matching the release criteria. Of course this doesn't make the +29000 packages outside of the proposed core repository go away. But I think we already agreed to use testing for installations of "non-core" packages. I would guess most testing happens in unstable, before a package gets promoted to testing, anyway. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3rIiIACgkQUTlbRTxpHjfh3QCfXMKW16yza5S9sG4t7vZdNMgx ZsYAni1DtpWYxf9ubYmwCATbGXhS7LAW =lBo9 -END PGP SIGNATURE- -- 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/4deb222f.8020...@afaics.de
Re: distinguish between "core" and "main"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/05/11 13:17, Tshepang Lekhonkhobe wrote: > On Sun, 2011-06-05 at 08:29 +0200, Harald Dunkel wrote: >> >> Understood. If you reduce the number of packages to be released by >> focusing on a core package set with 1000 or 1500 packages instead >> of +3, then your can do more rapid releases because there are >> fewer packages to wait for matching the release criteria. > > By rapid releases, are you referring to core/stable or main/testing? How > rapid? Do you mean people would now do system upgrades in less than 2-3 > years (life of a Debian release)? > Only core/stable should be released. The "rest" comes from main/testing. I cannot speak for others, but I don't wait 3 years. I do regular updates/upgrades to include the most recent security and bug fixes. We've scheduled regular maintenance weekends every 3 months for this. Important updates are installed immediately. >> Of course this doesn't make the +29000 packages outside of the >> proposed core repository go away. But I think we already agreed to >> use testing for installations of "non-core" packages. > > But it makes them second-class. They are surely not second-class, they are just not within core/stable. Debian already classifies packages in different priorities, to be used today when package updates are pushed into testing, for example. I just cannot use these priorities in sources.list, _and_ I cannot rely upon the packages in today's testing to work with the core packages in stable > Also, backports is supposed to fix this > anyway. All needed there is volunteers willing to do the work. Why would > you want a different scheme? > Because backports is not supported as good as the current testing repo. Why have a 3rd repository next to stable and testing with a similar package set, instead of keeping an eye upon compatibility right from the start? I understand that splitting main into core/stable and main/testing would be a deep cut. Surely I do not expect it to happen within the next few weeks or months. Just think about it. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3rqIYACgkQUTlbRTxpHjcGBQCeLcGloib4F3WXlHz/GeHCazyd ja4An2lzCyVvGrQUyVLjWvXipyZyY0cO =Bz2S -END PGP SIGNATURE- -- 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/4deba886.5000...@afaics.de
Re: distinguish between "core" and "main"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/06/11 07:06, Russ Allbery wrote: > > I still think this whole conversation is based on a false premise. I > think the original request originated from a belief that there is some > separable part of "core" Debian which could be held stable, and that > keeping that portion stable while using testing packages for everything > else would improve the stability of the system. > Not exactly. I would like to get a stable build and runtime environment for the packages in main/testing. That doesn't mean that there are no newer versions of the same tools installed in parallel, as it is done today with gcc vs gcc-4.6, their runtime environments, and a lot of other packages. I would like to suggest to keep these core packages in a seperate repository, though. > I don't think either of those assumptions are true. There is a *lot* of > entanglement between new packages and new libraries that goes deep into > what one would call "core," and the few things that are so stable that > they wouldn't require upgrading to support testing packages also hardly > change from release to release and are really unlikely to break in > testing. > The core should be self-contained. I would guess you doubt that this is possible? Surely it would be difficult to know where to cut the line. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3tVvwACgkQUTlbRTxpHjem2QCfbU1V7Bbpcgpq9Gs4B8fZ6kcF QjkAnijWsY1yM6pYeFrPjt2X2/40g4OP =x0v5 -END PGP SIGNATURE- -- 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/4ded5701.7020...@afaics.de
Re: distinguish between "core" and "main"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/11 00:59, Russ Allbery wrote: > Harald Dunkel writes: > >> Not exactly. I would like to get a stable build and runtime environment >> for the packages in main/testing. > > Yes, that's what I'm saying doesn't actually exist. There isn't, in > Debian, such a thing as a "build and runtime environment" that's separate > from the packages. The packages *are* the build and runtime environment. > There already is: Debian is shipping a "stable" gcc/g++ in parallel to an up-to-date version, for example. My suggestion is to extend this scheme, and to keep these packages separate from the current testing. > It's kind of like asking for walls separate from your house. > Its more like keeping the basement stable, while building new walls on top of it. > > More just irrelevant. It doesn't matter whether the core is > self-contained for what you're proposing. The problem is that the > packages that you want to run depend on newer versions of the packages > that you consider core, for basically any useful definition of "core." > I do not see that. All packages were available at build time in the right version. Where should this broken dependency come from, unless you are ignoring dependencies on promoting packages from unstable to testing to stable? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3xqpEACgkQUTlbRTxpHjdA7wCfbEt+vz9mO8INYg8vNCtFiOJk JNQAn2m1+g53dN0zno9BtSnq5opJHLL+ =nIMt -END PGP SIGNATURE- -- 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/4df1aa96.8090...@afaics.de
Re: distinguish between "core" and "main"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/10/11 07:24, Harald Dunkel wrote: > > I do not see that. All packages were available at build time in > the right version. Where should this broken dependency come from, > unless you are ignoring dependencies on promoting packages from > unstable to testing to stable? > More precisely: ... promoting packages from unstable to main/testing or core/stable? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3xq8YACgkQUTlbRTxpHjercQCfeQrKb2nA6NgBXfQtjcBpDOdf BbIAniKJEEHsQSPf9awrjBLt+Fa/eaDD =2Hbr -END PGP SIGNATURE- -- 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/4df1abc6.7020...@afaics.de
how to divert /etc/profile?
Hi folks, I would like to install a private package diverting /etc/profile (to support /etc/profile.d). Problem: There is no owner for this file. What would you suggest? Any helpful comment would be highly appreciated. Harri -- 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/4e118d02.3000...@aixigo.de
Re: how to divert /etc/profile?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/04/11 12:32, Timo Weingärtner wrote: > Hi Harald, > > Am Montag, 2011-07-04 schrieb Harald Dunkel: >> I would like to install a private package diverting /etc/profile (to support >> /etc/profile.d). Problem: There is no owner for this file. >> >> What would you suggest? >> >> >> Any helpful comment would be highly appreciated. > > See /usr/share/doc/base-files/README. > I am running Debian since Hamm, but I never recognized /usr/share/base-files before. Many thanx. Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4R6joACgkQUTlbRTxpHjf4YgCgiQZ/lb4cxxTbyiK6Y00C3qp/ sBkAn19u9eVihzkudurrurlxuYpvP1if =cimK -END PGP SIGNATURE- -- 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/4e11ea3a.3000...@afaics.de
combined dependencies?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, would it be possible to support combined dependencies, e.g. if package A and B are installed, then package C(A) has to be installed, too? That might be helpful for dkms packages, for example. A would be the kernel, B the dkms package, and C(A) would be the headers for A. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5PUdgACgkQUTlbRTxpHjfYfQCfWM1RisxvS7Go1uHpKt2dPnzW BC4An15/uHt09paP913+Ibeb2Q8PQxFO =vSXj -END PGP SIGNATURE- -- 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/4e4f51dd.2090...@afaics.de
Re: combined dependencies?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michael, On 08/20/11 08:55, Michael Tautschnig wrote: > > What event would induce installation of C(A)?! Let's assume neither A nor B > are installed. > > apt-get install A (no point installing C(A)) apt-get install B (B does not > depend on C(A), otherwise this discussion is pointless) > B _does_ depend on C(A), if A is installed. > ... time passes ... > > magic install C(A) ??? > > > Isn't all you want a hard dependency of dkms on both the Linux kernel and its > header package? It seems that right now this is just a Recommends. Could you > maybe elaborate why a proper Depends: is not appropriate in your opinion? > Its not any header package: dkms needs the _appropriate_ header package matching the installed kernel package. If linux-image-2.6.39-1-amd64 is installed, then dkms needs linux-headers-2.6.39-1-amd64. If linux-image-3.0-1-amd64 is installed in parallel, then dkms needs linux-headers-3.0-1-amd64, too. Its just an example, anyway. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5QLTwACgkQUTlbRTxpHjfV9QCgkmbeutp6/YRKY6c0mp9irZqh TC4AoIBa6sBYeExw9eZLNgx+/dsg0DBn =SRKl -END PGP SIGNATURE- -- 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/4e502d42.5010...@afaics.de
network-manager-strongswan kicked out from Jessie, even though there is a fix?
Hi folks, Do you think it would it be possible to fix network-manager-strongswan for Jessie? Currently it seems it has been kicked out due to #773764, even though the report provides an easy fix to make it work at least for xfce4 and gnome on Jessie. I have pushed an NMU (1.3.0-1.2) to mentors for your consideration. http://mentors.debian.net/package/network-manager-strongswan Thanx in advance. Keep on your good work Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54d1edc3.90...@aixigo.de
Re: network-manager-strongswan kicked out from Jessie, even though there is a fix?
On 02/04/15 12:22, Dominique Dumont wrote: > > According to PTS [1], this package was kicked out because of > a FTBS [2]. Is this bug fixed ? > Sorry, I had built network-manager-strongswan on Wheezy to use it on Wheezy and Jessie. I didn't notice the FTBFS on sid. Building on Jessie I still get the error about using deprecated header files. The package built on Wheezy installs and runs fine on both. Upstream seems to be aware of the problem (see https://wiki.strongswan.org/issues/797), but it is pretty unlikely that there will be a fix for 1.3.0, so I wonder what is the recommended procedure to make an exception and to override the deprecated-declarations error for Jessie at build time? Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54d2149b.5000...@aixigo.de
Re: network-manager-strongswan kicked out from Jessie, even though there is a fix?
On 02/04/15 12:22, Dominique Dumont wrote: > > According to PTS [1], this package was kicked out because of > a FTBS [2]. Is this bug fixed ? > I have pushed a new version 1.3.0-1.3 to mentors, providing a workaround for #773764 as well. http://mentors.debian.net/package/network-manager-strongswan It would be nice if n-m-s could make it into Jessie. Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54d37bdb.1000...@aixigo.de
Re: network-manager-strongswan kicked out from Jessie, even though there is a fix?
On 02/05/15 15:38, Dominique Dumont wrote: > > Sorry that's not possible: this package was removed from Jessie back in > September. Freeze policy excludes package removed more than 1 week ago [1] > Highly discouraging. Feels like I wasted my time. :-( -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54d387c0.7070...@aixigo.de
Re: network-manager-strongswan kicked out from Jessie, even though there is a fix?
On 02/05/15 16:58, Thibaut Paumard wrote: > > I understand that it can make you sad, especially since you missed the > final deadline by only a few days, but you didn't waste your time: its > too late for jessie, but you will be able to push your package into > jessie-backports, once it is available, which should be soonish (part of > the infrastructure is [1]ready). > No problem with me, but technically it would be a "jessie-forwardport". The version I fixed is in Wheezy. There is no sign of it in Stretch. Since these bugs have a pretty high severity (grave and FTBFS), I wonder if it would be possible to include the fixes into the wheezy-updates branch? Just to make sure they are not lost, and it would reduce overall bug count. Not to mention that the Ubunto folks could pick it up from there. Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54d4657c.9010...@aixigo.de
Re: network-manager-strongswan kicked out from Jessie, even though there is a fix?
On 02/06/15 10:01, Dominique Dumont wrote: > > network-manager-strongswan is still in unstable and will be part of stretch > once jessie is out and the RC bugs are fixed. > Sorry, I thought it was kicked out completely. > Your work is definitely not a waste of time: it can be used for stretch or > for > jessie-backport > I will look on the mentors mailing list for a sponsor, unless there is a volunteer reading this? Surely the NMU needs some polish. I would be glad to contribute. Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54d4c0bf.60...@aixigo.de
conflicts between Debian's and upstream's Debian package
Hi folks, I would like to use upstream's Debian/Ubuntu packages for a certain tool 'foo'. Its closer to what I need, and I don't have migrate between both versions before asking the mailing list for help or for reporting/fixing problems. Problem: The Debian maintainer messed up the version numbers and had to introduce a "1:" for his foo package. Now upstream's package always appears to be out of date, forcing me to override apt-get. If upstream's Debian package of a tool is "not good enough" for Debian for some reason, wouldn't it be reasonable to avoid a naming conflict on creating the Debian package? Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnkpovo7@sylvester.afaics.de
Re: conflicts between Debian's and upstream's Debian package
Hi Daniel, On 02/20/15 13:09, Daniel Leidert wrote: > > Just to understand your problem: there is a package foo. Debian provides > it with version 1:A-B and upstream provides some self-compiled packages > with the same name under version C-D (and C-D < 1:A-B) and you want to > force apt to install the package from the upstream developers site. Not exactly: I want to avoid that such a mess happens again. I think its obvious that a naming conflict should be avoided. Having 2 source or binary packages with identical names in 2 independent repositories is just asking or troubles. IMHO there should be a policy for the special case, that there is a naming conflict between upstream's source or binary packages, and the packages included in Debian. Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54e743dc.8090...@aixigo.de
Re: conflicts between Debian's and upstream's Debian package
Hi Andreas, On 02/20/15 18:54, Andreas Tille wrote: > Hi Harald, > > Is there any reason why you do not even now are talking about package > name and upstream URL featuring the same name? Its not fruitful to > leave your discussion partners in the dark. > Sorry, but I don't want to blame anybody producing "bad" packages. It shouldn't matter here. Hope you agree? Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54ec860b.1060...@aixigo.de
Re: conflicts between Debian's and upstream's Debian package
On 02/24/15 15:09, Harald Dunkel wrote: > > Sorry, but I don't want to blame anybody producing "bad" packages. > It shouldn't matter here. > Should be: Sorry, but I don't want to blame anybody to produce "bad" packages. Name and upstream URL shouldn't matter here. Sorry for my bad English. Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54ec884a.1030...@aixigo.de
DEB_SIGN_KEYID vs DEBSIGN_KEYID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi folks, Trying to get rid of my old GPG key I stumbled over this: For devscripts you can define a variable "DEBSIGN_KEYID". For dpkg it is called "DEB_SIGN_KEYID". git-buildpackage doesn't support a keyid environment variable at all, as it seems. All ignore the default-key option set in .gnupg/gpg.conf . Would it be possible to get a common line here? Thanx in advance Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVdAKZAAoJEAqeKp5m04HLtWIH/ilKMAmWhtOgEQhYYg0HejVR xLvxAI2LJTpMI9Z2EkTwKjU0tVQNOJlupBlO42h3pt3zFNMgQkQPwlS6bNnNue34 HHutVmo+9/ONz7aigIzUuELjNmk4DR/9UXWweUM+A/oDSwJx5Q/i05aPu0pOC7Wx Sr9YGYznz1PTkoWqZ/2OJTdAGIhN801ElFt22hkykVDJwoqJym9bdEVQkrm90lky lINvsFokS7rmMrvHFOMFJ5Bpp2MN4HLvwba0qzwxPs9m2hSpFUvRRMAxWYjtzi4l 7CqyAjub+GRgqGZuDFQlDZM5efmeSNe8y6B95BlenE0ORAbDm5bGbZOVyz+1VCc= =IXqs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55740299.1040...@afaics.de
Re: DEB_SIGN_KEYID vs DEBSIGN_KEYID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/08/15 18:48, Guido Günther wrote: > On Sun, Jun 07, 2015 at 10:36:41AM +0200, Harald Dunkel wrote: Hi folks, > > Trying to get rid of my old GPG key I stumbled over this: > > For devscripts you can define a variable "DEBSIGN_KEYID". For dpkg it is > called "DEB_SIGN_KEYID". git-buildpackage doesn't > >> Gbp has a keyid option. What would be the usecase for the env var? Cheers, >> -- Guido > I did not ask for yet another environment variable. I am just asking for a common way to configure the *default* GPG key to use for *all* Debian tools signing packages. My suggestion would be use the default-key configured in gpg.conf. A command line option or local config file option should be used to override the default. Thats not the case here. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVfDg6AAoJEAqeKp5m04HLBm0H/1pXoaDswagyZ6xC9HKEBj5O lQZmAVmV/4HUWbdC71q4VpuqsjdZTDKa22axQk4lhpKL9SvY/WiwC3T0YyzVSNIb igqwQOydrSFze2XEBKewYLbw14D+k9VrIDuX4wyEdpFjWoc5JIMaY7nmc6XWwqFa H7eU3cG4VMCIvB3+g+/x3r2FbeMXoHQ836JfUorkHC3YrKpmBjKZgmqevuelgVCq f2I23NhlIsOJbU66IzIGtzpUaEpPzjzX+1/is2yB8PcAOuR8v0dJgpm9lEVmQUNI hmkdy80SrWksUfNKQ9aE8dY6G4smi3G2iNL8ixRdN+GodojkS0l64PuhGalilhY= =n/2s -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/557c383a.9040...@afaics.de
Debian vs Linux namespaces
Hi folks, AFAICS there are several packages that appear to be unaware of / do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng, probably everything using pidof or pidofproc from /lib/lsb/init-\ functions). I noticed that containerization and Linux namespaces are not number one priority for Debian, but do you think this could be addressed for Buster? Its pretty annoying if you try to maintain the Debian host system, and a LXC container is affected instead. Thanx in advance Harri https://bugs.debian.org/888569 https://bugs.debian.org/888743 https://bugs.debian.org/858837 https://bugs.debian.org/924551
Re: Debian vs Linux namespaces
Hi Ondřej, On 3/23/19 2:26 PM, Ondřej Surý wrote: > Hi Harald, > > since you are using non-default init system, I would recommend sending > patches along with your bug reports if you want to get niche things fixed. > I already did. See the bug reports for lsb and opensmtpd. I stumbled over apt-cacher-ng just recently. IMHO the best fix is to avoid pidof and pidofproc completely and to rely upon the /run/daemonname.pid file as usual. Regards Harri
Re: Debian vs Linux namespaces
On 3/25/19 11:41 AM, Florian Lohoff wrote: Hi, On Sat, Mar 23, 2019 at 01:34:34PM +0100, Harald Dunkel wrote: Hi folks, AFAICS there are several packages that appear to be unaware of / do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng, probably everything using pidof or pidofproc from /lib/lsb/init-\ functions). Or assuming that pid 1 is your init which you can send arbitrary signals without hurting anyone. Sorry to say, but Linux maps the container's init process to 1 on purpose, exactly to support this approach. See http://man7.org/linux/man-pages/man7/pid_namespaces.7.html Regards Harri
how to ignore signed kernel packages and use the unsigned instead?
Hi folks, I would like to install the unsigned kernel packages instead of the signed ones, but using linux-headers-amd64 and linux-image-amd64 I have to wait for a signature being applied. Obviously the signed kernel image and header packages for amd64 rely upon information not being publicly available, making it impossible (or at least pretty unlikely) for me to rebuild the dpendencies for linux-headers-amd64 and linux-image-amd64 on my own. So I wonder if linux-headers-amd64 and linux-image-amd64 shouldn't depend upon the unsigned kernel-headers and kernel-image packages, as for other platforms? Regards Harri
freeipa is in trouble for the next release (again)
Hi folks, I understand that freeipa-server has a very serious problem (#970880), making it unfit for Bullseye. It is *highly* painful that it puts freeipa-client at risk for the next release, too. We had something similar for Buster about 2 years ago, AFAIR. For my own part, I run freeipa-server on CentOS 7. I am not affected by #970880. I would be very happy with freeipa-client in Bullseye, even if freeipa-server doesn't make it. Do you think it would be possible to cut a clear line between freeipa- client and -server? Regards Harri -- https://bugs.debian.org/970880
Re: freeipa is in trouble for the next release (again)
On 3/24/21 11:05 AM, Andrey Rahmatullin wrote: On Wed, Mar 24, 2021 at 10:02:37AM +0100, Harald Dunkel wrote: For my own part, I run freeipa-server on CentOS 7. I am not affected by #970880. I would be very happy with freeipa-client in Bullseye, even if freeipa-server doesn't make it. The deadline for adding new packages to testing was 2021-02-12. So what would be your suggestion?
Re: freeipa is in trouble for the next release (again)
On 3/24/21 2:49 PM, Andrey Rahmatullin wrote: On Wed, Mar 24, 2021 at 12:33:53PM +0100, Harald Dunkel wrote: So what would be your suggestion? If you are still asking about getting this package into bullseye then I'm afraid it's not possible. Otherwise, as already suggested, it's possible to have it in bullseye-backports after fixing problems keeping it outside testing. Thats not the point. The point is, how can we make sure that freeipa-client stays in Testing for Bookworm, even if there is a fatal problem with freeipa-server?
please document why a package has been dropped from Testing/Bullseye
Hi folks, https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so I wonder what is the recommended way to find out why rsnapshot (or any other package) has been dropped from Testing? rsnapshot is still in Sid. I found #986709, of course, but this information should be much easier to access. Regards Harri
Re: Seeking consensus for some changes in adduser
On 2022-03-08 17:49:04, Marc Haber wrote: (1a) would it be necessary to handle --system accounts differently? I think yes. I think it would be helpful to define "system account" and "normal user". Neither adduser(8) nor useradd(8) provide a sufficient definition, especially wrt the existing network directory services (LDAP, AD, etc). Is a "system user" supposed to be a local account, defined in /etc/passwd only? Related question: How are naming collisions between local entries and the entries in a network directory service supposed to be handled? Something like passwd: files sss in /etc/nsswitch.conf is not helpful, if a postinst script fails to create a local account due to the entry it has found in freeipa, for example. Not to mention that such a service might fail at boot time, if the directory service is not available (yet). Regards Harri
Re: Seeking consensus for some changes in adduser
On 2022-03-09 21:00:20, Marc Haber wrote: On Wed, 9 Mar 2022 14:10:04 +0100, Harald Dunkel Related question: How are naming collisions between local entries and the entries in a network directory service supposed to be handled? Something like passwd: files sss in /etc/nsswitch.conf is not helpful, if a postinst script fails to create a local account due to the entry it has found in freeipa, for example. Not to mention that such a service might fail at boot time, if the directory service is not available (yet). That is beyond adduser's scope. We're (as the adduser team) usually weasel out of that topic by saying that a system refering to a directory service is run by skilled staff, and we expect those people to do their job. It's a small team, adduser has been in limbo for years, so we need to concentrate on the traps that a novice or unexperiences user might fall into while relying on skilled users to work around the issues that we haven't found the time to fix. This is another trap: /etc/login.defs seems to define some ranges for "system" uids and gids. They are commented out by default, nevertheless they imply some configurability. Are changes in login.defs supposed to be respected by all packages, including passwd (useradd) and adduser? Regards Harri
bitte ueberprueft die Energy settings unter Linux
Hi folks, bitte ueberprueft die Power Management Settungs (Energy) auf Eurem Linux Host. Die dpcls sollten *nicht* automatisch ausgehen, sonst ist remote management nicht moeglich. Vielen Dank Harri
moving mg from salsa to github?
Hi folks, I am maintainer for mg, currently on salsa. Problem is, upstream doesn't release tar balls anymore, but moved the code to github. No tags. How can I tell Salsa? Should I drop the upstream and pristine-tar branches on Salsa and integrate the repository on github? Would you suggest to move the debian part to github instead? Every helpful comment is highly appreciated Harri https://github.com/hboetes/mg https://salsa.debian.org/debian/mg
Re: moving mg from salsa to github?
On 2/15/20 2:44 PM, Peter Silva wrote: fwiw, looking at the repo on github. There are tags. They're just dates, Ideally one would get an idea of what the tags are from upstream, but you could just git clone using a tag. Also github allows you to easily get a tarball given a tag: wget https://github.com/hboetes/mg/tarball/20180927 Thats the most recent version in Debian. AFAIR it was created before mg moved to github. I will try to contact upstream. Regards Harri
Re: moving mg from salsa to github?
Hi Marco, On 2020-02-15 20:44, Marco d'Itri wrote: On Feb 15, Harald Dunkel wrote: I am maintainer for mg, currently on salsa. Problem is, upstream doesn't release tar balls anymore, but moved the code to github. I plan to do something like this for ppp, which now has a proper upstream git repository but no actual releases in a long time: mkdir /dev/shm/ppp/ cd /dev/shm/ppp rsync -aH .../ppp-2.4.7/ ppp-2.4.7/ cd ppp-2.4.7/ git branch -m upstream tarupstream git checkout tarupstream git remote add upstream https://github.com/paulusmack/ppp.git git fetch upstream git checkout remotes/upstream/master git switch -c upstream git merge tarupstream --allow-unrelated-histories git branch -d tarupstream git tag ppp-2.4.7+20191019 git checkout master git merge ppp-2.4.7+20191019 dch --preserve --version 2.4.7+20191019-1+1 "New upstream snapshot." cat << END > debian/gbp.conf [DEFAULT] upstream-tag = ppp-%(version)s pristine-tar = False compression = xz [pq] patch-numbers = False END gbp export-orig Cool, thanx very much. I have tons of this kind of self-made recipes in my doc folder. Very helpful. Harri
Re: f...@packages.debian.org Re: moving mg from salsa to github?
On 2/15/20 10:03 PM, Bernd Zeimetz wrote: So far I did not find a single upstream that was not able to understand a sentence like "Hi, my name is foo and I'm the Debian developer who is maintaining blubb in Debian". Thats correct. The maintainer for mg attached a new label 20200215 without hesitation, I created a tar file, imported it via gbp and pushed all to salsa. Thanx to all for your help Harri
kurze downtime der jenkins server um 12:00
Hi folks, zur RAM Erweiterung gibt es heute um 12:00 eine kurze Downtime der Jenkins Server invde8i001 mbrjenkins01 nvode7i001 semde7i001 sprjenkins01 Regards Harri
Re: kurze downtime der jenkins server um 12:00
Sorry for the noise, that was a bad To: address. Regards Harri On 10/18/2016 09:14 AM, Harald Dunkel wrote: > Hi folks, > > zur RAM Erweiterung gibt es heute um 12:00 eine kurze Downtime > der Jenkins Server > > invde8i001 > mbrjenkins01 > nvode7i001 > semde7i001 > sprjenkins01 > > Regards > Harri >
libcurl3 vs libcurl4
Hi folks, maybe a stupid question, but how comes libcurl4 doesn't provide a new soname, making it possible to install both libcurl3 and libcurl4 in parallel? Would it be possible for libcurl4 to provide libcurl3 to avoid the conflict? Regards Harri
can't push new version to collab-maint
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi folks,
trying to push a new version of mg to collab-maint I get an error
message "unable to update info/refs+"
{harri@cecil:mg (pristine-tar) 588} git push
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 2.54 KiB | 0 bytes/s, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: Sending notification emails to: dispatch+mg_...@tracker.debian.org
remote: error: unable to update info/refs+
To ssh://git.debian.org/git/collab-maint/mg.git
75c9e8a..74e pristine-tar -> pristine-tar
{harri@cecil:mg (pristine-tar) 589} git remote -v
origin ssh://harri-gu...@git.debian.org/git/collab-maint/mg.git (fetch)
origin ssh://harri-gu...@git.debian.org/git/collab-maint/mg.git (push)
This is not my first upload of mg, of course.
Every helpful comment is highly appreciated.
Harri
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEH2V614LbR/u1O+a1Cp4qnmbTgcsFAljksfgACgkQCp4qnmbT
gctCVwf8DUapLD2eE07KpEXhlLJcSJfoHWJVOywj+SeDE0B+ZAkIEdZPd6Pm1+Ej
TekFXxZOtqfQSqQbssIronHyltvNIKQDMsoF+vQ/jCN6A5So1CVtAc01YSVn4VWk
I0kno85zGN8hdW448ojXRX9e1FtYHWbYBlzYI8V/zv203PGHIQIHm0t+OG2BEeOQ
vJoKNnWqcPM7LBk8HFnT4jwLI+grRRVrhXQbfKl98g7Jvz6TKX0qwupSRteR4CQZ
XIL0st74tXyfitgmglxL9uQHRrNVEyemYBKeTVvSFgUtNM7qk9OuCpVZ3b3wJXSj
spj3TOlkPtQvpc6VjpTWDxTZCaPW+w==
=gzwI
-END PGP SIGNATURE-
Re: Naming of network devices - how to improve it in buster
On Tue, 11 Jul 2017 12:14:59 +0200
Guus Sliepen wrote:
>
> So, what can we do to improve the situation and get the best of both
> worlds?
>
systemd.link(5) describes a NamePolicy option for interface names.
I would suggest to introduce a new policy "keep" to stick with
the native interface names assigned by the kernel ("INTERFACE",
see "udevadm info /sys/class/net/eth0", for example).
Advantages:
- its easy to configure (much better than using kernel command
line options
- easy to implement (hopefully)
- you can still have the reproducible interface names, even if you
have only one NIC
Please note that systemd.link is read by udev, i.e. it is not bound
to systemd.
Regards
Harri
Re: Naming of network devices - how to improve it in buster
On Tue, 11 Jul 2017 15:20:41 +0200 Michael Biebl wrote: > Am 11.07.2017 um 12:14 schrieb Guus Sliepen: > > Ok, it should be clear now that the new way of naming interfaces is not > > ideal, but the older ways weren't either. Let's have a look at what we > > want: > > > > - A simple name for systems with a single Ethernet and/or Wireless > > interface (the simple desktop/laptop scenario). > > How would you determine that a system will only ever have a single > interface? > The user knows. I think that's the major problem with these reproducible interface names: Debian never gave the user a choice between the old and the new names. Regard Harri
iscsi support in Jessie
Hi folks, Some years ago I have setup an iscsi target using targetcli 2.0 on Wheezy. Actually it works pretty well, but there were some serious upgrade problems to 2.1 and 3.0, making targetcli go away for Jessie :-(. See #764005 and #751226. I lost confident in a newer version. Now I have to install a new iscsi target (using Jessie, hopefully). Which iscsi solution would you recommend? Regards Harri
debian/control: enhanced version dependencies?
Hi folks,
For running a local set of meta packages I would like to
express package dependencies depending upon other packages
installed, e.g.
Package: xyz
Version: all
Depends: ${misc:Depends}
, dbus (systemd >= 215)
Hopefully you get the meaning. Package xyz could make sure
that dbus is installed, if systemd is installed. (systemd
version 215 itself just recommends dbus.)
Another example:
Package: mykde
Version: all
Depends: ${misc:Depends}
. kde-full
, mykde1 (kde-full >= 5:66)
, mykde2 (kde-full >= 5:77)
, mykde3 (kde-full >= 5:84)
Package mykde1
:
:
Do you think this could be possible? Are there other
options for debian/control to express complex package
dependencies?
Regards
Harri
