Re: A Look In the Mirror: Attacks on Package Managers
Le dimanche 06 juin 2010 à 14:50 +0900, Ansgar Burchardt a écrit : > The Release file in the repository has now a Valid-Until field that > invalidates the repository after some time without updates. This can be > used to detect a mirror provided outdated packages. > > I am not sure whether APT checks this or not. I hope it does. It does. If you don’t re-run “apt-get update”, the signature will be considered invalid. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: A Look In the Mirror: Attacks on Package Managers
* Fernando Lemos: > 1. Man-in-the-middle attacks between clients and security update servers > 2. Denial-of-service attacks to the security updates infrastructure > 3. No trusted servers for security updates for testing and unstable > > Using HTTPS for the security update infrastructure could solve #1, Not really, because the mirrors are already middlemen, so encrypting the transport to them doesn't change much. > Now if we had a timestamp in the root metadata updated on a daily > basis, that would solve #1 and #3 Actually, it wouldn't because we do not provide a secure time source. pool.ntp.org faces the same theoretical issues as our mirror network. You'd have to fetch the root metadata from a trusted server over something like HTTPS (that is, something with authentication and a challange-response component built in). -- 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/87631wy335@mid.deneb.enyo.de
Re: A Look In the Mirror: Attacks on Package Managers
On Sun, 06 Jun 2010, Florian Weimer wrote: > You'd have to fetch the root metadata from a trusted server over > something like HTTPS (that is, something with authentication and a > challange-response component built in). That wouldn't be a stupid design at all. It would also allow that root metadata server to suggest mirrors to the client for downloading the rest. Cheers, weasel -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100606091445.gm14...@anguilla.noreply.org
Re: how to help end-users to increase the life-time of their SSDs
On Sun, 2010-06-06 at 10:28 +0400, Michael Tokarev wrote: > > - optionally /var/tmp as tmpfs > Not an answer to your original question, just a not-so-random observation. > /var/tmp is declared by LFS as "temporary storage that persists across > reboots". It wont be this way if it's on tmpfs obviously. That's why I've said optionally,... as far as I understand the FHS (http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE) it is still allowed to clean it up,... it should happen just less frequently. > > - moving my browser's Cache to some tmpfs (either it's own) or simply > > to /tmp > And browser cache is something that is not very useful if it does not > survive a reboot. Well isn't it also used for just reloading the site and so? Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#584760: ITP: ibus-table-others -- provide various tables that beyond Chinese for IBus-Table
Package: wnpp Severity: wishlist Owner: Asias He * Package name: ibus-table-others Version : 1.3.0.20100528 * URL : http://code.google.com/p/ibus/ * License : GPLv3 Programming Lang: Python Description : provide various tables that beyond Chinese for IBus-Table ibus-table-others provides the following input methods on IBus-Table on IBus framework: * CNS11643 * Compose * Emoji * IPA-X-SAMPA * LaTex * RussianTraditional * Thai * Translit * Ua-Translit * Viqr * Yawerty -- 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/20100606120250.9734.76703.report...@localhost
enquiry about linux debian
Good day I am Bassam hadi from saudi arabia,Riyadh capital city. I have bachelor in information technolgy. I prefered linux OS as I can review IT courses from daily usage. I have ubuntu & debian distributions , and I want to know is (universities -*.iso filetypes) Contact me to universities (tutorials,lectures,publications or libaray downloads) And canbe good e-learing platform. Best regards, Bassam Hadi. Al-Dogash Email: bassam.al-dog...@riyadbank.com Riyadh,KSA Mobile:00966541265150 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Riyad Bank. Finally, the recipient should check this email and any attachments for the presence of any viruses. Riyad Bank accepts no liability for any damage caused by any virus / error transmitted by this email.
Re: Permission to NMU gcc-mingw32
On Sun, Jun 06, 2010 at 11:53:08AM +, Ove Kaaven wrote: > The lack of a suitable (i.e. non-buggy) mingw32 cross-compiler has blocked > Wine updates for half a year now. Both the mingw32 package (gcc 4.2.1) and > the gcc-mingw32 package (gcc 4.4.2) have a bug which was fixed in upstream > gcc 4.4.3. At least one of these should be updated, if we want a fully > featured Wine, but neither of them seems to be updating. The maintainer of > gcc-mingw32, Robert Millan, appears MIA, and mingw32 appears to be blocked on > some politics issue (apparently not helped by the existence of gcc-mingw32?). Well, mingw32 has not been updated since 2007 and is barely usable now. The license issues looks more like a pretext to stall it than anything else since it is still possible to use gcc 4.3 anyway. > Anyway, for me, the easiest way to be able to build an updated Wine package > would be to NMU gcc-mingw32. Doing so seems to be just a matter of putting in > a new gcc tarball in the source package, and I've confirmed that updating it > to gcc 4.4.4 seems to work for what Wine needs. > > Is it okay if I go ahead and do such a NMU? Please do it ASAP. Robert will probably welcome the NMU. Cheers, -- Bill. Imagine a large red swirl here. -- 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/20100606121118.gi11...@yellowpig
Bug#584769: ITP: clustershell -- An event-based python library to execute commands on local or distant cluster nodes in parallel
Package: wnpp Severity: wishlist Owner: stephan gorget * Package name: clustershell Version : 1.2.83 Upstream Author : Stephane Thiell * URL : https://sourceforge.net/projects/clustershell/ * License : CeCILL Programming Lang: Python Description : An event-based python library to execute commands on local or distant cluster nodes in parallel depending on the selected engine and worker mechanisms. Example : clush -w node[001-256] hostname or clush -w node[001-256] apt-get update|clubak -c -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- 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/20100606122256.15092.4580.report...@phantez.net
status of circulars dependencies in unstable
Dear developers, Today circular dependencies in unstable reached an all-time low. Here the list of current circular dependencies: * libc6 libgcc1 * perl perl-modules * debconf debconf-english debconf-i18n * abuse abuse-frabs abuse-lib * ghostscript gs-common * python-imaging python-imaging-tk * odbcinst odbcinst1debian2 * g++-4.4 libstdc++6-4.4-dev * xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-synaptics xserver-xorg-input-wacom xserver-xorg-video-all xserver-xorg-video-apm xserver-xorg-video-ark xserver-xorg-video-ati xserver-xorg-video-chips xserver-xorg-video-cirrus xserver-xorg-video-fbdev xserver-xorg-video-i128 xserver-xorg-video-i740 xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-neomagic xserver-xorg-video-nouveau xserver-xorg-video-nv xserver-xorg-video-openchrome xserver-xorg-video-r128 xserver-xorg-video-radeon xserver-xorg-video-rendition xserver-xorg-video-s3 xserver-xorg-video-s3virge xserver-xorg-video-savage xserver-xorg-video-siliconmotion xserver-xorg-video-sis xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-trident xserver-xorg-video-tseng xserver-xorg-video-vesa xserver-xorg-video-vmware xserver-xorg-video-voodoo * fglrx-driver fglrx-glx * ca-certificates-java openjdk-6-jre-headless openjdk-6-jre-lib * sun-java6-bin sun-java6-jre * default-jre libaccess-bridge-java libaccess-bridge-java-jni openjdk-6-jre * uqm uqm-content * acheck acheck-rules * console-common kbd * aide aide-common * exim4 exim4-base exim4-daemon-heavy exim4-daemon-light fcron * libmono-corlib2.0-cil libmono-security2.0-cil libmono-system2.0-cil mono-2.0-gac mono-gac mono-runtime * libmono-system-web2.0-cil libmono2.0-cil * gamin libgamin0 * xemacs21 xemacs21-bin xemacs21-mule xemacs21-mule-canna-wnn xemacs21-nomule xemacs21-support * monodoc-browser monodoc-http monodoc-manual * bible-kjv bible-kjv-text * iamerican ispell * bochs bochs-wx * g++-4.3 libstdc++6-4.3-dev * bootcd bootcd-hppa bootcd-i386 bootcd-ia64 (1 pre-depends) * caudium caudium-modules * libcherokee-config0 libcherokee-server0 * cowbuilder cowdancer * tasksel tasksel-data * desktopnova desktopnova-module-gnome desktopnova-module-xfce * python-netcdf python-scientific * gcj-4.4-jdk libgcj10-dev * gdc-4.3 libphobos-4.3-dev * pcb-common pcb-gtk pcb-lesstif * ggz-kde-games ggz-kde-games-data * ggz-gtk-games ggz-gtk-games-data * ggz-sdl-games ggz-sdl-games-data * gnuift gnuift-perl * heroes-common heroes-ggi heroes-sdl * kopete libkopete4 * strongswan-ikev1 strongswan-ikev2 strongswan-nm strongswan-starter * cli-uno-bridge libuno-cli-cppuhelper1.0-cil * phpgroupware phpgroupware-0.9.16-admin phpgroupware-0.9.16-core-base phpgroupware-0.9.16-phpgwapi phpgroupware-0.9.16-preferences phpgroupware-0.9.16-setup * klogd sysklogd Cheers, -- Bill. Imagine a large red swirl here. -- 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/20100606132103.gj11...@yellowpig
Re: Re (2): lilo removal in squeeze / new lilo upstream
Russell Coker wrote on 2010-06-05 22:30: > On Wed, 26 May 2010, Stephen Powell wrote: > > You're missing the point. The main selling point to management > > is that Linux is free. If they have to buy new backup software > > in order to accommodate Linux' backup requirements, that will > > kill it on the spot. Whatever boot loader I use must not > > require new backup software or impose special backup requirements. > > One of the advantages of Linux is that you are not forced to do things the > way > that the distribution vendor packages it. > > You can take the last lilo package that gets uploaded, build it and put it in > your own apt repository, and then support it for your own users. I see that more people than thought still want to have or need LiLO. Now I have decided to start and reanimate the upstream development. Everyone is invited to join in this development. I'm working on LiLO version 23. Shortly with more informations ... Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: A Look In the Mirror: Attacks on Package Managers
Josselin Mouette wrote: > It does. If you don’t re-run “apt-get update”, the signature will be > considered invalid. j...@gnu:~/tmp/apt-0.7.26~exp5>grep -i Valid-Until -r . zsh: exit 2 grep -i Valid-Until -r . What'm I missing? -- see shy jo signature.asc Description: Digital signature
Re: status of circulars dependencies in unstable
[Bill Allombert] > Dear developers, > Today circular dependencies in unstable reached an all-time low. Very good to hear. If only we could get it down to zero, piuparts would be able to test all the packages and a more deterministic package installation order would be ensured. :) Happy hacking, -- Petter Reinholdtsen -- 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/2fly6eskuxe@login1.uio.no
Re: A Look In the Mirror: Attacks on Package Managers
On Sun, Jun 6, 2010 at 5:31 AM, Florian Weimer wrote: > * Fernando Lemos: > >> 1. Man-in-the-middle attacks between clients and security update servers >> 2. Denial-of-service attacks to the security updates infrastructure >> 3. No trusted servers for security updates for testing and unstable >> >> Using HTTPS for the security update infrastructure could solve #1, > > Not really, because the mirrors are already middlemen, so encrypting > the transport to them doesn't change much. Sorry, I think I wasn't clear enough. I mean using HTTPS for security.debian.org, i.e., the security update servers. Regular updates would still come from whatever mirror the user chooses, HTTPS wouldn't help there. >> Now if we had a timestamp in the root metadata updated on a daily >> basis, that would solve #1 and #3 > > Actually, it wouldn't because we do not provide a secure time source. > pool.ntp.org faces the same theoretical issues as our mirror network. Indeed. But if you play with the system clock, the admin is probably going to notice it. "make", "tar" and possibly others are going to complain about timestamps in the future. An attacker would have to create an evil mirror and an evil NTP server, hope that some admin uses both his evil mirror and his evil NTP server (not that unlikely if the evil mirror and NTP server are geographically closer to the target) and hope that the admin doesn't notice a lot of clues that something is going on. It's one more problem an attacker would have to deal with. > You'd have to fetch the root metadata from a trusted server over > something like HTTPS (that is, something with authentication and a > challange-response component built in). That's a good solution, but, as mentioned before, that would generate a lot of false positives. Mirrors only synchronize every X hours. If you happened to download the root metadata from the trusted server before the mirror catched up, you'd be told the mirror is stale when in fact it's perfectly healthy. Perhaps the trusted server could serve the root metadata mentioning packages available from time() - X hours before through time(), where X is the maximum delay between a mirror and the master servers. -- 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/aanlktin-ubsfoitistapvqgnwgumo74vjuqby2psp...@mail.gmail.com
Re: status of circulars dependencies in unstable
Le dimanche 06 juin 2010 à 18:06 +0200, Petter Reinholdtsen a écrit : > [Bill Allombert] > > Dear developers, > > Today circular dependencies in unstable reached an all-time low. > > Very good to hear. If only we could get it down to zero, piuparts > would be able to test all the packages and a more deterministic > package installation order would be ensured. :) Indeed that would help a lot. It is probably too late for squeeze, but how about forbidding it into the policy after the release? -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: status of circulars dependencies in unstable
--=20 Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer signature.asc Description: OpenPGP digital signature
Re: status of circulars dependencies in unstable
On Sun, 06 Jun 2010 18:29:01 +0200 Josselin Mouette wrote: > Le dimanche 06 juin 2010 à 18:06 +0200, Petter Reinholdtsen a écrit : > > [Bill Allombert] > > > Dear developers, > > > Today circular dependencies in unstable reached an all-time low. > > > > Very good to hear. If only we could get it down to zero, piuparts > > would be able to test all the packages and a more deterministic > > package installation order would be ensured. :) > > Indeed that would help a lot. > > It is probably too late for squeeze, but how about forbidding it into > the policy after the release? Some might be too intrusive to be fixed for squeeze (lbc6, perl, g++) but others (hopefully the xorg ones and others like ggz which are Priority: optional or especially extra) should still be suitable for bug reports - severity important probably. Lintian usually can't catch these problems, so it's important that all these circular dependencies are easily identified via the BTS until each is fixed. Then, after the release, we can deal with the others. At least if the bugs are filed now, we have a chance to get some discussion on the specifics of each issue. Some might be inadvertent, some are just masking other problems or have reasons that may need to be discussed with the relevant upstreams. IMHO, Bill, file the bugs now and see which ones can be fixed for Squeeze. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpunoreCtOwb.pgp Description: PGP signature
Re: A Look In the Mirror: Attacks on Package Managers
2010/6/6 Joey Hess : > Josselin Mouette wrote: >> It does. If you don’t re-run “apt-get update”, the signature will be >> considered invalid. > > j...@gnu:~/tmp/apt-0.7.26~exp5>grep -i Valid-Until -r . > zsh: exit 2 grep -i Valid-Until -r . > > What'm I missing? Nothing - or at least I didn't know about such a feature until now… (Not impossible, but not very likely ;) ) A quick scan over the open bugreports also doesn't indicate that it was requested so far. Another quick look at non-official archives indicate also that it is NOT commonly used (official debian and security use it, backports not, anyone else?) so this should be propagated more? Third one: reprepro has a ValidFor option to generate this stanza, what about the others? (apt-ftparchive obviously doesn't so far) In regards to APT i will have a look later how to implement it, hints regarding a good error message are welcomed as i can currently only thing about stuff like: > W: http://debian.example.org squeeze Release: The Validation date for the archive has expired. (This can indicate an outdated mirror.) < Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimo3xk5wrojziegmpq1aj1cgimrkxbnlpnxr...@mail.gmail.com
Re: status of circulars dependencies in unstable
Hi, On Sun, Jun 06, 2010 at 06:29:01PM +0200, Josselin Mouette wrote: > Le dimanche 06 juin 2010 à 18:06 +0200, Petter Reinholdtsen a écrit : > > [Bill Allombert] > > > Dear developers, > > > Today circular dependencies in unstable reached an all-time low. > > > > Very good to hear. If only we could get it down to zero, piuparts > > would be able to test all the packages and a more deterministic > > package installation order would be ensured. :) > > Indeed that would help a lot. > > It is probably too late for squeeze, but how about forbidding it into > the policy after the release? No. Besides that I think it would be bad to forbid correct dependencies it would break some subpolicies. (I have the cli-uno-bridge <-> libuno-cppuhelper1.0-cil one in mind, see #495748). No, that's not the way to go, IMHO. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- 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/20100606165304.gi25...@rene-engelhard.de
Re: A Look In the Mirror: Attacks on Package Managers
On Sun, Jun 6, 2010 at 1:34 PM, David Kalnischkies wrote: > In regards to APT i will have a look later how to implement it, > hints regarding a good error message are welcomed > as i can currently only thing about stuff like: >> > W: http://debian.example.org squeeze Release: The Validation date for > the archive has expired. (This can indicate an outdated mirror.) > < I'd suggest that the warning message informed how many days behind the server is. Some sort of tolerance setting should also be implemented for the corner cases. -- 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/aanlktim59hnphxfwmrrs7phxhcdly9ewfjws7q1ti...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
(better late than never) 2010/6/1 Jacob Sparre Andersen : > David Kalnischkies wrote: >> 2010/5/31 Ludovic Brenta : >>> Question 2: if I add Breaks: to a -dev package, which ones of Conflicts: >>> and Replaces: should I also specify? (currently, both are specified; the new >>> packages replace almost all files of the old packages). >> >> You want only Breaks or Conflicts. Breaks is in general the nicer Conflict >> - in some way they are the negative version of Depends and Pre-Depends: >> Conflicts must be satisfied before the package is unpacked - so both >> packages can't be in unpack (or higher) at the same time, while Breaks only >> says that both can't be in installed at the same time. > > So if there are common files, conflicts is required? You can still add Replaces to replace these files. Conflicts is now that we have Breaks more for cases in which the presence of a package will change the behavior of your package or in situations two packages providing the same functionality in completely different incompatible ways (e.g. sysvinit vs. upstart). Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilmfi7stxn-ua1rlt7njnr06iwlf9s4ompgk...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
(better late than never) 2010/6/3 Ludovic Brenta : > Jacob Sparre Andersen writes: >> David Kalnischkies wrote: >>> With the break you can force the update of old-libs, which >>> could depend in their new version on the new-libs. > > OK, I just tried that (in a local repository). Having gnat break all > the -dev packages in Lenny does not help; the broken packages are marked > as such in aptitude but not removed by default. Worse, gnat is now > marked as broken too (without the Breaks: it is not). Even if I press > '+' on gnat, this still does not cause any broken packages to be > removed; I must mark them all for removal manually with '-'. So we're > back to square one. Mhhh. What does broken mean here? As far as i know aptitude it should come up with a solution in the end in which all packages are in a consistent state (=not half-installed / unconfigured). So it should remove "broken" packages as broken is not a valid state a package can be after a complete $packagemanager run… Just for reference, what does "apt-get dist-upgrade -s" proposes? ( -o Debug::pkgProblemResolver=1 will tell you also why in a more or less cryptical way). It should really work to break old-lib ( << squeeze version) in gnat, to force an upgrade of old-lib to (at least) the "squeeze version", which could depend on your new-lib to get it installed… >>> 2. the old-libs will stay installed in at least of the form of a >>> transitional package in oldlibs as at least apt/lenny has no support >>> for disappear packages so this trick can't be used (not sure about >>> dpkg, aptitude uses apt facility in this regard, so also no support). >> >> This is ugly, but not horrible. > > Does apt/squeeze have support for disappearing packages? Yeap, or at least >= 0.7.26~exp5 has and apt is registered for an abi transition/binnmu series so it will hopefully find its way into unstable/testing some day in the future… (currently blocked) Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim4_sfm0crslumw48coy--z2ifhhlypxn8en...@mail.gmail.com
Re: status of circulars dependencies in unstable
On Sun, 6 Jun 2010 18:53:04 +0200 Rene Engelhard wrote: > On Sun, Jun 06, 2010 at 06:29:01PM +0200, Josselin Mouette wrote: > > Le dimanche 06 juin 2010 à 18:06 +0200, Petter Reinholdtsen a > > écrit : > > > [Bill Allombert] > > > > Dear developers, > > > > Today circular dependencies in unstable reached an all-time low. > > > > > > Very good to hear. If only we could get it down to zero, piuparts > > > would be able to test all the packages and a more deterministic > > > package installation order would be ensured. :) > > > > Indeed that would help a lot. > > > > It is probably too late for squeeze, but how about forbidding it > > into the policy after the release? > > No. Besides that I think it would be bad to forbid correct > dependencies it would break some subpolicies. (I have the > cli-uno-bridge <-> libuno-cppuhelper1.0-cil one in mind, see #495748). > > No, that's not the way to go, IMHO. That bug doesn't explain why the second half of the circular dependency is required: libuno-cli-cppuhelper1.0-cil:Depends: cli-uno-bridge Isn't there a way of moving files between packages to prevent the circular dependency? The bug report doesn't explain why this needs to be a Depends: either - it could be a Recommends AFAICT. To quote the report, "which for some stuff needs" - the definition of a Recommends in my book. If packageA is more than slightly usable without packageB being unpacked, there is no need for a Depends:, it should be a Recommends. It's already part of Policy 7.2 - the problem isn't just to do with your two packages, it's about reverse dependencies of those packages. Policy can be improved and clarified but that's what will probably have to wait until after Squeeze. For one thing, it makes things hard for people who want to have full control over which packages are installed - including ignoring Recommends. Consider this example: PackageA does not need libfoo, it just needs bin-bar. bin-bar depends on libfoo in a normal shlibs:Depends manner, so, fair enough, libfoo is necessary. PackageB does not need bin-bar, just libfoo and has been very carefully designed to be minimalist and only uses a fraction of the symbols from libfoo - why force bin-bar to be installed when it is completely unnecessary? If it's that hard, make a new package - PackageC - which contains those elements which cause the library to depend on files in the binary package. The slimmed down binary then just depends on the library which depends on the new package. This would still mean that anything which only depends on the library would only need the library and the new package. Removing circular dependencies IS the way to go in Debian IMHO. It's long overdue, even for perl|perl-modules and g++|libstdc++. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgplE8VHlrLQh.pgp Description: PGP signature
Re: status of circulars dependencies in unstable
Hi, On Sun, Jun 06, 2010 at 06:15:41PM +0100, Neil Williams wrote: > The bug report doesn't explain why this needs to be a Depends: either - > it could be a Recommends AFAICT. To quote the report, "which for some > stuff needs" - the definition of a Recommends in my book. If "some stuff" in the sense "I don't know what exactly needs it, but it needs it". > packageA is more than slightly usable without packageB being unpacked, > there is no need for a Depends:, it should be a Recommends. And that is the problem. It opens the .so, no matter what you want. Of course, unless the CLI policy gets in some way changed or someone tells me a better way... Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- 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/20100606171819.ga31...@rene-engelhard.de
Re: Re (2): lilo removal in squeeze / new lilo upstream
On Sun, 06 Jun 2010 09:39:59 -0400 (EDT), Joachim Wiedorn wrote: > > I see that more people than thought still want to have or need LiLO. Now > I have decided to start and reanimate the upstream development. Everyone > is invited to join in this development. I'm working on LiLO version 23. > > Shortly with more informations ... > > Fondest regards, > Joachim Wiedorn That's great news, Joachim! If it weren't for my complete ignorance of x86 assembly language, I might have been tempted to try it myself. But perhaps I may be able to help out in some way. We lilo users are very grateful to you for your willingness to take over. By the way, did anyone ever find out what happened to John Coffman? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1978551454.33.1275845120737.javamail.r...@md01.wow.synacor.com
Re: status of circulars dependencies in unstable
On Sun, 6 Jun 2010 19:18:19 +0200 Rene Engelhard wrote: > On Sun, Jun 06, 2010 at 06:15:41PM +0100, Neil Williams wrote: > > The bug report doesn't explain why this needs to be a Depends: > > either - it could be a Recommends AFAICT. To quote the report, > > "which for some stuff needs" - the definition of a Recommends > > in my book. If > > "some stuff" in the sense "I don't know what exactly needs it, > but it needs it". Umm, then some testing could be in order?? > > packageA is more than slightly usable without packageB being > > unpacked, there is no need for a Depends:, it should be a > > Recommends. > > And that is the problem. It opens the .so, no matter what you want. How does that explain why the lib depends on the binary? Why cannot the "glue" be put into a new package? (If it's unversioned, how are transitions meant to be handled?) > Of course, unless the CLI policy gets in some way changed or someone > tells me a better way... Well some definite information and test results would be helpful. So far, the only data in the bug report or on this list is too vague for anyone to offer a solution - whether they know the package or not. "some stuff", "I don't know what exactly needs it," and "glue" are not helpful assessments which would encourage anyone to offer a reasoned solution. You know the package, I don't - please, help others help you by putting some real usable data into the bug report. Which symbols, which executables, which circumstances, which files? Exactly where is the breakage? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp1skslLKSid.pgp Description: PGP signature
Re: status of circulars dependencies in unstable
Le dimanche 06 juin 2010 à 18:53 +0200, Rene Engelhard a écrit : > No. Besides that I think it would be bad to forbid correct dependencies it > would break some subpolicies. (I have the cli-uno-bridge <-> > libuno-cppuhelper1.0-cil > one in mind, see #495748). This is a very classical case of circular dependencies, similar to what used to be in GConf. The solution is to merge both packages. If there is really something that requires splitting, put the .so currently in cli-uno-bridge in libuno-cppuhelper1.0-cil, in a private directory, and put a symlink to the canonical place in libuno-cppuhelper1.0-cil. Doesn’t look unfixable to me. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling -- 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/1275851946.2347.3.ca...@tomoe
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/6/6 Ludovic Brenta : > Package: gnat > Architecture: any > Depends: gnat-4.4 (>= 4.4.2-1) > Recommends: ada-reference-manual, gnat-gps > Breaks: libadasockets-dev (<= 1.8.6-2), libasis-dev, libaunit-dev, > libaws-dev, libflorist-dev, libgnademysql-dev, libgnadeodbc-dev, > libgnadepostgresql-dev, libgnadesqlite-dev, > libgnatprj4.3-dev, libgnatvsn4.3-dev, > libgnomeada2-dev, libgtkada2-dev, libtemplates-parser-dev, > libtexttools-dev, libxmlada-dev These breaks need to be versioned - e.g. libasis-dev ( << squeeze) there "squeeze" is the version of the transitional package libasis-dev which depends on the new libasis-newabi-dev just like in a package rename. > 2. the old-libs will stay installed in at least of the form of a > transitional package in oldlibs as at least apt/lenny has no > support for disappear packages so this trick can't be used (not > sure about dpkg, aptitude uses apt facility in this regard, so also > no support). This is ugly, but not horrible. >>> >>> Does apt/squeeze have support for disappearing packages? >> >> Yeap, or at least >= 0.7.26~exp5 has and apt is registered for an abi >> transition/binnmu series so it will hopefully find its way into >> unstable/testing some day in the future… (currently blocked) > > Could you shed some light or point me to some doc as to how this feature > works? I'd like to know whether it can solve the problem or not. E.g here http://wiki.debian.org/Renaming_a_Package It is not documented very well currently as it can't be used for squeeze and would therefore most likely only confuse maintainers (i guess). Disappear should remove the need in the future for transitional packages (see "apt-cache search dummy transitional"). Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimhxgmdss7xhlsjwnzijy1wjtwlwpf0txqwf...@mail.gmail.com
Re: status of circulars dependencies in unstable
On Sun, Jun 06, 2010 at 06:29:01PM +0200, Josselin Mouette wrote: > Le dimanche 06 juin 2010 à 18:06 +0200, Petter Reinholdtsen a écrit : > > [Bill Allombert] > > > Dear developers, > > > Today circular dependencies in unstable reached an all-time low. > > > > Very good to hear. If only we could get it down to zero, piuparts > > would be able to test all the packages and a more deterministic > > package installation order would be ensured. :) Circular dependencies should not prevent piuparts from testing packages. That's simply a bug in piuparts for not knowing what to do with them. > Indeed that would help a lot. > It is probably too late for squeeze, but how about forbidding it into > the policy after the release? Forbidding something that has always been supported and that has a number of useful (and important) corner cases should not be the role of policy. Please demonstrate first that the use cases for which circular depends are used have been adequately addressed, *before* ruling it out in Policy. If there are a limited subset of problem cases where circular deps are still needed, it would be fine to have policy enumerate these exceptions and forbid it in the general case. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100606200058.gb19...@dario.dodds.net
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies writes: > 2010/6/6 Ludovic Brenta : >> Package: gnat >> Architecture: any >> Depends: gnat-4.4 (>= 4.4.2-1) >> Recommends: ada-reference-manual, gnat-gps >> Breaks: libadasockets-dev (<= 1.8.6-2), libasis-dev, libaunit-dev, >> libaws-dev, libflorist-dev, libgnademysql-dev, libgnadeodbc-dev, >> libgnadepostgresql-dev, libgnadesqlite-dev, >> libgnatprj4.3-dev, libgnatvsn4.3-dev, >> libgnomeada2-dev, libgtkada2-dev, libtemplates-parser-dev, >> libtexttools-dev, libxmlada-dev > > These breaks need to be versioned - e.g. libasis-dev ( << squeeze) > there "squeeze" is the version of the transitional package libasis-dev > which depends on the new libasis-newabi-dev just like in a > package rename. As discussed before, introducing transitional packages would be sufficient to guarantee smooth upgrades (without the need for "Breaks" in gnat) but it would also defeat the purpose of the "aliversion" component of packages names. We do not want any transitional packages. Consequently, the version numbers are also unnecessary (except in the case of libadasockets-dev due to #580907). I believe this is as far as we can go; apt simply does not offer the feature that we would need, i.e. a way to explain that apt should remove a package libX1-dev (which disappeared from the archive) and install libX2-dev (new in the archive) as the upgrade path. >> 2. the old-libs will stay installed in at least of the form of a >> transitional package in oldlibs as at least apt/lenny has no >> support for disappear packages so this trick can't be used (not >> sure about dpkg, aptitude uses apt facility in this regard, so also >> no support). > > This is ugly, but not horrible. Does apt/squeeze have support for disappearing packages? >>> >>> Yeap, or at least >= 0.7.26~exp5 has and apt is registered for an abi >>> transition/binnmu series so it will hopefully find its way into >>> unstable/testing some day in the future… (currently blocked) >> >> Could you shed some light or point me to some doc as to how this feature >> works? I'd like to know whether it can solve the problem or not. > > E.g here http://wiki.debian.org/Renaming_a_Package I've already read that and it has not changed since then (I checked the change history). Basically, both methods require a transitional package; we cannot use that for Ada -dev packages. > It is not documented very well currently as it can't be used for squeeze > and would therefore most likely only confuse maintainers (i guess). > Disappear should remove the need in the future for transitional packages > (see "apt-cache search dummy transitional"). OK. I think we'll let the issue rest and try do document why unattended in-place upgrades are not supported for Ada development packages. I already have a draft of this in the next edition of the Debian Policy for Ada. We will revisit this issue in squeeze+1. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5kjrict@ludovic-brenta.org
Re: Re (2): lilo removal in squeeze / new lilo upstream
Hi, - "Joachim Wiedorn" wrote: > Russell Coker wrote on 2010-06-05 22:30: > > > On Wed, 26 May 2010, Stephen Powell wrote: > > > You're missing the point. The main selling point to management > > > is that Linux is free. If they have to buy new backup software > > > in order to accommodate Linux' backup requirements, that will > > > kill it on the spot. Whatever boot loader I use must not > > > require new backup software or impose special backup > requirements. > > > > One of the advantages of Linux is that you are not forced to do > things the way > > that the distribution vendor packages it. > > > > You can take the last lilo package that gets uploaded, build it and > put it in > > your own apt repository, and then support it for your own users. > > I see that more people than thought still want to have or need LiLO. > Now > I have decided to start and reanimate the upstream development. > Everyone > is invited to join in this development. I'm working on LiLO version > 23. > > Shortly with more informations ... Have fun. When you have a release that actually has merit, it can be reconsidered for inclusion in Debian. In the meantime, the original plan continues. William -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/28336861.3901275860645697.javamail.r...@ifrit.dereferenced.org
Re: Re (2): lilo removal in squeeze / new lilo upstream
On: Sun, 06 Jun 2010 17:44:05 -0400 (EDT), William Pitcock wrote: > "Joachim Wiedorn" wrote: >> I see that more people than thought still want to have or need LiLO. >> Now I have decided to start and reanimate the upstream development. >> Everyone is invited to join in this development. I'm working on LiLO >> version 23. Shortly with more informations ... > > Have fun. When you have a release that actually has merit, it can be > reconsidered for inclusion in Debian. What is your definition of "merit", William? And why does the current release not have it? > > In the meantime, the original plan continues. The original plan was based on false assumptions. Why would you continue with a plan based on false assumptions? We now have a release of lilo with (a) an active upstream maintainer, and (b) no release critical bugs. If you simply don't want to be a Debian package maintainer for lilo anymore, why not ask for volunteers to take over for you? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1545549194.342558.1275871054568.javamail.r...@md01.wow.synacor.com
