Re: dpkg-buildpackage creating uninstallable packages?

[Norbert Preining]

severity 699206 serious
thanks

Hi Dominik,

first of all, please stop including all the email and bottom-posting,
this is a pain and against usual netiquette.

Then ...

On Mo, 30 Sep 2013, Dominik George wrote:
> If you accuse everyone else in the community
  [...]

I did not accuse anyone, I asked why a RC bug is tagged as important
and not as RC, and why there is no activity since month, although
easily reproducible.

Anyway, I have raised the severity of this bug. Removing a package
must not leave the system in an non-operable state.


Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



-- 
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/20130930155031.ga30...@gamma.logic.tuwien.ac.at

Re: dpkg-buildpackage creating uninstallable packages?

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Norbert Preining  schrieb:
>Hi Dominik,
>
>> Simply put: Because you made no effort to fix it :).
>
>Thanks for the very useful comment.
>
>Yes, I care for RC bugs in my own packages ... and that are quite
>a lot. So no time to fix RC bugs of other maintainers.
>
>Norbert
>
>
>PREINING, Norbert
>http://www.preining.info
>JAIST, Japan TeX Live & Debian
>Developer
>DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5
>B094
>

Hi Norbert,

I do not filter my replies for DDs or Non-DDs. If you accuse everyone else in 
the community of not caring for something, I accuse you of not noticing it 
earlier. I am certain everyone here does a great job, so I feel disappointed by 
such accusations.

- -nik
- --
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSSXHtMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJUXwCAC0WiHHGm1MU0pkxiCiXOAh
SXxItktOPHms/FTnp+CTxp+ZNwEtfwH59e4UpkFYdUIkiK9uxIwoDXhJ6icY7rV3
H7/IG+Tx/3L8+pSIrMAQEvXcBrscXfKjrQexPHTlO8wgASP0BL3hUq2YHzEn9dRI
up13o2LP/lCb4w0dSV4CG9QeBlJuwEteVdNnLw5csnKYhTNWRY+wvPmYJHEiGJit
0olbEUWwqX4JZd+TFmHNnbG2xGqzgOR3EXUQApxkgRpzEL+rdXowZjmmc/AEdXya
imT7WL+ckycSLb4dwUMT9B23gQTwqaOdt771e/JEsRYHT1TD2cBh7IJInl5pL2sK
=xuJw
-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/c8929909-a597-4928-82dd-4f29ae8ce...@email.android.com

Re: dpkg-buildpackage creating uninstallable packages?

[Norbert Preining]

Hi Dominik,

> Simply put: Because you made no effort to fix it :).

Thanks for the very useful comment.

Yes, I care for RC bugs in my own packages ... and that are quite
a lot. So no time to fix RC bugs of other maintainers.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



-- 
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/20130930123939.ga25...@gamma.logic.tuwien.ac.at

Re: dpkg-buildpackage creating uninstallable packages?

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Norbert Preining  schrieb:
>On So, 29 Sep 2013, Stephen Kitt wrote:
>> > Uninstall the libc6-amd64:i386 package.
>> > See http://lists.debian.org/debian-mentors/2013/03/msg00139.html.
>>
>> But watch out for http://bugs.debian.org/699206 - make sure you have
>a root
>> sash running somewhere so you can relink
>/lib64/ld-linux-x86-64.so.2...
>
>Indeed, suddenly my system was hosed ... nothing did run again. Umpf.
>I managed to get it back without knowing the above bug, but
>it did cost me some nerves.
>
>Sorry, might I ask *why* bugs like this that break *all* other software
>are tagged as important and open since *January* ???
>
>Norbert
>
>
>PREINING, Norbert
>http://www.preining.info
>JAIST, Japan TeX Live & Debian
>Developer
>DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5
>B094
>

Simply put: Because you made no effort to fix it :).

- -nik
- --
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSST1JMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJQMXB/954UMli1fbKU4qTASJ+mOw
4D7txAdR0MUUgKHrelZeJ4MNPsstOvGybqtd14NdrG0WnCZM3w1hWv9kyYtX76n4
ot7N79zReheZJsSj/uQ0nVjPL6N9nut5ONzd+suLQhThg0dHCzuUiPUC7hPNmKEC
h3r7pLw3zw/f8cNAn4QA4XvBfoU2TS5+Il6YZ0ODxGvJE6mdeGYO3SXh09HmkABA
Ec1KNDNOs5zOHQjNnb75+9WGZXs/5DJnTDxrMAkPS8qbgSfT+N+RfTU9WBD2f/Wv
u2JjbsNWqsDZLkegtKgOsrWuGIA52inSD+jIaXhGPH6Aviv4bcw+5qYdTj8F5jn2
=fgDw
-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/20155ad1-6366-460d-86da-0388793af...@email.android.com

Re: dpkg-buildpackage creating uninstallable packages?

[Norbert Preining]

On So, 29 Sep 2013, Stephen Kitt wrote:
> > Uninstall the libc6-amd64:i386 package.
> > See http://lists.debian.org/debian-mentors/2013/03/msg00139.html.
> 
> But watch out for http://bugs.debian.org/699206 - make sure you have a root
> sash running somewhere so you can relink /lib64/ld-linux-x86-64.so.2...

Indeed, suddenly my system was hosed ... nothing did run again. Umpf.
I managed to get it back without knowing the above bug, but
it did cost me some nerves.

Sorry, might I ask *why* bugs like this that break *all* other software
are tagged as important and open since *January* ???

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



-- 
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/20130930075943.gb17...@gamma.logic.tuwien.ac.at

Re: dpkg-buildpackage creating uninstallable packages?

[Stephen Kitt]

On Sun, 29 Sep 2013 08:58:36 +0200, Sven Joachim  wrote:
> On 2013-09-28 22:18 +0200, Norbert Preining wrote:
> > since a short time when I build a binary package on my running system,
> > I cannot install the created .deb anymore because it depends on
> > libc-amd64 (>= some.version) which somehow is not what I have although
> > I am running amd64 sid.
> 
> Uninstall the libc6-amd64:i386 package.
> See http://lists.debian.org/debian-mentors/2013/03/msg00139.html.

But watch out for http://bugs.debian.org/699206 - make sure you have a root
sash running somewhere so you can relink /lib64/ld-linux-x86-64.so.2...

Regards,

Stephen


signature.asc
Description: PGP signature

Re: dpkg-buildpackage creating uninstallable packages?

[Paul Gevers]

On 29-09-13 08:40, Norbert Preining wrote:
> What is going wrong here?

