Re: Full install/removal/upgrade test results available

[Mike Hommey]

On Wed, Nov 17, 2010 at 08:37:17AM -0600, Lucas Nussbaum wrote:
> Mike Hommey 
>python-xpcom (U)

I /think/ this could be solved by not using a pre-depends on
xulrunner-1.9.1. OTOH, the pre-depends solves a part of another
problem though not entirely, due to triggers ordering: the
xulrunner-1.9.1 trigger can't work until the python-support trigger has
been run... The only fix for that issue that I can think of would be to
stop using python-support... If other people have ideas, I'm all ears.

Cheers,

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101119081840.ga3...@glandium.org

Re: Full install/removal/upgrade test results available

[Josselin Mouette]

Le mercredi 17 novembre 2010 à 08:37 -0600, Lucas Nussbaum a écrit :
> Debian GNOME Maintainers 
>gnome
>gnome-accessibility
>gnome-app-install (U)
>gnome-core
>gnome-dbg
>gnome-desktop-environment
>gnome-devel
>gnome-office
>python-software-properties (U)
>software-properties-gtk (U)
>software-properties-kde (U)
>update-manager-core

All these failures seem to be caused by the “apt-get install apt” run
which happens before the rest. It will remove xulrunner:

   Package libcairo2 has broken dep on xulrunner-1.9
 Considering xulrunner-1.9 2 as a solution to libcairo2 302
 Added xulrunner-1.9 to the remove list
 Fixing libcairo2 via remove of xulrunner-1.9

I think libapt causes synaptic (and/or other APT frontends) to be
upgraded, which is why it tries to upgrade cairo, but in the end it just
removes both synaptic and the xulrunner rdeps.

OTOH a plain dist-upgrade with lenny’s APT would probably just work.

>rhythmbox (U)
>rhythmbox-dbg (U)

This one is similar, although a bit different. Because of the python
upgrade, python-gtk2 ends up removed instead of upgraded.

All of this suggests that the idea to upgrade APT first, as suggested in
the release notes, is a very bad one. It would work if libapt hadn’t
changed its ABI in the meantime.

> sabayon (U)

This one looks like a genuine RC bug in sabayon.postrm. I’ve reported it
and fixed it in the SVN.

All in all, thanks for this very thorough test.
-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  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/1290158968.23343.21.ca...@meh

Re: Bug#603938: debian-installer: The 1st CD doesn't contain desktop nor laptop tasks

[Holger Levsen]

Hi,

On Donnerstag, 18. November 2010, Samuel Thibault wrote:
> > - download debian-squeeze-di-beta1-i386-CD-1.iso
> > - boot it on a computer without any access to the network
> > - use all default options (but french localisation) until tasksel
> > appears.
> >
> > Result: only "mail server", "SSH server" and standart system are
> > available.
>
> Unfortunately, that's "expected" result.  As discussed on

So let's close this bug. There is no need and gain to keep this bug report 
open (against general at least), CDs wont grow in size and I'm pretty sure 
the desktop install sizes wont shrink.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#603938: marked as done (debian-installer: The 1st CD doesn't contain desktop nor laptop tasks)

[Debian Bug Tracking System]

Your message dated Fri, 19 Nov 2010 11:06:51 +0100
with message-id <201011191106.53050.hol...@layer-acht.org>
and subject line Re: Bug#603938: debian-installer: The 1st CD doesn't contain 
desktop nor laptop tasks
has caused the Debian Bug report #603938,
regarding debian-installer: The 1st CD doesn't contain desktop nor laptop tasks
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
603938: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603938
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-installer
Version: 6.0 beta1
Severity: important


Steps to reproduce the problem:

- download debian-squeeze-di-beta1-i386-CD-1.iso
- boot it on a computer without any access to the network
- use all default options (but french localisation) until tasksel appears.

Result: only "mail server", "SSH server" and standart system are available.

Expected result: the desktop and laptop tasks are available.



--- End Message ---
--- Begin Message ---
Hi,

On Donnerstag, 18. November 2010, Samuel Thibault wrote:
> > - download debian-squeeze-di-beta1-i386-CD-1.iso
> > - boot it on a computer without any access to the network
> > - use all default options (but french localisation) until tasksel
> > appears.
> >
> > Result: only "mail server", "SSH server" and standart system are
> > available.
>
> Unfortunately, that's "expected" result.  As discussed on

So let's close this bug. There is no need and gain to keep this bug report 
open (against general at least), CDs wont grow in size and I'm pretty sure 
the desktop install sizes wont shrink.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
--- End Message ---

Re: Full install/removal/upgrade test results available

[Yves-Alexis Perez]

On 19/11/2010 08:52, Yves-Alexis Perez wrote:
> Anyone knows why and how to fix that? Would a “breaks” instead of a
> “conflicts” fix it?

Seems that “Breaks:” doesn't work either:

