Bug#1069330: ITP: golang-github-akihirosuda-apt-transport-oci -- OCI transport plugin for apt-get (i.e., apt-get over ghcr.io)

[Jianfeng Liu]

Package: wnpp
Severity: wishlist
Owner: Jianfeng Liu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org, 
liujianfeng1...@gmail.com

* Package name: golang-github-akihirosuda-apt-transport-oci
  Version : 0.0~git20240416.a7e2cf0-1
  Upstream Contact: Akihiro Suda 
* URL : https://github.com/AkihiroSuda/apt-transport-oci
* License : Apache-2.0
  Programming Lang: Go
  Description : OCI transport plugin for apt-get (i.e., apt-get over 
ghcr.io)

apt-transport-oci is an apt-get plugin to support distributing *.deb
 packages over an OCI registry such as ghcr.io
More info about it from is github page:
 https://github.com/AkihiroSuda/apt-transport-oci

GHCR is a free platform to host apt repos, supporting oci in apt should
be cool.

Re: can someone help my with apt-get ???

[Omnis Moriar]

hi. Can i know all tweaks to fstab in jfs file system ??

wt., 4 wrz 2018 o 20:40 omnismoriar1  napisał(a):

>
> Hello can i join to that list ??My name is Milczarski von - underground
> and official president of Debian i Poland
> --
> omnismoriar1 
>

Re: "apt-get source snappy" pulls Extra-Source-Only 1.1.4-1 in Debian-Stretch?

[Ian Jackson]