For whatever reason, the amd64 build is picking up i386 paths. I don't
know how that happens, except that I expect it is some multi-arch
twitch. I recommend you build your packages in a chroot to avoid this
(an other) issues. I use pbuilder for all my builds, but other solutions
exist.

Paul




signature.asc
Description: OpenPGP digital signature

Re: dpkg-buildpackage creating uninstallable packages?

[Sven Joachim]

On 2013-09-28 22:18 +0200, Norbert Preining wrote:

> since a short time when I build a binary package on my running system,
> I cannot install the created .deb anymore because it depends on
> libc-amd64 (>= some.version) which somehow is not what I have although
> I am running amd64 sid.

Uninstall the libc6-amd64:i386 package.
See http://lists.debian.org/debian-mentors/2013/03/msg00139.html.

Cheers,
   Sven


-- 
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/87eh88nmg3@turtle.gmx.de

Re: dpkg-buildpackage creating uninstallable packages?

[Norbert Preining]

Hi everyone,

second try, with more data ..


default package texinfo, I am importing a new upstream into my git,
no changes to debian/rules or debian/control, rebuild.
>From the debian/control:
..
Package: info
...
Architecture: any
Multi-Arch: foreign
...

After building the package looks like:
info_5.2.0.dfsg.1-1_amd64.deb:
 new debian package, version 2.0.
 
 Version: 5.2.0.dfsg.1-1
 Architecture: amd64
 Maintainer: Debian TeX maintainers 
 Installed-Size: 451
 Depends: libc6-amd64 (>= 2.15), libtinfo5, install-info
 ...

--

When installing the just built deb on my machine for testing I get:

dpkg: dependency problems prevent configuration of info:
 info depends on libc6-amd64 (>= 2.15).


For completeness, I am on amd64, and on uptodate sid.

$ dpkg --print-architecture
amd64

$ dpkg -l libc6-amd64
ii  libc6-amd642.17-93  i386 Embedded GNU C Library: 64bit S..

$ apt-cache policy libc6-amd64
libc6-amd64:i386:
  Installed: 2.17-93
  Candidate: 2.17-93
  Version table:
 *** 2.17-93 0
500 http://ftp2.jp.debian.org/debian/ sid/main i386 Packages
100 /var/lib/dpkg/status


What is going wrong here?

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



-- 
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/20130929064022.ga11...@gamma.logic.tuwien.ac.at

Re: dpkg-buildpackage creating uninstallable packages?

[Andrey Rahmatullin]

On Sun, Sep 29, 2013 at 12:18:03AM +0400, Norbert Preining wrote:
> since a short time when I build a binary package on my running system, I 
> cannot install the created .deb anymore because it depends on
>libc-amd64 (>= some.version)
> which somehow is not what I have although I am running amd64 sid.
You need to provide more data. 

-- 
WBR, wRAR


signature.asc
Description: Digital signature

dpkg-buildpackage creating uninstallable packages?

[Norbert Preining]

Hi everyone,

since a short time when I build a binary package on my running system, I cannot 
install the created .deb anymore because it depends on
   libc-amd64 (>= some.version)
which somehow is not what I have although I am running amd64 sid.

Any suggestions?

Thanks

Norbert


PREINING, Norbert  http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

Re: Perl 5.12 transition in progress; uninstallable packages

[Mehdi Dogguy]

On 03/05/2011 12:02, Neil Williams wrote:
> 
> With such a large number of packages involved and the transition page
> being constructed from multiple dependency levels, is there a way of
> linking the transitions data from DDPO or having some other output
> which is organised on a per-developer / dd-list type layout?
> 

Considering the list of source packages available at [1]:

Daniel Leidert (dale) 
   openbabel (U)

Krzysztof Krzyzaniak (eloy) 
   libalias-perl (U)
   libastro-fits-cfitsio-perl (U)
   libcompress-raw-zlib-perl (U)
   libcrypt-des-perl (U)
   libdbd-sqlite2-perl (U)
   libhtml-parser-perl (U)
   libimage-librsvg-perl (U)
   liblist-moreutils-perl (U)
   libsearch-xapian-perl (U)
   libset-object-perl (U)
   libstring-crc32-perl (U)
   libterm-readline-gnu-perl (U)
   libtext-csv-xs-perl (U)
   libtime-piece-perl (U)

Krzysztof Krzyżaniak (eloy) 
   libcache-fastmmap-perl (U)
   libclass-c3-xs-perl (U)
   libclass-mop-perl (U)
   libcoro-perl (U)
   libdbd-mysql-perl (U)
   libdbd-pg-perl (U)
   libdbd-sqlite3-perl (U)
   libdevel-globaldestruction-perl (U)
   libfcgi-perl (U)
   libimager-perl (U)
   libipc-sharelite-perl (U)
   libjavascript-perl (U)
   libmoose-perl (U)
   libparams-validate-perl (U)
   libsub-current-perl (U)
   libsub-identify-perl (U)
   libsub-name-perl (U)
   libtokyocabinet-perl (U)
   libyaml-libyaml-perl (U)

Davide Puricelli (evo) 
   xchat

Felipe Augusto van de Wiel (faw) 
   eperl (U)
   wml (U)

Dario Minnucci (midget) 
   libalgorithm-permute-perl (U)

Loic Dachary (OuoU) 
   libtext-unaccent-perl

Stefan Hornburg (Racke) 
   courier
   mongodb-perl (U)
   safe-hole-perl

J.H.M. Dassen (Ray) 
   gnumeric

Ernesto Hernández-Novich (USB) 
   libdigest-jhash-perl (U)

Danai SAE-HAN (韓達耐) 
   libunicode-collate-perl (U)

Angel Abad 
   libautobox-perl (U)
   libclass-mop-perl (U)
   libdata-dump-streamer-perl (U)
   libdate-pcalc-perl (U)
   libindirect-perl (U)
   libjson-xs-perl (U)
   libscalar-string-perl (U)
   libvariable-magic-perl (U)

Russ Allbery 
   libafs-perl
   libauthen-krb5-admin-perl (U)
   libauthen-krb5-perl (U)
   libauthen-sasl-cyrus-perl (U)
   libheimdal-kadm5-perl
   libnet-ldapapi-perl (U)
   openldap (U)
   remctl
   webauth

Thomas Anders 
   net-snmp (U)

Micah Anderson 
   libcrypt-openssl-x509-perl (U)
   silc-client (U)

Stuart R. Anderson 
   ming

Don Armstrong 
   libimage-imlib2-perl
   libthreads-perl
   libthreads-shared-perl

maximilian attems 
   linux-2.6 (U)

Ernesto Nadir Crespo Avila 
   flow-tools (U)

Nicholas Bamber 
   libapache2-mod-perl2 (U)
   libclass-xsaccessor-perl (U)
   libcompress-raw-zlib-perl (U)
   libdatetime-perl (U)
   libdbd-mysql-perl (U)
   libdbd-odbc-perl (U)
   libdbi-perl (U)
   libdevel-bt-perl (U)
   libdevel-cover-perl (U)
   libdevel-nytprof-perl (U)
   libdevel-size-perl (U)
   libencode-hanextra-perl (U)
   libencode-jis2k-perl (U)
   libfile-spec-perl (U)
   libhtml-parser-perl (U)
   libhtml-template-pro-perl (U)
   libimager-perl (U)
   libio-aio-perl (U)
   libjavascript-minifier-xs-perl (U)
   libjavascript-perl (U)
   libjson-xs-perl (U)
   libnetaddr-ip-perl (U)
   libparams-validate-perl (U)
   libquota-perl (U)
   libsgml-parser-opensp-perl (U)
   libsocket-getaddrinfo-perl (U)
   libsub-prototype-perl (U)
   libxml-sax-expatxs-perl (U)
   libyaml-syck-perl (U)

Michael Banck 
   openbabel (U)

Jack Bates 
   libnet-dbus-perl

Roland Bauerschmidt 
   openldap (U)

Romain Beauxis 
   libfuse-perl

Axel Beckert 
   eperl (U)
   wml (U)

Dave Beckett 
   redland-bindings

Luciano Bello 
   imagemagick (U)

Hilko Bengen 
   hivex
   libsendmail-milter-perl

Christoph Berg 
   cyrus-imapd-2.2 (U)
   cyrus-imapd-2.4 (U)

Jay Berkenbilt 
   libxml-xerces-perl

Edward Betts 
   libdate-simple-perl (U)

Olly Betts 
   libsearch-xapian-perl (U)

Bastian Blank 
   libfile-spec-perl (U)
   libperlio-eol-perl
   linux-2.6 (U)
   redhat-cluster (U)

Jérémy Bobbio 
   silc-client (U)

Salvatore Bonaccorso 
   libclass-mop-perl (U)
   libcrypt-openssl-x509-perl (U)
   libdbd-sqlite3-perl (U)
   libdigest-sha-perl (U)
   libgtk2-perl (U)
   libmath-gmp-perl (U)
   libmoose-perl (U)
   libsearch-xapian-perl (U)
   libsys-virt-perl (U)
   libwww-curl-perl (U)

Salvatore Bonaccorso 
   libbsd-resource-perl (U)
   libdate-calc-perl (U)
   libforks-perl (U)
   libhtml-parser-perl (U)
   libmath-random-mt-perl (U)
   libnet-ssh2-perl (U)
   libpadwalker-perl (U)
   libposix-strptime-perl (U)
   libscalar-list-utils-perl (U)
   libtime-piece-perl (U)

Jay Bonci 
   libclass-date-perl (U)
   libcurses-perl (U)
   libdigest-md4-perl (U)
   libimager-perl (U)
   libipc-sharelite-perl (U)
   libparams-validate-perl (U)

Alan Boudreault 
   mapserver (U)

Emmanuel Bouthenot 
   weechat

Michael Bramer 
   liblinux-inotify2-perl

Joachim Breitner 
   libalias-perl (U)
   libastro-fits-cfitsio-perl (U)
   libfile-sync-perl (U)

David Bremner 
   highlight (U)

Marc 'HE' Brockschmidt 
   libastro-fits-cfits

Re: Perl 5.12 transition in progress; uninstallable packages

[Neil Williams]

On Tue, 3 May 2011 10:21:09 +0100
Dominic Hargreaves  wrote:

> Hi all,
> 
> On Sunday, in collaboration with the release team, I uploaded
> perl 5.12-6 to unstable. This necessarily causes around 400 packages
> to be uninstallable with the new perl. The release team will be
> scheduling binNMUs in due course; in the meantime, if you find such a
> package, there is no need to report a bug against it. The rebuilds will
> take a little time, so please be patient in the meantime.
> 
> The list of affected packages is available at
> 
> 

With such a large number of packages involved and the transition page
being constructed from multiple dependency levels, is there a way of
linking the transitions data from DDPO or having some other output
which is organised on a per-developer / dd-list type layout?

Even if it just results in the package names per-developer as a
separate page consisting of static list of links back to the transition
page for that package, it would help.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpGRRyIgUQjK.pgp
Description: PGP signature

Perl 5.12 transition in progress; uninstallable packages

[Dominic Hargreaves]

Hi all,

On Sunday, in collaboration with the release team, I uploaded
perl 5.12-6 to unstable. This necessarily causes around 400 packages
to be uninstallable with the new perl. The release team will be
scheduling binNMUs in due course; in the meantime, if you find such a
package, there is no need to report a bug against it. The rebuilds will
take a little time, so please be patient in the meantime.

The list of affected packages is available at


and more information about the transition is at


Thanks,
Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


-- 
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/20110503092109.gh4...@urchin.earth.li

Re: Uninstallable packages testing/sarge

[Colin Watson]

On Fri, Nov 14, 2003 at 11:31:59AM +1100, Brian May wrote:
> If a package is uninstallable on testing, is it appropriate
> to file a bug report against it, even though it might be OK
> on unstable?
> 
> If a bug report is filled, then people can become aware of the
> problem, preferably before sarge is released..
> 
> On the other hand, it could irritate the maintainer who can't
> do anything about it, perhaps because the problem is fixed
> in unstable.

Packages that are uninstallable purely due to dependencies, as opposed
to broken maintainer scripts, are already tracked here:

  http://ftp-master.debian.org/testing/testing_probs.html

  (ditto stable_probs, unstable_probs)

... so there's usually not a great deal of point if the package is fixed
in unstable. As you say, there's often not much the maintainer can do
about it in that case. The people who work on the state of testing
directly are more likely to notice things in testing_probs.html anyway.

> Examples:
> 
> gnome-desktop-data (conflicts against the old version of gnome-core in
> testing).

We do need to get meta-gnome2 into testing anyway.

> kde: depends on broken packages:
> kfind: conflicts with old kdebase-libs in testing
> etc... (total 21 packages marked as broken in aptitude when selecting
> kde)

This is definitely known about; a number of bugs have already been
filed.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Uninstallable packages testing/sarge

[Brian May]

Hello,

If a package is uninstallable on testing, is it appropriate
to file a bug report against it, even though it might be OK
on unstable?

If a bug report is filled, then people can become aware of the
problem, preferably before sarge is released..