> Investigating (0) xfce4-settings [ amd64 ] < none -> 4.6.5-3 > ( xfce )
> Broken xfce4-settings:amd64 Breaks on xfce4-mcs-plugins [ amd64 ] < 4.4.2-4 > 
> ( x11 )
>   Considering xfce4-mcs-plugins:amd64 0 as a solution to xfce4-settings:amd64 > 0
>   Holding Back xfce4-settings:amd64 rather than change xfce4-mcs-plugins:amd64
> Investigating (0) xfce4-session [ amd64 ] < 4.4.2-6 -> 4.6.2-2 > ( xfce )
> Broken xfce4-session:amd64 Depends on xfce4-settings [ amd64 ] < none -> 
> 4.6.5-3 > ( xfce )
>   Considering xfce4-settings:amd64 0 as a solution to xfce4-session:amd64 0
>   Holding Back xfce4-session:amd64 rather than change xfce4-settings:amd64
>  Try to Re-Instate (1) xfce4-session:amd64
> Done

I'm not sure why apt doesn't want to remove xfce4-mcs-plugin at all. Any
idea?
-- 
Yves-Alexis


-- 
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/4ce65239.7040...@debian.org

Bug#603938: debian-installer: The 1st CD doesn't contain desktop nor laptop tasks

[Raphael Hertzog]

Hi,

On Fri, 19 Nov 2010, Holger Levsen wrote:
> > > Result: only "mail server", "SSH server" and standart system are
> > > available.
> >
> > Unfortunately, that's "expected" result.  As discussed on
> 
> So let's close this bug. There is no need and gain to keep this bug report 
> open (against general at least), CDs wont grow in size and I'm pretty sure 
> the desktop install sizes wont shrink.

Ubuntu is taking steps to ensure that their desktop still fits in
a single CD (that's the reason why the changelogs are shrinked in the
ubuntu packages now, some images are recompressed, etc.).

So there are possibilities, and we can tweak the tasks and the
dependencies in some cases.

But it's probably too late for squeeze and like most tasks touching lots
of packages, it will be difficult to find someone leading such a project.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)



--
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/20101119113301.gb25...@rivendell.home.ouaza.com

Re: Full install/removal/upgrade test results available

[David Kalnischkies]

On Fri, Nov 19, 2010 at 11:32, Yves-Alexis Perez  wrote:
> On 19/11/2010 08:52, Yves-Alexis Perez wrote:
>> Anyone knows why and how to fix that? Would a “breaks” instead of a
>> “conflicts” fix it?
>
> Seems that “Breaks:” doesn't work either:
>
>> Investigating (0) xfce4-settings [ amd64 ] < none -> 4.6.5-3 > ( xfce )
>> Broken xfce4-settings:amd64 Breaks on xfce4-mcs-plugins [ amd64 ] < 4.4.2-4 
>> > ( x11 )
>>   Considering xfce4-mcs-plugins:amd64 0 as a solution to 
>> xfce4-settings:amd64 0
>>   Holding Back xfce4-settings:amd64 rather than change 
>> xfce4-mcs-plugins:amd64
>> Investigating (0) xfce4-session [ amd64 ] < 4.4.2-6 -> 4.6.2-2 > ( xfce )
>> Broken xfce4-session:amd64 Depends on xfce4-settings [ amd64 ] < none -> 
>> 4.6.5-3 > ( xfce )
>>   Considering xfce4-settings:amd64 0 as a solution to xfce4-session:amd64 0
>>   Holding Back xfce4-session:amd64 rather than change xfce4-settings:amd64
>>  Try to Re-Instate (1) xfce4-session:amd64
>> Done
>
> I'm not sure why apt doesn't want to remove xfce4-mcs-plugin at all. Any
> idea?

xfce4-mcs-manager recommends it.
As APT has no indication that this package can go away it does the
only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise
the user will lose functionality…
(recommends are defined as installed on all, expect "unusual" systems,
 so their value is very close to a depends for APT)


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/aanlktino9o5nfbect-kif1=sj6jgspukvunjp3x4s...@mail.gmail.com

Re: Full install/removal/upgrade test results available

[Yves-Alexis Perez]

On 19/11/2010 12:29, David Kalnischkies wrote:
> xfce4-mcs-manager recommends it.
> As APT has no indication that this package can go away it does the
> only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise
> the user will lose functionality…
> (recommends are defined as installed on all, expect "unusual" systems,
>  so their value is very close to a depends for APT)

Except it's not. System would be perfectly usable with xfce4-mcs-plugin
and without xfce4-mcs-manager (it wouldn't make much sense, but still).
Preferring to ignore a Breaks: in order to keep a Recommends: satisfied
looks to me like the wrong thing to do, though I'm not fluent enough in
dependencies to be sure.

By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't
work either, apt will still prefer to hold xfce4-session and keep
xfce4-mcs-*.

Cheers,
-- 
Yves-Alexis


-- 
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/4ce66692.1050...@debian.org

Re: Work-needing packages report for Oct 22, 2010

[Alexander Reichle-Schmehl]

Hi!

Am 22.10.2010 16:26, schrieb Martin Zobel-Helas:

>> The following is a listing of packages for which help has been requested
>> through the WNPP (Work-Needing and Prospective Packages) system in the
>> last week.
>>
>> Total number of orphaned packages: 0 (new: 0)
>> Total number of packages offered up for adoption: 0 (new: 0)
>> Total number of packages requested help for: 0 (new: 0)
>>
>> Please refer to http://www.debian.org/devel/wnpp/ for more information.
> 
> I disabled that cronjob for now, it misses the bts2ldap part on quantz.

Any news on that?  We used to mention the numbers on the Debian Project
News, and I got asked, why we dropped these numbers.  So it seems they
are indeed read and missed :)


