Re: Bug#741930: reportbug: add current init system information

[Sandro Tosi]

Hello,

On Wed, Nov 5, 2014 at 1:09 AM, Cameron Norman  wrote:
> A few notes I have:
>
> 1. With Jessie and on, with sysvinit /sbin/init //will// be a link,
> not the true init file. This would lead to unknowns when the init was
> actually sysv.

care to explain a bit better? I just upgraded a Wheezy VM to testing
and (except some issues) once I replaced systemd with sysvinit-core
/sbin/init *is* a regular file:

morph@debian:~$ dpkg -l sysvinit-core | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  sysvinit-core  2.88dsf-53.4 amd64System-V-like init utilities
morph@debian:~$ dpkg -S /sbin/init
sysvinit-core: /sbin/init
morph@debian:~$ file /sbin/init
/sbin/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=0b29c65c4ae879649971cfd1d469ca03421714ff, stripped

> 2. With Upstart, /sbin/init is not a link, so that third test would
> give a false positive for sysvinit when it was actually Upstart
> (assuming the Upstart check gave a false negative).

it should not be a false negative, do you have a situation in mind
where it might happen?

> 3. Maybe you should embed the check for Upstart, so that you do not
> have to source all of the init functions, and if that file is ever not
> available you still get the correct check.

lsb init functions are part of lsb-base, a required package

> 4. There is a tiny typo in the Upstart check. It needs an extra right
> parenthese at the end of the message.

I know I know, I should have probably followed up as i noticed 10
seconds after having sent the email and a lot of people pointed it out
(more of the people actually running the script and report back the
results to me :( ).

Cheers
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
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/CAB4XWXzYW9+WeiUaVVTM8C3zr7MONEb6qMOBSr7+O1C2=4f...@mail.gmail.com

Re: [Bug-wget] certificate revocation lists (CRLs) #43501

[Noël Köthe]

Hello Debian,;)

wget developers are working on CRL support and raised the following
questions which somebody of you guys have a better answer:

Am Mittwoch, den 05.11.2014, 12:48 +0100 schrieb Tim Ruehsen:

> BTW, does Debian meanwhile has a CRL infrastructure (something like 
> /etc/ssl/certs/) or is planning something like it ?

I'm aware of fetch-crl
https://packages.debian.org/unstable/main/fetch-crl but maybe there is
more anything planed like CRL support for the ca-certificates package?


Thx.

Regards

Noël

-- 
Noël Köthe 
Debian GNU/Linux, www.debian.org


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

Bug#768156: general: dpkg frontend inconsistent

[Michal Suchanek]

Package: general
Severity: minor

Hello,

I was upgrading my system and several times I was asked for installing a
new configuration file. Sometimes the question is posed in teletype
style frontend sometimes in colour character terminal TUI style
frontend.

Can't this be consistent?

I don't remember ever configurin the frontend to use but whatever is the
default there should be only one default.

Thanks

Michal


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (910, 'testing'), (900, 'stable'), (410, 'unstable'), (400, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.15-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
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/20141105135246.20550.84750.report...@optiplex960.ruk.cuni.cz

Re: Punctuation characters in Debian packaging

[Elmar Heeb]

> On 04 Nov 2014, at 18:38, Ian Jackson  wrote:
> 
> The Wanderer writes ("Re: Punctuation characters in Debian packaging"):
>> On 11/04/2014 at 12:12 PM, Ian Jackson wrote:
>>> apt-get seems to prefer actual package names to ones resulting from 
>>> stripping `+' (which is also IMO a bug).
>> 
>> Can you explain why this would be considered a bug? It seems to produce
>> the desired behavior in every case I've been able to think of so far.
> 
> apt's interpretation of ordinary command lines should not depend on
> the (non-)existence of particular packages.
> 
> If it does, then it is not possible to reliably unparse the command
> line.

In the current collection of packages we have wmweather and wmweather+ as an
example, both available in oldstable through unstable.

Moreover, there could be any number of package names being used in local
repositories maintained within organisations.  If they are not careful they
might trip over this issue.

As the author and maintainer of aptitude-robot I rely on the feature (of
aptitude in this particular case) to be able to add a plus, minus, or a few
other supported character combination.  However, I do not care what the
characters are as I am passing them through as is.

There are a few considerations that I care about:

* I fully support that the interpretation of command lines should not depend
 on the (non-)existence of particular packages

* I do not particularly care which way the ambiguity is resolved.  Either
 some characters are banned from appearing at the end of package names
 (this would affect quite a few packages) or the modifiers supported are
 changed (with probably fewer affected packages).

* If the modifiers are changed then apt and aptitude should support the
 same characters as long as the semantics is the same and use different
 characters when the semantics is different.

* This change should preferably be well coordinated.  The freeze period
 for jessie seems a risky time to “fix” this.  There are probably quite
 a few scripts around that rely on these modifiers (scripts more so than
 command line habbits...).

Just my two cents — Elmar



--
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/f8860da8-a8db-4562-8370-42cc003b6...@heebs.ch

Re: inconsistent versions of M-A: same packages

[Holger Levsen]

Hi,

indeed I forgot about multiarch... and I ment that non-installibility is a bug 
for sure (though just a sympton of the real bug), but often packages can still 
be installed even though the versions of a package differs due to binNMUs. 
Andway - more to the point:

(leaving full context for the benefit of Ralf whom I added to cc:ed..)

On Samstag, 1. November 2014, Wookey wrote:
> +++ Marc Glisse [2014-11-01 11:45 +0100]:
> > sorry for the naive question, but is there a plan for massively
> > rebuilding all "Multi-Arch: same" packages that have inconsistent
> > version numbers across architectures before releasing Jessie?
> I don't know, but I think there should be. Thank you for bringing this
> up. As you say, currently this is the only way to make multiarch
> co-installability work properly.

Ralf, does DOSE already detect such inconsistencies or how hard would it be to 
add support for that?

(also, btw, I couldn't find the daily DOSE runs linked from 
tttps://qa.debian.org/dose - did I miss it or is it missing?)

> I am happy to spend some time scheduling rebuilds to resync all arches
> to whichever number is highest. This problem will have been made worse
> by the late-in-the-cycle additions of arm64 and mips64el (despite some
> effort being made to avoid library binNMUs when there was a choice,
> specifically to minimise the size of this issue) so it's only fair
> that us porters take the time to fix it up.
> 
> The problem evaporates when new source versions are uploaded, and I
> expect there will be a fair amount more of that before release time
> due to bugfixes. So I expect the release team have an opinion about
> the most appropriate time for deciding that some 'version sync only'
> rebuilds should be scheduled to fix remaining library-version mismatches.
> 
> It is currently a feature of our bootstrap/import process that we do
> binNMUs of packages (to rebuild packages originally imported from
> debian-ports to break cyclic dependency loops on the 'kosher' buildds,
> or to rebuild profile-built bootstrap packages). And some of these
> imports have to be library packages, so this issue inevitably
> arises. Before multiarch this didn't actually matter. They are also
> heavily used for library transitions where arches have different sets
> of packages built against an old library (and thus need rebuilding to
> get rid of the old version).
> 
> Changes to the system such as a mechanism for rebuilds that didn't
> change the version number, or changes to dpkg to consider binary
> rebuilds 'multiarch equivalent' would solve this in a more systematic
> way.

I agree that a systematic fix is in order, I just wonder whether it's more 
reasonable to defer that for jessie+1...


cheers,
Holger


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

Re: [Bug-wget] certificate revocation lists (CRLs) #43501

[Michael Shuler]

On 11/05/2014 06:51 AM, Noël Köthe wrote:

Hello Debian,;)

wget developers are working on CRL support and raised the following
questions which somebody of you guys have a better answer:

Am Mittwoch, den 05.11.2014, 12:48 +0100 schrieb Tim Ruehsen:


BTW, does Debian meanwhile has a CRL infrastructure (something like
/etc/ssl/certs/) or is planning something like it ?


I'm aware of fetch-crl
https://packages.debian.org/unstable/main/fetch-crl but maybe there is
more anything planed like CRL support for the ca-certificates package?


Patches welcomed!  :)

--
Kind regards
Michael


--
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/545a5108.1070...@pbandjelly.org

Bug#768156: general: dpkg frontend inconsistent

[Holger Levsen]

Hi Michal,

On Mittwoch, 5. November 2014, Michal Suchanek wrote:
> I was upgrading my system and several times I was asked for installing a
> new configuration file. Sometimes the question is posed in teletype
> style frontend sometimes in colour character terminal TUI style
> frontend.

which tool did you use (how) to upgrade?


cheers,
Holger


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

Bug#768169: ITP: sfarklib -- Library for decompressing sfArk soundfonts

[Ruben Undheim]

Package: wnpp
Severity: wishlist
Owner: Ruben Undheim 

* Package name: sfarklib
  Version : 0.20131219gitee08d0c
  Upstream Author : Andy Inman
* URL : http://melodymachine.com/sfark-linux-mac
* License : GPL-3
  Programming Lang: C++
  Description : Library for decompressing sfArk soundfonts

sfArk is a lossless audio compression format optimized for SoundFont files.
This library can decompress such files into .sf SoundFont files.

I intend to maintain it as part of the Debian Science team.


-- 
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/20141105164354.12096.21351.report...@miniserver.beebeetle.com

Bug#768173: ITP: sfarkxtc -- Converts soundfonts in the legacy sfArk v2 file format to sf2

[Ruben Undheim]

Package: wnpp
Severity: wishlist
Owner: Ruben Undheim 

* Package name: sfarkxtc
  Version : 0.20130812git80b1da3
  Upstream Author : Andy Inman
* URL : http://melodymachine.com/sfark-linux-mac
* License : GPL-3
  Programming Lang: C++
  Description : Converts soundfonts in the legacy sfArk v2 file format to 
sf2

This is a very small command line tool to convert legacy sfArk files
into the SoundFont 2 format. It uses the library sfarklib.

I intend to maintain it as part of the Debian Science team.


-- 
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/20141105164756.12162.60711.report...@miniserver.beebeetle.com

Re: inconsistent versions of M-A: same packages

[Ralf Treinen]

Hi,

On Wed, Nov 05, 2014 at 04:22:06PM +0100, Holger Levsen wrote:

> (also, btw, I couldn't find the daily DOSE runs linked from 
> tttps://qa.debian.org/dose - did I miss it or is it missing?)

yes, you did miss something :-) 

first link on the page: "Non-installable packages"

then you choose among the scenarios you are interested in, like
"unstable:main only" leads you to 

https://qa.debian.org/dose/debcheck/unstable_main/index.html

> On Samstag, 1. November 2014, Wookey wrote:
> > +++ Marc Glisse [2014-11-01 11:45 +0100]:
> > > sorry for the naive question, but is there a plan for massively
> > > rebuilding all "Multi-Arch: same" packages that have inconsistent
> > > version numbers across architectures before releasing Jessie?
> > I don't know, but I think there should be. Thank you for bringing this
> > up. As you say, currently this is the only way to make multiarch
> > co-installability work properly.
> 
> Ralf, does DOSE already detect such inconsistencies or how hard would it be
> to add support for that?

I am not sure what precisely is needed here :

1) if it is about detecting M-A=same packages with different version numbers
across different architectures : we currently do not detect this. The dose
library could be use to parse the different Packages files and then detect
these case, but IMHO this would be an overkill. A simple perl/python script
would do the job, or possibly an integration into (not-dose)-debcheck.

2) if you ask about co-installablity of packages with the same name but
different architectictures (and which are M-A=same) : this is a completely
different (and much more interesting) question. Since dose is now 
multi-arch aware we can do this, but there are some questions to discuss
about the precise scenario. Is this what you meant ?

-Ralf.


-- 
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/20141105171217.ga7...@seneca.home.org

Bug#768156: general: dpkg frontend inconsistent

[Julien Cristau]

On Wed, Nov  5, 2014 at 17:53:50 +0100, Holger Levsen wrote:

> Hi Michal,
> 
> On Mittwoch, 5. November 2014, Michal Suchanek wrote:
> > I was upgrading my system and several times I was asked for installing a
> > new configuration file. Sometimes the question is posed in teletype
> > style frontend sometimes in colour character terminal TUI style
> > frontend.
> 
> which tool did you use (how) to upgrade?
> 
Pretty sure this is ucf vs dpkg's conffile prompt.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#768156: general: dpkg frontend inconsistent

[Matt Wheeler]

Hi Holger,

On 5 Nov 2014 16:53, "Holger Levsen"  wrote:
> which tool did you use (how) to upgrade?

I also experienced this when upgrading a system from squeeze to wheezy a
few days ago. I followed the upgrade instructions in wheezy's release
notes, i.e. using apt-get.

I'll have a look through the logs to see if I can spot a pattern.

Thanks

--
Matt Wheeler
http://funkyh.at

Re: Packages using old dpkg tools paths

[Guillem Jover]

Hi!

On Mon, 2014-11-03 at 22:20:48 +0100, Niels Thykier wrote:
> On 2014-11-03 11:23, Guillem Jover wrote:
> > I'm planning on starting to file bug reports for the source packages
> > below (BCCed). I've not checked (yet) how severe the dpkg-statoverride
> > ones are, but if most of them do not get fixed, I might consider
> > reintroducing the compat symlink for that one alone if the release-team
> > (CCed) sees fit to that. :/
> 
> Could you please re-instate all the compat symlinks for Jessie?  Besides
> the package listed, we are also concerned about the upgrade path from
> Wheezy.

I just did a bit more digging, and the compat symlinks have been
present since dpkg 1.15.0 (squeeze). I removed them in 1.17.0 because
the lintian check (which I've found now :), reported no more callers:



but it seems that is not exhaustive. So we cannot really know how many
packages where affected in wheezy, w/o a full archive scan. :( At least
now we have an exhaustive list, which I could make dpkg Breaks/Conflicts
with in 1.18.x.

So, yes, given the above, I'll reinstate the compat symlinks for dpkg
1.17.22. It would be nice though, if as many of the fixes for the
remaining callers could be accepted for jessie, if possible?

Thanks,
Guillem


-- 
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/20141105202105.ga31...@gaara.hadrons.org

Bug#768200: ITP: annex -- anime themed real time strategy game

[Markus Koschany]

Package: wnpp
Severity: wishlist
Owner: Markus Koschany 

* Package name: annex
  Version : 4.0
  Upstream Author : Adrian Delpha
* URL : http://annexconquer.com
* License : CC-BY-SA-3.0
  Programming Lang: none
  Description : anime themed, futuristic real time strategy game

Annex: Conquer the World is an anime themed, futuristic, real time
strategy game that brings fast paced combat with a diverse arsenal.
Play as one of four factions: The East Ocean Alliance, the NEO
Republic, the Shadow Organization or the Renegades as they struggle
for dominance all over the world, competing for a priceless red
mineral. The game now contains 4 factions, over 30 tech trees,
original maps and tilesets and focuses on multiplayer and single
player skirmishes.

The game is built using the MegaGlest RTS game engine. This package
contains all necessary game data for playing Annex.

I intend to maintain this package as part of the Debian Games Team
which will depend on Debian's unmodified MegaGlest engine in the future.


-- 
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/20141105223512.8897.30877.reportbug@conan

Re: Packages using old dpkg tools paths

[Julien Cristau]

On Wed, Nov  5, 2014 at 21:21:05 +0100, Guillem Jover wrote:

> So, yes, given the above, I'll reinstate the compat symlinks for dpkg
> 1.17.22. It would be nice though, if as many of the fixes for the
> remaining callers could be accepted for jessie, if possible?
> 
The cost of keeping symlinks around for one more release doesn't seem
all that big?

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#768248: ITP: gnome-shell-extension-redshift -- gnome shell extension for controlling redshift

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: gnome-shell-extension-redshift
  Version : 8a57273af00f413afd47d2b31d2cd50c6f8d8b6d
  Upstream Author : Thomas Liebetraut 
* URL : https://github.com/tommie-lie/gnome-shell-extension-redshift
* License : GPLv3
  Programming Lang: Javascript
  Description : redshift extension for GNOME Shell

redshift integration for GNOME Shell.


-- 
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/20141106034823.22871.95434.report...@gambit.kuroneko.ca