On the other hand, it could irritate the maintainer who can't
do anything about it, perhaps because the problem is fixed
in unstable.

Examples:

gnome-desktop-data (conflicts against the old version of gnome-core in
testing).

kde: depends on broken packages:
kfind: conflicts with old kdebase-libs in testing
etc... (total 21 packages marked as broken in aptitude when selecting
kde)
-- 
Brian May <[EMAIL PROTECTED]>

Re: Purposely broken/uninstallable packages in archive

[Steve Greenland]

On 20-Sep-01, 20:30 (CDT), Brian May <[EMAIL PROTECTED]> wrote: 
> I made it a *.deb package, because that allows you to use apt-get to
> automatically upgrade the package on a *nfs root* partition to the
> latest version.

(Brian, thanks for the explanation. That was a lot more useful than "you
want boot floppies, dontcha?")

But why are they are in the main archive? Apt-get supports specifing
different alternative sources.list files from the command line, which
would allow these packages to live in a "non-public" part of the
archive.

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>

Re: Bug#112723: Purposely broken/uninstallable packages in archive

[Junichi Uekawa]

Brian May <[EMAIL PROTECTED]> immo vero scripsit

> In practise, it might be perfectly safe to install on a normal
> partition. Just that there is no point.  

I think it replaces /sbin/init, so it's not harmless..


Thinking about the merits of having diskless nodes being
able to upgrade, is an important plus.

I think the way to go is to have a Pre-Depends: (or 
is Depends: enough for not allowing packages to install
without something?) on a specific symbol, which is only
available inside the NFS system.




regards,
junichi



-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

Re: Purposely broken/uninstallable packages in archive

[Brian May]

> "Norbert" == Norbert Veber <[EMAIL PROTECTED]> writes:

Norbert> From the description of diskless-image-simple: WARNING:
Norbert> This package can and will break your computer. Do not
Norbert> install manually. It should only be installed via the
Norbert> diskless-newimage, part of the diskless package.

Norbert> Why are such things allowed into the archive?  Will these
Norbert> things ever even make it into testing given that they are
Norbert> uninstallable?

Hello,

I no longer maintain diskless-*, but I originally came up with this
idea, so thought I probably should justify my (perhaps broken )
reasons here. IIRC, I posted my reasons on this mailing list
previously, surprisingly though, nobody responded.

Norbert> IMHO. this is a completelly wrong way of going about
Norbert> this.  These packages contain data used by other

Not quite.

It is a package that is designed to get installed on a NFS-root image,
in order to setup the root image in such a way to facilitate booting
on a remote machine.

I made it a *.deb package, because that allows you to use apt-get to
automatically upgrade the package on a *nfs root* partition to the
latest version.

Not only that, but the postinst scripts and postrm scripts will
automatically run, setting up the base directories (especially the
case for diskless-image-secure) using symlinks, etc, required for the
image (I can't remember now what it does, it has been ages).

That means, completely different image layouts can be archived (at
least in theory) only by changing the diskless-image-* package.

In practise, it might be perfectly safe to install on a normal
partition. Just that there is no point.  Also you run the risk that if
installation is interrupted at any time, it will only be half done,
resulting it, say, /var not existing any more (as IIRC, it gets moved
in order to replace it with a symlink). So, why run the risk only to
get a very non-standard system if there is no benefit?  Hence the
warning. In fact, I think there is a primitive check inside the
postinst script to ensure it isn't installed unless everything looks
OK.

Perhaps a better way would be to somehow include the deb packages in
diskless.deb, and somehow upgrade them from diskless.deb. This is
something I was thinking of at the time, but instead gave up
maintainership of the package, since I no longer have time to play
around with diskless systems.

Anyway, I hope this helps explain the situation a bit better. It is
now up to Junichi Uekawa <[EMAIL PROTECTED]> (the new maintainer) to
answer the ifs, whats, whens, and whys about dealing with this bug
report.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Purposely broken/uninstallable packages in archive

[Ethan Benson]

On Thu, Sep 20, 2001 at 09:58:16AM -0400, Norbert Veber wrote:
> 
> If its not to be installed, it should not be in the archive.  This is like
> going to a restaurant and being told not to eat a certain dish under any
> circumstances because you'll get food poisoning.. :)
> 
> Clearly these pacakges are 'data' files, and should be treated as such. 
> They could just as easily be .tar files (or any format, including .deb) 
> inside of an INSTALLABLE .deb..

do you want boot-floppies or not?  because that won't work with
boot-floppies.  

until the next release after woody when debian-installer may become
viable you have to live with these -bf packages as they currently
exist.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpxi2U3XK3cG.pgp
Description: PGP signature

Re: Purposely broken/uninstallable packages in archive

[Eduard Bloch]

#include 
Norbert Veber wrote on Thu Sep 20, 2001 um 09:58:16AM:

> If its not to be installed, it should not be in the archive.  This is like
> going to a restaurant and being told not to eat a certain dish under any
> circumstances because you'll get food poisoning.. :)

What is the problem? The -bf versions are either not dangerous, or the
conflict with their big brothers which are essential (like e2fsprogs),
so they cannot be installed unless the user has been warned explicitely.
And even then, some people maybe want to install the reduced-size
packages because of small harddisk or so (like parted-bf).

Gruss/Regards,
Eduard.
-- 
Diese Message wurde erstellt mit freundlicher Unterstützung eines frei-
laufenden Pinguins aus artgerechter Freilandhaltung.  Er ist garantiert
frei von Micro$oft'schen Viren.


pgpxlAp91e5Gx.pgp
Description: PGP signature

Re: Purposely broken/uninstallable packages in archive

[Steve Greenland]

On 19-Sep-01, 18:16 (CDT), Ethan Benson <[EMAIL PROTECTED]> wrote: 
> read the description for xfsprogs-bf and e2fsprogs-bf, your NOT
> SUPPOSED to install them.  we need them for boot-floppies.  

Fine. Why are they in the main archive? If it's so that the bf can
access them over the net, then they can and should go into a special
archive.

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>

Re: Purposely broken/uninstallable packages in archive

[Norbert Veber]

On Wed, Sep 19, 2001 at 03:16:13PM -0800, Ethan Benson wrote:
> On Wed, Sep 19, 2001 at 11:01:24AM -0400, Norbert Veber wrote:
> > packages such as diskless-image-secure, diskless-image-simple, xfsprogs-bf,
> > e2fsprogs-bf should automatically qualify for grave or even critical bugs
> > for breaking your system if installed.
> 
> read the description for xfsprogs-bf and e2fsprogs-bf, your NOT
> SUPPOSED to install them.  we need them for boot-floppies.  
> 
> with at least the -bf packages the user has to explicity type `yes
> please wreck my system' or something like that into apt before it will
> proceed, if they are that determined to shoot thier own foot, let them.

If its not to be installed, it should not be in the archive.  This is like
going to a restaurant and being told not to eat a certain dish under any
circumstances because you'll get food poisoning.. :)

Clearly these pacakges are 'data' files, and should be treated as such. 
They could just as easily be .tar files (or any format, including .deb) 
inside of an INSTALLABLE .deb..

Thanks,

Norbert


pgphJKl5Oqtls.pgp
Description: PGP signature

Re: Debian testing - uninstallable packages

[Martin Schulze]

Andrew M. Bishop wrote:
> [ I sent this to debian-testing a month ago, but the mailing list   ]
> [ doesn't exist anymore - it is not archived at http://list.debian.org/ ]
> [ If there is a more appropriate list for this discussion let me know.  ]

The list does exist.  For some reason it wasn't archived anymore, which
I had changed recently.  Check out 
.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Please always Cc to me when replying to me on the lists.

Re: Purposely broken/uninstallable packages in archive

[Junichi Uekawa]

severity 112723 critical
thanks

David Starner <[EMAIL PROTECTED]> immo vero scripsit

> On Thu, Sep 20, 2001 at 02:20:31PM +0900, Junichi Uekawa wrote:
> > This is, IMO a bogus bug.
> > Go and fix a real bug. There are enough already.
> 
> A package that will do grave damage to your system if installed
> is not a real bug? 

Define grave damage.

But yes, a machine will not boot after installing this package.
Maybe this was a grave bug after all.

I am overloaded at the moment, and if someone can play around
and test this thing, any help would be appreciated.

I am thinking  of something in the line of building the .deb file and 
installing it somewhere in 
/usr/lib/diskless/




regards,
junichi

-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

Re: Purposely broken/uninstallable packages in archive

[David Starner]

On Thu, Sep 20, 2001 at 02:20:31PM +0900, Junichi Uekawa wrote:
> This is, IMO a bogus bug.
> Go and fix a real bug. There are enough already.

A package that will do grave damage to your system if installed
is not a real bug? 

-- 
David Starner - [EMAIL PROTECTED]
Pointless website: http://dvdeug.dhis.org
When the aliens come, when the deathrays hum, when the bombers bomb,
we'll still be freakin' friends. - "Freakin' Friends"

Re: Purposely broken/uninstallable packages in archive

[Junichi Uekawa]

Junichi Uekawa <[EMAIL PROTECTED]> immo vero scripsit

A note.

> Good. Send me a patch.
> I will apply it.

... after woody, probably.

It has been there since potato, and I don't think I will make a last 
minute change to a package.

This is, IMO a bogus bug.
Go and fix a real bug. There are enough already.



regards,
junichi

-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

Re: Purposely broken/uninstallable packages in archive

[Gustavo Noronha Silva]

Em Wed, 19 Sep 2001 11:01:24 -0400
Norbert Veber <[EMAIL PROTECTED]> escreveu:

> It looks like more and more of these are popping up.  It seems to me that
by the way, I think we're losing lots of the benefits our release/test cycle
is suppose to give us... I see many people making last-hour changes and
rapdly upgrading the upstream version of their packages so that they'll
reach woody's release these packages are missing lots of testing 
major changes and version upgrades should not be left to the last months
of the cycle IMHO...

> I am writing here so that this can be discussed.  I filed grave bugs on some
> of these packages which were imediatelly downgraded by their respective
> maintainers to a wishlist severity, and tagged "wontfix".
that's abuse IMO if the bugs are real bugs...

[]s!

-- 
Gustavo Noronha Silva - kov 
**
|  .''`.  | Debian GNU/Linux: |
| : :'  : | Debian BR...:  |
| `. `'`  |  Be Happy! Be FREE!  |
|   `-| "Think globally, act locally!"   |
**

Re: Purposely broken/uninstallable packages in archive

[Ethan Benson]

On Wed, Sep 19, 2001 at 11:01:24AM -0400, Norbert Veber wrote:
> packages such as diskless-image-secure, diskless-image-simple, xfsprogs-bf,
> e2fsprogs-bf should automatically qualify for grave or even critical bugs
> for breaking your system if installed.

read the description for xfsprogs-bf and e2fsprogs-bf, your NOT
SUPPOSED to install them.  we need them for boot-floppies.  

with at least the -bf packages the user has to explicity type `yes
please wreck my system' or something like that into apt before it will
proceed, if they are that determined to shoot thier own foot, let them.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgp6ddkqrcUEp.pgp
Description: PGP signature

Re: Purposely broken/uninstallable packages in archive

[Junichi Uekawa]

In Wed, 19 Sep 2001 11:01:24 -0400 Norbert cum veritate scripsit :

> Why are such things allowed into the archive?  Will these things ever
> even
> make it into testing given that they are uninstallable?

diskless-image-secure |  0.3.6 |stable | all
diskless-image-secure | 0.3.15 |   testing | all
diskless-image-secure | 0.3.15 |  unstable | all

> IMHO. this is a completelly wrong way of going about this.  These
> packages
> contain data used by other packages.  This is not uncommon, many
> packages
> have a -common or -data package to go with them.  This is a special case
> because the data is in the format of a .deb.  I suggest then that
> diskless-image-simple and friends should be packages that contain the
> .deb
> files.  Ie. there is no reason one cannot have a harmless
> diskless-image-simple that contains another .deb as data.  This second
> .deb
> can then be used by the diskless package to setup its chroot.

Good. Send me a patch.
I will apply it.


regards,
junichi

-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

Purposely broken/uninstallable packages in archive

[Norbert Veber]

Hi,

It looks like more and more of these are popping up.  It seems to me that
packages such as diskless-image-secure, diskless-image-simple, xfsprogs-bf,
e2fsprogs-bf should automatically qualify for grave or even critical bugs
for breaking your system if installed.

From the description of diskless-image-simple:
WARNING: This package can and will break your computer. Do not install
manually. It should only be installed via the diskless-newimage, part of
the diskless package.

Why are such things allowed into the archive?  Will these things ever even
make it into testing given that they are uninstallable?

IMHO. this is a completelly wrong way of going about this.  These packages
contain data used by other packages.  This is not uncommon, many packages
have a -common or -data package to go with them.  This is a special case
because the data is in the format of a .deb.  I suggest then that
diskless-image-simple and friends should be packages that contain the .deb
files.  Ie. there is no reason one cannot have a harmless
diskless-image-simple that contains another .deb as data.  This second .deb
can then be used by the diskless package to setup its chroot.

I am writing here so that this can be discussed.  I filed grave bugs on some
of these packages which were imediatelly downgraded by their respective
maintainers to a wishlist severity, and tagged "wontfix".

Thanks,

Norbert


pgpgxUHyj8sap.pgp
Description: PGP signature

Re: Debian testing - uninstallable packages

[Anthony Towns]

On Sat, Sep 15, 2001 at 03:15:45PM +0100, Andrew M. Bishop wrote:
> [ I sent this to debian-testing a month ago, but the mailing list   ]
> [ doesn't exist anymore - it is not archived at http://list.debian.org/ ]

Actually, the list still exists, and is available at
http://lists.debian.org/debian-testing/. Not sure why it doesn't seem to be
listed amongst all the other mailing lists.

> I have seen a problem with two packages that I wanted to install from
> testing not being installable.  These were gnumeric and gnucash, so I
> raised bug reports about them - currently unanswered.

Right. There're a few packages that aren't installable in woody. There're
also a number that're out of sync, or that have RC bugs, or whatever. It's
not perfect, and it shouldn't really be expected to be.

FWIW, there're accurate lists of uninstallable packages (which does take into
account versions and conflicts, but ignores recommends and suggests) at
http://ftp-master.debian.org/testing/.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

 ``Freedom itself was attacked this morning by faceless cowards.
 And freedom will be defended.''   Condolences to all involved.


pgpw6ma3ue9Aa.pgp
Description: PGP signature

Debian testing - uninstallable packages

[Andrew M. Bishop]

[ I sent this to debian-testing a month ago, but the mailing list   ]
[ doesn't exist anymore - it is not archived at http://list.debian.org/ ]
[ If there is a more appropriate list for this discussion let me know.  ]

The debian FAQ (/usr/share/debian/FAQ) says the following:

: Packages are installed into the `testing' directory after they have undergone
: some degree of testing in unstable.  They must be in sync on all architectures
: where they have been built and mustn't have dependencies that make them
: uninstallable; they also have to have fewer release-critical bugs than the
: versions currently in testing.  This way, we hope that `testing' is always
: close to being a release candidate.

I have seen a problem with two packages that I wanted to install from
testing not being installable.  These were gnumeric and gnucash, so I
raised bug reports about them - currently unanswered.

I realise that there may be other packages that are also
uninstallable, so I wrote a script that parses /var/lib/dpkg/available
and lists those packages that have unmet dependencies, recommendations
or suggestions for packages that are not available.  The script only
checks the package names, not the version numbers, so they may be more
problems.

The list below was compiled from the current status of debian testing
as found in the following sources.list today.

 sources.list 
deb http://www.uk.debian.org/debian woody main
deb http://www.uk.debian.org/debian woody contrib
deb http://www.uk.debian.org/debian woody non-free
deb http://www.uk.debian.org/debian woody non-US/main
deb http://www.uk.debian.org/debian woody non-US/contrib
deb http://www.uk.debian.org/debian woody non-US/non-free
 sources.list 


Package  RelationDependency (not available)
---  --

glcpudepends on  libcommonc++1

gnucash  depends on  libguile9
gnucash  depends on  guile1.4
gnucash  depends on  guile1.4-slib
gnucash  depends on  libgwrapguile0

gnumeric depends on  libgal4

mozilla  depends on  mozilla-browser
mozilla  depends on  mozilla-mailnews

roxen-ssldepends on  pike-crypto

sphinx2-bin  depends on  sphinx2-hmm-6k


Package  RelationRecommendation (not available)
---  --

alamin-serverrecommends  gnokii

bibletimerecommends  sword-dict
bibletimerecommends  sword-comm

cdrecord recommends  mkisofs

cjk-latexrecommends  freetype1-tools

guile1.4-doc recommends  guile1.4

ibcs-source-2.0  recommends  kernel-source-2.0.36 | 
kernel-source-2.0.38

kernel-patch-2.4.0-ia64  recommends  kernel-source-2.4.0

kernel-patch-2.4.1-ia64  recommends  kernel-source-2.4.1

kernel-patch-2.4.3-arm   recommends  kernel-source-2.4.3

kernel-patch-2.4.4-ia64  recommends  kernel-source-2.4.4

kernel-patch-2.4.5-ia64  recommends  kernel-source-2.4.5

kernel-patch-2.4.5-s390  recommends  kernel-source-2.4.5

mozilla  recommends  mozilla-psm

pipsecd  recommends  userlink

quickppp recommends  pppd

tpctlrecommends  tpctl-modules

unp  recommends  unace

webmin-ssl   recommends  webmin-core

zope-pagetemplates   recommends  zope-parsedxml


Package  RelationSuggestion (not available)
---  --

alsa-basesuggestsalsadriver

alsa-utils   suggestsalsadriver

alsa-utils-0.4   suggestsalsadriver

alsa-utils-0.5   suggestsalsadriver

ant  suggestsjmf

aolserversuggestsaolserver-postgres
aolserversuggestsopenacs

atoolsuggestsbzip

cbedic   suggestskbedic

cdrtoaster   suggestsmkisofs

cpuburn  suggestskernel-patch-badram

crafty   suggestscraftywatcher

cupsys-clientsuggestskdelibs3-cups

cvsbook  suggestscvs-doc

cxterm-gbsuggestsintlfonts-chinese

cxterm-jis   suggestsintlfonts-japanese

dhelp   

Re: Uninstallable packages & testing

[Richard Braakman]

On Tue, Mar 28, 2000 at 01:20:33PM +1000, Anthony Towns wrote:
>   tkirc (not installable on any arch, depends on ircii, which isn't in
>   potato or woody)

ircii is now in non-us.

Richard Braakman

Re: Uninstallable packages & testing

[Anthony Towns]

On Tue, Mar 28, 2000 at 01:20:33PM +1000, Anthony Towns wrote:
> There's a list of uninstallable packages for both woody and potato
> (sorted by source package) linked from there too. Stats for potato at
> the moment are: (number of uninstallable binary packages by arch)
>  * sparc:45
>  * i386:10
>  * m68k:45
>  * alpha:64
>  * powerpc:75

It's now:
 * i386:12

The three extras (pcmcia-modules-2.0.36 was removed) are:

task-games (depends on gnuchess, which is only in woody, not in potato)

timidity (depends on libasound1, which is only in woody, not in potato)

timidity-patches (depends on timidity)

> The ten i386 uninstallables are:
> 
>   cricket (not installable on any arch, librrds-perl is depended upon
>   but only available in woody, not potato)
> 
>   libglide2-v3 (needs device3dfx-module, which is presumably built by
>   device3dfx-source, but there aren't any existing packages
>   that match the kernels we distribute. libglide2 is also
>   an `optional' package that seems to depend on an `extra'
>   package)
> 
>   gsnes9x (in main, which needs snes9x-x which is in non-free)
> 
>   pcmcia-modules-2.0.36 (which has already been removed, but the
>   rsync pulse still seems to be happening so auric's out
>   of date)
> 
>   scalapack-lam-test
>   scalapack-mpich-test
>   scalapack-pvm-test
>   (all depend on atlas1, which isn't in potato, or even woody
>   anymore)
> 
>   spamfilter
>   (not installable on any arch, depends on spamdb, which
>   isn't in potato or woody)
> 
>   tkhylafax (not installable on any arch, depends on hylafax-client,
>   which isn't in potato)
> 
>   tkirc (not installable on any arch, depends on ircii, which isn't in
>   potato or woody)

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpElJDXfAIpy.pgp
Description: PGP signature

Uninstallable packages & testing

[Anthony Towns]

Hello world,

My `testing' distribution thing is back up on auric (rather than lully)
now. http://auric.debian.org/~ajt/ . It's running daily or so.

There's a list of uninstallable packages for both woody and potato
(sorted by source package) linked from there too. Stats for potato at
the moment are: (number of uninstallable binary packages by arch)

 * sparc:45
 * i386:10
 * m68k:45
 * alpha:64
 * powerpc:75

The ten i386 uninstallables are:

cricket (not installable on any arch, librrds-perl is depended upon
but only available in woody, not potato)

libglide2-v3 (needs device3dfx-module, which is presumably built by
device3dfx-source, but there aren't any existing packages
that match the kernels we distribute. libglide2 is also
an `optional' package that seems to depend on an `extra'
package)

gsnes9x (in main, which needs snes9x-x which is in non-free)

pcmcia-modules-2.0.36 (which has already been removed, but the
rsync pulse still seems to be happening so auric's out
of date)

scalapack-lam-test
scalapack-mpich-test
scalapack-pvm-test
(all depend on atlas1, which isn't in potato, or even woody
anymore)

spamfilter
(not installable on any arch, depends on spamdb, which
isn't in potato or woody)

tkhylafax (not installable on any arch, depends on hylafax-client,
which isn't in potato)

tkirc (not installable on any arch, depends on ircii, which isn't in
potato or woody)

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpDra5uWNCTw.pgp
Description: PGP signature

Re: Uninstallable Packages

[Martin Bialasinski]

* "Filip" == Filip Van Raemdonck <[EMAIL PROTECTED]> wrote:

Filip> IMO there's yet another issue to consider (which brings another
Filip> complication with it): there may be people who will want both
Filip> mesa and glx, if they own a Riva or Matrox + Voodoo* add-on
Filip> board.

/me waves his hand.

Matrox G200 and Vodoo Graphics.

BTW: is there a mesa deb with glide support somewhere?

Ciao,
Martin

Re: Uninstallable Packages

[Filip Van Raemdonck]

Joseph Carter wrote:

> On Tue, Oct 05, 1999 at 10:13:51PM +1000, Anthony Towns wrote:
> >
> >   Depends: libgl1 ; which doesn't exist
>
> This exists in CVS.  libGL.so.1 is what is used by the latest versions of
> GLX and Mesa.  I think the problem was coming up with a sane way to make
> alternatives work for the purpose since libgl1 is almost certainly a
> virtual package provided by Mesa, GLX, and probably commercial offerings
> as well.
>
> Compound this with Mesa and GLX merging and you've got something close to
> a nightmare.

IMO there's yet another issue to consider (which brings another complication
with it): there may be people who will want both mesa and glx, if they own a
Riva or Matrox + Voodoo* add-on board. As long as Mesa keeps using the name
libMesa* it can probably coexists with GLX (exept perhaps for include files?),
but I've heard that they will change to libGL* as well. If they are planning
on merging with GLX, the problem of multiple video cards (and drivers) will be
theirs I guess.

Re: Uninstallable Packages

[Joseph Carter]

On Tue, Oct 05, 1999 at 10:13:51PM +1000, Anthony Towns wrote:
> Packages with unknown dependencies:
> 
> clanlib0-display-fbdev-dev
> clanlib0-display-ggi-dev
> clanlib0-display-glx
> clanlib0-display-glx-dev
> clanlib0-display-svgalib-dev
> clanlib0-display-x11-dev
>   Depends: libgl1 ; which doesn't exist

This exists in CVS.  libGL.so.1 is what is used by the latest versions of
GLX and Mesa.  I think the problem was coming up with a sane way to make
alternatives work for the purpose since libgl1 is almost certainly a
virtual package provided by Mesa, GLX, and probably commercial offerings
as well.


Compound this with Mesa and GLX merging and you've got something close to
a nightmare.  It's a release critical bug that these packages depend on
something that isn't yet available as a package however.  The packages
should be removed if the problem is not resolved by the time we're ready
to release.
-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
Indifference will certainly be the downfall of mankind, but who cares?



pgp7npmGvsl0a.pgp
Description: PGP signature

Re: Uninstallable Packages

[Petr Cech]

On Tue, Oct 05, 1999 at 10:13:51PM +1000 , Anthony Towns wrote:
> Hello world,
> 
> I'm experimenting with a script to work out whether packages are
> installable or not. I figured the world at large might be interested in
> some of the results.
> 
> The following packages are not installable (ie, their Depends:,
> Recommends:, and Conflicts: can't be concurrently satisfied) using i386
> packages from main, contrib, non-free, and non-US/*.
> 
> Here we go...
> 
> Packages with out-dated dependencies:
> 
> Mosaic
> fsviewer
> imaptool
> knews
> libmagick4g-lzw
> libtiff3
> xacc
> xloadimage
>   Depends: libjpegg6a ; libjpegg62 is available

these should be fixed (except for libmagick4g-lzw which has yet another
problems) by simply recompiling.
I could do imaptools fsviewer and xloadimage. 

> ibcs2.0.35
> pcmcia-modules-2.0.35
> pcmcia-modules-2.2.1
> pcmcia-modules-2.2.5
> pcmcia-modules-2.2.7
> pcmcia-modules-2.2.9
>   Recommends: kernel-image- ;
>   2.0.36, 2.2.10, 2.2.12, 2.2.12-i386 are available

so these should be removed. Bug against ftp.debian.org. But I would let it
on pcmcia package maintainer.

> fbrowser
> yagirc
>   Depends: libglib1.1 ; libglib1.2 is available

another recompile? Maybe there are other problems. Don't know glib so well.

> emacs19   Depends: liblockfile0 ; liblockfile1 is available, not 0

recompile. Could do it.

> gnome-apt Depends: libapt-pkg2.5 ; libapt-pkg2.6 is available

I've looked at it. But it cannot be only recompiled :((

> libwine-dbg   Depends: libwine0.0.971116 ; libwine 0.0.990815-1 is 
> available

this should explain it

wine (0.0.990704-2) unstable; urgency=low

  * New maintainer Andrew Lenharth.
  * Repackaged.
  * libwine0.0.971116 renamed to libwine

 -- Andrew D. Lenharth <[EMAIL PROTECTED]>  Sun,  1 Aug 1999 14:36:54 -0700

so. According to debian/control there is no libwine-dbg any more.
I'm filling a bugreport.

> tcl8.0-docDepends: tcl8.0 (= 8.0.5-2); 8.0.5-3 is available
> tcl8.2-docDepends: tcl8.2 (= 8.2.0-1); 8.2.0-2 is available
> tk8.0-doc Depends: tk8.0 (= 8.0.5-3); 8.0.5-4 is available
> tk8.2-doc Depends: tk8.2 (= 8.2.0-1); 8.2.0-2 is available

BTW why do these depend on the exact version?

> lyx   Depends: libforms0.89 ; which is in Incoming (since Oct 
> 1)

wait :((

> libtricks Depends: libc6, which Conflicts: libtricks

maybe this should be removed as it doesn't/can't work with glibc-2.1

> linbot
>   Depends: python-base (>= 1.5.1), python-net (>= 1.5.1),
>   python-misc (>= 1.5.1);
>   python-base Provides/Replaces/Conflicts:
>   python-net, python-misc
> 
> python-misc
> python-net
>   Depends: python-base ; which Conflicts: python-misc, python-net

these two packages are obsolete. Should be removed. Is the maintainer with us
again. I recall a request for NMU on d-d.

Petr Čech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

Uninstallable Packages

[Anthony Towns]

Hello world,

I'm experimenting with a script to work out whether packages are
installable or not. I figured the world at large might be interested in
some of the results.

The following packages are not installable (ie, their Depends:,
Recommends:, and Conflicts: can't be concurrently satisfied) using i386
packages from main, contrib, non-free, and non-US/*.

Here we go...

Packages with out-dated dependencies:

Mosaic
fsviewer
imaptool
knews
libmagick4g-lzw
libtiff3
xacc
xloadimage
Depends: libjpegg6a ; libjpegg62 is available

ibcs2.0.35
pcmcia-modules-2.0.35
pcmcia-modules-2.2.1
pcmcia-modules-2.2.5
pcmcia-modules-2.2.7
pcmcia-modules-2.2.9
Recommends: kernel-image- ;
2.0.36, 2.2.10, 2.2.12, 2.2.12-i386 are available

fbrowser
yagirc
Depends: libglib1.1 ; libglib1.2 is available

gtkglareamm
xt
Depends: gtkglarea ; gtkglarea4 is available

libapache-mod-auth-pam
libapache-mod-ruby
Depends: apache-common (== 1.3.6-*) ; 1.3.9-8 is available

boot-floppies Depends: newt0.25, newt0.25-dev ; newt0.30 is available
emacs19 Depends: liblockfile0 ; liblockfile1 is available, not 0
gnome-apt   Depends: libapt-pkg2.5 ; libapt-pkg2.6 is available
libwine-dbg Depends: libwine0.0.971116 ; libwine 0.0.990815-1 is available
llettersDepends: libglib1.1.13; but libglib1.2 is available
sane-gimp1.1 Depends: libgimp1.1.6 ; 1.1.9 is available
snmptraplogd Depends: libsnmp3.6 ; libsnmp4.0 is available
tcl8.0-doc  Depends: tcl8.0 (= 8.0.5-2); 8.0.5-3 is available
tcl8.2-doc  Depends: tcl8.2 (= 8.2.0-1); 8.2.0-2 is available
tk8.0-doc   Depends: tk8.0 (= 8.0.5-3); 8.0.5-4 is available
tk8.2-doc   Depends: tk8.2 (= 8.2.0-1); 8.2.0-2 is available

Packages with unknown dependencies:

clanlib0-display-fbdev-dev
clanlib0-display-ggi-dev
clanlib0-display-glx
clanlib0-display-glx-dev
clanlib0-display-svgalib-dev
clanlib0-display-x11-dev
Depends: libgl1 ; which doesn't exist

dbf2mysql
libchmsql-mysql
Depends: mysql-base ; should depend on mysql-client? -server?

lyx Depends: libforms0.89 ; which is in Incoming (since Oct 1)
vflib2  Recommends: watanabe-vfont ; which doesn't exist
osh Depends: libnfslock ; which doesn't exist
roxen-ssl   Depends: pike-crypto ; which doesn't exist?
sdic-edict  Depends: edict ; which doesn't exist?

Confusing Packages:

libroxen-ldapmod
Depends: roxen (>= 1.2.46-9)
Conflicts: roxen (>= 1.3.111) ; roxen 1.3.111-8 is available

libstdc++2.9-glibc2.1-dev
Depends: g++, which Depends: libstdc++2.10-dev,
which Conflicts: libstdc++2.9-glibc2.1-dev

libtricks   Depends: libc6, which Conflicts: libtricks

linbot
Depends: python-base (>= 1.5.1), python-net (>= 1.5.1),
python-misc (>= 1.5.1);
python-base Provides/Replaces/Conflicts:
python-net, python-misc

python-misc
python-net
Depends: python-base ; which Conflicts: python-misc, python-net

r-pdl
Depends: pdl; which Conflicts/Replaces: r-pdl

Transitively uninstallable pacakges:

custom
emacs19-el
emacs-czech
vm
w3-el-e19
Depends: emacs19 ; which isn't installable

vflib2-dev
vflib2-misc
mgp
Depends: vflib2 ; which nominally isn't installable

libmagick4-lzw-dev Depends: libmagick4g-lzw
libtiff3-altdev Depends: libtiff3
libstdc++2.9-glibc2.1-dbg Depends: libstdc++2.9-glibc2.1-dev

Huh, well, that worked out better than I expected. The only two that I
deleted were contrib/ programs depending on pine/qmail/other things, all
the rest seem to actually be uninstallable.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgp6t1GOebHZ0.pgp
Description: PGP signature