Best regards,
  Alexander


-- 
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/4ce66d28.3060...@schmehl.info

Bug#604022: ITP: fcitx-config - graphic fcitx configuration tool

[Aron Xu]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: fcitx-config
  Version : 0.1.3
* URL : http://code.google.com/p/fcitx
* License : GPL-3+
  Programming Lang: C
  Description : graphic fcitx configuration tool


-- 
Regards,
Aron Xu


signature.asc
Description: Digital signature

Re: Full install/removal/upgrade test results available

[Julien Cristau]

On Fri, Nov 19, 2010 at 10:29:28 +0100, Josselin Mouette wrote:

> All of this suggests that the idea to upgrade APT first, as suggested in
> the release notes, is a very bad one. It would work if libapt hadn’t
> changed its ABI in the meantime.
> 
Last I checked the squeeze release notes didn't recommend that.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#604023: ITP: fcitx-sunpinyin - sunpinyin engine for fcitx

[Aron Xu]

Package: wnpp
Severity: wishlist
Reporter: IME Packaging Team 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: fcitx-sunpinyin
  Version : 0.1.1
* URL : http://code.google.com/p/fcitx
* License : GPL-3+
  Programming Lang: C++
  Description : sunpinyin engine for fcitx

-- 
Regards,
Aron Xu


signature.asc
Description: Digital signature

Re: Full install/removal/upgrade test results available

[David Kalnischkies]