Philipp Hahn writes (""apt-get source snappy" pulls Extra-Source-Only 1.1.4-1 
in Debian-Stretch?"):
> today I encountered the strange situation, that Debian-Stretch
> officially has 1.1.3-3, but if I do a "apt-get source snappy" I get 1.1.4-1:

Andreas has answered your actual question, but I would like to take
this opportunity to plug dgit, which would (i) have provided you with
a git tree (ii) probably have saved you from asking this question
because the relevant tutorial manpage has instructions on how to get
the source in specific suite:

  https://manpages.debian.org/stretch/dgit/dgit-user.7.en.html

Ian.

Re: "apt-get source snappy" pulls Extra-Source-Only 1.1.4-1 in Debian-Stretch?

[Andreas Metzler]

In gmane.linux.debian.devel.general Philipp Hahn <h...@univention.de> wrote:
> Hello APT developers,

> today I encountered the strange situation, that Debian-Stretch
> officially has 1.1.3-3, but if I do a "apt-get source snappy" I get 1.1.4-1:
[...]

> So how can I tell "apt-get source" to pull the "right" version, e.g. the
> version "libsnappy1v5" was built from?

>> $ LANG=C apt-cache policy libsnappy1v5
>> libsnappy1v5:
>>   Installed: 1.1.3-3
>>   Candidate: 1.1.3-3
>>   Version table:
>>  *** 1.1.3-3 500
>> 500 http://deb.debian.org/debian stretch/main amd64 Packages
>> 100 /var/lib/dpkg/status

> This looks like a bug in APT and did I miss something?

apt-get source does not care which version is installed.
from apt-get(8)
| APT will examine
| the available packages to decide which source package to fetch. It
| will then find and download into the current directory the newest
| available version of that source package ...

-t stretch or libsnappy1v5=1.1.3-3 will probably work.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

"apt-get source snappy" pulls Extra-Source-Only 1.1.4-1 in Debian-Stretch?

[Philipp Hahn]

Hello APT developers,

today I encountered the strange situation, that Debian-Stretch
officially has 1.1.3-3, but if I do a "apt-get source snappy" I get 1.1.4-1:

> $ LANG=C apt-get -d --print-uris source snappy
> Reading package lists... Done
> Need to get 1498 kB of source archives.
> 'http://deb.debian.org/debian/pool/main/s/snappy/snappy_1.1.4-1.dsc' 
> snappy_1.1.4-1.dsc 1817 
> SHA256:a81ea405fe5710d0ee31e62d7007ce6fd4a5e9d2dcfd5767b1c8131b3459349f
> 'http://deb.debian.org/debian/pool/main/s/snappy/snappy_1.1.4.orig.tar.gz' 
> snappy_1.1.4.orig.tar.gz 1491767 
> SHA256:134bfe122fd25599bb807bb8130e7ba6d9bdb851e0b16efcb83ac4f5d0b70057
> 'http://deb.debian.org/debian/pool/main/s/snappy/snappy_1.1.4-1.debian.tar.xz'
>  snappy_1.1.4-1.debian.tar.xz 4400 
> SHA256:9be718653559b45d5bd6eab32d4f18e7b5a1dbff57463cd94ba3f51eb11b0a20

Comparing that with <https://tracker.debian.org/pkg/snappy> and
<https://packages.debian.org/search?searchon=sourcenames=snappy>
shows "1.1.3-3" for Debian-Stretch.

> $ curl -s 
> http://ftp.de.debian.org/debian/dists/stretch/main/source/Sources.xz | xz -d 
> | grep-dctrl -s Package,Version,Extra-Source-Only -PX snappy
> Package: snappy
> Version: 1.1.3-3
> 
> Package: snappy
> Version: 1.1.4-1
> Extra-Source-Only: yes

So how can I tell "apt-get source" to pull the "right" version, e.g. the
version "libsnappy1v5" was built from?

> $ LANG=C apt-cache policy libsnappy1v5
> libsnappy1v5:
>   Installed: 1.1.3-3
>   Candidate: 1.1.3-3
>   Version table:
>  *** 1.1.3-3 500
> 500 http://deb.debian.org/debian stretch/main amd64 Packages
> 100 /var/lib/dpkg/status

This looks like a bug in APT and did I miss something?

Philipp
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
h...@univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Re: apt-get dist-upgrade uninstalled most of KDE

[Andreas Henriksson]

On Wed, Aug 16, 2017 at 12:56:07PM -0700, nob...@gmail.com wrote:
> Hello,
> 
> I just upgraded my system (Debian sid with main, contrib, non-free) to
> the most recent unstable version, running "apt-get update" and
> "apt-get dist-upgrade".
[...]

>From what I've been told you should basically only use 'dist-upgrade'
when you upgrade between different releases, eg. wheezy -> jessie,
jessie -> stretch, stretch -> testing/unstable.

If you upgrade the same release (eg. sid -> sid) you should normally
only use 'apt upgrade'. By using 'apt dist-upgrade' you're telling
apt that it's ok to remove things.

If you do use dist-upgrade in sid while transitions is still
ongoing/unfinished you will end up with lots of things removed.
At the same time you might need to use dist-upgrade to upgrade
things in sid after a transition has been made. You're basically
expected to be able to understand what apt is asking you and answer
correctly. Also when running sid you should be able to unbreak your
own system.

Regards,
Andreas Henriksson

Re: apt-get dist-upgrade uninstalled most of KDE

[Adam Borowski]

On Thu, Aug 17, 2017 at 10:28:57AM +1200, Ben Caradoc-Davies wrote:
> The only other thing I did after the downgrade was to "apt-mark hold" the
> packages affected by the transition that I did not want to remove; this is
> my preferred tactic for surviving transitions.

On machines running unstable, I wish again and again for a way to tell apt
"do upgrade this package if possible, but never even contemplate removing
it".  This can be avoided by answering the question over and over, but this
gets tedious if the breakage lasts a week.  This is drastically worse on
second-class ports (apt tries to remove git because of git-man like half of
the time recently), but even on amd64 in-progress transitions are common.

So far I make equivs packages "keep-foo" and apt-mark hold them.  This
doesn't work that well.

Thus I wonder, is there a better way?

If not, adding a new mark "apt-mark unremovable" would be nice.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ James Damore is a hero.  Even mild criticism of bigots these days
⢿⡄⠘⠷⠚⠋⠀ comes at great personal risk.
⠈⠳⣄ 

Re: apt-get dist-upgrade uninstalled most of KDE

[nobrin]

Hi All,

As a reference, I undid the last apt command in one (long) line:

apt-get install `cat /var/log/apt/history.log | awk
'/Start-Date/{last=""} /^Start-Date:/,/End-Date/{last=last $0 "\n"}
END {print last}' | sed 's/ \([^ ]*\) (\([^,)]\+\)\(,
[^)]\+\)\?)/\1=\2/g' | awk -F, '/Install:/{gsub(/^Install:/,"");
gsub(/=[^,]*/,""); for(i=1;i<NF;i++) printf ($i "- ")}
/(Upgrade|Remove):/{gsub(/^(Upgrade|Remove):/,""); $1=$1; print $0}' |
sed 's/ \(heroku[^ ]*\) / /'`

using the snapshot from a couple days ago in sources.list:

deb http://snapshots.debian.org/archive/debian/20170814T210836Z/ sid
main non-free contrib

Cheers,
Marco

On Wed, Aug 16, 2017 at 3:35 PM,  <nob...@gmail.com> wrote:
> Thanks!
>
> I was thinking about implementing an "apt-get rollback-upgrade"
> command, which would also remove any package installed by the previous
> upgrade. To be reliable, though, it should also restore any
> configuration overwritten by the install. So maybe it is not feasible.
>
> I agree, maybe "apt-mark hold" is a better strategy if one wants to
> keep installing packages during the transition.
>
> Best,
> Marco
>
> On Wed, Aug 16, 2017 at 3:28 PM, Ben Caradoc-Davies <b...@transient.nz> wrote:
>> On 17/08/17 10:08, nob...@gmail.com wrote:
>>>
>>> Using snapshot repositories and "apt-get install packagename=version"
>>> sounds like a*great*  strategy to implement a quick-and-dirty rollback
>>> function for apt-get. Do you think it would suffice to analyze
>>> history.log and run "apt-get install" with
>>> - "package-" for all packages installed by the last update and
>>> - add "package=version" for all updated and removed packages?
>>> The snapshot it would use is the one of the previous upgrade.
>>
>>
>> "apt-get install package=version" should remove any packages that conflict
>> with the installation, so you should not have to manually remove anything.
>> The only other thing I did after the downgrade was to "apt-mark hold" the
>> packages affected by the transition that I did not want to remove; this is
>> my preferred tactic for surviving transitions.
>>
>>
>> Kind regards,
>>
>> --
>> Ben Caradoc-Davies <b...@transient.nz>
>> Director
>> Transient Software Limited <http://transient.nz/>
>> New Zealand
>>

Re: apt-get dist-upgrade uninstalled most of KDE

[nobrin]

Thanks!

I was thinking about implementing an "apt-get rollback-upgrade"
command, which would also remove any package installed by the previous
upgrade. To be reliable, though, it should also restore any
configuration overwritten by the install. So maybe it is not feasible.

I agree, maybe "apt-mark hold" is a better strategy if one wants to
keep installing packages during the transition.

Best,
Marco

On Wed, Aug 16, 2017 at 3:28 PM, Ben Caradoc-Davies <b...@transient.nz> wrote:
> On 17/08/17 10:08, nob...@gmail.com wrote:
>>
>> Using snapshot repositories and "apt-get install packagename=version"
>> sounds like a*great*  strategy to implement a quick-and-dirty rollback
>> function for apt-get. Do you think it would suffice to analyze
>> history.log and run "apt-get install" with
>> - "package-" for all packages installed by the last update and
>> - add "package=version" for all updated and removed packages?
>> The snapshot it would use is the one of the previous upgrade.
>
>
> "apt-get install package=version" should remove any packages that conflict
> with the installation, so you should not have to manually remove anything.
> The only other thing I did after the downgrade was to "apt-mark hold" the
> packages affected by the transition that I did not want to remove; this is
> my preferred tactic for surviving transitions.
>
>
> Kind regards,
>
> --
> Ben Caradoc-Davies <b...@transient.nz>
> Director
> Transient Software Limited <http://transient.nz/>
> New Zealand
>

Re: apt-get dist-upgrade uninstalled most of KDE

[Ben Caradoc-Davies]

On 17/08/17 10:08, nob...@gmail.com wrote:

Using snapshot repositories and "apt-get install packagename=version"
sounds like a*great*  strategy to implement a quick-and-dirty rollback
function for apt-get. Do you think it would suffice to analyze
history.log and run "apt-get install" with
- "package-" for all packages installed by the last update and
- add "package=version" for all updated and removed packages?
The snapshot it would use is the one of the previous upgrade.


"apt-get install package=version" should remove any packages that 
conflict with the installation, so you should not have to manually 
remove anything. The only other thing I did after the downgrade was to 
"apt-mark hold" the packages affected by the transition that I did not 
want to remove; this is my preferred tactic for surviving transitions.


Kind regards,

--
Ben Caradoc-Davies <b...@transient.nz>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Re: apt-get dist-upgrade uninstalled most of KDE

[nobrin]

Thanks you all for the help! I usually do pay attention, and I prefer
sid even given the risks (it's great).
I don't need the machine at the moment, so I'll just wait for the
transition to complete.

Using snapshot repositories and "apt-get install packagename=version"
sounds like a *great* strategy to implement a quick-and-dirty rollback
function for apt-get. Do you think it would suffice to analyze
history.log and run "apt-get install" with
- "package-" for all packages installed by the last update and
- add "package=version" for all updated and removed packages?

The snapshot it would use is the one of the previous upgrade.

Thanks,
Marco

On Wed, Aug 16, 2017 at 2:55 PM, Martin Steigerwald <mar...@lichtvoll.de> wrote:
> Martin Steigerwald - 16.08.17, 23:43:
>> There is no automatic way to undo the action. I suggest you install again
>> by  using metapackages like
>>
>> - plasma-desktop
>> - kde-standard
>> - kde-full
>>
>> depending on the amount of packages you want to have installed.
>>
>> And then add any additional packages you want to have again.
>
> I missed that this wouldn´t fix current KDE/Plasma packages not fitting yet to
> Qt 5.9.1.
>
> So I suggest you switch to Debian testing temporarily.
>
> Then either aptitude install one of above meta packages will over a nice
> solution that will downgrade Qt packages to 5.7.1 again… or you need to
> manually do that by something along the lines of
>
> apt/aptitude install package=versionnummer
>
> Next time check output of apt more closely. It must have shown a *very long*
> list of packages it is about to remove.
>
> Another thing would be to temporarily install a different desktop like lxqt or
> Mate or so :)
>
> Thanks,
> --
> Martin

Re: apt-get dist-upgrade uninstalled most of KDE

[Adam Borowski]

On Wed, Aug 16, 2017 at 11:55:59PM +0200, Martin Steigerwald wrote:
> Martin Steigerwald - 16.08.17, 23:43:
> > There is no automatic way to undo the action. I suggest you install again
> > by  using metapackages like
> > 
> > - plasma-desktop
> > - kde-standard
> > - kde-full
> > 
> > depending on the amount of packages you want to have installed.
> > 
> > And then add any additional packages you want to have again.
> 
> I missed that this wouldn´t fix current KDE/Plasma packages not fitting yet 
> to 
> Qt 5.9.1.
> 
> So I suggest you switch to Debian testing temporarily.
> 
> Then either aptitude install one of above meta packages will over a nice 
> solution that will downgrade Qt packages to 5.7.1 again… or you need to 
> manually do that by something along the lines of
> 
> apt/aptitude install package=versionnummer

This should help:
.--==[ /etc/apt/preferences ]
Package: *
Pin: release a=testing
Pin-Priority: 1001
`
apt dist-upgrade

This is the most automated way to undo the mess I know of.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ James Damore is a hero.  Even mild criticism of bigots these days
⢿⡄⠘⠷⠚⠋⠀ comes at great personal risk.
⠈⠳⣄ 

Re: apt-get dist-upgrade uninstalled most of KDE

[Martin Steigerwald]

Martin Steigerwald - 16.08.17, 23:43:
> There is no automatic way to undo the action. I suggest you install again
> by  using metapackages like
> 
> - plasma-desktop
> - kde-standard
> - kde-full
> 
> depending on the amount of packages you want to have installed.
> 
> And then add any additional packages you want to have again.

I missed that this wouldn´t fix current KDE/Plasma packages not fitting yet to 
Qt 5.9.1.

So I suggest you switch to Debian testing temporarily.

Then either aptitude install one of above meta packages will over a nice 
solution that will downgrade Qt packages to 5.7.1 again… or you need to 
manually do that by something along the lines of

apt/aptitude install package=versionnummer

Next time check output of apt more closely. It must have shown a *very long* 
list of packages it is about to remove.

Another thing would be to temporarily install a different desktop like lxqt or 
Mate or so :)

Thanks,
-- 
Martin

Re: apt-get dist-upgrade uninstalled most of KDE

[Ben Caradoc-Davies]

On 17/08/17 09:29, Andrey Rahmatullin wrote:

On Wed, Aug 16, 2017 at 12:56:07PM -0700, nob...@gmail.com wrote:

(Is there any way to undo the last apt-get? Unfortunately, I don't
have all the removed packages still in /var/cache/apt/archives)

Download them from testing, e.g. by adding testing to sources.list.


Or add a snapshot repo from <http://snapshot.debian.org/> a few days in 
the past, for example
<http://snapshot.debian.org/archive/debian/20170815T032716Z/>, and then 
downgrade with "apt-get install packagename=version". Sadly this does 
not seem to resolve dependencies, and you may also need many 
dependency=version arguments. Many many. You could construct this from 
your log using regular expressions.


I always run "apt-get dist-upgrade -V -s" before dist-upgrade. This 
morning I neglected to notice that dist-upgrade was removing qpdfview 
and its dependencies, so I feel your pain. Fortunately I use XFCE so the 
damage was limited. sid is for people who pay attention.


One thing I miss from Fedora is yum history, which allows any update 
transaction to be rolled back. I found the Debian process to be tedious 
and error-prone. I would be delighted if anyone has a better suggestion.


Kind regards,

--
Ben Caradoc-Davies <b...@transient.nz>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Re: apt-get dist-upgrade uninstalled most of KDE

[Martin Steigerwald]

Hello Marco.

Please use a mailinglist for user support. This mailing list is for 
development topics.

For Plasma/KDE related questions I suggest debian-kde mailinglist. Cc´d. 
Please drop Cc to debian-devel on your answer.

nob...@gmail.com - 16.08.17, 12:56:
> I just upgraded my system (Debian sid with main, contrib, non-free) to
> the most recent unstable version, running "apt-get update" and
> "apt-get dist-upgrade".
> 
> Unfortunately, this uninstalled most of KDE, including

If you run Debian GNU/Sid, you always, always, read again *always* have to 
carefully check what packages apt dist-upgrade would uninstall, before 
confirming the action. If you are not willing to do this, I suggest you use 
Debian Stable.

Debian Qt/KDE team works an upgrade from Qt 5.7.1 to Qt 5.9.1 and its not yet 
complete. Trying to force a partial upgrade with apt dist-upgrade will 
uninstall Plasma desktop currently. I actually warned about this on debian-kde 
mailinglist this morning. You may like to choose Debian GNU/Buster/Testing 
instead of Sid in order to have *some* protection, as I read about a 
transition on #debian-qt-kde IRC channel and it might very well related to the 
Qt upgrade. I didn´t check this tough.

There is no automatic way to undo the action. I suggest you install again by 
using metapackages like

- plasma-desktop
- kde-standard
- kde-full

depending on the amount of packages you want to have installed.

And then add any additional packages you want to have again.

Thanks,
-- 
Martin

Re: apt-get dist-upgrade uninstalled most of KDE

[Andrey Rahmatullin]

On Wed, Aug 16, 2017 at 12:56:07PM -0700, nob...@gmail.com wrote:
> I just upgraded my system (Debian sid with main, contrib, non-free) to
> the most recent unstable version, running "apt-get update" and
> "apt-get dist-upgrade".
> 
> Unfortunately, this uninstalled most of KDE, including
> "plasma-desktop", "kde-plasma-desktop", "konsole",  and many packages
> starting with "libkf5" and "libqt5".
That's why you should read what are you accepting.
Also, debian-devel@ is a wrong place for such questions.

> The last "apt-get dist-upgrade" was from two days ago, so I suspect
> some major change going with sid packages. Is it the case? Any ETA?
Qt transition.

> (Is there any way to undo the last apt-get? Unfortunately, I don't
> have all the removed packages still in /var/cache/apt/archives)
Download them from testing, e.g. by adding testing to sources.list.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: apt-get dist-upgrade uninstalled most of KDE

[nobrin]

Start-Date: 2017-08-16  11:30:15
Commandline: apt-get dist-upgrade
Requested-By: marco (1000)
Install: libx265-130:amd64 (2.5-2, automatic), libc-ares2:amd64
(1.13.0-2, automatic), gnupg-utils:amd64 (2.1.23-2, automatic),
gpg-wks-client:amd64 (2.1.23-2, automatic), gnupg-l10n:amd64
(2.1.23-2, automatic), gpg-wks-server:amd64 (2.1.23-2, automatic),
gpg:amd64 (2.1.23-2, automatic), gnuplot-x11:amd64 (5.0.6+dfsg1-1,
automatic), libdirectfb-1.7-7:amd64 (1.7.7-5, automatic),
gpg-agent:amd64 (2.1.23-2, automatic), gpgconf:amd64 (2.1.23-2,
automatic), gpgsm:amd64 (2.1.23-2, automatic)
Upgrade: vlc-bin:amd64 (2.2.6-4, 2.2.6-4+b1), tex-common:amd64 (6.07,
6.08), vlc-plugin-video-output:amd64 (2.2.6-4, 2.2.6-4+b1),
libqgsttools-p1:amd64 (5.7.1~20161021-2, 5.9.1-2), libavformat57:amd64
(7:3.3.3-2, 7:3.3.3-3), libpangoft2-1.0-0:amd64 (1.40.6-1, 1.40.9-1),
libavfilter6:amd64 (7:3.3.3-2, 7:3.3.3-3),
qt5-image-formats-plugins:amd64 (5.7.1~20161021-2, 5.9.1-1),
qml-module-qtquick-window2:amd64 (5.7.1-2+b2, 5.9.1-5),
libqt5test5:amd64 (5.7.1+dfsg-4, 5.9.1+dfsg-7),
qml-module-qtwebkit:amd64 (5.7.1+dfsg-1, 5.9.1+dfsg-2), ffmpeg:amd64
(7:3.3.3-2, 7:3.3.3-3), vim-common:amd64 (2:8.0.0197-5, 2:8.0.0946-1),
gnupg-agent:amd64 (2.1.18-8, 2.1.23-2), vlc-plugin-samba:amd64
(2.2.6-4, 2.2.6-4+b1), qt5-gtk-platformtheme:amd64 (5.7.1+dfsg-4,
5.9.1+dfsg-7), qml-module-qtquick2:amd64 (5.7.1-2+b2, 5.9.1-5),
libqt5help5:amd64 (5.7.1-1, 5.9.1-2), libswresample2:amd64 (7:3.3.3-2,
7:3.3.3-3), vlc-plugin-qt:amd64 (2.2.6-4, 2.2.6-4+b1),
qml-module-qt-labs-folderlistmodel:amd64 (5.7.1-2+b2, 5.9.1-5),
heroku:amd64 (6.13.13-1, 6.13.17-1), libqt5multimedia5:amd64
(5.7.1~20161021-2, 5.9.1-2), libopenmpt0:amd64 (0.2.8461~beta26-1,
0.2.8760~beta27-1), vlc-plugin-skins2:amd64 (2.2.6-4, 2.2.6-4+b1),
vlc-plugin-visualization:amd64 (2.2.6-4, 2.2.6-4+b1),
libvigraimpex6:amd64 (1.10.0+git20160211.167be93+dfsg-4,
1.10.0+git20160211.167be93+dfsg-5), libqt5dbus5:amd64 (5.7.1+dfsg-4,
5.9.1+dfsg-7), libqt5sql5-sqlite:amd64 (5.7.1+dfsg-4, 5.9.1+dfsg-7),
nodejs:amd64 (4.8.4~dfsg-1, 6.11.2~dfsg-2),
qml-module-qtquick-layouts:amd64 (5.7.1-2+b2, 5.9.1-5),
libqt5widgets5:amd64 (5.7.1+dfsg-4, 5.9.1+dfsg-7),
vlc-plugin-notify:amd64 (2.2.6-4, 2.2.6-4+b1), libvlc5:amd64 (2.2.6-4,
2.2.6-4+b1), gir1.2-pango-1.0:amd64 (1.40.6-1, 1.40.9-1),
gstreamer1.0-plugins-bad:amd64 (1.12.2-1, 1.12.2-1+b1),
libnet-http-perl:amd64 (6.12-1, 6.16-1),
qml-module-qtqml-models2:amd64 (5.7.1-2+b2, 5.9.1-5),
qml-module-qt-labs-settings:amd64 (5.7.1-2+b2, 5.9.1-5),
libpostproc54:amd64 (7:3.3.3-2, 7:3.3.3-3), libvlccore8:amd64
(2.2.6-4, 2.2.6-4+b1), libvlc-bin:amd64 (2.2.6-4, 2.2.6-4+b1),
libqt5xml5:amd64 (5.7.1+dfsg-4, 5.9.1+dfsg-7),
libqt5printsupport5:amd64 (5.7.1+dfsg-4, 5.9.1+dfsg-7),
libqt5qml5:amd64 (5.7.1-2+b2, 5.9.1-5), dirmngr:amd64 (2.1.18-8,
2.1.23-2), libqt5designercomponents5:amd64 (5.7.1-1, 5.9.1-2),
libqt5multimediawidgets5:amd64 (5.7.1~20161021-2, 5.9.1-2),
libdatetime-format-strptime-perl:amd64 (1.7300-1, 1.7400-1),
libqt5concurrent5:amd64 (5.7.1+dfsg-4, 5.9.1+dfsg-7),
libpangoxft-1.0-0:amd64 (1.40.6-1, 1.40.9-1), libqt5gui5:amd64
(5.7.1+dfsg-4, 5.9.1+dfsg-7), libqt5multimedia5-plugins:amd64
(5.7.1~20161021-2, 5.9.1-2), libqt5quickwidgets5:amd64 (5.7.1-2+b2,
5.9.1-5), libpangocairo-1.0-0:amd64 (1.40.6-1, 1.40.9-1),
libopenmpt-modplug1:amd64 (0.2.8461~beta26-1, 0.2.8760~beta27-1),
libqt5multimediaquick-p5:amd64 (5.7.1~20161021-2, 5.9.1-2),
libavcodec57:amd64 (7:3.3.3-2, 7:3.3.3-3), libqt5webkit5:amd64
(5.7.1+dfsg-1, 5.9.1+dfsg-2), libqt5script5:amd64
(5.7.1~20161021+dfsg-2, 5.9.1+dfsg-2), vim-runtime:amd64
(2:8.0.0197-5, 2:8.0.0946-1), gpgv:amd64 (2.1.18-8, 2.1.23-2),
vim:amd64 (2:8.0.0197-5+b1, 2:8.0.0946-1), vlc:amd64 (2.2.6-4,
2.2.6-4+b1), libavutil55:amd64 (7:3.3.3-2, 7:3.3.3-3),
libqt5core5a:amd64 (5.7.1+dfsg-4, 5.9.1+dfsg-7), libavdevice57:amd64
(7:3.3.3-2, 7:3.3.3-3), python3-numexpr:amd64 (2.6.2-1, 2.6.2-2),
xxd:amd64 (2:8.0.0197-5+b1, 2:8.0.0946-1), libswscale4:amd64
(7:3.3.3-2, 7:3.3.3-3), qdbus-qt5:amd64 (5.7.1-1, 5.9.1-2),
vlc-plugin-video-splitter:amd64 (2.2.6-4, 2.2.6-4+b1), gnupg2:amd64
(2.1.18-8, 2.1.23-2), libqt5opengl5:amd64 (5.7.1+dfsg-4,
5.9.1+dfsg-7), qml-module-qtmultimedia:amd64 (5.7.1~20161021-2,
5.9.1-2), libqt5xmlpatterns5:amd64 (5.7.1~20161021-3, 5.9.1-2),
qttranslations5-l10n:amd64 (5.7.1~20161021-1, 5.9.1-1), vim-tiny:amd64
(2:8.0.0197-5+b1, 2:8.0.0946-1), qttools5-dev-tools:amd64 (5.7.1-1,
5.9.1-2), libqt5network5:amd64 (5.7.1+dfsg-4, 5.9.1+dfsg-7),
gnupg:amd64 (2.1.18-8, 2.1.23-2), vlc-plugin-base:amd64 (2.2.6-4,
2.2.6-4+b1), libqt5designer5:amd64 (5.7.1-1, 5.9.1-2),
libpango-1.0-0:amd64 (1.40.6-1, 1.40.9-1),
libgstreamer-plugins-bad1.0-0:amd64 (1.12.2-1, 1.12.2-1+b1),
libqt5quick5:amd64 (5.7.1-2+b2, 5.9.1-5), libavresample3:amd64
(7:3.3.3-2, 7:3.3.3-3), libqt5sql5:amd64 (5.7.1+dfsg-4, 5.9.1+dfsg-7),
qml-module-qtgraphicaleffects:amd64 (5.7.1~20161021-3, 5.9.1-2),
mplayer:amd64 (2:1.3.0-6+b3, 2:1.3.0-6+b4), libqt5sql5-mysql:amd64
(5.7.1+dfsg-4, 5.9.1

apt-get dist-upgrade uninstalled most of KDE

[nobrin]

Hello,

I just upgraded my system (Debian sid with main, contrib, non-free) to
the most recent unstable version, running "apt-get update" and
"apt-get dist-upgrade".

Unfortunately, this uninstalled most of KDE, including
"plasma-desktop", "kde-plasma-desktop", "konsole",  and many packages
starting with "libkf5" and "libqt5".
I've enclosed the relevant part of /var/log/apt/history.log at the end
of this email.

The last "apt-get dist-upgrade" was from two days ago, so I suspect
some major change going with sid packages. Is it the case? Any ETA?

(Is there any way to undo the last apt-get? Unfortunately, I don't
have all the removed packages still in /var/cache/apt/archives)

Thanks!
Marco

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Adam Borowski]

On Tue, May 30, 2017 at 06:32:17PM +0100, Ian Jackson wrote:
> Emilio Pozuelo Monfort writes ("Re: Bug#863361: dgit-user(7): replace apt-get 
> build-deps with mk-build-deps"):
> > I think what David wanted to say is:
> > 
> > `apt-get install $foo' install recommends
> > `apt-get build-dep $foo' does not install recommends
> > 
> > Thus you don't need to pass --no-install-recommends when doing build-dep.
> 
> Ah.  Has that changed ?  Certainly I have a finger macro to explicitly
> disable the recommends for build deps but maybe it's not necessary...

#454479 and its dupe #467313.

-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Ian Jackson]

Emilio Pozuelo Monfort writes ("Re: Bug#863361: dgit-user(7): replace apt-get 
build-deps with mk-build-deps"):
> I think what David wanted to say is:
> 
> `apt-get install $foo' install recommends
> `apt-get build-dep $foo' does not install recommends
> 
> Thus you don't need to pass --no-install-recommends when doing build-dep.

Ah.  Has that changed ?  Certainly I have a finger macro to explicitly
disable the recommends for build deps but maybe it's not necessary...

Ian.

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Emilio Pozuelo Monfort]

On 30/05/17 18:32, Ian Jackson wrote:
> David Kalnischkies writes ("Re: Bug#863361: dgit-user(7): replace apt-get 
> build-deps with mk-build-deps"):
>> I would recommend not to recommend it because apt follows the general
>> recommendation of not recommending the installation of recommendations
>> of build-dependencies by default for all recommended Debian releases.
> 
> When you install the build-depends for unfamiliar programs, you are
> trying to debug, do you install recommends ?  I have found that it is
> usually wiser not to.
> 
> Installing the recommends of build-depends typically shovels in
> massive piles of junk, which is (a) a big download (b) often contains
> daemons and other weirdness that is obviously not needed.

I think what David wanted to say is:

`apt-get install $foo' install recommends
`apt-get build-dep $foo' does not install recommends

Thus you don't need to pass --no-install-recommends when doing build-dep.

Cheers,
Emilio

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Ian Jackson]

David Kalnischkies writes ("Re: Bug#863361: dgit-user(7): replace apt-get 
build-deps with mk-build-deps"):
> I would recommend not to recommend it because apt follows the general
> recommendation of not recommending the installation of recommendations
> of build-dependencies by default for all recommended Debian releases.

When you install the build-depends for unfamiliar programs, you are
trying to debug, do you install recommends ?  I have found that it is
usually wiser not to.

Installing the recommends of build-depends typically shovels in
massive piles of junk, which is (a) a big download (b) often contains
daemons and other weirdness that is obviously not needed.

Ian.

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[David Kalnischkies]

On Fri, May 26, 2017 at 03:33:17PM +0100, Ian Jackson wrote:
> Emilio Pozuelo Monfort writes ("Re: A proposal for a tool to build local 
> testing debs"):
> > Or you can just do
> > 
> > $ sudo apt-get build-dep ./
[…]
> Probably we should recommend --no-install-recommends.

I would recommend not to recommend it because apt follows the general
recommendation of not recommending the installation of recommendations
of build-dependencies by default for all recommended Debian releases.

Recommended summary: Already the default since 2011.

Recommending everyone to have a wonderful day,

David Kalnischkies


signature.asc
Description: PGP signature

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps [and 2 more messages]

[Ian Jackson]

(CCing Nikolaus's bug.)

Emilio Pozuelo Monfort writes ("Re: A proposal for a tool to build local 
testing debs"):
> Or you can just do
> 
> $ sudo apt-get build-dep ./

That's not available in jessie of course, but ISTM that this is the
right answer for stretch.  I won't upload a new dgit to stretch to
change this but I think I should change this in buster.

Probably we should recommend --no-install-recommends.

Ian.

Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade

[Luca Capello]

Hi there,

On Thu, 23 Feb 2017 13:12:10 +0100, Michael Prokop wrote:
> * David Kalnischkies [Wed Feb 22, 2017 at 10:28:33PM +0100]:
> > On Wed, Feb 22, 2017 at 09:04:16PM +0100, Luca Capello wrote:
> 
> > > ...it will break existing practices, e.g.:
> > >  DEBIAN_FRONTEND=noninteractive apt-get upgrade -y
> > > FYI, I would call it a regression.
[...]
> > Ignoring that reading the apt output even in such invocations isn't
> > a bad idea as it will e.g. tell you which packages it can't upgrade
> > – I kinda hope you aren't performing a release upgrade unattended…
> 
> Several customers of mine have fully automated upgrade procedures,
> without any manual intervention needed and I'm sure there are
> several other folks doing similar stuff. In big environments with
> many systems and also products based on Debian which require easy
> upgrade procedures (possibly even by the enduser) I'm actually
> expecting to see such practices, since the process to get there can
> be automated + tested in advance (that's what we're doing).

I could have not said better, thanks Mika.

And for the release upgrade (which FTR I have never tested/done
unattended yet), I first carefully read the release notes, which most of
the time helps me sorting the biggest problem way before starting the
upgrade.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade

[Michael Prokop]

* David Kalnischkies [Wed Feb 22, 2017 at 10:28:33PM +0100]:
> On Wed, Feb 22, 2017 at 09:04:16PM +0100, Luca Capello wrote:

> > ...it will break existing practices, e.g.:
> >  DEBIAN_FRONTEND=noninteractive apt-get upgrade -y
> > FYI, I would call it a regression.

> That specific invocation can "fail" for all sorts of interesting reasons
> like dpkg config files or apt hooks. "fail" as in apt (and debconf) does
> what it was told to do, but that doesn't say dpkg what it is supposed to
> do. Or apt-list{changes,bugs} or …

With the according options all of that can be controlled as needed, e.g.:

APT_LISTBUGS_FRONTEND=none
APT_LISTCHANGES_FRONTEND=none
APT_PARAMS="--no-install-recommends -y -o DPkg::Options::=--force-confask -o 
DPkg::Options::=--force-confdef -o DPkg::Options::=--force-confmiss -o 
DPkg::Options::=--force-confnew"
DEBIAN_FRONTEND=noninteractive

(Disclaimer: especially the quoted "APT_PARAMS" is highly
environment specific of course and the environment variable is just
named by me/us as such. I know that you - David - know all of that
and that you wrote "[with] That specific invocation can "fail", so
consider it JFTR :))

> Ignoring that reading the apt output even in such invocations isn't
> a bad idea as it will e.g. tell you which packages it can't upgrade
> – I kinda hope you aren't performing a release upgrade unattended…

Several customers of mine have fully automated upgrade procedures,
without any manual intervention needed and I'm sure there are
several other folks doing similar stuff. In big environments with
many systems and also products based on Debian which require easy
upgrade procedures (possibly even by the enduser) I'm actually
expecting to see such practices, since the process to get there can
be automated + tested in advance (that's what we're doing).

regards,
-mika-


signature.asc
Description: Digital signature

[solved] Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade

[martin f krafft]

also sprach martin f krafft <madd...@debian.org> [2017-02-23 11:22 +1300]:
> I'm now taking this to a bug report:
> 
>   http://bugs.debian.org/855891

Read the gory details there, the gist is that David spotted my used
of

  APT::Get::AutomaticRemove "true";

in the apt.conf.d files. The rest is in the bug report, I just
wanted to bring this thread to a close.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"if english was good enough for jesus christ,
 it's good enough for us."
   -- miriam ferguson, governor of texas


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade

[martin f krafft]

also sprach Jonas Smedegaard  [2017-02-23 12:06 +1300]:
> Maybe your ifupdown was flagged as auto-installed, a recent prior APT 
> process upgraded to netbase 5.4 (no longer recommending ifupdown), and 
> your latest APT process just finished an auto-removal of the no longer 
> needed ifupdown for some reason not finalized earlier.

I doubt this. ifupdown has no entry in apt.extended_states.1.gz, and
netbase was upgraded from 5.3 during the same upgrade process. There
was no upgrade process before this which might have been continued.
Apart, auto-removal I think is specifically identified and should
also not happen on "upgrade" cf. manpage, no?

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"arthur slapped his arms about himself to try and get his
 circulation a little more enthusiastic about its job."
 -- hitchhiker's guide to the galaxy


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade

[Jonas Smedegaard]

Quoting martin f krafft (2017-02-22 01:06:24)
> Hey,
> 
> I just upgraded a system that had ifupdown from backports.org on it.
> Following cleanup and dpkg --audit etc., I ran
> 
>   root@cymbaline:/etc/apt/sources.list.d# apt-get upgrade
>   Reading package lists... Done
>   Building dependency tree
>   Reading state information... Done
>   Calculating upgrade... Done
>   The following packages will be REMOVED:
> ifupdown libasprintf0c2 libperl4-corelibs-perl libuuid-perl python-bson 
> python-pymongo
> 
> and indeed, it then went on to remove ifupdown.
> 
> What am I not understanding right here? Shouldn't "apt-get upgrade"
> NEVER EVER EVER EVER remove something?
> 
> Can I find out in hindsight (can't reproduce this) what might have
> happened?

Maybe your ifupdown was flagged as auto-installed, a recent prior APT 
process upgraded to netbase 5.4 (no longer recommending ifupdown), and 
your latest APT process just finished an auto-removal of the no longer 
needed ifupdown for some reason not finalized earlier.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade

[Eric Cooper]

On Thu, Feb 23, 2017 at 11:22:17AM +1300, martin f krafft wrote:
> [...] I've been using APT since one of its first
> versions, and I think "upgrade" has existed from the early days with
> precisely the promise that, unlike "dist-upgrade", it would not
> modify the set of installed packages, either way.

Indeed, from apt-get(8), under "upgrade":

"under no circumstances are currently installed packages removed, or
 packages not already installed retrieved and installed."

--
Eric Cooper e c c @ c m u . e d u

Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade

[martin f krafft]

Dear David,

Thank you for your witty response, and your work on APT. I mean it.
I am quite sure you get a lot of diverging requests and then one
like mine, without version numbers, logs, but CAPITAL LETTERS
instead.

While your points are spot-on, and I especially liked "this is
a proposal, not a EULA", I've been using APT since one of its first
versions, and I think "upgrade" has existed from the early days with
precisely the promise that, unlike "dist-upgrade", it would not
modify the set of installed packages, either way. Thence stems my
habit to run "apt-get upgrade" without reading the "proposal",
unlike when I run "dist-upgrade" or "install"/"remove"/"purge"
instead.

So I hope you understand that the confusion when I saw what had
happened. Fortunately, the damage wasn't so bad, but just imagine
this had happened via an SSH connection on a machine without console
access…

Now for your input:

> I am not opposed to the possibility of bugs in apt in general, but
> the amount of "upgrade with removal"-bugs which all turned out to
> be either scrollback-confusion, aliases or wrapper scripts is
> astonishing, so triple-double-check this first.

I sixtuple-checked as per your instructions and can confirm that the
apt-get I invoked was /usr/bin/apt-get from apt==1.0.9.8.4 and there
were no aliases or wrapper scripts involved. I checked this, but
I also purposely never have any of those when logged in as root.

I am not sure what you mean with scrollback-confusion. I mean, APT
told me it'd remove the packages, which I didn't see, and so when
I agreed, it removed them. And I recovered, and that's not a big
deal, but it shouldn't have put the packages up for removal in the
first place. And I cannot come up with a case where it should have
done that.

> have run and which solutions were applied due to it. That also
> includes dates, so you might be able to fish
> a /var/lib/dpkg/status file from before the "bad" interaction in
> /var/backups/dpkg.status.*.

I'm now taking this to a bug report:

  http://bugs.debian.org/855891

> in general: native tools are offtopic (by thread popularity) on
> d-d@ …
> 
> … but let me help you to get the thread some replies: I don't have
> ifupdown installed anymore. systemd-networkd + wpa_supplicant FTW.
> (also: RC bugs for all node packages failing a cat-picture test!)

Oh, the cynicism… ;)

Don't worry, I won't take your bait. This is a headless madchine in
a remote datacentre running 24/7. There's KVM access, fortunately.
I just need it to come up with its static IPs on every boot and
ifupdown has been doing a fantastic job for years with that.

> Oh, and of course the standard reply: You know, apt does print
> a proposal not an EULA – so you don't have to press 'yes' without
> reading.

This still made my day. ♥

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
echo Prpv a\'rfg cnf har cvcr | tr Pacfghnrvp Cnpstuaeic


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade

[David Kalnischkies]

On Wed, Feb 22, 2017 at 09:04:16PM +0100, Luca Capello wrote:
> On Wed, 22 Feb 2017 13:16:27 +0100, David Kalnischkies wrote:
> > On Wed, Feb 22, 2017 at 01:06:24PM +1300, martin f krafft wrote:
> > > What am I not understanding right here? Shouldn't "apt-get upgrade"
> > > NEVER EVER EVER EVER remove something?
> [...]
> > Fun fact: We have a few reports which request "upgrade" to remove
> > packages. You know, automatically installed packages, obsolete ones or
> > obviously clear upgrades like exim4 to postfix (or the other way around,
> > depending on who reports it). I tend to be against that, but in case of
> > need we could still consider that a feature and close bugs… win-win :P
> 
> Please do not change the current behavior because...

JFTR: That wasn't really meant to be serious… as said I tend to be
against it for all sort of reasons, but even if not it would be hidden
behind config options and if enabled by default only for 'apt' as we did
e.g. with --with-new-pkgs. And yes, we haven't willingly implemented
that & I still can't really believe that it actually happened without
a LOT more details.

The funfact is more a comment on what people assume the current
behaviour to be based on either having formed an opinion of what
"upgrade" means by popular opinion (e.g. on a mailinglist) or learned by
experience (or documentation) that certain specific rules apply – one of
them being that no package is supposed to be removed in this mode.


But I don't have a good day today in terms of writing working
patches/mails so I can see how I failed here, too.
Too much carnival around me I guess.


> > Oh, and of course the standard reply: You know, apt does print
> > a proposal not an EULA – so you don't have to press 'yes' without
> > reading.
> 
> ...it will break existing practices, e.g.:
> 
>  DEBIAN_FRONTEND=noninteractive apt-get upgrade -y
> 
> FYI, I would call it a regression.

That specific invocation can "fail" for all sorts of interesting reasons
like dpkg config files or apt hooks. "fail" as in apt (and debconf) does
what it was told to do, but that doesn't say dpkg what it is supposed to
do. Or apt-list{changes,bugs} or …

Ignoring that reading the apt output even in such invocations isn't
a bad idea as it will e.g. tell you which packages it can't upgrade
– I kinda hope you aren't performing a release upgrade unattended…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade

[Luca Capello]

Hi there,

On Wed, 22 Feb 2017 13:16:27 +0100, David Kalnischkies wrote:
> On Wed, Feb 22, 2017 at 01:06:24PM +1300, martin f krafft wrote:
> > What am I not understanding right here? Shouldn't "apt-get upgrade"
> > NEVER EVER EVER EVER remove something?
[...]
> Fun fact: We have a few reports which request "upgrade" to remove
> packages. You know, automatically installed packages, obsolete ones or
> obviously clear upgrades like exim4 to postfix (or the other way around,
> depending on who reports it). I tend to be against that, but in case of
> need we could still consider that a feature and close bugs… win-win :P

Please do not change the current behavior because...

> Oh, and of course the standard reply: You know, apt does print
> a proposal not an EULA – so you don't have to press 'yes' without
> reading.

...it will break existing practices, e.g.:

 DEBIAN_FRONTEND=noninteractive apt-get upgrade -y

FYI, I would call it a regression.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade

[David Kalnischkies]

On Wed, Feb 22, 2017 at 01:06:24PM +1300, martin f krafft wrote:
>   root@cymbaline:/etc/apt/sources.list.d# apt-get upgrade
[…]
>   The following packages will be REMOVED:
> ifupdown libasprintf0c2 libperl4-corelibs-perl libuuid-perl python-bson 
> python-pymongo
>
> and indeed, it then went on to remove ifupdown.

Outrageous! apt was always slow to adapt, so the new way of saying one
thing and doing the other isn't fully implemented yet. I am sorry. SCNR


> What am I not understanding right here? Shouldn't "apt-get upgrade"
> NEVER EVER EVER EVER remove something?

I am not opposed to the possibility of bugs in apt in general, but the
amount of "upgrade with removal"-bugs which all turned out to be either
scrollback-confusion, aliases or wrapper scripts is astonishing, so
triple-double-check this first.

Fun fact: We have a few reports which request "upgrade" to remove
packages. You know, automatically installed packages, obsolete ones or
obviously clear upgrades like exim4 to postfix (or the other way around,
depending on who reports it). I tend to be against that, but in case of
need we could still consider that a feature and close bugs… win-win :P


> Can I find out in hindsight (can't reproduce this) what might have
> happened?

/var/log/apt/history.log* should be able to tell you which commands you
have run and which solutions were applied due to it. That also includes
dates, so you might be able to fish a /var/lib/dpkg/status file from
before the "bad" interaction in /var/backups/dpkg.status.*. Pick the
apt.extended_states* file from around the same date for good measure.
A good idea might also be to write down the result of "grep ^Date
/var/lib/apt/lists/*Release" somewhere to have an easier time of getting
the same mirror state out of snapshot if we need that. Armed with that
you can try debugging on your own as detailed in apts README (in the
source) and/or I would suggest to report a bug with all the details you
collected [and all those the bugscript wants to collect] as its hard to
reproduce otherwise and in general: native tools are offtopic (by thread
popularity) on d-d@ …

… but let me help you to get the thread some replies: I don't have
ifupdown installed anymore. systemd-networkd + wpa_supplicant FTW.
(also: RC bugs for all node packages failing a cat-picture test!)


Oh, and of course the standard reply: You know, apt does print
a proposal not an EULA – so you don't have to press 'yes' without
reading.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

apt-get upgrade removing ifupdown on jessie→stretch upgrade

[martin f krafft]

Hey,

I just upgraded a system that had ifupdown from backports.org on it.
Following cleanup and dpkg --audit etc., I ran

  root@cymbaline:/etc/apt/sources.list.d# apt-get upgrade
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  Calculating upgrade... Done
  The following packages will be REMOVED:
ifupdown libasprintf0c2 libperl4-corelibs-perl libuuid-perl python-bson 
python-pymongo

and indeed, it then went on to remove ifupdown.

What am I not understanding right here? Shouldn't "apt-get upgrade"
NEVER EVER EVER EVER remove something?

Can I find out in hindsight (can't reproduce this) what might have
happened?

Thanks,

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
unix, because rebooting is for adding new hardware.


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Use apt-get indextargets instead of accessing /var/lib/apt/lists/ directly (was: Bug#833388: ITP: metaphlan2 Metagenomic Phylogenetic Analysis)

[Johannes Schauer]

Hi,

Quoting Christian Seiler (2016-08-04 10:03:04)
> Shell snipped I used to get this data:
> awk '/^Package:/ { pkg = $2; }
>  /^Installed-Size:/ { is = $2; }
>  /^Size:/ { print pkg, $2, is }' \
>  < /var/lib/apt/lists/*_debian_dists_sid_main_binary-amd64_Packages \
>   | sort -k3 -n \
>   | awk '{ print $1, $2 / 1024.0 / 1024.0 / 1024.0, $3 / 1024.0 / 1024.0 }' \
>   | tail -n 5 \
>   | tac

using the files in /var/lib/apt/lists/ directly should be avoided because the
naming scheme can change arbitrarily and the files might be compressed. You
should use "apt-get indextargets" instead.

Also, instead of awk, you might want to use grep-dctrl instead.

So the first part above until the sort would become:

apt-get indextargets \
| grep-dctrl -s Filename -n \
  -F Created-By Packages \
  -a -F Suite unstable \
  -a -F Component main \
  -a -F Architecture amd64 \
| xargs /usr/lib/apt/apt-helper cat-file \
| grep-dctrl -n -sPackage,Installed-Size,Size -FInstalled-Size '' \
| paste -sd "   \n" \
| sort ...

One can avoid the first grep-dctrl call by using "apt-get indextargets" command
line options like so:

apt-get indextargets \
  --format '$(FILENAME)' \
  "Created-By: Packages" \
  "Suite: unstable" \
  "Component: main" \
  "Architecture: amd64" \
| xargs ...

I just personally like to use grep-dctrl because then I don't have to learn yet
another syntax of how to filter deb822 files.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: deb.debian.org [was: Re: howto avoid "apt-get update" going guru?]

[Josh Triplett]

On Fri, Jul 08, 2016 at 08:56:37AM +0200, Adam Borowski wrote:
> On Thu, Jul 07, 2016 at 11:03:16PM -0700, Josh Triplett wrote:
> > Tollef Fog Heen wrote:
> > > ]] Josh Triplett
> > > > Tollef Fog Heen wrote:
> > > > > I personally recommend using deb.debian.org.
> > > > 
> > > > That works nicely, thanks!  Seems to have decent performance.
> > 
> > Ah, that makes sense.  I look forward to the announcement.
> > 
> > When you make the announcement, can you include a link to the details of
> > the CDN, such as the extent of its caching servers?  That would help
> > people determine if using it will likely produce good results for them.
> 
> The locality of this CDN seems to be... not the best.
> 
> In Poland, there's 11 mirrors (according to choose-mirror 2.69), and
> httpredir.debian.net always gives me one of those.  Not the closest one
> network- or geography- wise, but in a country the size of Poland, that's
> good enough.
> 
> deb.debian.org on the other hand, trying from two locations over three ISPs:
> Starogard Gdański/Netia, Starogard Gdański/UPC, Gdańsk/Limes:
> * IPv6: Amsterdam or London
> * IPv4: MIT, San Francisco, London

Just to confirm, did you use SRV records for this check as apt does, or
did you check the path to deb.debian.org's A or  records directly?

If I ping deb.debian.org directly, it resolves to various mirrors,
with ping times ranging from 20ms to 200ms away.  The SRV records,
though, point to a CDN server that reliably gets 20ms.

(I don't actually know the benefit of using SRV records here.)

- Josh Triplett

Re: deb.debian.org [was: Re: howto avoid "apt-get update" going guru?]

[Tollef Fog Heen]

]] Josh Triplett 

> [Please CC me on replies.]
> 
> Tollef Fog Heen wrote:
> > ]] Josh Triplett
> > > Tollef Fog Heen wrote:
> > > > I personally recommend using deb.debian.org.
> > > 
> > > That works nicely, thanks!  Seems to have decent performance.
> > > 
> > > I couldn't find any announcement or documentation of this, other than
> > > that on the site itself, though I did find a use of it in a recent
> > > announcement of dbgsym packages.
> > 
> > It's somewhat in beta yet.  I should probably write up an announcement
> > about it.
> 
> Ah, that makes sense.  I look forward to the announcement.
> 
> When you make the announcement, can you include a link to the details of
> the CDN, such as the extent of its caching servers?  That would help
> people determine if using it will likely produce good results for them.

Yeah, though what you actually want to check is whether it is faster for
them or not, rather than base it on just geographical distance.

> > > Does the CDN this uses download and cache packages on first request?
> > > Because I noticed when testing it that if I requested a package
> > > reasonably unlikely to have already been fetched, it would hang at "0%
> > > [Waiting for headers]" for a long time (minutes).  But if I reattempted
> > > that same package later, it would download just fine.
> > 
> > This was a bug and should be fixed now.  (It downloads on first request,
> > but it streams, so there should not be a big initial delay.)
> 
> Out of curiosity, what was the bug?

A bug in the VCL generator which caused an early return before
the flag to enable streaming was set.  I added a workaround which makes
it so we no longer hit the bug.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: deb.debian.org [was: Re: howto avoid "apt-get update" going guru?]

[Adam Borowski]

On Thu, Jul 07, 2016 at 11:03:16PM -0700, Josh Triplett wrote:
> Tollef Fog Heen wrote:
> > ]] Josh Triplett
> > > Tollef Fog Heen wrote:
> > > > I personally recommend using deb.debian.org.
> > > 
> > > That works nicely, thanks!  Seems to have decent performance.
> 
> Ah, that makes sense.  I look forward to the announcement.
> 
> When you make the announcement, can you include a link to the details of
> the CDN, such as the extent of its caching servers?  That would help
> people determine if using it will likely produce good results for them.

The locality of this CDN seems to be... not the best.

In Poland, there's 11 mirrors (according to choose-mirror 2.69), and
httpredir.debian.net always gives me one of those.  Not the closest one
network- or geography- wise, but in a country the size of Poland, that's
good enough.

deb.debian.org on the other hand, trying from two locations over three ISPs:
Starogard Gdański/Netia, Starogard Gdański/UPC, Gdańsk/Limes:
* IPv6: Amsterdam or London
* IPv4: MIT, San Francisco, London

-- 
An imaginary friend squared is a real enemy.

deb.debian.org [was: Re: howto avoid "apt-get update" going guru?]

[Josh Triplett]

[Please CC me on replies.]

Tollef Fog Heen wrote:
> ]] Josh Triplett
> > Tollef Fog Heen wrote:
> > > I personally recommend using deb.debian.org.
> > 
> > That works nicely, thanks!  Seems to have decent performance.
> > 
> > I couldn't find any announcement or documentation of this, other than
> > that on the site itself, though I did find a use of it in a recent
> > announcement of dbgsym packages.
> 
> It's somewhat in beta yet.  I should probably write up an announcement
> about it.

Ah, that makes sense.  I look forward to the announcement.

When you make the announcement, can you include a link to the details of
the CDN, such as the extent of its caching servers?  That would help
people determine if using it will likely produce good results for them.

> > Does the CDN this uses download and cache packages on first request?
> > Because I noticed when testing it that if I requested a package
> > reasonably unlikely to have already been fetched, it would hang at "0%
> > [Waiting for headers]" for a long time (minutes).  But if I reattempted
> > that same package later, it would download just fine.
> 
> This was a bug and should be fixed now.  (It downloads on first request,
> but it streams, so there should not be a big initial delay.)

Out of curiosity, what was the bug?

- Josh Triplett

Re: howto avoid "apt-get update" going guru?

[Tollef Fog Heen]

]] Josh Triplett 

> Tollef Fog Heen wrote:
> > I personally recommend using deb.debian.org.
> 
> That works nicely, thanks!  Seems to have decent performance.
> 
> I couldn't find any announcement or documentation of this, other than
> that on the site itself, though I did find a use of it in a recent
> announcement of dbgsym packages.

It's somewhat in beta yet.  I should probably write up an announcement
about it.

> Does the CDN this uses download and cache packages on first request?
> Because I noticed when testing it that if I requested a package
> reasonably unlikely to have already been fetched, it would hang at "0%
> [Waiting for headers]" for a long time (minutes).  But if I reattempted
> that same package later, it would download just fine.

This was a bug and should be fixed now.  (It downloads on first request,
but it streams, so there should not be a big initial delay.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: howto avoid "apt-get update" going guru?

[Marco d'Itri]

On Jul 06, Tollef Fog Heen  wrote:

> I personally recommend using deb.debian.org.
I do not, since it does not have local nodes in my country.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: howto avoid "apt-get update" going guru?

[Josh Triplett]

Tollef Fog Heen wrote:
> I personally recommend using deb.debian.org.

That works nicely, thanks!  Seems to have decent performance.

I couldn't find any announcement or documentation of this, other than
that on the site itself, though I did find a use of it in a recent
announcement of dbgsym packages.

Does the CDN this uses download and cache packages on first request?
Because I noticed when testing it that if I requested a package
reasonably unlikely to have already been fetched, it would hang at "0%
[Waiting for headers]" for a long time (minutes).  But if I reattempted
that same package later, it would download just fine.

- Josh Triplett

Re: howto avoid "apt-get update" going guru?

[Tollef Fog Heen]

]] Josh Triplett 

> Tollef Fog Heen wrote:
> > I'd not actively recommend people use httpredir.debian.org as it's
> > somewhat sporadically maintained.
> 
> Do you have any more details on that?  Does a better alternative exist?

I personally recommend using deb.debian.org.

> I still have hopes that someday the d-i mirror question becomes an
> expert-level question for people with a local mirror (assuming we don't
> also someday have automatic local mirror discovery).

Yeah, that'd be great.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: howto avoid "apt-get update" going guru?

[Tiago Ilieve]

Josh,

On 5 July 2016 at 14:53, Josh Triplett  wrote:
> Tollef Fog Heen wrote:
>> I'd not actively recommend people use httpredir.debian.org as it's
>> somewhat sporadically maintained.
>
> Do you have any more details on that?

There was a discussion[1] on "debian-project" mailing list a few
months ago. The first message is about shutting it down, but there
were other exchanged messages that you might find interesting.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-project/2016/04/msg00012.html

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: howto avoid "apt-get update" going guru?

[Josh Triplett]

Tollef Fog Heen wrote:
> I'd not actively recommend people use httpredir.debian.org as it's
> somewhat sporadically maintained.

Do you have any more details on that?  Does a better alternative exist?

I still have hopes that someday the d-i mirror question becomes an
expert-level question for people with a local mirror (assuming we don't
also someday have automatic local mirror discovery).

- Josh Triplett

Re: howto avoid "apt-get update" going guru?

[Tollef Fog Heen]

]] Martin Bagge / brother 

> On 2016-07-05 06:32, Harald Dunkel wrote:
>
> > # apt-get update
> > Err:1 http://ftp.debian.org/debian sid InRelease
> >   Could not connect to klecker-ftp.debian.org:80 (130.89.148.12),
> > connection timed out [IP: 2001:6b0:e:2018::173 80]
> > Reading package lists... Done
> > W: Failed to fetch http://ftp.debian.org/debian/dists/sid/InRelease
> > Could not connect to klecker-ftp.debian.org:80 (130.89.148.12),
> > connection timed out [IP: 2001:6b0:e:2018::173 80]
> > W: Some index files failed to download. They have been ignored, or old ones 
> > used instead.

We had some networking trouble for klecker today.

> > I didn't mention klecker-ftp anywhere in my config files.
> > Its not on the round-robin list for ftp.debian.org either:

It's the rdns entry for the IP you're connecting to.

> The concluding answer to your question is probably "use another
> hostname". Either a ftp.xx.d.o host or the geo dns based:
> http://httpredir.debian.org

I'd not actively recommend people use httpredir.debian.org as it's
somewhat sporadically maintained.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: howto avoid "apt-get update" going guru?

[Harald Dunkel]

Hi Martin,

On 07/05/16 10:09, Martin Bagge / brother wrote:
> On 2016-07-05 06:32, Harald Dunkel wrote:
>>
>> I didn't mention klecker-ftp anywhere in my config files.
>> Its not on the round-robin list for ftp.debian.org either:
>>
>> # host ftp.debian.org
>> ftp.debian.org has address 130.239.18.173
>> ftp.debian.org has address 130.239.18.165
>> ftp.debian.org has IPv6 address 2001:6b0:e:2018::165
>> ftp.debian.org has IPv6 address 2001:6b0:e:2018::173
>> ftp.debian.org mail is handled by 0 .
> 
> Was this command on the same box as the problematic apt-get update command?

Yes.

> Long time after the command was issued? ("this morning found" suggests a
> time between the two).
> 

No, the "host" was running on the same machine while apt-get
was waiting.

>> What would you suggest to avoid this kind of problem?
> 
> klecker is serving ftp.d.o.
> 
> http://anonscm.debian.org/cgit/mirror/dsa-auto-dns.git/tree/services/ftp.debian.org.service
> 
> From my view
> brother ~$ host ftp.debian.org
> ftp.debian.org has address 130.89.148.12
> ftp.debian.org mail is handled by 0 .
> 
> And by now my view have switched to use the ACC provided mirrors just as
> your example.
> 
> On the other hand the long standing recommendation is to not use ftp.d.o:
> https://wiki.debian.org/ftp.debian.org#line-22
> 

I see. "ftp.debian.org" is in my sources.list since ages.
Probably I missed the note introducing this new host.

Maybe it would help to provide recommended settings for
sources.list within /usr/share/base-files ?


Thanx very much
Harri

Re: howto avoid "apt-get update" going guru?

[Harald Dunkel]

On 07/05/16 06:32, Harald Dunkel wrote:
> Hi folks,
> 
> this morning I found "apt-get update" getting stuck due to an
> unresponsive host:
> 

Sorry, this was supposed to go to debian-user.
Regards
Harri

Re: howto avoid "apt-get update" going guru?

[Martin Bagge / brother]

On 2016-07-05 06:32, Harald Dunkel wrote:
> Hi folks,
> 
> this morning I found "apt-get update" getting stuck due to an
> unresponsive host:
> 
> # cat /etc/apt/sources.list
> deb http://ftp.debian.org/debian sid main contrib non-free
> deb-src http://ftp.debian.org/debian sid main contrib non-free
> 
> # apt-get update
> Err:1 http://ftp.debian.org/debian sid InRelease
>   Could not connect to klecker-ftp.debian.org:80 (130.89.148.12), connection 
> timed out [IP: 2001:6b0:e:2018::173 80]
> Reading package lists... Done
> W: Failed to fetch http://ftp.debian.org/debian/dists/sid/InRelease  Could 
> not connect to klecker-ftp.debian.org:80 (130.89.148.12), connection timed 
> out [IP: 2001:6b0:e:2018::173 80]
> W: Some index files failed to download. They have been ignored, or old ones 
> used instead.
> 
> 
> I didn't mention klecker-ftp anywhere in my config files.
> Its not on the round-robin list for ftp.debian.org either:
> 
> # host ftp.debian.org
> ftp.debian.org has address 130.239.18.173
> ftp.debian.org has address 130.239.18.165
> ftp.debian.org has IPv6 address 2001:6b0:e:2018::165
> ftp.debian.org has IPv6 address 2001:6b0:e:2018::173
> ftp.debian.org mail is handled by 0 .

Was this command on the same box as the problematic apt-get update command?
Long time after the command was issued? ("this morning found" suggests a
time between the two).

> What would you suggest to avoid this kind of problem?

klecker is serving ftp.d.o.

http://anonscm.debian.org/cgit/mirror/dsa-auto-dns.git/tree/services/ftp.debian.org.service

From my view
brother ~$ host ftp.debian.org
ftp.debian.org has address 130.89.148.12
ftp.debian.org mail is handled by 0 .

And by now my view have switched to use the ACC provided mirrors just as
your example.

On the other hand the long standing recommendation is to not use ftp.d.o:
https://wiki.debian.org/ftp.debian.org#line-22

The concluding answer to your question is probably "use another
hostname". Either a ftp.xx.d.o host or the geo dns based:
http://httpredir.debian.org

-- 
brother
http://sis.bthstudent.se



signature.asc
Description: OpenPGP digital signature

howto avoid "apt-get update" going guru?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi folks,

this morning I found "apt-get update" getting stuck due to an
unresponsive host:

# cat /etc/apt/sources.list
deb http://ftp.debian.org/debian sid main contrib non-free
deb-src http://ftp.debian.org/debian sid main contrib non-free

# apt-get update
Err:1 http://ftp.debian.org/debian sid InRelease
  Could not connect to klecker-ftp.debian.org:80 (130.89.148.12), connection 
timed out [IP: 2001:6b0:e:2018::173 80]
Reading package lists... Done
W: Failed to fetch http://ftp.debian.org/debian/dists/sid/InRelease  Could not 
connect to klecker-ftp.debian.org:80 (130.89.148.12), connection timed out [IP: 
2001:6b0:e:2018::173 80]
W: Some index files failed to download. They have been ignored, or old ones 
used instead.


I didn't mention klecker-ftp anywhere in my config files.
Its not on the round-robin list for ftp.debian.org either:

# host ftp.debian.org
ftp.debian.org has address 130.239.18.173
ftp.debian.org has address 130.239.18.165
ftp.debian.org has IPv6 address 2001:6b0:e:2018::165
ftp.debian.org has IPv6 address 2001:6b0:e:2018::173
ftp.debian.org mail is handled by 0 .


What would you suggest to avoid this kind of problem?


Every helpful comment is highly appreciated.
Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXezg8AAoJEAqeKp5m04HLbC0H/iBgrNyKqqa1oaDKywxHRbju
C+GOQDw0+ZDYG+nxkNVTVkO+nerAyCo9GwHqOkpaMOX8KXSMAxOkL8rPXsOc+pBu
+lrmJBa4Spu7nh+MZtPj6euljGCmBb4mzgbKZDTJpI4X8n02u5Yb3XroB3VqFmtT
HBKwvxADyKIUz1MUTpHLVDUhHgAN46VncbPfT2ecX6CSWrlclHEIbunDqYNjf4xW
nrIkNXr4oGs814CydTFo2Qk1xjCaiL9TKAIEjg8bXAIt5pUHnLw2fFcYLmQH1rEU
y0xvFympNkNJDmd5Ci8qF1Y6XJ0dzQDDDI+He6NRFe9/371wB+gd0tKGLMFbwOc=
=yurE
-END PGP SIGNATURE-

Bug#817805: develop a means for apt-get update to learn about new archive signing subkeys

[Peter Palfrader]

Package: apt
Severity: wishlist
X-Debbugs-Cc: debian-...@lists.debian.org, debian-devel@lists.debian.org

We would like to start creating the keys that sign unstable in crypto
tokens, so that they are never seen by a general purpose comuting
devices.

These keys would probably be subkeys of the ftpmaster's archive signing
key.  We can't backup such subkeys sanely.  Tokens might break or
mistakes might be made.

There should be a way for us to easily rotate these signing subkeys.

Ideally, apt would accept any Release file signed by a valid subkey of
an openpgp key it trusts.  Therefore, it needs a way to learn about new,
valid subkeys[*].

Maybe we can ship a set of openpgp key updates on the mirrors next to
the Release file, or somewhere in /project, and apt would merge keys
from there.  Care needs to be taken so we don't start trusting
completely new keys just because they were on a mirror.


We should to figure out a way how to properly do this.


Cheers,
weasel

* and while we're at it, it might also learn about subkey revocations.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Re: apt-get source linux behaves weird

[Andreas Cadhalpun]

On 29.11.2015 19:25, Josh Triplett wrote:
> Andreas Cadhalpun wrote:
>> The correct way would be to choose a new 'best hit', if either
>>  * there is a target release and it matches the release of the package,
>>  * or there is no target release
>> and the version is higher than the last best hit.
> 
> Not quite; that would fail if you have "1.1 (stable)" and "1.0 (stable)"
> in that order. You want to choose the package under consideration as
> the new 'best hit' if it matches the target release (or no target
> release exists) *and* if it has a higher version than the last best hit.

That's what I (thought I) described.

> Looking at the code, it looks like you may have implemented that, rather
> than what you describe above.  However, your comments don't match that,
> and your test case doesn't test for that:
> 
>> @@ -311,7 +309,7 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
>> continue;
>>  
>>  // Newer version or an exact match? Save the hit
> 
> This comment needs updating for the new algorithm.  Something like:
> "Newer version (in the target release if any)? Save it."

Maybe.

>> -if (Last == 0 || Cache->VS().CmpVersion(Version,Ver) < 
>> 0) {
>> +if (CorrectRelTag && (Last == 0 || 
>> Cache->VS().CmpVersion(Version,Ver) < 0)) {
>>         Last = Parse;
>>         Offset = Parse->Offset();
>> Version = Ver;
> 
>> --- a/test/integration/test-apt-get-source
>> +++ b/test/integration/test-apt-get-source
>> @@ -27,6 +27,14 @@ insertsource 'stable' 'foo' 'all' '1.0'
>>  insertsource 'wheezy' 'foo' 'all' '0.0.1'
>>  insertsource 'wheezy' 'foo' 'all' '0.1'
>>  
>> +# the order of these versions is choosen to ensure that
> 
> s/choosen/chosen/

Indeed.

>> +# * apt will pick the one in the correct release, despite a higher version 
>> coming later and
>> +# * apt will pick the highest version in a release, despite a lower version 
>> coming later.
>> +# (bts #746412)
>> +insertsource 'stable' 'baz' 'all' '1.0'
>> +insertsource 'unstable' 'baz' 'all' '2.0'
>> +insertsource 'unstable' 'baz' 'all' '1.5'
> 
> This test case doesn't ensure that apt picks the highest version in
> stable, rather than the last-mentioned version in stable.>  For more
> robustness, I'd suggest:
> 
> insertsource 'stable' 'baz' 'all' '0.1'
> insertsource 'stable' 'baz' 'all' '1.0'
> insertsource 'stable' 'baz' 'all' '0.5'
> insertsource 'unstable' 'baz' 'all' '1.4'
> insertsource 'unstable' 'baz' 'all' '2.0'
> insertsource 'unstable' 'baz' 'all' '1.5'

That'd be a bit redundant, but shouldn't hurt.

Best regards,
Andreas

Re: apt-get source linux behaves weird

[Andreas Cadhalpun]

On 29.11.2015 14:41, David Kalnischkies wrote:
> On Sun, Nov 29, 2015 at 03:17:47AM +0100, Andreas Cadhalpun wrote:
>> One has to do:
>> $ cd test/interactive-helper
>> $ make aptwebserver
> 
> A simple 'make' in the top-level directory builds this webserver

Indeed, but somehow 'debian/rules build-arch' doesn't.

>> How sane can a framework be if it has to generate packages that are "used
>> only by testcases and surf [...]", even though there are no waves? ;)
> 
> You have never seen apt fail bigtime then.
> That generates lots of waves… ;)

I'm glad I haven't. ;)

> And as a testrun doesn't show regressions… applied & pushed to git.

Thanks.

> Should be part of the next upload, which might or might not be soon
> depending on how many RCs people find now to block our transition after
> they had months in experimental to do it. ;)

Apparently somebody found something...

> Thanks for working on this!

Thank you for apt 1.1, I like it. :-)

Best regards,
Andreas

Re: apt-get source linux behaves weird

[Josh Triplett]

Andreas Cadhalpun wrote:
> The relevant testcases are in test/integration/test-apt-get-source.
> There is a test for #731853 that is supposed to "ensure that apt will
> pick the higher version number" of 0.0.1 (stable) and 0.1 (stable).
> However, this works by pure chance, as simply reversing the order
> of the two insertsource lines makes the test fail.
> So #731853 isn't really fixed, yet.
> 
> Actually, that's related to the problem I reported, as the underlying
> issue for both is the same:
> In the FindSrc function apt chooses a new 'best hit', if either
>  * there is a target release and it matches the release of the package,
>  * or the version of the package is higher than the last best hit.
> 
> Consider having 1.0 (stable), 2.0 (unstable) and 1.5 (unstable),
> in this order.
> 
> Looking for the version in stable, apt first selects 1.0, because the
> release matches the target release, but then subsequently selects 2.0,
> because the version is higher.
> 
> Looking for the version in unstable, apt first selects 2.0, because the
> release matches the target release, but then subsequently selects 1.5,
> because the release also matches the target release.
> 
> The correct way would be to choose a new 'best hit', if either
>  * there is a target release and it matches the release of the package,
>  * or there is no target release
> and the version is higher than the last best hit.

Not quite; that would fail if you have "1.1 (stable)" and "1.0 (stable)"
in that order.  You want to choose the package under consideration as
the new 'best hit' if it matches the target release (or no target
release exists) *and* if it has a higher version than the last best hit.

Looking at the code, it looks like you may have implemented that, rather
than what you describe above.  However, your comments don't match that,
and your test case doesn't test for that:

> @@ -311,7 +309,7 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
> continue;
>  
>  // Newer version or an exact match? Save the hit

This comment needs updating for the new algorithm.  Something like:
"Newer version (in the target release if any)? Save it."

> -if (Last == 0 || Cache->VS().CmpVersion(Version,Ver) < 
> 0) {
> +if (CorrectRelTag && (Last == 0 || 
> Cache->VS().CmpVersion(Version,Ver) < 0)) {
> Last = Parse;
> Offset = Parse->Offset();
> Version = Ver;

> --- a/test/integration/test-apt-get-source
> +++ b/test/integration/test-apt-get-source
> @@ -27,6 +27,14 @@ insertsource 'stable' 'foo' 'all' '1.0'
>  insertsource 'wheezy' 'foo' 'all' '0.0.1'
>  insertsource 'wheezy' 'foo' 'all' '0.1'
>  
> +# the order of these versions is choosen to ensure that

s/choosen/chosen/

> +# * apt will pick the one in the correct release, despite a higher version 
> coming later and
> +# * apt will pick the highest version in a release, despite a lower version 
> coming later.
> +# (bts #746412)
> +insertsource 'stable' 'baz' 'all' '1.0'
> +insertsource 'unstable' 'baz' 'all' '2.0'
> +insertsource 'unstable' 'baz' 'all' '1.5'

This test case doesn't ensure that apt picks the highest version in
stable, rather than the last-mentioned version in stable.  For more
robustness, I'd suggest:

insertsource 'stable' 'baz' 'all' '0.1'
insertsource 'stable' 'baz' 'all' '1.0'
insertsource 'stable' 'baz' 'all' '0.5'
insertsource 'unstable' 'baz' 'all' '1.4'
insertsource 'unstable' 'baz' 'all' '2.0'
insertsource 'unstable' 'baz' 'all' '1.5'

Re: apt-get source linux behaves weird

[David Kalnischkies]

On Sun, Nov 29, 2015 at 03:17:47AM +0100, Andreas Cadhalpun wrote:
> >> Last = Parse;
> >> Offset = Parse->Offset();
> >> Version = Ver;
> >> +   break;
> >>  }
> >>   }
> >>  
> > 
> > That 'fixes' this problem while reopening #731853 among others. Running
> > the autopkgtest tests would have shown it. You can do this without
> > building and installing apt packages via ./test/integration/run-tests,
> > which will use the apt buildtree it is in. You need to install a bunch
> > of additional test-dependencies through.
> 
> Thanks for pointing to the autopkgtests. However, some tests fail with:
> "You have to build aptwerbserver or install a webserver"
> 
> But there is no aptwe*r*bserver...
> One has to do:
> $ cd test/interactive-helper
> $ make aptwebserver

A simple 'make' in the top-level directory builds this webserver just
the same as it builds all the rest of the (apt) world [in fact, it
should be the very last thing it does] which is needed in some capacity
by the various testcases.  That there is an explicit check for the
aptwebserver is caused by a) for a while we tried getting real
webservers in line, but the simple ones lack HTTP1.1 features and the
bigger ones are a giant pain to setup (and do lack features as well) and
b) that aptwebserver isn't shipped in a package as Debian doesn't need
yet another packaged security-buggy webserver.  (aka: going to fix
message to reflect reality).

> > Adding a testcase here (they are simple shell scripts with an insane
> > amount of shell functions building a testing 'framework' to setup
> > packages, repositories and webservers among others) wouldn't hurt the
> > acceptance of a patch either.
> 
> How sane can a framework be if it has to generate packages that are "used
> only by testcases and surf [...]", even though there are no waves? ;)

You have never seen apt fail bigtime then.
That generates lots of waves… ;)


> The relevant testcases are in test/integration/test-apt-get-source.
> There is a test for #731853 that is supposed to "ensure that apt will
> pick the higher version number" of 0.0.1 (stable) and 0.1 (stable).
> However, this works by pure chance, as simply reversing the order
> of the two insertsource lines makes the test fail.
> So #731853 isn't really fixed, yet.
> 
> Actually, that's related to the problem I reported, as the underlying
> issue for both is the same:
> In the FindSrc function apt chooses a new 'best hit', if either
>  * there is a target release and it matches the release of the package,
>  * or the version of the package is higher than the last best hit.
> 
> Consider having 1.0 (stable), 2.0 (unstable) and 1.5 (unstable),
> in this order.

[you usually do not have this order as Sources tends to be ordered, but
you are right that assuming it is wrong.]


> Looking for the version in stable, apt first selects 1.0, because the
> release matches the target release, but then subsequently selects 2.0,
> because the version is higher.
> 
> Looking for the version in unstable, apt first selects 2.0, because the
> release matches the target release, but then subsequently selects 1.5,
> because the release also matches the target release.
> 
> The correct way would be to choose a new 'best hit', if either
>  * there is a target release and it matches the release of the package,
>  * or there is no target release
> and the version is higher than the last best hit.
> 
> Attached is a patch fixing this and another one adding above two
> testcases.

And as a testrun doesn't show regressions… applied & pushed to git.
Should be part of the next upload, which might or might not be soon
depending on how many RCs people find now to block our transition after
they had months in experimental to do it. ;)

Thanks for working on this!


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: apt-get source linux behaves weird

[Andreas Cadhalpun]

Control: tag -1 patch

Hi David,

On 15.08.2015 13:40, David Kalnischkies wrote:
> Control: tag -1 - patch
> 
>> @@ -387,13 +388,15 @@ static pkgSrcRecords::Parser *FindSrc(const char 
>> *Name,pkgRecords ,
>>   // See if we need to look for a specific release tag
>>   if (RelTag != "" && UserRequestedVerTag == "")
>>   {
>> -const string Rel = GetReleaseForSourceRecord(SrcList, Parse);
>> +string Dist;
>> +const string Rel = GetReleaseForSourceRecord(SrcList, Parse, 
>> Dist);
>>  
>> -if (Rel == RelTag)
>> +if (Rel == RelTag || Dist == RelTag)
>>  {
> 
> In the experimental git branch this changed completely as Release files
> have risen from the underground to be proper first class citizens (while
> Sources are still second class at best) where this was fixed by
> "accident" already in a seemingly "unrelated" commit (5ad0096a4) by me.

Since that has finally reached sid, I had another look at this bug.

>> Last = Parse;
>> Offset = Parse->Offset();
>> Version = Ver;
>> +   break;
>>  }
>>   }
>>  
> 
> That 'fixes' this problem while reopening #731853 among others. Running
> the autopkgtest tests would have shown it. You can do this without
> building and installing apt packages via ./test/integration/run-tests,
> which will use the apt buildtree it is in. You need to install a bunch
> of additional test-dependencies through.

Thanks for pointing to the autopkgtests. However, some tests fail with:
"You have to build aptwerbserver or install a webserver"

But there is no aptwe*r*bserver...
One has to do:
$ cd test/interactive-helper
$ make aptwebserver

> Adding a testcase here (they are simple shell scripts with an insane
> amount of shell functions building a testing 'framework' to setup
> packages, repositories and webservers among others) wouldn't hurt the
> acceptance of a patch either.

How sane can a framework be if it has to generate packages that are "used
only by testcases and surf [...]", even though there are no waves? ;)

The relevant testcases are in test/integration/test-apt-get-source.
There is a test for #731853 that is supposed to "ensure that apt will
pick the higher version number" of 0.0.1 (stable) and 0.1 (stable).
However, this works by pure chance, as simply reversing the order
of the two insertsource lines makes the test fail.
So #731853 isn't really fixed, yet.

Actually, that's related to the problem I reported, as the underlying
issue for both is the same:
In the FindSrc function apt chooses a new 'best hit', if either
 * there is a target release and it matches the release of the package,
 * or the version of the package is higher than the last best hit.

Consider having 1.0 (stable), 2.0 (unstable) and 1.5 (unstable),
in this order.

Looking for the version in stable, apt first selects 1.0, because the
release matches the target release, but then subsequently selects 2.0,
because the version is higher.

Looking for the version in unstable, apt first selects 2.0, because the
release matches the target release, but then subsequently selects 1.5,
because the release also matches the target release.

The correct way would be to choose a new 'best hit', if either
 * there is a target release and it matches the release of the package,
 * or there is no target release
and the version is higher than the last best hit.

Attached is a patch fixing this and another one adding above two
testcases.

Best regards,
Andreas
--- a/apt-private/private-source.cc
+++ b/apt-private/private-source.cc
@@ -288,6 +288,7 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
 		  while ((Parse = SrcRecs.Find(Src.c_str(), MatchSrcOnly)) != 0) 
 		  {
 		 const std::string Ver = Parse->Version();
+   bool CorrectRelTag = false;
 
 		 // See if we need to look for a specific release tag
 		 if (RelTag != "" && UserRequestedVerTag == "")
@@ -297,13 +298,10 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
 			{
 			   if ((Rls->Archive != 0 && RelTag == Rls.Archive()) ||
  (Rls->Codename != 0 && RelTag == Rls.Codename()))
-			   {
-			  Last = Parse;
-			  Offset = Parse->Offset();
-			  Version = Ver;
-			   }
+CorrectRelTag = true;
 			}
-		 }
+		 } else
+CorrectRelTag = true;
 
 		 // Ignore all versions which doesn't fit
 		 if (VerTag.empty() == false &&
@@ -311,7 +309,7 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
 			continue;
 
 		 // Newer version or an exact match? Save the hit
-		

Re: apt-get source linux behaves weird

[Andreas Cadhalpun]

Control: tag -1 patch

On 15.08.2015 02:13, Russ Allbery wrote:
 I believe the explanation is that selecting the distribution doesn't work
 the way that you think it does.  It just changes the prioritization used
 for selecting packages to install, which is then ignored by the source
 command.  (I could have the details wrong; this is vague memory from
 previous discussions.)

Actually the explanation is that it's a bug (or two) in apt.
The code responsible for this behavior is [1]:

  while ((Parse = SrcRecs.Find(Src.c_str(), MatchSrcOnly)) != 0) 
  {
 const string Ver = Parse-Version();

 // See if we need to look for a specific release tag
 if (RelTag !=   UserRequestedVerTag == )
 {
const string Rel = GetReleaseForSourceRecord(SrcList, Parse);

if (Rel == RelTag) /// -- Here it compares the '-t' argument with 
the release, e.g. stable/unstable. 
{
   Last = Parse;
   Offset = Parse-Offset();
   Version = Ver; /// -- Here it can have the correct version. :-)
}
 }

 // Ignore all versions which doesn't fit
 if (VerTag.empty() == false 
 Cache-VS().CmpVersion(VerTag, Ver) != 0) // exact match
continue;

 // Newer version or an exact match? Save the hit
 if (Last == 0 || Cache-VS().CmpVersion(Version,Ver)  0) {
Last = Parse;
Offset = Parse-Offset();
Version = Ver; /// -- But here it overwrites the found version 
with any newer one. :-(
 }

 // was the version check above an exact match?
 // If so, we don't need to look further
 if (VerTag.empty() == false  (VerTag == Ver))
break;
  }

To fix this problem, one can add a 'break;' at the point, where apt got
the correct version.
Then 'apt-get -t unstable source source-pkg' works as expected,
but  'apt-get -t sid source source-pkg' still doesn't work, because
apt doesn't compare with the distribution codename, e.g. jessie/sid.
That's not hard to fix either.

 It would be great if this could be fixed at some point, since it's really
 surprising UI behavior.

Attached patch fixes both problems, so hopefully the next apt release gets
this right.

Best regards,
Andreas


1: 
https://anonscm.debian.org/cgit/apt/apt.git/tree/cmdline/apt-get.cc?id=990af3c952676eaa51ccd614ab2d4234693da397#n383
--- a/cmdline/apt-get.cc
+++ b/cmdline/apt-get.cc
@@ -161,7 +161,7 @@ static std::string MetaIndexFileNameOnDisk(metaIndex *metaindex)
 // -
 /* */
 static std::string GetReleaseForSourceRecord(pkgSourceList *SrcList,
-  pkgSrcRecords::Parser *Parse)
+  pkgSrcRecords::Parser *Parse, std::string Dist)
 {
// try to find release
const pkgIndexFile CurrentIndexFile = Parse-Index();
@@ -184,6 +184,7 @@ static std::string GetReleaseForSourceRecord(pkgSourceList *SrcList,
 {
indexRecords records;
records.Load(path);
+   Dist = records.GetDist();
return records.GetSuite();
 }
  }
@@ -387,13 +388,15 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,pkgRecords Recs,
  // See if we need to look for a specific release tag
  if (RelTag !=   UserRequestedVerTag == )
  {
-const string Rel = GetReleaseForSourceRecord(SrcList, Parse);
+string Dist;
+const string Rel = GetReleaseForSourceRecord(SrcList, Parse, Dist);
 
-if (Rel == RelTag)
+if (Rel == RelTag || Dist == RelTag)
 {
Last = Parse;
Offset = Parse-Offset();
Version = Ver;
+   break;
 }
  }
 

Re: apt-get source linux behaves weird

[Paul Wise]

On Sat, Aug 15, 2015 at 2:13 AM, Russ Allbery wrote:

 The workaround, as you discovered, is to figure out what version you want
 with apt-cache show and then specify it with the = syntax.

Another workaround is to specify binary package names instead of
source package names. Sometimes this is more useful than your
workaround but probably not in this case.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: apt-get source linux behaves weird

[David Kalnischkies]

Control: tag -1 - patch

 @@ -387,13 +388,15 @@ static pkgSrcRecords::Parser *FindSrc(const char 
 *Name,pkgRecords Recs,
   // See if we need to look for a specific release tag
   if (RelTag !=   UserRequestedVerTag == )
   {
 -const string Rel = GetReleaseForSourceRecord(SrcList, Parse);
 +string Dist;
 +const string Rel = GetReleaseForSourceRecord(SrcList, Parse, 
 Dist);
  
 -if (Rel == RelTag)
 +if (Rel == RelTag || Dist == RelTag)
  {

In the experimental git branch this changed completely as Release files
have risen from the underground to be proper first class citizens (while
Sources are still second class at best) where this was fixed by
accident already in a seemingly unrelated commit (5ad0096a4) by me.


 Last = Parse;
 Offset = Parse-Offset();
 Version = Ver;
 +   break;
  }
   }
  

That 'fixes' this problem while reopening #731853 among others. Running
the autopkgtest tests would have shown it. You can do this without
building and installing apt packages via ./test/integration/run-tests,
which will use the apt buildtree it is in. You need to install a bunch
of additional test-dependencies through.

Adding a testcase here (they are simple shell scripts with an insane
amount of shell functions building a testing 'framework' to setup
packages, repositories and webservers among others) wouldn't hurt the
acceptance of a patch either.


If you wanna work on this further feel free to find me at DebConf (if
you are here). I am the guy accompanied by super cow. Otherwise hit me
on IRC (DonKult) in #debian-apt or anywhere else. That extends to all
the things apt of course like bugs tagged newcomer… *hint hint*


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

apt-get source linux behaves weird

[Daniel Reichelt]

Hi folks,

when I do 'apt-get source linux' with jessie+sid enabled in sources.list,
there's no way to select jessie's ksrc version by target release. Neither
of these work:

- apt-get source linux
- apt-get -t jessie source linux
- apt-get source linux/jessie


Everytime the result is:
---8---
$ apt-get source linux/jessie
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Selected version '4.1.3-1' (jessie) for linux
NOTICE: 'linux' packaging is maintained in the 'Svn' version control system at:
svn://anonscm.debian.org/svn/kernel/dists/trunk/linux/
Need to get 85.2 MB of source archives.
Get:1 http://ftp.de.debian.org/debian/ sid/main linux 4.1.3-1 (dsc) [139 kB]
Get:2 http://ftp.de.debian.org/debian/ sid/main linux 4.1.3-1 (tar) [84.3 MB]
Get:3 http://ftp.de.debian.org/debian/ sid/main linux 4.1.3-1 (diff) [743 kB]
Fetched 85.2 MB in 1s (76.5 MB/s)
dpkg-source: info: extracting linux in linux-4.1.3
dpkg-source: info: unpacking linux_4.1.3.orig.tar.xz
[...]
---8---

Doing an 'apt-get source linux=3.16.7-ckt11-1+deb8u3' works as expected.


My sources.list at this point is

--8-
deb http://ftp.de.debian.org/debian jessie main contrib non-free
deb-src http://ftp.de.debian.org/debian jessie main contrib non-free

deb http://security.debian.org jessie/updates main contrib non-free
deb-src http://security.debian.org jessie/updates main contrib non-free

deb http://ftp.de.debian.org/debian jessie-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian jessie-updates main contrib non-free

deb http://ftp.de.debian.org/debian jessie-proposed-updates main contrib 
non-free
deb-src http://ftp.de.debian.org/debian jessie-proposed-updates main contrib 
non-free

deb http://ftp.de.debian.org/debian jessie-backports main contrib non-free
deb-src http://ftp.de.debian.org/debian jessie-backports main contrib non-free

deb http://ftp.de.debian.org/debian sid main contrib non-free
deb-src http://ftp.de.debian.org/debian sid main contrib non-free
--8-


Am I missing something or is this a bug in apt?
Any hints are greatly appreciated.

Daniel


PS: Please CC me, I'm not subscribed to the list

Re: apt-get source linux behaves weird

[Andreas Cadhalpun]

Hi Daniel,

On 14.08.2015 08:10, Daniel Reichelt wrote:
 when I do 'apt-get source linux' with jessie+sid enabled in sources.list,
 there's no way to select jessie's ksrc version by target release. Neither
 of these work:
 
 - apt-get source linux
 - apt-get -t jessie source linux
 - apt-get source linux/jessie
 
 
 Everytime the result is:
 ---8---
 $ apt-get source linux/jessie
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 Selected version '4.1.3-1' (jessie) for linux

Note how this line is clearly wrong, as jessie doesn't have linux 4.1.3-1.

[...]
 Am I missing something or is this a bug in apt?
 Any hints are greatly appreciated.

This looks very much like apt bug #746412 [1], which I reported in April
last year (and which was mistakenly closed today).

Best regards,
Andreas


1: https://bugs.debian.org/746412

Re: apt-get source linux behaves weird

[Russ Allbery]

Daniel Reichelt deb...@nachtgeist.net writes:

 when I do 'apt-get source linux' with jessie+sid enabled in sources.list,
 there's no way to select jessie's ksrc version by target release. Neither
 of these work:

 - apt-get source linux
 - apt-get -t jessie source linux
 - apt-get source linux/jessie

[...]

 Doing an 'apt-get source linux=3.16.7-ckt11-1+deb8u3' works as expected.

Yeah, it's been like this forever.  I've reported this before.

I believe the explanation is that selecting the distribution doesn't work
the way that you think it does.  It just changes the prioritization used
for selecting packages to install, which is then ignored by the source
command.  (I could have the details wrong; this is vague memory from
previous discussions.)

It would be great if this could be fixed at some point, since it's really
surprising UI behavior.

The workaround, as you discovered, is to figure out what version you want
with apt-cache show and then specify it with the = syntax.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/

Problème avec certain dépots et apt-get

[Laurent COOPER]

Bonjour

Sur un certain nombre de serveurs, j'ai un problème avec apt-get pour
récupérer les fichiers Packages.Gz. Le plus étonnant est que ce problème
ne se produit pas sur tous mes serveurs.

J'utilise apt-cacher, et je pensais initialement que le problème venait
de là. Voilà l'erreur d'apt-cacher :

W: Impossible de récupérer
http://security.debian.org/dists/squeeze/updates/main/binary-i386/Packages.gz
 403  Confusing request

Du coup, je supprime apt-cacher de la configuration pour voir le
résultat. Apt-get update de nouveau ...

W: Impossible de récupérer
http://security.debian.org/dists/squeeze/updates/main/binary-i386/Packages.gz
 400  Bad Request [IP : 212.211.132.32 80]

Ah, une erreur 400 ... requête incorrecte ?!

Bon, est ce que le serveur est malcomprenant ? J'essaye avec wget :

wget
http://security.debian.org/dists/squeeze/updates/main/binary-i386/Packages.gz

Et là, ça fonctionne sans l'ombre d'un problème.

J'avoue que je suis dans le brouillard. Apt peut il avoir des requêtes
http incorrecte ? Y a t'il un moyen de rendre apt-get verbeux pour voir
les requetes ?

Ah, j'oubliais, c'est du squeeze.

En vous remerciant par avance pour votre aide

Cordialement

Laurent
-- 
Laurent COOPER
Carmi de l'académie de Grenoble
laurent.coo...@ac-grenoble.fr


--
To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/549001fa.5060...@ac-grenoble.fr

Re: Problème avec certain dépots et apt-get

[Laurent COOPER]

Le 16/12/2014 10:57, Laurent COOPER a écrit :
 Bonjour
 
 Sur un certain nombre de serveurs, j'ai un problème avec apt-get pour
 récupérer les fichiers Packages.Gz. Le plus étonnant est que ce problème
 ne se produit pas sur tous mes serveurs.
 
 J'utilise apt-cacher, et je pensais initialement que le problème venait
 de là. Voilà l'erreur d'apt-cacher :
 
 W: Impossible de récupérer
 http://security.debian.org/dists/squeeze/updates/main/binary-i386/Packages.gz
  403  Confusing request
 
 Du coup, je supprime apt-cacher de la configuration pour voir le
 résultat. Apt-get update de nouveau ...
 
 W: Impossible de récupérer
 http://security.debian.org/dists/squeeze/updates/main/binary-i386/Packages.gz
  400  Bad Request [IP : 212.211.132.32 80]
 
 Ah, une erreur 400 ... requête incorrecte ?!
 
 Bon, est ce que le serveur est malcomprenant ? J'essaye avec wget :
 
 wget
 http://security.debian.org/dists/squeeze/updates/main/binary-i386/Packages.gz
 
 Et là, ça fonctionne sans l'ombre d'un problème.
 
 J'avoue que je suis dans le brouillard. Apt peut il avoir des requêtes
 http incorrecte ? Y a t'il un moyen de rendre apt-get verbeux pour voir
 les requetes ?
 
 Ah, j'oubliais, c'est du squeeze.
 
 En vous remerciant par avance pour votre aide
 
 Cordialement
 
 Laurent
 
Une auto-réponse ...

Visiblement, c'est le bug 720485

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720485

Le fix est de mettre à jour apt à la main. EN utilisant la version de
apt du dépot squeeze-lts, ça fonctionne.

Dur de mettre à jour quand le système de mise à jour fait défaut :(

Bonne journée

Laurent


--
To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54900529.5010...@ac-grenoble.fr

aptitude dependency-resolver behaviors (was Re: apt-get install sysvinit-core removes gnome?)

[The Wanderer]

On 10/20/2014 at 11:59 AM, David Kalnischkies wrote:

 On Sun, Oct 19, 2014 at 09:32:54AM +0200, Matthias Urlichs wrote:
 
 David Kalnischkies:

 This isn't trying harder, it is trying increasingly incorrect
 solutions to the problem because aptitude assumes the users is
 not able to express himself correctly. apt-get is treating its
 user as its god instead, aka: user is always right, even if it
 makes no sense in apt's simple mind.
 
 My main problem is that, whenever I install a difficult package,
 the first solution I get presented is always to simply not install
 the package in question. The next 2^n-1 solutions transitively
 remove everything that currently conflicts with installing the
 thing in question. Rejecting the removal of a few core packages
 then gets me the correct solution, e.g. upgrading two packages.
 
 I think aptitude is calling this canceling actions. I would bet you
 can use this config setting to discourage it from doing that, but 
 ultimately its a design choice to allow or forbid them at all.
 
 Selecting one package in an or-group is a grand example of people
 not understand their tools although the policy is simple and
 logic: If it isn't impossible to let it win, the first
 alternative wins. If the package manager would go for any
 heuristic based on simplicity of installation instead everyone
 would have lsb-invalid-mta as MTA because that is damn easy to
 install by any standard. Maintainers are very heavily relying on
 this property while e.g. building packages.
 
 You don't have to drop that part of its logic. Choosing a different
 package as a dependency should of course be a last resort action
 (i.e. be heavily penalized). I'm not talking about changing that.
 I'm talking about the fact that aptitude treats upgrading to a
 slightly-lower-prioritized version of a package as a *way* worse
 solution than removing that package (and/or 500 others).
 
 Well, slightly lower priority means packages from a different
 release in general, so that isn't a safe action either. experimental
 and backports come to mind. Never upgrading to a security fix is
 another.
 
 Also – but that might be a relatively controversial point – users
 are much better at figuring out which packages they don't want
 removed compared to e.g. which packages should be held at a lower
 version, so I can optimize the other values and let the user decide
 along a property he can easily reason about (I am not suggestion that
 aptitude or apt-get work that way, but who knows that for sure
 anyway, right?).

What I think is being asked for (and what I'd certainly like to see,
anyway) is a way for the user, having figured out which packages they
don't want removed, to tell the aptitude resolver that and have it taken
into account in calculating a dependency solution.

As it happens, there's an obvious way to do that: specify the package(s)
you don't want removed on the aptitude command line.

However, one of the behaviors I've observed - which I think, per the
quote above, is part of exactly what is being complained about - is that
aptitude will often propose a solution which involves keep
package-X-from-command-line at its current version before proposing a
solution which involves install a new version of that same package.
Thus, specifying a package on the command line does not effectively tell
the aptitude resolver that you don't want it removed.

(I'm pretty sure I've seen a proposed solution, in a package-upgrade
scenario, which involved remove package X and everything that depends
on it, as well. But I don't recall any specifics on that one, so it
might be my imagination.)

My core objection to aptitude is less that it proposes non-optimal
solutions first (although that's certainly part of it) than that it
frequently, indeed perhaps consistently, proposes solutions which
involve *not doing the actual thing which was requested* before
proposing ones which do. That does not seem remotely reasonable, to me.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: aptitude dependency-resolver behaviors (was Re: apt-get install sysvinit-core removes gnome?)

[Andrei POPESCU]

On Ma, 21 oct 14, 09:08:26, The Wanderer wrote:
 
 What I think is being asked for (and what I'd certainly like to see,
 anyway) is a way for the user, having figured out which packages they
 don't want removed, to tell the aptitude resolver that and have it taken
 into account in calculating a dependency solution.
 
 As it happens, there's an obvious way to do that: specify the package(s)
 you don't want removed on the aptitude command line.

It's also possible to do it in interactive mode.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: apt-get install sysvinit-core removes gnome?

[Andrei POPESCU]

On Jo, 16 oct 14, 17:35:09, Martin Read wrote:
 
 mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
 Aptitude::ProblemResolver {
 SolutionCost priority, removals, canceled-actions;

I've had better (as in not unexpected) results with just 'removals'.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: apt-get install sysvinit-core removes gnome?

[David Kalnischkies]

On Sun, Oct 19, 2014 at 09:32:54AM +0200, Matthias Urlichs wrote:
 David Kalnischkies:
   Apitude, too, *really* likes to choose 500 deletions rather than upgrading
   even a single package to a version with slightly-lower priority (as 
   defined
   in /etc/apt/pref*), but at least you can tell it to try harder. :-/
  
  I shouldn't, I really shouldn't, but well, I bite…
  
  This isn't trying harder, it is trying increasingly incorrect solutions
  to the problem because aptitude assumes the users is not able to express
  himself correctly. apt-get is treating its user as its god instead, aka:
  user is always right, even if it makes no sense in apt's simple mind.
  
 My main problem is that, whenever I install a difficult package, the
 first solution I get presented is always to simply not install the package
 in question. The next 2^n-1 solutions transitively remove everything that
 currently conflicts with installing the thing in question. Rejecting the
 removal of a few core packages then gets me the correct solution, e.g.
 upgrading two packages.

I think aptitude is calling this canceling actions. I would bet you can
use this config setting to discourage it from doing that, but
ultimately its a design choice to allow or forbid them at all.


  Selecting one package in an or-group is a grand example of people not
  understand their tools although the policy is simple and logic: If it
  isn't impossible to let it win, the first alternative wins. If the
  package manager would go for any heuristic based on simplicity of
  installation instead everyone would have lsb-invalid-mta as MTA because
  that is damn easy to install by any standard. Maintainers are very
  heavily relying on this property while e.g. building packages.
 
 You don't have to drop that part of its logic. Choosing a different package
 as a dependency should of course be a last resort action (i.e. be heavily
 penalized). I'm not talking about changing that. I'm talking about the fact
 that aptitude treats upgrading to a slightly-lower-prioritized version of a
 package as a *way* worse solution than removing that package (and/or 500
 others).

Well, slightly lower priority means packages from a different release
in general, so that isn't a safe action either. experimental and
backports come to mind. Never upgrading to a security fix is another.

Also – but that might be a relatively controversial point – users are
much better at figuring out which packages they don't want removed
compared to e.g. which packages should be held at a lower version, so I can
optimize the other values and let the user decide along a property he can
easily reason about (I am not suggestion that aptitude or apt-get work
that way, but who knows that for sure anyway, right?).


 Basically, this boils down to the fact that people shouldn't have to read a
 manpage about a complex priority scheme in an equally-complex resolver.
 All I want is for aptitude to behave in a sane way by default.
 
 Its current behavior is not.

The usual approach to improving software is to whine about it on mailing
lists until its done. While this might work for init systems, it doesn't
for most stuff, so the better approach is helping to make it happen.

You even made the first step already by realising that the resolver is
indeed just as complex as the priority scheme – which can be described
in a few sentences. Most people regard them as ancient magic no living
human being understands. The irony is that this could very well be
a self-fulfilling prophecy as not that many people are left who work on
them…

(case in point: even with the dirty tricks I pulled to make MultiArch work
without too much pain, aptitude with its own solver was still more or less
broken by it. I guess I should have done a RoQA while I could… thankfully
a small new team materialized out of nowhere later on solving this problem.
The history of apt is equally fun to look at. We will see when Debian
finally run out of luck and does a RoQA ^apt.* I guess…)


Anyway, you want to talk about changes to aptitude to someone who is
actually into aptitude. aka: ¬me and I doubt you will find such
a person in a systemd related thread…


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Re: apt-get install sysvinit-core removes gnome?

[David Kalnischkies]

On Sun, Oct 19, 2014 at 01:34:13PM +0200, Holger Levsen wrote:
 cc:ing the apt maintainers to get their opinion on making this the default...

[Disclaimer: I have written the APT part of it. I might be biased.]

Hell no – as this isn't the point of the implementation. It is intended
to help researchers and developers alike to experiment with resolvers in
normal situations rather than fabricated snapshots as you can't jump
to conclusion about the greatness of a resolver based on one single
test – and experimentation is basically the opposite of what you would
want the default resolver be:
The multiple levels of indirection in the design are e.g. great for
playing, but horrible from a speed point of view. It would also move
a lot of stuff onto every debian system… I guess I don't have to tell
you what it means to pull in prio:extra packages from a build-essential
prio:important (and for all practical proposes nearly essential:yes)
package.

It's also not complete yet. The CUDF protocol for example learned very
recently what MutliArch is and how to not explode if its encountered,
I wouldn't exactly call this path exceptional well tested as a result.
[Disclaimer: I have written MultiArch in APT as well, so I flipped
between both for quiet a while… not fun, so biased again].

It isn't even clear yet which technique is strictly superior to what we
have at the moment as our naturally grown heuristic-solvers do pretty
well in real world scenarios. If you don't trust me on that:
http://mancoosi.org/~abate/package-managers-comparison-take-2 which
talks about http://www.mancoosi.org/measures/packagemanagers/2012/
[Disclaimer: I have written a lengthy comment there which should give
you a hint why I come to this conclusion … bias the third]

(And yes, while I consider it a bug that apt isn't able to figure this
one out without a little help, I don't really consider this case
an important realworld scenario. In the end, the times I will change
init systems is hopefully far below the GR proposal count for that.
Not only because I am lazy, but because it would mean that everyone
would have done a pretty crappy job making Debian jessie the best release
ever if no init works reliably [totally unbiased on this one] )


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Re: apt-get install sysvinit-core removes gnome?

[Matthias Urlichs]

Hi,

David Kalnischkies:
  Apitude, too, *really* likes to choose 500 deletions rather than upgrading
  even a single package to a version with slightly-lower priority (as defined
  in /etc/apt/pref*), but at least you can tell it to try harder. :-/
 
 I shouldn't, I really shouldn't, but well, I bite…
 
 This isn't trying harder, it is trying increasingly incorrect solutions
 to the problem because aptitude assumes the users is not able to express
 himself correctly. apt-get is treating its user as its god instead, aka:
 user is always right, even if it makes no sense in apt's simple mind.
 
My main problem is that, whenever I install a difficult package, the
first solution I get presented is always to simply not install the package
in question. The next 2^n-1 solutions transitively remove everything that
currently conflicts with installing the thing in question. Rejecting the
removal of a few core packages then gets me the correct solution, e.g.
upgrading two packages.

 Selecting one package in an or-group is a grand example of people not
 understand their tools although the policy is simple and logic: If it
 isn't impossible to let it win, the first alternative wins. If the
 package manager would go for any heuristic based on simplicity of
 installation instead everyone would have lsb-invalid-mta as MTA because
 that is damn easy to install by any standard. Maintainers are very
 heavily relying on this property while e.g. building packages.

You don't have to drop that part of its logic. Choosing a different package
as a dependency should of course be a last resort action (i.e. be heavily
penalized). I'm not talking about changing that. I'm talking about the fact
that aptitude treats upgrading to a slightly-lower-prioritized version of a
package as a *way* worse solution than removing that package (and/or 500
others).

Basically, this boils down to the fact that people shouldn't have to read a
manpage about a complex priority scheme in an equally-complex resolver.
All I want is for aptitude to behave in a sane way by default.

Its current behavior is not.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141019073253.ga24...@smurf.noris.de

Re: apt-get install sysvinit-core removes gnome?

[Thomas Krennwallner]

On Sun Oct 19, 2014 09:32:54AM +0200, Matthias Urlichs wrote:
 David Kalnischkies:
  Selecting one package in an or-group is a grand example of people not
  understand their tools although the policy is simple and logic: If it
  isn't impossible to let it win, the first alternative wins. If the
  package manager would go for any heuristic based on simplicity of
  installation instead everyone would have lsb-invalid-mta as MTA because
  that is damn easy to install by any standard. Maintainers are very
  heavily relying on this property while e.g. building packages.
 
 You don't have to drop that part of its logic. Choosing a different package
 as a dependency should of course be a last resort action (i.e. be heavily
 penalized). I'm not talking about changing that. I'm talking about the fact
 that aptitude treats upgrading to a slightly-lower-prioritized version of a
 package as a *way* worse solution than removing that package (and/or 500
 others).
 
 Basically, this boils down to the fact that people shouldn't have to read a
 manpage about a complex priority scheme in an equally-complex resolver.
 All I want is for aptitude to behave in a sane way by default.

I think it's time to use apt-cudf. On a standard sid installation with
gnome, it could perfectly resolve this situation:

 % apt-get -s --solver aspcud install sysvinit-core 

 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 Execute external solver... Done
 The following extra packages will be installed:
   cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim
 The following packages will be REMOVED:
   systemd-sysv
 The following NEW packages will be installed:
   cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim sysvinit-core
 0 upgraded, 6 newly installed, 1 to remove and 0 not upgraded.

Compare with apt-get without aspcud:

 % sudo apt-get -s install sysvinit-core
 
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 The following package was automatically installed and is no longer required:
   linux-image-amd64
 Use 'apt-get autoremove' to remove it.
 The following extra packages will be installed:
   cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim
 The following packages will be REMOVED:
   aptdaemon brasero colord gdm3 gnome gnome-bluetooth gnome-color-manager 
gnome-control-center gnome-core gnome-disk-utility gnome-packagekit
   gnome-packagekit-session gnome-session gnome-settings-daemon gnome-shell 
gnome-shell-extensions gnome-sushi gnome-system-log gnome-user-share gvfs
   gvfs-backends gvfs-daemons gvfs-fuse libpam-systemd nautilus nautilus-sendto 
network-manager network-manager-gnome packagekit packagekit-tools
   policykit-1 policykit-1-gnome systemd-sysv task-gnome-desktop udisks2
 The following NEW packages will be installed:
   cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim sysvinit-core
 0 upgraded, 6 newly installed, 35 to remove and 0 not upgraded.

Best,
TK


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141019090313.ga29...@kr.tuwien.ac.at

Re: apt-get install sysvinit-core removes gnome?

[Holger Levsen]

Hi,

cc:ing the apt maintainers to get their opinion on making this the default...

On Sonntag, 19. Oktober 2014, Thomas Krennwallner wrote:
  Basically, this boils down to the fact that people shouldn't have to read
  a manpage about a complex priority scheme in an equally-complex
  resolver. All I want is for aptitude to behave in a sane way by default.
 
 I think it's time to use apt-cudf. On a standard sid installation with
 gnome, it could perfectly resolve this situation:
 
  % apt-get -s --solver aspcud install sysvinit-core
[keeps gnome]
[...]
 Compare with apt-get without aspcud:
  % sudo apt-get -s install sysvinit-core
[removes gnome]

wow.

I guess the usual too late for jessie applies, though, or?


cheers,
Holger


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

Re: apt-get install sysvinit-core removes gnome?

[Julian Andres Klode]

On Sun, Oct 19, 2014 at 1:34 PM, Holger Levsen hol...@layer-acht.org wrote:
 Hi,

 cc:ing the apt maintainers to get their opinion on making this the default...

aspcud is not suitable as a default solver. It is far too slow and
ignores some aspects people are accustomed to, like a Depends: a | b
installing a whenever possible. Same for all other CUDF solvers.


 On Sonntag, 19. Oktober 2014, Thomas Krennwallner wrote:
  Basically, this boils down to the fact that people shouldn't have to read
  a manpage about a complex priority scheme in an equally-complex
  resolver. All I want is for aptitude to behave in a sane way by default.

 I think it's time to use apt-cudf. On a standard sid installation with
 gnome, it could perfectly resolve this situation:

  % apt-get -s --solver aspcud install sysvinit-core
 [keeps gnome]
 [...]
 Compare with apt-get without aspcud:
  % sudo apt-get -s install sysvinit-core
 [removes gnome]

 wow.

 I guess the usual too late for jessie applies, though, or?

Something strange is going on there. If I do the same on my system
which has its own GNOME meta packages currently, I get:

The following package was automatically installed and is no longer required:
  gnome-packagekit-data
Use 'apt-get autoremove' to remove it.
The following extra packages will be installed:
  acpi-fakekey acpi-support acpi-support-base acpid cgmanager ethtool
libcgmanager0 libck-connector0 libnih-dbus1 libnih1
libpam-ck-connector
  pm-utils systemd-shim
Suggested packages:
  radeontool consolekit
The following packages will be REMOVED:
  gnome-packagekit gnome-packagekit-session gnome-session-flashback systemd-sysv
The following NEW packages will be installed:
  acpi-fakekey acpi-support acpi-support-base acpid cgmanager ethtool
libcgmanager0 libck-connector0 libnih-dbus1 libnih1
libpam-ck-connector
  pm-utils systemd-shim sysvinit-core
0 upgraded, 14 newly installed, 4 to remove and 102 not upgraded.

Although none of gnome-packagekit gnome-packagekit-session
gnome-session-flashback need to be removed. I thus believe gnome gets
removed because it depends on gnome-packagekit which APT somehow
thinks it has to remove.
-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAEA6rAx2mTXoPm89h2sDZh1MG6web8RB=8zuz5icyioqnaj...@mail.gmail.com

Re: apt-get install sysvinit-core removes gnome?

[David Kalnischkies]

On Thu, Oct 16, 2014 at 01:20:54PM +0200, Matthias Urlichs wrote:
 Florian Lohoff:
  is it intentional that gnome is removed when systemd is replaced by 
  sysvinit-core?
 
 Please always retry this kind of thing with aptitude, and try to let it
 choose alternate resolutions to the dependency chains.
 
 Apitude, too, *really* likes to choose 500 deletions rather than upgrading
 even a single package to a version with slightly-lower priority (as defined
 in /etc/apt/pref*), but at least you can tell it to try harder. :-/

I shouldn't, I really shouldn't, but well, I bite…

This isn't trying harder, it is trying increasingly incorrect solutions
to the problem because aptitude assumes the users is not able to express
himself correctly. apt-get is treating its user as its god instead, aka:
user is always right, even if it makes no sense in apt's simple mind.

Selecting one package in an or-group is a grand example of people not
understand their tools although the policy is simple and logic: If it
isn't impossible to let it win, the first alternative wins. If the
package manager would go for any heuristic based on simplicity of
installation instead everyone would have lsb-invalid-mta as MTA because
that is damn easy to install by any standard. Maintainers are very
heavily relying on this property while e.g. building packages.

Beside that with every alternative you choose a non-default package for
you move further into here be dragons land so that should really not
be the first suggestion if it can be avoided.

A user who on the other hand already knows what he wants has a multitude
of options to express his needs/requirements, it is just a matter of how
to do it properly…


I shouldn't be the one advising against using any aptitude option,
because I have no experience with it, but I have enough dependency
resolver experience to be able to say that optimising along less removes
is very dangerous: Apart from the lsb-invalid-mta example mentioned
above, such a setting has no problem with removing essential packages
(remember, close to nothing has a positive dependency on it) and
aptitude not even has a scary warning for it. I think you should know
that before its removing dpkg on your next dist-upgrade (okay, it will
not be dpkg, too many positive dependencies for that for now).  So act
like the chosen configfile name suggests and read the manual, aptitude
has one and it documents these kind of things for a reason…

If that isn't enough motivation to read it already, let me tell you that
the suggested setting isn't even helping in the scenario you described
as you optimize for priority first…


In terms of the I don't want package X problem class its easiest to
simply tell the package manager that this is the case. Negative pins and
action modifiers on the commandline come to mind.

The don't be an idiot problem is a bit harder. I actually like apt-get
for being so simple minded as it means I can easily follow its thought
process. The problem with removes is that we tend to bundle a big bunch
of different cases into the same group ranging from these two packages
can no longer co-exist; choose wisely as you will loose functionality
all the way down to this is a transitional package nobody will miss.
If you have a clever idea how to solve this, I am all ears…


Moo,

David Kalnischkies


signature.asc
Description: Digital signature

Re: apt-get install sysvinit-core removes gnome?

[Matthias Urlichs]

Hi,

Martin Read:
 I got sick of remove half the planet being the first suggested option, so
 added a configuration fragment to /etc/apt/apt.conf.d that gets a behaviour
 I find more reasonable:
 
Ah. Thank you very much. I'll add that to my generic all my Debian stuff
should have this package.

IIRC I already filed a bug on Aptitude about this, but given that the thing
currently has 700+ open bugs …

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017075119.ga5...@smurf.noris.de

Re: Re: apt-get install sysvinit-core removes gnome?

[Jonathan de Boyne Pollard]

Dominik George:

There is no GNOME without systemd. This is not specific to Debian.


Florian Lohoff:

Because i - aehm - cant set an icon for my system via hostnamed or something?


As you've spotted, what M. George wrote is ambiguous and unspecific and liable 
to be further distorted.  This may help:

* 
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/debian-systemd-packaging-hoo-hah.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5441b377.2060...@ntlworld.com

apt-get install sysvinit-core removes gnome?

[Florian Lohoff]

Hi,

is it intentional that gnome is removed when systemd is replaced by 
sysvinit-core?
an

apt-get install sysvinit-core sysvinit-utils

on a fresh jessie removed most of the gnome desktop.

I dont want systemd and i'd like to remove as much of the blob as possible. I 
thought
systemd-shim + sysvinit-core/utils would be enough to make a usable system
but it seems there is some dependency in jessie which makes gnome unavailable
without systemd.

Am i wrong?

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Re: apt-get install sysvinit-core removes gnome?

[Dominik George]

Hi,

but it seems there is some dependency in jessie which makes gnome
unavailable
without systemd.

It is there because upstream requires it. There is no GNOME without systemd. 
This is not specific to Debian.

-nik


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/09e6843b-eb29-4082-8868-d9617b053...@naturalnet.de

Re: apt-get install sysvinit-core removes gnome?

[Emilio Pozuelo Monfort]

On 16/10/14 12:47, Dominik George wrote:
 Hi,
 
 but it seems there is some dependency in jessie which makes gnome
 unavailable
 without systemd.
 
 It is there because upstream requires it. There is no GNOME without systemd. 
 This is not specific to Debian.

No, that's wrong.

$ sudo aptitude install sysvinit-core
The following NEW packages will be installed:
  sysvinit-core 
0 packages upgraded, 1 newly installed, 0 to remove and 204 not upgraded.
Need to get 130 kB of archives. After unpacking 253 kB will be used.
The following packages have unmet dependencies:
 systemd-sysv : Conflicts: sysvinit-core but 2.88dsf-53.4 is to be installed.
Internal error: found 2 (choice - promotion) mappings for a single choice.
Internal error: found 2 (choice - promotion) mappings for a single choice.
The following actions will resolve these dependencies:

  Remove the following packages:
 
1)  aptdaemon   
 
2)  brasero 
 
3)  colord  
 
4)  gdm3
 
5)  gnome-control-center
 
6)  gnome-disk-utility  
 
7)  gnome-session   
 
8)  gnome-settings-daemon   
 
9)  gnome-shell 
 
10) gnome-shell-dbg 
 
11) gvfs
 
12) gvfs-backends   
 
13) gvfs-daemons
 
14) gvfs-dbg
 
15) gvfs-fuse   
 
16) hplip   
 
17) libpam-systemd  
 
18) nautilus
 
19) nautilus-sendto 
 
20) network-manager 
 
21) network-manager-gnome   
 
22) packagekit  
 
23) packagekit-tools
 
24) policykit-1 
 
25) policykit-1-gnome   
 
26) printer-driver-postscript-hp
 
27) steadyflow  
 
28) systemd-sysv
 
29) udisks2 
 

  Leave the following dependencies unresolved:  
 
30) python-aptdaemon recommends aptdaemon   
 
31) python3-aptdaemon recommends aptdaemon  
 
32) libcolord2 recommends colord
 
33) libcolord-gtk1 recommends colord
 
34) cups recommends colord  
 
35) cups-daemon recommends colord   
 
36) cups-filters recommends colord  
 
37) empathy recommends gvfs-backends
 
38) evince recommends gvfs  
 
39) file-roller recommends gvfs 
 
40) gnome-calculator recommends gvfs
 
41) gnome-control-center-data recommends gnome-control-center (= 
1:3.14.0-1)
42) gnome-media recommends gnome-control-center 
 
43) gnome-online-accounts recommends gnome-control-center (= 3.6.1)
 
44) gnome-session-bin recommends libpam-systemd 
 
45) gnome-shell recommends gnome-control-center 
 
46) gnome-system-monitor recommends gvfs
 
47) gnome-terminal recommends gvfs  
 
48) gvfs-common recommends gvfs  

Re: apt-get install sysvinit-core removes gnome?

[Florian Lohoff]

On Thu, Oct 16, 2014 at 12:47:41PM +0200, Dominik George wrote:
 Hi,
 
 but it seems there is some dependency in jessie which makes gnome
 unavailable
 without systemd.
 
 It is there because upstream requires it. There is no GNOME without systemd. 
 This is not specific to Debian.

*örgs* Because i - aehm - cant set an icon for my system via hostnamed or
something?

I still wait to wake up to let this bad dream of systemd go past me. This
can only be a bad dream ...

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Re: apt-get install sysvinit-core removes gnome?

[Matthias Urlichs]

Hi,

Florian Lohoff:
 is it intentional that gnome is removed when systemd is replaced by 
 sysvinit-core?

Please always retry this kind of thing with aptitude, and try to let it
choose alternate resolutions to the dependency chains.

Apitude, too, *really* likes to choose 500 deletions rather than upgrading
even a single package to a version with slightly-lower priority (as defined
in /etc/apt/pref*), but at least you can tell it to try harder. :-/

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016112053.ga17...@smurf.noris.de

Re: apt-get install sysvinit-core removes gnome?

[Martin Read]

On 16/10/14 12:20, Matthias Urlichs wrote:

Apitude, too, *really* likes to choose 500 deletions rather than upgrading
even a single package to a version with slightly-lower priority (as defined
in /etc/apt/pref*), but at least you can tell it to try harder. :-/


I got sick of remove half the planet being the first suggested option, 
so added a configuration fragment to /etc/apt/apt.conf.d that gets a 
behaviour I find more reasonable:


mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
Aptitude::ProblemResolver {
SolutionCost priority, removals, canceled-actions;
}
mormegil@cocytus:~$

(Yes, the choice of filename does reflect a certain amount of... 
*grouchiness* on my part regarding the default behaviour of the aptitude 
interactive dependency resolver. This is a home system; if I was writing 
this up as a general-purpose article I'd give it a less loaded name.)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ff3bd.1020...@zen.co.uk

Re: apt-get install sysvinit-core removes gnome?

[Bas Wijnen]

On Thu, Oct 16, 2014 at 05:35:09PM +0100, Martin Read wrote:
 mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
 Aptitude::ProblemResolver {
 SolutionCost priority, removals, canceled-actions;
 }

That looks very useful, thanks!
Bas


signature.asc
Description: Digital signature

Re: apt-get install sysvinit-core removes gnome?

[Svante Signell]

On Thu, 2014-10-16 at 20:36 +0200, Bas Wijnen wrote:
 On Thu, Oct 16, 2014 at 05:35:09PM +0100, Martin Read wrote:
  mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
  Aptitude::ProblemResolver {
  SolutionCost priority, removals, canceled-actions;
  }
 
 That looks very useful, thanks!

How to configure apt pinning? Just for the record (to be published
where?) (or does this apply to apt too, not only aptitude?)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413485223.27347.17.ca...@g3620.my.own.domain

Re: schroot, apt-get and experimental

[Peter Palfrader]

On Sat, 20 Sep 2014, Adam Majer wrote:

 There seems to be an issue with dd-schroot-cmd on porter boxes (I just
 checked barriere) where it seems impossible to actually use
 experimental distribution.
 
 For example,
 
 $ dd-schroot-cmd -c $ssession -- apt-get build-dep qtcreator -t experimental

From

  dd-schroot-cmd -c weaseltst -- apt-get install libqt5opengl5-dev/experimental

I eventually ended up at

  dd-schroot-cmd -c weaseltst -- apt-get install 
{libqt5opengl5-dev,libqt5opengl5,qtbase5-dev,libqt5concurrent5,libqt5core5a,libqt5dbus5,libqt5gui5,libqt5network5,libqt5printsupport5,libqt5sql5,libqt5test5,libqt5widgets5,libqt5xml5,qt5-qmake,qtbase5-dev-tools}/experimental

Which appears to have worked.

(If you don't like that, we can probably consider your patches to
 dd-schroot-cmd :)

Cheers,
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140921091441.gj8...@anguilla.noreply.org

Re: schroot, apt-get and experimental

[Adam Majer]

On Sun, Sep 21, 2014 at 11:14:41AM +0200, Peter Palfrader wrote:

   dd-schroot-cmd -c weaseltst -- apt-get install 
 libqt5opengl5-dev/experimental

OK, thank you.


 Which appears to have worked.
 
 (If you don't like that, we can probably consider your patches to
  dd-schroot-cmd :)

Is the source code only in /usr/local/bin on the schroot machines? Or
is there a better repository?

- Adam


-- 
Adam Majer
ad...@zombino.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140921151148.ga2...@mira.lan.galacticasoftware.com

Re: schroot, apt-get and experimental

[Julien Cristau]

On Sun, Sep 21, 2014 at 10:11:50 -0500, Adam Majer wrote:

 On Sun, Sep 21, 2014 at 11:14:41AM +0200, Peter Palfrader wrote:
  (If you don't like that, we can probably consider your patches to
   dd-schroot-cmd :)
 
 Is the source code only in /usr/local/bin on the schroot machines? Or
 is there a better repository?
 
There's
http://anonscm.debian.org/cgit/mirror/dsa-puppet.git/tree/modules/porterbox/files/dd-schroot-cmd

Cheers,
Julien


signature.asc
Description: Digital signature

schroot, apt-get and experimental

[Adam Majer]

Hello,

There seems to be an issue with dd-schroot-cmd on porter boxes (I just
checked barriere) where it seems impossible to actually use
experimental distribution.

For example,

$ dd-schroot-cmd -c $ssession -- apt-get build-dep qtcreator -t experimental

E: Build-Depends dependency for qtcreator cannot be satisfied because
candidate version of package libqt5opengl5-dev can't satisfy version
requirements

but,

$ schroot -r -c $ssession
$ apt-get --dry-run build-dep qtcreator -t experimental

finds all prerequisites. It seems that -t parameter is not passed in
the dd-schroot-cmd script.

Is there any way to actually use experimental distribution in schroot?

- Adam

-- 
Adam Majer
ad...@zombino.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140920210025.ga12...@mira.lan.galacticasoftware.com

Bug#743282: ITP: apt-get-snapshot -- Download a specific package version from snapshot.debian.org

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de

* Package name: apt-get-snapshot
  Version : 1.1
  Upstream Author : Leandro Lisboa Penz lp...@lpenz.org
* URL : https://github.com/lpenz/apt-get-snapshot
* License : BSD
  Programming Lang: Python
  Description : Download a specific package version from snapshot.debian.org

 apt-get-snapshot is a command-line tool that downloads a specific version of
 a debian package from snapshot.debian.org.
 .
 When using debian testing, it is not trivial to get the previous version of a
 package after it is upgraded. snapshot.debian.org is the source to go for these
 cases, but it has only a web interface. apt-get-snapshot navigates that web
 interface and fetches the desired package.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140401103829.17481.87143.report...@minobo.das-netzwerkteam.de

Re: Bug#743282: ITP: apt-get-snapshot -- Download a specific package version from snapshot.debian.org

[James McCoy]

On Apr 1, 2014 6:39 AM, Mike Gabriel mike.gabr...@das-netzwerkteam.de
wrote:
 * Package name: apt-get-snapshot
   Version : 1.1
   Upstream Author : Leandro Lisboa Penz lp...@lpenz.org
 * URL : https://github.com/lpenz/apt-get-snapshot
 * License : BSD
   Programming Lang: Python
   Description : Download a specific package version from
snapshot.debian.org

  apt-get-snapshot is a command-line tool that downloads a specific
version of
  a debian package from snapshot.debian.org.

This sounds a lot like the debsnap tool in the devscripts package.

Cheers,
James

Re: Bug#743282: ITP: apt-get-snapshot -- Download a specific package version from snapshot.debian.org

[Mike Gabriel]

Hi James, hi Arno,

On  Di 01 Apr 2014 13:07:47 CEST, James McCoy wrote:


On Apr 1, 2014 6:39 AM, Mike Gabriel mike.gabr...@das-netzwerkteam.de
wrote:

* Package name: apt-get-snapshot
  Version : 1.1
  Upstream Author : Leandro Lisboa Penz lp...@lpenz.org
* URL : https://github.com/lpenz/apt-get-snapshot
* License : BSD
  Programming Lang: Python
  Description : Download a specific package version from

snapshot.debian.org


 apt-get-snapshot is a command-line tool that downloads a specific

version of

 a debian package from snapshot.debian.org.


This sounds a lot like the debsnap tool in the devscripts package.


I was not aware of that tool. Sorry. Would have saved me some work...

Considering to request a REJECT for my already uploaded package.

Mike

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpeztYFYqjMo.pgp
Description: Digitale PGP-Signatur

Re: Bug#743282: ITP: apt-get-snapshot -- Download a specific package version from snapshot.debian.org

[Arno Töll]

Hi,

On 01.04.2014 12:38, Mike Gabriel wrote:
  When using debian testing, it is not trivial to get the previous version of a
  package after it is upgraded.  [..]

debsnap (in devscripts) is your friend.



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Bug#743282: ITP: apt-get-snapshot -- Download a specific package version from snapshot.debian.org

[Peter Palfrader]

Mike Gabriel schrieb am Dienstag, dem 01. April 2014:

  When using debian testing, it is not trivial to get the previous version of a
  package after it is upgraded. snapshot.debian.org is the source to go for 
 these
  cases, but it has only a web interface. apt-get-snapshot navigates that web
  interface and fetches the desired package.

Others already have pointed to debsnap.  This is just to state that
navigating the web interface is not the way to access snapshot
programatically.  There's an interface documented at [1] and linked
from the snapshot front-page.

Cheers,
weasel

1.  
http://anonscm.debian.org/gitweb/?p=mirror/snapshot.debian.org.git;a=blob_plain;f=API
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140401113344.gw1...@anguilla.noreply.org

Idea for apt-get : getting source code instead getting binaries

[Solal Rastier]

Hello! I've an idea for a new apt-get package style :

Developer side :
-The developer create a ./install script in the source code.
-The install script executes all commands necessary for install the software. 
Also, it getting dependancies, etc.
-The developer create a tarball (.tar.bzip2) and rename the file name. Instead 
of software.tar.bzip2 , that's software.deb
-The developer distribute the software.deb

Apt-get side :
-The apt-get tool download software.deb from the Debian repository.
-The program is installed with dpkg

Dpkg side :
-dpkg rename the software.deb software.tar.bzip2
-tar uncompress the software.tar.bzip2
-cd go into the software folder
-./install execute install script

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/77f6194c-04df-4e3d-ad74-2a3f55520...@me.com

Re: Idea for apt-get : getting source code instead getting binaries

[Liang Suilong]

There is a tool named as apt-build. It should be satisfied for your need.

Sent From My Heart
My Page: http://www.liangsuilong.info



On Thu, Mar 6, 2014 at 11:33 PM, Solal Rastier solal.rast...@me.com wrote:

 Hello! I've an idea for a new apt-get package style :

 Developer side :
 -The developer create a ./install script in the source code.
 -The install script executes all commands necessary for install the
 software. Also, it getting dependancies, etc.
 -The developer create a tarball (.tar.bzip2) and rename the file name.
 Instead of software.tar.bzip2 , that's software.deb
 -The developer distribute the software.deb

 Apt-get side :
 -The apt-get tool download software.deb from the Debian repository.
 -The program is installed with dpkg

 Dpkg side :
 -dpkg rename the software.deb software.tar.bzip2
 -tar uncompress the software.tar.bzip2
 -cd go into the software folder
 -./install execute install script

 --
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 https://lists.debian.org/77f6194c-04df-4e3d-ad74-2a3f55520...@me.com

Re: Idea for apt-get : getting source code instead getting binaries

[Matt Zagrabelny]

On Thu, Mar 6, 2014 at 9:33 AM, Solal Rastier solal.rast...@me.com wrote:
 Hello! I've an idea for a new apt-get package style :

 Developer side :
 -The developer create a ./install script in the source code.
 -The install script executes all commands necessary for install the software. 
 Also, it getting dependancies, etc.
 -The developer create a tarball (.tar.bzip2) and rename the file name. 
 Instead of software.tar.bzip2 , that's software.deb
 -The developer distribute the software.deb

 Apt-get side :
 -The apt-get tool download software.deb from the Debian repository.
 -The program is installed with dpkg

 Dpkg side :
 -dpkg rename the software.deb software.tar.bzip2
 -tar uncompress the software.tar.bzip2
 -cd go into the software folder
 -./install execute install script

Maybe I'm missing something:

apt-get source foo
apt-get build-dep foo

Do those commands do what you are needing?

-m


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caolfk3x-kesuqo+ozbeuu5ddbng9fxgaw1az5dadgo4vb9j...@mail.gmail.com

Re: Idea for apt-get : getting source code instead getting binaries

[Paul Tagliamonte]

On Thu, Mar 06, 2014 at 04:33:50PM +0100, Solal Rastier wrote:
 Hello! I've an idea for a new apt-get package style :
 
 Developer side :
 -The developer create a ./install script in the source code.
 -The install script executes all commands necessary for install the software. 
 Also, it getting dependancies, etc.
 -The developer create a tarball (.tar.bzip2) and rename the file name. 
 Instead of software.tar.bzip2 , that's software.deb
 -The developer distribute the software.deb
 
 Apt-get side :
 -The apt-get tool download software.deb from the Debian repository.
 -The program is installed with dpkg
 
 Dpkg side :
 -dpkg rename the software.deb software.tar.bzip2
 -tar uncompress the software.tar.bzip2
 -cd go into the software folder
 -./install execute install script

Script to do this attached; can I have my GSoC money now? :)

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte paul...@debian.org  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt
#!/bin/bash

PACKAGE=$1
WORKDIR=$(mktemp -d)
pushd ${WORKDIR} /dev/null

apt-get build-dep ${PACKAGE}
apt-get source --build ${PACKAGE}
dpkg -i *deb


popd ${WORKDIR} /dev/null


signature.asc
Description: Digital signature

Re: Idea for apt-get : getting source code instead getting binaries

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/06/2014 05:01 PM, Paul Tagliamonte wrote:
 Script to do this attached; can I have my GSoC money now? :)

Comic Book Guy: I'm interested in upgrading my 28.8k modem to a
fibre-optic T1 line. Will you be able to provide
an interface which is compatible with my Token
Ring network setup?

Homer: Can I have some money now?

On a more serious side note, I think OP's point was to promote a package
format where the upstream developer already does all the work and create
a Debian package on the fly which could simply be dropped into the
archives ready to install. Even when the package wasn't in Debian in
the first place, which is the main assumption of your script, Paule.

However, this shifts the responsibility for the QA of a package from
Debian towards upstream which will probably end in fear and loathing
in the archives in no time.

Turning an upstream source into a working Debian package isn't really
time-consuming and difficult for most cases. However, creating a well-
maintainable and (lintian-)clean package into Debian isn't and takes
lots of care and attention by a dedicated Debian Maintainer which knows
the in and outs of Debian, its Policy and its powerful tools.

Cheers,

Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTGLdLAAoJEHQmOzf1tfkT6xAQAK3tirD60pLctFdDXwWaWguz
6q86WCxMCJzB8Lsui7UcV2Ert2+Sm6YGQlZrMKUzydor9p1Z42091OfXgHWArdY8
/0afJ2YTGEJxBtPxncCH2WlwcA7c5wCEJdPPdEemxMgiQDD3MeNH5bp4bEJreN73
T37ug61urFhM1alWsjLOC2dMHbuaTHLNSHaETKwRAHOxJ4MIt4JwQLyPgJtlLw7V
2jsOxTG/ebKjlg/EHUZsbwyMWZnkzjC5RAIcM5UY5l5J4XGYKlUBZrxhTqacT/M8
0vSPGr7/5Ky3SBvPUuw9x09oEDK3I2MNrWNiH8wAP3c8duv9ue9iEviTBWR+q+/Z
mkbzwA3PvI5MJacUX4ISDDhzLgzUpDfghC6s1USNEqU0Iy4ABsDgIg9OrPyqmZfJ
68grddbbog/LocueyIoQPrRChpqvYGCgwiD4yxaW3QVcEGyxCmjVb4unamJ4RrAS
Onkz883hvdx6Nof13639hSW9sc9y9zYwEU0U0I/4/CxHcPHY80yOUIPrKxfMZoin
rfAoRxkuz3YBg2Hqt2uIbFKbn3a86IGuZuq81NmWPY2F+VuzOn8fboOFghUwCgqd
RRFSBqg0aydA6H1B1TdVOerwx3giiRq2nGZOkg4denCXP7rYlZ0BrPFqQDwaHzRN
u+pu2jAQq290TyzVnFsT
=5IBC
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5318b751.4010...@physik.fu-berlin.de

Re: Idea for apt-get : getting source code instead getting binaries

[Paul Tagliamonte]

On Thu, Mar 06, 2014 at 06:58:41PM +0100, John Paul Adrian Glaubitz wrote:
 On 03/06/2014 05:01 PM, Paul Tagliamonte wrote:
  Script to do this attached; can I have my GSoC money now? :)
 
 Homer: Can I have some money now?

BTW; just for context, I thought this message was to a soc-coordination
list (and idling making a joke, I didn't intend to slander our student's
work, they do great stuff, and I respect the crap out of everyone that
works in GSoC).

 On a more serious side note, I think OP's point was to promote a package
 format where the upstream developer already does all the work and create
 a Debian package on the fly which could simply be dropped into the
 archives ready to install. Even when the package wasn't in Debian in
 the first place, which is the main assumption of your script, Paule.

Yeah, well, I was just showing that this is feasible with a properly
defined source package in the archive, even without any built debs. This
script was just snark (and has two big bugs, at least)

 However, this shifts the responsibility for the QA of a package from
 Debian towards upstream which will probably end in fear and loathing
 in the archives in no time.

Yep.

 Turning an upstream source into a working Debian package isn't really
 time-consuming and difficult for most cases. However, creating a well-
 maintainable and (lintian-)clean package into Debian isn't and takes
 lots of care and attention by a dedicated Debian Maintainer which knows
 the in and outs of Debian, its Policy and its powerful tools.

The proposed idea was basically as much effort as properly debianizing
the package.

 Cheers,
 
 Adrian
 
 - -- 
  .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Much love,
  Paul

-- 
 .''`.  Paul Tagliamonte paul...@debian.org  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature