retitle 616131 ITA: lsb -- Linux Standard Base 4.0 support package
owner 616131 !
Hi all,
(tl;dr Git repository with actual state is available, please help :->)
I just noticed the worrying state of the LSB package in Debian:
* Still in version 3.2 (released in January 2008) while 4.1 is out
tags 604360 +patch
thanks
Hi Eckhart, and thanks for your bugreport,
Le 21.11.2010 20:42, Eckhart Wörner a écrit :
> In order to make this move, all packages directly or indirectly depending on
> the KDE3/Qt3 libraries have to either get ported to KDE4/Qt4 or eventually
> get
> removed from th
Le 27.02.2012 21:14, Thorsten Glaser a écrit :
> This still results in:
>
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux 1.0 (n/a)
> Release:1.0
> Codename: n/a
>
> The most important thing is probably the Codename (always sid, as
> debia
tags 637039 +unreproducible +moreinfo
thanks
Hi Luke, and thanks for your bugreport,
Le 08.08.2011 04:45, Luke Kenneth Casson Leighton a écrit :
> On Mon, Aug 8, 2011 at 1:33 AM, lkcl wrote:
>> Package: lsb-release
>> Version: 3.2-27
>> Severity: normal
>> Tags: patch
>>
>> ok it's not exactly a
tags 604360 -patch +wontfix
thanks
Le 23.02.2012 18:54, Jeff Licquia a écrit :
> On 02/23/2012 09:31 AM, Didier 'OdyX' Raboud wrote:
>> Given that LSB has deprecated the use of Qt3 libraries since its 3.2
>> version, I propose to demote the relationship on libqt3-mt from
tags 642076 +patch
thanks
Le 23.01.2012 21:44, Sven Joachim a écrit :
> On 2011-09-19 11:15 +0200, Colin Watson wrote:
>>
>> Nothing ever created /lib/ld-lsb-x86-64.so.[23] symlinks in the first
>> place, so as far as I can see there's no need to clean them up; the
>> problem was that the symlink
tags 403120 +wontfix
thanks
Hi Steffen, and thanks for your bugreport,
Le 14.12.2006 21:31, Steffen Joeris a écrit :
> Yesterday I saw a package which uses the shell functions provided by
> lsb-base but did not have a dependency against it and I came across this
> topic.
That's a bug.
> Current
Hi again,
Le 02.03.2012 13:18, Didier 'OdyX' Raboud a écrit :
> Hi Colin and Sven, and thanks for your input on this bug;
>
> I propose the attached patch to get this fixed by removing the symlinks
> farm handling and replacing all symlinks by `solid` symlinks in the
>
Hi Steve, and thanks for your bugreport,
Le 24.02.2012 10:05, Steve Langasek a écrit :
> Please find attached a patch for lsb that adds a new helper function to
> /lib/lsb/init-functions to support maintainer scripts that should behave as
> no-ops because the package is upstart-aware and upstart i
tags 565631 +patch
thanks
Le 17.01.2010 15:58, Thomas Koch a écrit :
> Package: lsb-base
> Version: 3.2-23
> Severity: normal
>
> status_of_proc is not documented. You may want to provide documentation
> in /usr/share/doc/lsb-base/README.Debian
Hi Thomas, and thanks for your bugreport,
I propos
tags 653598 +pending +patch
thanks
Hi Peter, and thanks for your bugreport, and patch
Le 29.12.2011 19:15, Peter Eisentraut a écrit :
> When a pid file is specified to status_of_proc with the -p option, but
> it's not readable, then status_of_proc returns 3 (not running) instead
> of 4 (unknown).
Le 07.03.2012 11:37, Didier 'OdyX' Raboud a écrit :
> Agreed. I committed the attached patch, attributed to you (as it's not
> 100% the same patch, but equal in functionality and essence).
Meh, failed at attaching.
From 1a02293da50c624a01c61c6fd4e956215726994a Mon Sep 17 00:0
tags 660790 +wontfix
thanks
Hi Luca, and thanks for your bugreport,
Le 21.02.2012 22:42, Luca Capello a écrit :
>
> As you can see, the leading space is not respected. I think this is
> because log_warning_msg calls log_begin_msg, which actually uses
> `/bin/echo -n "$@"` instead of adding a lea
tags 650584 +patch
thanks
Le 30.11.2011 23:37, Daniel Nelson a écrit :
> The killproc function called without a signal does not wait for the
> process to end as required by the lsb specification, and never sends
> SIGKILL if the process does not end.
>
> I believe this was introduced with the fix
tags 644285 +moreinfo
thanks
Hi Mats, and thanks for your bugreport,
Le 04.10.2011 21:36, Mats Erik Andersson a écrit :
> At a previous time the functions in 'init-functions'
> were allowed to use
>
>/bin/echo -e
>
> whereas presently they are all forced into using
>
> /bin/echo -n
>
>
tags 479295 +wontfix +help
tags 450652 +wontfix +help
thanks
Le 08.11.2007 21:22, Marc Haber, in #450652, a écrit :
> to start a daemon that does not write its pidfile itself, it might be
> needed to pass the --background and/or --make-pidfile to
> start-stop-daemon. Ths lsb-base function should o
tags 338556 +unreproducible +moreinfo
thanks
Le 11.11.2005 01:46, Ian Zimmerman a écrit :
> Now that they use the functions in /lib/lsb/init-functions, the output from
> many
> initscripts now looks like this:
>
> Thu Nov 10 18:48:02 2005: .
> Thu Nov 10 18:48:02 2005: findfs: Unable to resolve
Hi -devel (and -lsb),
I have recently uploaded lsb-base 4.1+Debian0+fancy0 to experimental. As
this version introduces a small change that has a big visual impact on
the Debian boot, I would like to get some feedback on it before
uploading it to unstable.
In short, this version implements a new "
Hi Martin,
Le 11.04.2012 22:09, Martin Zobel-Helas a écrit :
> root@kvasir:/home/zobel# /etc/init.d/apache2 foobar
> [ ok ] Usage: /etc/init.d/apache2
> {start|stop|graceful-stop|restart|reload|force-reload|start-htcacheclean|stop-htcacheclean|status}.
> root@kvasir:/home/zobel#
>
> it that [ o
severity 668416 serious
tags 668416 +patch
thanks
Le 11.04.2012 19:59, Peter Eisentraut a écrit :
> Somewhere between versions 3.2+Debian31 and 4.1+Debian0, the exit
> status of the killproc function (/lib/lsb/init-functions) was changed
> to return 3 when the program is not running. This is only
tags 668958 +patch
thanks
Le 16.04.2012 03:48, Adrian Fita a écrit :
> Hi.
>
> I noticed that "/etc/init.d/hddtemp status" wasn't returning the correct
> status when the daemon was running. hddtemp daemon doesn't create a pidfile
> when started, so I tracked the problem back to the pidofproc func
tags 668958 +pending
thanks
Le 16.04.2012 11:07, Adrian Fita a écrit :
>> This patch (besides being reversed) makes all "pidofproc with
>> unspecified pidfile name" calls call /bin/pidof, which is undesired IMHO.
>>
>> I propose the attached patch, that only resorts to calling /bin/pidof
>> when t
tags 670144 +help
retitle 670144 fancy output sometimes broken by misbehaving initscripts
thanks
Le 23.04.2012 13:56, Michael Biebl a écrit :
> the new "fancy" output is nice. I've noticed a few services though,
> where it is broken, e.g. the udev or fsck init script. The output looks
> like this:
tags 661109 -moreinfo +pending
thanks
Le 01.05.2012 07:42, Steve Langasek a écrit :
> My opinion is that this is best done in the single /lib/lsb/init-functions
> file. The filename is an interface defined in the LSB, but there's nothing
> in the LSB that says this interface can't provide additio
Hi Colin, hi Matthias,
now that the Ubuntu Pangolin was released (congrats!), from what I
understand from the Ubuntu release process, it will very soon be the
"big merge" time. And the src:lsb package has diverged quite a lot
between the Debian and Ubuntu counterparts.
Now, while I tried my best
Le 02.05.2012 08:55, Steve Langasek a écrit :
> BTW, I'm sorry to say I've just noticed the patch I sent has a bug; the
> output of 'which initctl' should be suppressed, otherwise each init script
> using this function will output "/sbin/initctl" which we don't want.
>
> So the line should be:
>
Le 01.05.2012 15:12, Matthias Klose a écrit :
> On 01.05.2012 10:39, Didier 'OdyX' Raboud wrote:
>> So I am willing to put work where needed towards the goal of sharing a
>> single Debian source package. Where do you want to start from?
>>
>> (By the way, one
Hi Roger, and thanks for your (quick) feedback,
Le 18.05.2012 22:16, Roger Leigh a écrit :
> On Fri, May 18, 2012 at 10:00:12PM +0200, Didier Raboud wrote:
>> Le jeudi, 17 mai 2012 00.19:38, Stanislav Maslovski wrote :
>>> Evidently, if you decide to use /etc/default/rcS for this setting,
>>> this
Hi Mats,
Le 07.03.2012 14:25, Didier 'OdyX' Raboud a écrit :
> Le 04.10.2011 21:36, Mats Erik Andersson a écrit :
>> At a previous time the functions in 'init-functions'
>> were allowed to use
>>
>>/bin/echo -e
>>
>> whereas pr
Le 21.05.2012 12:18, Roger Leigh a écrit :
>> FANCYTTY=$([ -e /etc/default/rcS ] && . /etc/default/rcS && echo $FANCYTTY)
>
> I'm not sure why you need to do this BTW, none of the existing users
> do. If you want to avoid polluting your environment with settings
> you don't need, then it's fine,
Le 21.05.2012 13:47, Roger Leigh a écrit :
> I'm not sure what you mean here. Do you plan to keep the definition
> in two places (for backward compatibility?)? Which would be the
> "preferred" location, i.e. which would take priority over the other?
Given that /etc/lsb-base-logging.sh is a docum
tags 673207 +pending
thanks
Le 21.05.2012 14:07, Didier 'OdyX' Raboud a écrit :
> Hmm; now that I think of it, it would be possible to simply have
> /etc/default/rcS ship an empty (or even commented) FANCYTTY= definition
> and let /etc/lsb-base-logging.sh untouched: if an adm
Le 21.05.2012 15:07, Roger Leigh a écrit :
> On Mon, May 21, 2012 at 02:07:40PM +0200, Didier 'OdyX' Raboud wrote:
>> Hmm; now that I think of it, it would be possible to simply have
>> /etc/default/rcS ship an empty (or even commented) FANCYTTY= definition
>> a
severity 675162 serious
tags 675162 +patch +pending
thanks
Le 30.05.2012 11:50, Kamen Naydenov a écrit :
> Package: lsb-base
> Version: 4.1+Debian5
> Severity: normal
>
> Dear Maintainer,
>
> after lsb-base upgrade (Wed May 30 12:41:22 EEST 2012: [UPGRADE]
> lsb-base:amd64
> 4.1+Debian4 -> 4.1+
Le 30.05.2012 17:08, Stuart Anderson a écrit :
> On Wed, 30 May 2012, Jonathan Nieder wrote:
>>
>> There is not much time, but would anyone like to help revive it,
>> perhaps in an LSB 4 version?
>
> If anyone is interested in adoping this package, and the ones related to
> it, please get in touch
Le lundi, 18 juin 2012 16.35:36, vous avez écrit :
>
> Thank you very much. Removing the file did solve the problem.
>
> But tracing its roots, I get:
>
> rrs@champaran:~$ sudo dpkg -S /etc/lsb-base-logging.sh
> lsb-base: /etc/lsb-base-logging.sh
>
> Would you want to remove it or at least prom
Hi Phil,
First, many thanks for your detailed bugreport, that even proposes a patch;
that's highly appreciated!
Le mercredi, 13 juin 2012 23.13:45, vous avez écrit :
> Package: lsb-base
> Version: 3.2-23.2squeeze1
>
> The specific problem I'm experiencing is with /etc/init.d/portmap, which
> re
tags 678260 +moreinfo
thanks
Hi Thilo, and thanks for your bugreport,
Le mercredi, 20 juin 2012 13.15:46, vous avez écrit :
> the lsb fancy boot messages currently provided via
> '/lib/lsb/init-functions' and
> '/lib/lsb/init-functions.d/20-left-info-blocks' get mixed up.
> Attached is a 1:1 exer
Le jeudi, 21 juin 2012 16.13:47, vous avez écrit :
> > Has this appeared only with 4.1+Debian7 or was it there before ?
>
> Now that you ask i can not exactly tell when this started. I only noticed
> it lately when i had to install/remove some services for testing.
> Just for completeness after su
X-PTS-Approved: yes
reassign 678260 sysvinit-utils 2.88dfs-22.1
retitle 678260 startpar has a timeout value that lets boot messages get mixed
thanks
Hi Thilo, hi sysvinit maintainers,
Le jeudi, 21 juin 2012 17.17:35, Thilo Six a écrit :
>
> > Hmm. Weird; really. Does it still shuffle the boot m
tags 682963 +moreinfo
thanks
Le vendredi, 27 juillet 2012 14.13:33, Jonas Smedegaard a écrit :
> Package: lsb-printing
> Version: 4.1+Debian7
> Severity: normal
>
> ghostscript-cups is only generally usable together with cups.
>
> If intent of lsb-printing is to _ensure_ that related packages ar
Le jeudi, 19 juillet 2012 03.19:56, vous avez écrit :
> If upstart is installed but not running, init_is_upstart produces this
> error message:
>
> initctl: Unable to connect to Upstart: Failed to connect to socket
> /com/ubuntu/upstart: Connection refused
>
> I guess initctl version should redir
tags 683654 +moreinfo
thanks
Le jeudi, 2 août 2012 16.38:41, Teodor a écrit :
> In Debian the recommendation for all init scripts is to check the variable
> VERBOSE from /etc/default/rcS and only print a message on console only if
> this variable is not 0.
From the content of the debian-policy pa
Control: tags -1 +wontfix
Le dimanche, 4 novembre 2012 01.36:53, Jeff Licquia a écrit :
> The LSB spec for pidofproc is here:
>
> https://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-ge
> neric/iniscrptfunc.html
>
> It defines the command line arguments for pidofproc as your
Control: tags -1 -wontfix +pending
Le samedi, 10 novembre 2012 16.36:35, Jeff Licquia a écrit :
> I've attached a patch which will add some sanity checking to pidofproc's
> command-line argument parsing. With this patch, pidofproc will fail if
> it finds more than one non-dashed argument under an
Hi Arno,
Le dimanche, 11 novembre 2012 13.01:41, Arno Töll a écrit :
> "Relying" on that broken behavior essentially means to trigger a bug,
> e.g. see #691365. If there are more such false uses of pidofproc, they
> should really be fixed - even in Wheezy. That said, the Release Team
> recently ma
Control: severity -1 serious
Control: tags -1 +moreinfo
Hi Klaus, and thanks for your bugreport,
Le lundi, 19 novembre 2012 10.51:21, Klaus Ethgen a écrit :
> The last patch to fix #691422 will break init scripts of unrelated
> software like for example exim. Please roll it back. I set the severi
/init-functions wrongly:
Le lundi, 19 novembre 2012 11.50:02, Didier 'OdyX' Raboud a écrit :
> $ grep pidofproc /etc/init.d/exim4
> if pidofproc -p "$QRPIDFILE" >/dev/null; then
> if pidofproc -p "$PIDFILE" >/dev/null; then
pidofproc is documente
Control: retitle -1 pidofproc enforces the presence of pathname, thereby
breaking wrong uses of it
Control: severity -1 important
Control: tag -1 +wontfix
Hi Klaus,
as you might have seen, I have cloned this bug against exim4-base as the use
of pidofproc there is incorrect. That's where it shoul
Control: notfound -1 lsb-base
Control: found -1 plymouth/0.8.5.1-6
Le vendredi, 16 novembre 2012 23.27:46, Adrian Fita a écrit :
> I tried replacing the *pre hooks with *post hooks in the
> /lib/lsb/init-functions.d/99-plymouth file and it seems to be working. I
> haven't experienced any obvious s
Control: severity -1 normal
Control: reassign -1 src:lsb
Control: merge 673586 -1
Control: retitle 673586 FTBFS if Python 3.2 is installed in chroot
Le samedi, 2 février 2013 08.12:49, peter green a écrit :
> Attempting to build lsb in a wheezy amd64 chroot I get
>
> PYTHONPATH=. python3.2 test/t
Control: tags -1 +confirmed
Hi Raphaël, and thanks for your bugreport,
Le vendredi, 22 mars 2013 09.11:20, Raphaël Hertzog a écrit :
> A Debian derivative is advised to fork base-files and to update the
> information there so that it can be properly distinguished from Debian.
> That's what we did
Hi all,
Le vendredi, 5 avril 2013 15.02:39, Julien Cristau a écrit :
> cc:ing the lsb maintainer
Thanks for the explicit CC.
> On Sun, Mar 31, 2013 at 01:22:59 -0700, Jonathan Nieder wrote:
> > If I understand the lsb packaging correctly, Debian aims at support
> > for LSB 4.1 these days instead
Hi Steve,
thanks for your two bugreports.
Le mercredi, 15 mai 2013 10.03:38, Steve Langasek a écrit :
> As Ubuntu uses python3, not python2, in its base system, we are building
> lsb against python3. So this patch will be included in Ubuntu shortly.
Does this imply Ubuntu will use Debian's lsb
Hi Steve,
Le mercredi, 15 mai 2013 21.46:39, Steve Langasek a écrit :
> Well, this was the first time the lsb package has been merged into Ubuntu
> from Debian in about four years; so there's still a delta, which we can try
> to clean up (that's always the goal) - but at this point it's too early
Control: tags -1 +moreinfo
Hi varacanero, and thanks for your bugreport,
Le mercredi, 19 décembre 2012 18.20:27, varacanero a écrit :
> Subject: lsb-release: release/codename depend on a successful apt-get
> update Package: lsb-release
> Version: 4.1+Debian8
> Severity: normal
>
> If an apt-get
Hi again Steve,
Le dimanche, 19 mai 2013 03.44:04, Steve Langasek a écrit :
> On Wed, May 15, 2013 at 11:31:03PM +0200, Didier 'OdyX' Raboud wrote:
> > I feel compelled to point out here that this is not how I understand
> > collab- maint is supposed to work. That sa
Control: severity -1 minor
Control: merge 683654 -1
Control: tag 683654 +wontfix -moreinfo
Hi Josh, hi Teodor,
Le samedi, 1 juin 2013 09.41:00, Teodor MICU a écrit :
> This topic was discussed with LSB maintainers on #683654. Maybe these
> two bugs should be merged, but I don't know if the discus
Hi both,
Le samedi, 6 juillet 2013 20.58:15, Jeff Licquia a écrit :
>
>
> The LSB is, first and foremost, about compatibility for apps. If
> apps expect something to be there, and for it to act in a certain
> way, then that's our top priority. Everything else is secondary.
>
> (…) To the exte
Hi,
Le lundi, 8 juillet 2013 09.38:21, Aaron Sowry a écrit :
> > BTW, if you feel strongly about this, I'd encourage you to file the
> > appropriate bugs and have this discussion over there. No one here
> > needs convincing, I think, that lsb-invalid-mta is a bad idea.
>
> I do feel strongly abo
Le jeudi, 11 juillet 2013 02.27:52, Russ Allbery a écrit :
> Steve Langasek writes:
> > If lsb-core is going to pull in default-mta as the preferred
> > option, then arguably lsb-invalid-mta shouldn't exist at all (or
> > at least, there's no reason to label it an 'lsb' package). I
> > think the
Le mercredi, 10 juillet 2013 20.20:21, Steve Langasek a écrit :
> On Wed, Jul 10, 2013 at 02:10:22AM -0700, Russ Allbery wrote:
> > (It's probably also worth noting that Debian does not claim LSB
> > compliance and the description of that Debian package states,
> > rather prominently: "The intent o
Le mardi, 27 mai 2014, 11.07:15 Aaron Sowry a écrit :
> Bad commit here:
>
> http://anonscm.debian.org/gitweb/?p=collab-maint/lsb.git;a=commitdiff;
> h=f4ed7f08600d633c3daba9f494997f1c3aed
>
> StringIO.StringIO and io.StringIO do not have identical API.
Nice catch, thanks. Can you suggest an
Control: tags -1 +confirmed +pending
Hi Michael, and thanks for the bug+patch,
Le samedi, 17 mai 2014, 05.32:03 Michael Biebl a écrit :
> lsb-core currently depends on lib32z1 and libc6-i386.
> I'm not sure if those dependencies are still required. If so, please
> consider changing those to use t
Hi Gunnar,
just jumping on one specific point, sorry to hijack the thread…
(Reply-To set to debian-lsb, please followup there…)
tl;dr: proposal to shrink src:lsb to only produce lsb-base and lsb-
release
Le jeudi, 2 juillet 2015, 09.15:12 Gunnar Wolf a écrit :
> But then I realized I was lying.
Le vendredi, 3 juillet 2015, 13.20:08 Mats Wichmann a écrit :
> On 07/03/15 07:28, Didier 'OdyX' Raboud wrote:
> > The crux of the issue is, I think, whether this whole game is worth
> > the work: I am yet to hear about software distribution happening
> > through L
Control: tag -1 +moreinfo
Le lundi, 1 juin 2015, 12.00:21 Alexandre Detiste a écrit :
> Here is a patch that has got some review from "Python3 porting devel" team.
Great, thanks. I'll make sure to include it in the next upload. That said, I
just tested it, and I get the following error when laun
Le jeudi, 16 juillet 2015, 17.45:49 Alexandre Detiste a écrit :
> I think the current behaviour where random strings
> got compared against index number doesn't make sense anyway.
I _think_ this code is used for the Ubuntu codenames comparison (they
happen to come alphabetically). I'll add an exp
Le mercredi, 12 août 2015, 08.33:56 Dan Kegel a écrit :
> This begs the question - why does lsb_release require python? I had
> to strip it out of an embedded system because of that dependency.
It just happens to be written in this language, and it is a modestly
complex piece of software, that h
Package: ftp.debian.org
Severity: important
Hi,
On the 26 August, I uploaded src:lsb dropping all arch-any binary
packages from it, doing a source-only upload.
>From what I understand from britney and grep-excuses, the old src:lsb
arch-any packages need to be decrufted for src:lsb to find its wa
Hi all,
It is time for an update about the lsb source package status, especially
as a quite important change landed in testing.
After the discussion [0] about these changes back in July (on both
debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826 to
unstable, building no LSB com
Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
> I don't know about formal LSB compatibility, but there are several
> proprietary applications that require nothing but the
> /{lib,lib64}/ld-lsb.so* symlinks to work properly under Debian. So it
> would be great if they could be preser
Hi Nikolaus,
Le jeudi, 17 septembre 2015, 09.27:56 Nikolaus Rath a écrit :
> On Sep 17 2015, Didier 'OdyX' Raboud wrote:
> > Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
> >> I don't know about formal LSB compatibility, but there are several
&
Le jeudi, 17 septembre 2015, 23.00:51 Michael Biebl a écrit :
> Am 17.09.2015 um 14:56 schrieb Didier 'OdyX' Raboud:
> > After the discussion [0] about these changes back in July (on both
> > debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826
> > t
Le samedi, 26 septembre 2015, 07.38:06 Alessandro a écrit :
> I'm using a debian testing amd64, but package lsb-printing in testing
> there is not. This package and it's dependency are important for
> installing Epson printer's driver and utility es: to see inklevel
> with escputil (my printer it's
Hi Keld,
Le jeudi, 15 octobre 2015, 22.23:14 Keld Simonsen a écrit :
> Would it be possible just to preserve the current LSB support,
> just like many other distros do, and what is done in Debian 7.8?
What is your precise use-case?
So far, I've concluded that the half-baked LSB support that we c
Hi again Keld, and sorry for the delay,
Le samedi, 17 octobre 2015, 19.26:05 Keld Simonsen a écrit :
> On Fri, Oct 16, 2015 at 03:43:15PM +0200, Didier 'OdyX' Raboud wrote:
> > Le jeudi, 15 octobre 2015, 22.23:14 Keld Simonsen a écrit :
> > > Would it be possible just
Le vendredi, 18 décembre 2015, 21.41:21 Travis Hurst a écrit :
> Debian is meant to be an open system. That means dropping LSB makes it
> harder for software developers to write programs for multiple
> distros!
The LSB standard is not enforced by distributions, you get subtle
differences despite
Le mardi, 12 janvier 2016, 08.12:31 Dan Kegel a écrit :
> Here's one use case:
> When I was building a binary linux app intended to run on all popular
> linux distros,
So a _proprietary_ binary linux application, then?
> I wanted very much to use lsb dependencies to make the binary more
> portabl
Le mardi, 12 janvier 2016, 11.46:56 Dan Kegel a écrit :
> Partly. But I can imagine people wanting open source binaries to run
> portably, too.
Let's stay with real use cases. We're not building Debian for imaginary
people or imaginary open source binaries.
> > And there's no way Debian would h
Control: clone -1 -2
Control: reassign -2 upstart
Control: retitle -2 upstart: please adopt the LSB hook from
/lib/lsb/init-functions.d/01-upstart-lsb
Control: block -1 by -2
Hi Michael,
Le mardi, 31 mai 2016, 18.47:42 Michael Biebl a écrit :
> Package: lsb-base
> Version: 9.20160110
> Severity:
Control: reassign -1 dkms
Le vendredi, 10 juin 2016, 07.48:57 Roman Horn�k a écrit :
> Package: lsb-release
> Version: 9.20160601
> Severity: normal
>
>
> /etc/kernel/header_postinst.d/dkms:
> Traceback (most recent call last):
> File "/usr/bin/lsb_release", line 25, in
> import l
Hi there,
this is _very_ long overdue, but here come the notes taken collectively during
DebConf16's LSB BoF. I'll put the takeaways first.
# tl;dr
Given that the word about lsb not being granted anymore might not have spread
enough, will try to work towards producing an 'lsb-compat' package
Control: tags -1 +wontfix
Hi there Luca,
Le dimanche, 8 janvier 2017, 14.54:16 h CET Luca Boccassi a écrit :
> Any chance this could be looked at before Stretch final freeze? Thank you!
tl;dr: unfortunately not.
I have thought about this issue for some time, and I think that the result is
act
Control: tags -1 +wontfix
Le samedi, 1 juillet 2017, 18.38:28 h CEST GT a écrit :
>* What led up to the situation?
> use of the command lsb_release --all
>
> :~$ lsb_release --all
>
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux oldstable-updates
Package: ftp.debian.org
Severity: normal
Hi there,
since it's 9.20170807 upload, src:lsb doesn't build the lsb-compat
package anymore. The fact that lsb-compat is still around in unstable
seems to confuse dak, and lsb-compat doesn't seem to be catched by the
autodecruft.
Please remove the lsb-co
Le vendredi, 5 janvier 2018, 17.44:31 h CET Rohit Yadav a écrit :
> Hi,
>
> I'm not sure if this is the best ML to start a conversation - I would like
> to request a Linux kernel security patch/package for Debian 7 (x86_64) for
> the Spectre/Meltdown security issues [1][2][3].
This is not the cor
Hi there Harald,
Le lundi, 29 janvier 2018, 14.19:53 h CET Harald Dunkel a écrit :
> Apparently pidofproc returns the PIDs of programs running
> in a chroot or in a container, if there is no local PID file.
> This is a *huge* problem for me, because either the init
> scripts on the host fail to re
Hi there Andreas,
Le mercredi, 6 février 2019, 20.20:54 h CET Andreas Metzler a écrit :
> there is a logic error in /lib/lsb/init-functions's killproc:
>
> base=${1##*/}
> if [ ! $pidfile ]; then
> name_param="--name $base --pidfile /var/run/$base.pid"
> else
> name_param=
Le mercredi, 13 mars 2019, 18.17:34 h CET Dmitry Bogatov a écrit :
> [2019-03-11 21:51] Axel Beckert
> > > I believe it would be reasonable to add '--name $base' into `else'
> > > clause. Opinions?
> >
> > Sounds sane, I just checked that with #924311 (miredo, uses
> > start-stop-daemon directly,
Package: wnpp
Severity: normal
I request an adopter for the lsb package.
The package description is:
The Linux Standard Base (http://www.linuxbase.org/) is a standard
core system that third-party applications written for Linux can
depend upon.
.
This package only includes the init-functions
Le dimanche, 24 mars 2019, 09.42:12 h CET Geert Stappers a écrit :
> What would be the harm to the Buster release
> if lsb-base got NMU
> with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=ini
> t-functions.diff;msg=37 ?
I have now uploaded src:lsb to experimental with
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
I hereby request an upload authorization towards an unblock for package lsb
10.2019051400, which was not uploaded yet.
lsb (10.2019051400) unstable; urgency=medium
[ Harald Dunkel ]
*
Le mercredi, 17 juillet 2019, 16.58:15 h CEST Dmitry Bogatov a écrit :
> [2019-05-13 04:05] Dmitry Bogatov
>
> > Package: lsb-base
> > Severity: wishlist
> > Tags: patch
> >
> > From 58dd6e6add24a4e5531a84ff2404f2f5ed71e114 Mon Sep 17 00:00:00 2001
> > From: Dmitry Bogatov
> > Date: Sat, 11 May
94 matches
Mail list logo