On Fri, Nov 19, 2010 at 12:59, Yves-Alexis Perez  wrote:
> On 19/11/2010 12:29, David Kalnischkies wrote:
>> xfce4-mcs-manager recommends it.
>> As APT has no indication that this package can go away it does the
>> only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise
>> the user will lose functionality…
>> (recommends are defined as installed on all, expect "unusual" systems,
>>  so their value is very close to a depends for APT)
>
> Except it's not. System would be perfectly usable with xfce4-mcs-plugin
> and without xfce4-mcs-manager (it wouldn't make much sense, but still).
> Preferring to ignore a Breaks: in order to keep a Recommends: satisfied
> looks to me like the wrong thing to do, though I'm not fluent enough in
> dependencies to be sure.

So, go and start reading. Debian has a lot of dependencies and you have a
lot of possibilities because of that.
You can't use them if you don't know them.
And, more important, you can't blame APT for being stupid if you don't
know what you talk about yourself.

Oh, and in the end, i am not a D{D,M}, so you shouldn't trust me and
what i say about a policy as i don't upload packages to the archive
which needs to comply to that policy…


> By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't
> work either, apt will still prefer to hold xfce4-session and keep
> xfce4-mcs-*.

You have way more information than APT - for example:
Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are
now obsolete? No. All which is said is that the new xfce4-session doesn't
work with them (it breaks them). So, for APT its clear that we loose two
packages just to get another one upgraded… that doesn't feel right.
Just imagine dpkg gets a new console interface and therefore isn't
compatible with apt/aptitude anymore - should APT really decide to
remove apt, aptitude and friends just to upgrade dpkg? No. Better wait
for apt, aptitude and friends to be upgraded to work again with dpkg
and retreat from upgrading dpkg now (in that case the breaks would be
versioned, but still).

We have cases in which packages in extra break each other - this
doesn't mean they obsolete each other - it doesn't even say that they
do the same nor even something similar, it just says that they doesn't
work together on the same system (unversioned as the breaks here).
If apt would provide a /usr/bin/apt it could break java for example (and v.v.)
as this provides /usr/bin/apt too - it should be clear that apt and java
have nothing in common expect that they use the same name for
an executable… (yes, thats completely made up, in reality this binary
is already an alternative - but even then it would feel strange to provide
an alternative with apt for javas annotation processing tool…)


Before you ask, no, debian has no way to say: "this package is obsolete -
its fine that it will be removed as other packages take care of its tasks."
The closest thing to that is §7.6.2, but i doubt that this is really such
a drop-in replacement in your case.
(and that doesn't say anything about an upgrade path, too)


So, to solve your problem, you have more or less only one option:
Do not try to clean up behind you, let the package managers do it
(with autoremove or deborphan or whatever). Trying it yourself only
complicates stuff -- and adding Breaks for this kind of stuff is even
against the policy if you want to read it that way: §7.4
> Neither Breaks nor Conflicts should be used unless two packages
> cannot be installed at the same time or installing them both causes
> one of them to be broken or unusable. Having similar functionality or
> performing the same tasks as another package is not sufficient
> reason to declare Breaks or Conflicts with that package.


Or in short: either make empty dummy packages out of them or
just leave them alone.


Best regards

David Kalnischkies

P.S.: The first option will be revisited and properly enhanced at the time
of wheezy (aka "disappearing packages") but let us talk about that later…


--
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/aanlktinb2eg+=+pmhkjrmkcf6t6pwcru-hqd+jfdq...@mail.gmail.com

Re: Full install/removal/upgrade test results available

[Goswin von Brederlow]

David Kalnischkies  writes:

> Before you ask, no, debian has no way to say: "this package is obsolete -
> its fine that it will be removed as other packages take care of its tasks."
> The closest thing to that is §7.6.2, but i doubt that this is really such
> a drop-in replacement in your case.
> (and that doesn't say anything about an upgrade path, too)

Also note that no frontend has ever made use of §7.6.2 and handled
upgrading obsolete packages to their replacements. This is usualy done
by providing a dummy package under the old name that depends on the new
name.

MfG
Goswin


-- 
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/87lj4p6sa4@frosties.localnet

Bug#603938: debian-installer: The 1st CD doesn't contain desktop nor laptop tasks

[Kjö Hansi Glaz]

[...]
> > Result: only "mail server", "SSH server" and standart system are available.
> 
> Unfortunately, that's "expected" result.  As discussed on
> 
> http://lists.debian.org/debian-devel/2010/10/msg00311.html
> 
> the desktop task has grown quite a bit! More than what a CD can hold, in
> any case.  This is not something that the Debian Installer can solve,
> it's general entropy at work.
> 
Sad to hear that. It was really handy to be able to install debian from one CD.

> > Expected result: the desktop and laptop tasks are available.
> 
> It seems we unfortunately can't expect that any more. We can still
> probably check that they fit on the 1st+2nd CDs.
> 

I think that it should then made be clear in the release notes that the 1st CD
is not enough to install a desktop anymore and that somebody having to install a
desktop without access to the network must download the two first CDs or the
first DVD.

Cheers,

K.



-- 
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/20101119190646.gl15...@a4nancy.net.eu.org

Re: Release Update - Upgrades, deep freeze info, BSPs

[Lubos Kopecky]

one more problem

in WIndows 7 then I run setup.exe after every "next" the program is 
minimalizet to task bar so I have to click again and again to icon with 
debian logo to open show up installer back on the desktop...


--
Kind regards, Lubos Kopecky


--
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/4ce6e061.6090...@fa-mi.org

Re: Release Update - Upgrades, deep freeze info, BSPs

[Lubos Kopecky]

Hi all,

I have problem with graphic debian squeeze installer and encrypt 
partitions. I din't try text version yet.


I choose manual, then create some partitions on disk, set ext4, 
mountpoint / or /home, then back to menu and choose encrypt (it's 4th 
line from the top - under lvm, under is list of all partitions), then 
select partitions which I want to encrypt, there I can see mountpoint 
and filesystem ext4 for selected partition, but when everything is done 
with partitioning, encrypted partitions don't have any mountpoints and 
are formated as ext3.
Other problem is, that when I save new state of partitions I can't 
change encrypt to something else anymore - only restart of instlator 
(back to bios and boot it again) is way to change type of partition.
I don't have CDRom, so I run setup in Windows 7 and then choose 
instalation in boot menu (from boot.ini).


Second problem is getting IP from DHCP - I couldn't get it at work. When 
I tried it at home it worked for the first time but when I tried to 
install system for second time I didn't get IP at home as well. Both on 
ethernet - my laptop is Dell Latitude E4310 (13"). I didn't tried wireless.


Third problem I've been surprised that system didn't get IP on ethernet 
until I didn't log in to KDE4 and enter password to wallet (so could't 
connect through ssh to notebook after system boot up).


My english and writing style are horrible I know but I hope you got 
everything... If you have any questions about it let me know.


I tried weekly build and daily build 19th Nov 2010 as well with the same 
effect.


--
Kind regards, Lubos Kopecky


--
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/4ce6df8c.9040...@fa-mi.org

Re: Full install/removal/upgrade test results available

[Yves-Alexis Perez]

On ven., 2010-11-19 at 19:23 +0100, David Kalnischkies wrote:

> 
> So, go and start reading. Debian has a lot of dependencies and you have a
> lot of possibilities because of that.
> You can't use them if you don't know them.
> And, more important, you can't blame APT for being stupid if you don't
> know what you talk about yourself.

Well, I thought that Recommends: and Depends: were different things,
which looks to me like a fair assumption. It seems I'm wrong.

Oh, and I don't really like your tone, and I'm not usually offended by
rudeness.

> > By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't
> > work either, apt will still prefer to hold xfce4-session and keep
> > xfce4-mcs-*.
> 
> You have way more information than APT - for example:
> Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are
> now obsolete? No. All which is said is that the new xfce4-session doesn't
> work with them (it breaks them).

No, xfce4-session depends on xfce4-settings. And xfce4-settings
*replaces* xfce4-mcs-*.

>  So, for APT its clear that we loose two
> packages just to get another one upgraded… that doesn't feel right.

Even with the Replaces: bit?

> 
> Before you ask, no, debian has no way to say: "this package is
> obsolete -
> its fine that it will be removed as other packages take care of its
> tasks."
> The closest thing to that is §7.6.2, but i doubt that this is really
> such
> a drop-in replacement in your case.
> (and that doesn't say anything about an upgrade path, too)

Well, it is a replacement, and I don't see such a thing as “drop-in”
replacement (and this is not a virtual package).

> 
> So, to solve your problem, you have more or less only one option:
> Do not try to clean up behind you, let the package managers do it
> (with autoremove or deborphan or whatever). Trying it yourself only
> complicates stuff -- and adding Breaks for this kind of stuff is even
> against the policy if you want to read it that way: §7.4

Except that in my case, I'm more in the $7.6. I'm not adding
Conflicts/Replaces just because I'd like to force people to get rid of
xfce4-mcs-*, it's just that it xfce4-settings needs it. They both ship
common files (along with xfce4-mcs-plugins) and xfce4-settings replaces
the functionality provided by xfce4-mcs-manager.

> > Neither Breaks nor Conflicts should be used unless two packages
> > cannot be installed at the same time or installing them both causes
> > one of them to be broken or unusable.

Which is the case here, and why the fields were added in the first
place.
> 
> 
> Or in short: either make empty dummy packages out of them or
> just leave them alone.

Which would then need to Depends on xfce4-settings in order to provide
the same set of functionality, adding complexity to the dependencies.

Cheers,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Static linking: pkgconfig vs libtool

[Dmitry Katsubo]

Dear Debian Developers!

In the application I am taking part in, I am trying to create a
configuration script to be able to provide two deliverables:
dynamically-linked executable and statically-linked.

The first problem I faced is that it is difficult to explore what should
be the list of libraries for static linking (as I have to provide the
list of libraries which are direct dependencies as well as indirect). I
know this problem is solved with libtool (which consumes the information
from *.la) and with pkg-config (which consumes the information from
*.pc). The problems I faced:

* General question. What is the current trend: to use libtool or
pkg-config? For me it is easier to use pkg-config CLI, rather then
re-write autoconf scripts to fit libtool ideology (maybe I don't need
to, fixme).
* Some libraries (e.g. GraphicsMagick) does not provide the list of
libraries for statis linking via .pc (compare 'pkg-config --static
--libs GraphicsMagick++' and 'GraphicsMagick++-config --libs'). Should
it be fired as a bug for GraphicsMagick package?
* Some libraries (e.g.) do not follow the agreement for .NET/CLI
(http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-pkg-config-file)
which I think is also good to follow for common libraries:
- xfprint4-4.6.1 package contains xfprint-1.0.pc (expected: xfprint4.pc
or xfprint4.pc -symlink-> xfprint4-4.6.1.pc)
- libxml2-dev package contains libxml-2.0.pc (expected: libxml2.pc or
libxml2.pc -symlink-> libxml2-2.7.7.pc)

I have posted this question also to stackoverflow
(http://stackoverflow.com/questions/3932742/static-library-auto-discovery-and-linking)
but I haven't got a complete answer, so I kindly ask the Debian
community to help me.

Thank you in advance!

-- 
With best regards,
Dmitry


-- 
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/4ce6ec61.7030...@mail.ru

Re: Full install/removal/upgrade test results available

[Russ Allbery]

Goswin von Brederlow  writes:

> Also note that no frontend has ever made use of §7.6.2 and handled
> upgrading obsolete packages to their replacements.

There's a reason for that: it's not possible to create a Policy-compliant
package that could use 7.6.2 in that fashion.

I keep trying to point this out each time you bring this up.

-- 
Russ Allbery (r...@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/87ipzt7zz6@windlord.stanford.edu

Re: Static linking: pkgconfig vs libtool

[Russ Allbery]

Dmitry Katsubo  writes:

> The first problem I faced is that it is difficult to explore what should
> be the list of libraries for static linking (as I have to provide the
> list of libraries which are direct dependencies as well as indirect). I
> know this problem is solved with libtool (which consumes the information
> from *.la) and with pkg-config (which consumes the information from
> *.pc). The problems I faced:

> * General question. What is the current trend: to use libtool or
> pkg-config? For me it is easier to use pkg-config CLI, rather then
> re-write autoconf scripts to fit libtool ideology (maybe I don't need
> to, fixme).

pkg-config is much superior to libtool, since libtool includes all the
libraries on dynamic links as well, which creates unwanted shared library
dependencies and causes other problems.  Because of that, the trend in
Debian is to empty that information from libtool *.la files or not ship
them at all, making them useless for static linking information.

> * Some libraries (e.g. GraphicsMagick) does not provide the list of
> libraries for statis linking via .pc (compare 'pkg-config --static
> --libs GraphicsMagick++' and 'GraphicsMagick++-config --libs'). Should
> it be fired as a bug for GraphicsMagick package?

I think it's reasonable to consider that a bug, although it's probably a
minor one and it may be closed wontfix if the GraphicsMagick maintainers
aren't interested in supporting static linking.  (A lot of upstreams just
don't care about static linking and aren't willing to support it.)

> * Some libraries (e.g.) do not follow the agreement for .NET/CLI
> (http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-pkg-config-file)
> which I think is also good to follow for common libraries:
> - xfprint4-4.6.1 package contains xfprint-1.0.pc (expected: xfprint4.pc
> or xfprint4.pc -symlink-> xfprint4-4.6.1.pc)
> - libxml2-dev package contains libxml-2.0.pc (expected: libxml2.pc or
> libxml2.pc -symlink-> libxml2-2.7.7.pc)

Er, what does an agreement for .NET/CLI have to do with pkg-config files
for libraries written in C?  I don't see any relevance of that packaging
documentation to the libraries you list.

The pkg-config configuration file name is not, in general, going to be
determinable from the Debian package name.

-- 
Russ Allbery (r...@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/87aal57zio@windlord.stanford.edu

Re: Release Update - Upgrades, deep freeze info, BSPs

[Didier 'OdyX' Raboud]

Lubos Kopecky wrote:

> one more problem
> 
> in WIndows 7 then I run setup.exe after every "next" the program is
> minimalizet to task bar so I have to click again and again to icon with
> debian logo to open show up installer back on the desktop...

Hi Lubos, 

could you please report a bug against the "win32-loader" package with 
details about that problem ?

Thanks in advance, cheers,

OdyX


-- 
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/ic6sko$pd...@dough.gmane.org

Bug#604065: ITP: ocaml-extunix -- Extended functions for OCaml Unix module

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: ocaml-extunix
  Version : 0.0.1
  Upstream Author : ygrek, Sylvain Le Gall, Stephane Glondu 
* URL : http://extunix.forge.ocamlcore.org/
* License : LGPL-2.1 with OCaml linking exception
  Programming Lang: OCaml
  Description : Extended functions for OCaml Unix module

Thin bindings to various low-level system APIs (often non-portable)
which are not covered by Unix module.
.
Example functions:
 * uname
 * statvfs
 * fsync
 * fadvise
 * fallocate
 * atfile
 * dirfd
 * eventfd
 * signalfd
 * ...



-- 
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/20101119223331.21843.95583.report...@yocto.gallu.homelinux.org

Bug#603938: debian-installer: The 1st CD doesn't contain desktop nor laptop tasks

[Samuel Thibault]

Kjö Hansi Glaz, le Fri 19 Nov 2010 20:06:46 +0100, a écrit :
> > > Expected result: the desktop and laptop tasks are available.
> > 
> > It seems we unfortunately can't expect that any more. We can still
> > probably check that they fit on the 1st+2nd CDs.
> > 
> 
> I think that it should then made be clear in the release notes that the 1st CD
> is not enough to install a desktop anymore and that somebody having to 
> install a
> desktop without access to the network must download the two first CDs or the
> first DVD.

Probably, yes.

Samuel



--
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/20101119224030.gb7...@const.famille.thibault.fr

Re: Full install/removal/upgrade test results available

[David Kalnischkies]

On Fri, Nov 19, 2010 at 22:10, Yves-Alexis Perez  wrote:
> On ven., 2010-11-19 at 19:23 +0100, David Kalnischkies wrote:
>
>>
>> So, go and start reading. Debian has a lot of dependencies and you have a
>> lot of possibilities because of that.
>> You can't use them if you don't know them.
>> And, more important, you can't blame APT for being stupid if you don't
>> know what you talk about yourself.
>
> Well, I thought that Recommends: and Depends: were different things,
> which looks to me like a fair assumption. It seems I'm wrong.
>
> Oh, and I don't really like your tone, and I'm not usually offended by
> rudeness.

And i am usually not offended by someone blaming APT to be too dumb.
APT is all about dependency resolution, so saying you are not to deep
into it, but blaming APT to be wrong isn't the best tone either.
Draw i would say…


>> > By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't
>> > work either, apt will still prefer to hold xfce4-session and keep
>> > xfce4-mcs-*.
>>
>> You have way more information than APT - for example:
>> Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are
>> now obsolete? No. All which is said is that the new xfce4-session doesn't
>> work with them (it breaks them).
>
> No, xfce4-session depends on xfce4-settings. And xfce4-settings
> *replaces* xfce4-mcs-*.
>
>>  So, for APT its clear that we loose two
>> packages just to get another one upgraded… that doesn't feel right.
>
> Even with the Replaces: bit?

Great, just that Replaces: only says that some files will be replaced,
not the complete package… (so its mostly only used by dpkg).

APT currently Replaces: manpages-pl as it ships its own manpage
translation now. Should APT assume now while upgrading itself
that it is a complete replacement for manpages-pl ?

My example with apt and java is similar: They will declare
Replaces and Breaks as they conflict on filename usage and
installing the one breaks the other… java is still no valid upgrade
path for apt nor vise versa.


>> So, to solve your problem, you have more or less only one option:
>> Do not try to clean up behind you, let the package managers do it
>> (with autoremove or deborphan or whatever). Trying it yourself only
>> complicates stuff -- and adding Breaks for this kind of stuff is even
>> against the policy if you want to read it that way: §7.4
>
> Except that in my case, I'm more in the $7.6. I'm not adding
> Conflicts/Replaces just because I'd like to force people to get rid of
> xfce4-mcs-*, it's just that it xfce4-settings needs it. They both ship
> common files (along with xfce4-mcs-plugins)

They ship common files => Replaces
Or is xfce4-mcs-plugins broken now that you replaces some of its files?
(or better as footnote 46 suggests: Does it hurt if the files are gone?)
Then it really also Breaks:, but you also give the indication that
something in xfce4-mcs-plugins is left which can be broken and
therefore functionality is lost by removing it… (or allowing the other
package to replace files of it in the first place).
So you might want to provide a new xfce4-mcs-plugins without
these files (by depending on them) which still provides this functionality
(or nothing as a dummy package).

> and xfce4-settings replaces
> the functionality provided by xfce4-mcs-manager.

dummy xfce4-mcs-manager depending on xfce4-settings if it is
a package rename. If its not, but they do not conflict just leave
xfce4-mcs-manager alone. If they conflict as they use the same files,
its the same as with the other package…


>> Or in short: either make empty dummy packages out of them or
>> just leave them alone.
>
> Which would then need to Depends on xfce4-settings in order to provide
> the same set of functionality, adding complexity to the dependencies.

In general positive dependencies are easier to satisfy than negative
as it is easier to install another package than to remove an installed.
If we install a new package we have a relatively low probability that a
negative dependency will effect it later. If we remove a package we can be
nearly sure that another package depends on it and is now broken.
(why would it be installed otherwise?)
Also, a user normally doesn't complain too much if new functionality
is added, but heavily if some functionality is gone without good reason…


And the "good reason" is why APT doesn't remove the package on the
breaks - the 'Considering' line in the output shows the scores the packages
have. 0 vs 0 isn't a strong thing. If more packages would depend on
one of the packages the decision will follow the highest scoring package.
To go back to the apt and java example: On most systems, far more
packages depend on apt, so if APT would need to choose, between
the two it would choose apt - but if the system is full of java packages
it might choose to prefer java instead -- depending on how broken the
system is after deciding for one of the sides.
And as the system is more broken if xfce4-session is upgrade

Re: Bug#603938: debian-installer: The 1st CD doesn't contain desktop nor laptop tasks

[Charles Plessy]

Le Fri, Nov 19, 2010 at 11:06:51AM +0100, Holger Levsen a écrit :
> CDs wont grow in size and I'm pretty sure 
> the desktop install sizes wont shrink.

Hi all,

there is actually room for sparing a couple of megabytes, by chosing a more
efficient compression algorithm for the data tar archive in binary packages
like gimp for instance.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101120004656.gg8...@merveille.plessy.net

Where is O_SHLOCK and O_EXLOCK defined?

[T. Alex Chen]

I am trying to use 'open()' with some file control flags. According to Linux 
manual of 'open()': 


int open(const char *path, int flags, ...);
..
The flags specified are formed by or’ing the following values

O_RDONLY open for reading only
O_WRONLY open for writing only
O_RDWR open for reading and writing
O_NONBLOCK do not block on open
O_APPEND append on each write
O_CREAT create file if it does not exist
O_TRUNC truncate size to 0
O_EXCL error if create and file exists
O_SHLOCK atomically obtain a shared lock
O_EXLOCK atomically obtain an exclusive lock
O_DIRECT eliminate or reduce cache effects
O_FSYNC synchronous writes
O_SYNC synchronous writes
O_NOFOLLOW do not follow symlinks
O_NOCTTY don’t assign controlling terminal

But when I tried to use O_SHLOCK or O_EXLOCK bits, I got compilation errors:
error: ‘O_SHLOCK’ was not declared in this scope
I check 'fcntl.h' and there is no such bit definition.

Anyone knows where these bits are defined.
Alex 


  

Using statfs to check a remote file

[T. Alex Chen]

How do I determine if a file is a remote mounted file from statfs() call, i.e. 
which member of the 'struct statfs' contains information to indicate the file 
is 
NOT a local file?

Any help is appreciated.
 Alex 


  

Atomic operations

[T. Alex Chen]

I want to do atomic operation and find there is already such implementation in 
Linux, e.g. atomic_add, atomic_set, atomic_cmpset, etc, after I google on the 
Web. I find a libatomic-ops-dev package and install it. But there is still no 
man page after the installation. Did I install the right package? Where can I 
get the man page of these atomic operations?
Alex 


  

Re: Using statfs to check a remote file

[Russ Allbery]

"T. Alex Chen"  writes:

> How do I determine if a file is a remote mounted file from statfs()
> call, i.e.  which member of the 'struct statfs' contains information to
> indicate the file is NOT a local file?

This is not a very well-defined question, so the answer in general is "you
can't know that."  Consider iSCSI, a VM that uses NFS as a backing file
store, etc.

You can use the f_type attribute to struct statfs to look for the specific
file systems you're interested in, but that's about as good as you can do.
(Note that the list in the man page is not complete.)

-- 
Russ Allbery (r...@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/871v6g7qtx@windlord.stanford.edu

Re: Where is O_SHLOCK and O_EXLOCK defined?

[Russ Allbery]

"T. Alex Chen"  writes:

> I am trying to use 'open()' with some file control flags. According to
> Linux manual of 'open()':

What Linux man page are you looking at that contains that list?  man
open(2) in manpages-dev 3.25-1 doesn't mention either of those flags.

-- 
Russ Allbery (r...@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/87wro86c6l@windlord.stanford.edu

Re: Atomic operations

[Fernando Lemos]

Hi,

On Fri, Nov 19, 2010 at 10:56 PM, T. Alex Chen  wrote:
> I want to do atomic operation and find there is already such implementation
> in Linux, e.g. atomic_add, atomic_set, atomic_cmpset, etc, after I google on
> the Web. I find a libatomic-ops-dev package and install it. But there is
> still no man page after the installation. Did I install the right package?
> Where can I get the man page of these atomic operations?

Please don't post support questions to debian-devel. debian-devel is
about the development *of* Debian, *not* the development *on* Debian.
This is the wrong list for this question and your other recent
questions. Please look for the support channels instead.

Regards,


-- 
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/aanlkti=lr9qdt2xhrdncbthevpjubmiuof9t6uc5z...@mail.gmail.com

Re: Where is O_SHLOCK and O_EXLOCK defined?

[T. Alex Chen]

I must have look it up from either FreeBSD or GNU man page.
I change to use 'flock' after a successful open().  I guess that is equivalent.
Alex 





From: Russ Allbery 
To: debian-devel@lists.debian.org
Sent: Fri, November 19, 2010 5:01:06 PM
Subject: Re: Where is O_SHLOCK and O_EXLOCK defined?

"T. Alex Chen"  writes:

> I am trying to use 'open()' with some file control flags. According to
> Linux manual of 'open()':

What Linux man page are you looking at that contains that list?  man
open(2) in manpages-dev 3.25-1 doesn't mention either of those flags.

-- 
Russ Allbery (r...@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/87wro86c6l@windlord.stanford.edu


  

Re: Full install/removal/upgrade test results available

[brian m. carlson]

On Fri, Nov 19, 2010 at 01:41:49PM -0800, Russ Allbery wrote:
> Goswin von Brederlow  writes:
> 
> > Also note that no frontend has ever made use of §7.6.2 and handled
> > upgrading obsolete packages to their replacements.
> 
> There's a reason for that: it's not possible to create a Policy-compliant
> package that could use 7.6.2 in that fashion.

Wait, what?

Are you saying that other parts of Policy conflict with §7.6.2?  Or are
you saying that the Debian tools and infrastructure don't support it?
Or something else entirely?

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Full install/removal/upgrade test results available

[Russ Allbery]

"brian m. carlson"  writes:
> On Fri, Nov 19, 2010 at 01:41:49PM -0800, Russ Allbery wrote:
>> Goswin von Brederlow  writes:

>>> Also note that no frontend has ever made use of §7.6.2 and handled
>>> upgrading obsolete packages to their replacements.

>> There's a reason for that: it's not possible to create a
>> Policy-compliant package that could use 7.6.2 in that fashion.

> Wait, what?

> Are you saying that other parts of Policy conflict with §7.6.2?  Or are
> you saying that the Debian tools and infrastructure don't support it?
> Or something else entirely?

Ack, sorry.  I was completely wrong on this because I assumed I knew what
Goswin was talking about but confused this with a previous discussion.

No, 7.6.2 doesn't contradict other parts of Policy, and I'm not familiar
with the issues in using that for transitional packages (other than the
general problem that Conflicts Is Hard To Get Right).  I thought Gowsin
was talking about 7.6.*1*, the provision where packages are removed if all
of their files are replaced, which isn't a usable way to eliminate
transitional packages due to other Policy requirements.

-- 
Russ Allbery (r...@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/87sjywzoqk@windlord.stanford.edu

Re: Full install/removal/upgrade test results available

[Ben Hutchings]

On Wed, 2010-11-17 at 08:37 -0600, Lucas Nussbaum wrote:
[...]
> Debian Kernel Team 
>linux-image-2.6-amd64
>linux-image-2.6.32-5-amd64
>linux-image-2.6.32-5-amd64-dbg
>linux-image-amd64
[...]

Removal of linux-image-2.6.32-5-amd64 failed because:

"""
You are running a kernel (version 2.6.32-5-amd64) and attempting to
remove the same version.

This can make the system unbootable as it will
remove /boot/vmlinuz-2.6.32-5-amd64 and all modules under the
directory /lib/modules/2.6.32-5-amd64. This can only be fixed with a
copy of the kernel image and the corresponding modules.

It is highly recommended to abort the kernel removal unless you are
prepared to fix the system after removal.
"""

and your script naturally sets DEBIAN_FRONTEND=noninteractive, so
debconf takes the default answer (abort removal).

The other packages all depend on this one.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

How many are using oldstable, stable, testing and unstable?

[Petter Reinholdtsen]

Just for fun, I had a look at http://popcon.debian.org/ > to see
how the relative distribution of Debian users across oldstable, stabe,
testing and unstable is spread.  Today there are 94546 computers
registered in popularity-contest, and as the number of users of
unstable seem to have stabilized, this seemed like a good time to
measure the relative usage.  These are the numbers:

  1.41 (etch)   : 10781  11.4%
  1.46 (lenny/stable)   : 57983  61.3%
  1.48 (testing): 19776  20.9%
  1.49 (unstable)   : 40564.3%

This do not sum up to 100%, because some machines are not using the
current versions from these repositories.

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/2flwro8mrlg@login2.uio.no