Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-containerd-platforms
Version : 0.2.1-1
Upstream Author : containerd
* URL : https://github.com/containerd
Description : single-pass C compiler for 16- and 32-bit x86/MIPS platforms
Smaller C is a simple single-pass C compiler with support for most of
C89 and C99. It targets 16- and 32-bit x86, and MIPS, on DOS,
Windows, Linux, and older versions of macOS.
.
Smaller C is primarily useful for building DOS
-clause, GFDL-NIV-1.3, Apache-2.0, CC0-1.0, FTL, Hybrid-BSD,
Boost-1.0, W3C, Unicode, libpng, brg-endian, ICC
Programming Lang: C, C++
Description : The QtGui module extends QtCore with GUI functionality for
GLES platforms.
libqt6gui6-gles is intend for embedded devices that support the OpenGL
ES
: LA_OPT_NXP_Software_License_v42
Description : Firmware binary blobs needed on NXP i.MX platforms
i.MX Firmware including firmware for VPU, DDR, EPDC, HDMI, DP
(Display Port), and SDMA
To build a working u-boot for i.MX8* at least the DDR train binaries
from NXP are needed.
More details are available in this
: Python
Description : Python library that allows creating system tray icons on
multiple platforms.
This python library allows you to create a system tray icon.
It allows specifying an icon, a title and a callback for when the icon is
activated. The icon and title can be changed after the icon
On Mon, 04 Jul 2022 at 09:29:54 +0200, Martin Quinson wrote:
> All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the
> package. They are added to the debian/libns3.36/DEBIAN/shlibs
Independent of the dh_shlibdeps failure that was already diagnosed, if
these libraries are pub
Hello,
Martin Quinson, le lun. 04 juil. 2022 09:29:54 +0200, a ecrit:
> dpkg-shlibdeps -Tdebian/libns3.36.substvars
> debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wimax.so.36.1
x86_64-linux-gnu is only valid for amd64.
In
./debian/rules: -DCMAKE_INSTALL_RUNSTATEDIR=/run
-DCM
yet (cmake checks on files created by the script), so I cannot use the
plain classical cmake build in debian/rules. I did my best to mimick the
behavior of `dh --buildsystem=cmake` but I have a strange failure on non-amd64
platforms:
https://buildd.debian.org/status/package.php?p=ns3
The build, tests
Package: wnpp
Severity: wishlist
Owner: Olek Wojnar
* Package name: bazel-platforms
Version : 0.0.2
Upstream Author : Google Inc.
* URL : https://github.com/bazelbuild/platforms
* License : Apache-2
Programming Lang: Settings
Description : Bazel
Le 25/06/2020 à 22:29, Kyle Edwards a écrit :
> Speaking as one of the CMake developers, we sometimes make breaking
> changes during our RC cycles, and don't freeze the interface until the
> official .0 release. There's a reason our RCs don't typically go into
> production distros, and there is th
On Thu, 2020-06-25 at 22:19 +0200, Emmanuel Bourg wrote:
> I'm not sure to understand what bothers you. In this case the final
> version will be nearly identical. The JakartaEE APIs consist
> basically
> in the JavaEE versions that have been stable and in use for years
> with
> the base package ren
Le 24/06/2020 à 16:40, Thorsten Glaser a écrit :
> Given how long some packages stay in milestone status (some for
> six years!) I’d prefer for there to be an actual 2.0.0 release
> first before this can enter Debian.
I'm not sure to understand what bothers you. In this case the final
version wil
On Wed, 24 Jun 2020, Emmanuel Bourg wrote:
> Version : 2.0.0~RC1
Given how long some packages stay in milestone status (some for
six years!) I’d prefer for there to be an actual 2.0.0 release
first before this can enter Debian.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-
Description : Annotations for common semantic concepts in the Java SE and
Jakarta EE platforms
Jakarta Annotations defines a collection of annotations representing common
semantic concepts that enable a declarative style of programming that applies
across a variety of Java technologies.
This
Programming Lang: Go
Description : Package wgctrl enables control of WireGuard interfaces on
multiple platforms.
Package wgctrl enables control of WireGuard devices on multiple platforms.
.
wgctrl can control multiple types of WireGuard devices, including:
- Linux kernel module devices, via
Hi Kurt,
On Tue, Mar 17, 2020 at 2:14 PM Kurt Roeckx - Debian Project Secretary
wrote:
> The platforms for all 3 the candidates are now avaiable at:
> https://www.debian.org/vote/2019/platforms/
You might mean: https://www.debian.org/vote/2020/platforms/ :)
Best,
Utkarsh
heterogeneous platforms
with SYCL from Khronos Group
Seemed to me that intel is going to use SYCL for both their FPGA and the
GPUs[1]. So I think it could be interesting the investigate the sycl
implementations.
An informative diagram about SYCL implementations:
https://github.com/illuhad
terminal screen size for many
platforms
tty-screen implements terminal screen size detection which works on Linux, OS
X and Windows/Cygwin platforms and supports MRI, JRuby and Rubinius
interpreters.
It is a component of the TTY Toolkit.
This library is required by ruby-tty-reader, which in the end
manager for heterogeneous memory
platforms
The memkind library is a user extensible heap manager built on top of
jemalloc which enables control of memory characteristics and a partitioning
of the heap between kinds of memory. While arbitrary user control is
possible, built-in characteristics include
Description : Run go programs as a service on major platforms.
service will install / un-install, start / stop, and run a program as a
service (daemon). Currently supports Windows XP+, Linux/(systemd | Upstart |
SysV), and OSX/Launchd.
.
Windows controls services by setting up callbacks
Lang: ruby
Description : build packages for multiple platforms (deb, rpm, etc) with
great ease and sanity
The goal of fpm is to make it easy and quick to build packages such as
rpms, debs, OSX packages, etc.
.
fpm, as a project, exists with the following principles in mind:
.
* If
deployment for cloud platforms
Otto detects your application type and builds a development environment
tailored specifically for
that application, with zero or minimal configuration. If your application
depends on other services
(such as a database), it'll automatically configure and start
notifications on several platforms
Notifier gem can be used to send system notifications on several platforms
with a simple and unified API. Currently supports Growl, Libnotify, OSD,
KDE (Knotify and Kdialog) and Snarl.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On 02/28/2014 01:10 AM, Tom H wrote:
>> Just to name a few:
>> - getting rid of the ugly LSB headers
>
> Beauty is in the eye of the beholder. The "Short-Description" and
> "Description" LSB fields are useless, but I don't find Debian's LSB
> headers and Gentoo's squiggle-delimited stanzas any mor
On Thu, 20 Feb 2014 22:28:56 +0800, Thomas Goirand wrote:
> On 02/20/2014 09:02 PM, Tom H wrote:
Thanks for your answer and apologies for the delay in responding but my
$dayjob's been keeping me very busy.
>> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
>> doesn't h
On 02/24/2014 04:29 AM, Marco d'Itri wrote:
> On Feb 23, Thomas Goirand wrote:
>
>> Marco and yourself are *a way* off topic. Please at least have the
>> decency to rename the subject of the tread to "systemd fanboys flamewar
>> yet-again bashing OpenRC just for fun" or something similar (but
>>
Dear Kevin,
Kevin Chadwick writes:
> The benefit that Linux and even firefox etc. has gained from OpenBSD's
> practically paranoid bug fixing as well as finding the bugs for all the
> platforms it's userland still runs on especially in compiler tools
> should be realised
Hey Adrian,
John Paul Adrian Glaubitz writes:
> That's correct. However, the problem with kFreeBSD is that I - as a
> package maintainer - have to invest extra time to make sure my
> packages don't FTBFS on these architectures as otherwise my packages
> wouldn't be allowed to migrate to testing.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/23/2014 03:29 PM, Marco d'Itri wrote:
> On Feb 23, Thomas Goirand wrote:
>
>> Marco and yourself are *a way* off topic. Please at least have the
>> decency to rename the subject of the tread to "systemd fanboys
>> flamewar yet-again bashing
On Feb 23, Thomas Goirand wrote:
> Marco and yourself are *a way* off topic. Please at least have the
> decency to rename the subject of the tread to "systemd fanboys flamewar
> yet-again bashing OpenRC just for fun" or something similar (but
> preferably: don't just do that in this list, and avo
previously on this list Kevin Chadwick contributed:
> Perhaps before this thread spirals out of control I should
should also mention this has been discussed on this very list already,
though before I was enrolled and the following response went
unreplied to.
On the other hand and I doubt of sig
previously on this list Matthias Urlichs contributed:
> One sample usecase where they dont't: "the system is wedged / overcommitted
> and I need to terminate some services; guess I'll start another ten processes
> to do that". Yeah, right.
>
> I'll be nice to everybody else here and not enumerate
Hi,
Kevin Chadwick:
> Regex works just fine for me.
>
One sample usecase where they dont't: "the system is wedged / overcommitted
and I need to terminate some services; guess I'll start another ten processes
to do that". Yeah, right.
I'll be nice to everybody else here and not enumerate any othe
On 02/21/2014 03:37 AM, Ondřej Surý wrote:
> mkdir -p /run/openrc
> touch /run/openrc/softlevel
>
> and then it still doesn't work as expected:
>
> root@howl:/etc/init.d# /etc/init.d/rsyslog start
> * WARNING: rsyslog is already starting
>
> root@howl:/etc/init.d# /etc/init.d/rsyslog stop
> *
milar (but
preferably: don't just do that in this list, and avoid replying about
anything related to OpenRC, since we all know what type of
non-productive content it's going to be).
On 02/23/2014 09:04 PM, John Paul Adrian Glaubitz wrote:
> Well. OpenRC was up for discussion as the de
n one system but not
another increasing forking, reducing eyefall, collaboration etc. and
perhaps want a simpler solution.
The benefit that Linux and even firefox etc. has gained from OpenBSD's
practically paranoid bug fixing as well as finding the bugs for all the
platforms it's userlan
previously on this list Marco d'Itri contributed:
> > But you aren't planning on running openrc at all, are you?
> Who is? Seriously, would you mind stepping forward?
If it was available I would use it but wouldn't be switching cgroups
on or would be switching them off even if I hadn't bothered
previously on this list Matthias Urlichs contributed:
> > Kevin, I don't think you understand the reasoning behind this. Again,
> > the problem the init system has to solve here is being able to track a
> > process with a 100% accuracy, so whatever automated mechanisms you have
> > configured when
On Fri, 21 Feb 2014 23:53:51 +0100
John Paul Adrian Glaubitz wrote:
> Kevin, I don't think you understand the reasoning behind this. Again,
> the problem the init system has to solve here is being able to track a
> process with a 100% accuracy, so whatever automated mechanisms you have
> configure
On Sun, Feb 23, 2014 at 08:45:10PM +0800, Thomas Goirand wrote:
> On 02/23/2014 07:32 PM, Jonathan Dowland wrote:
> >
> >
> >> On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz
> >> wrote:
> >>
> >> I agree and understand that this was the way to go back in the old
> >> days, but we shouldn't
On Sun, Feb 23, 2014 at 08:50:13PM +0800, Thomas Goirand wrote:
> http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
> sysv-rc wins...
>
> With
On Sun, Feb 23, 2014 at 12:43:14PM +, Jonathan Dowland wrote:
> Since you aren't a user nor are going to be a user of openrc, I don't
> see why you feel the need to critique it, especially on debian-devel
> where the majority of subscribers are just not interested.
Well. OpenRC was up for disc
On 02/23/2014 07:36 PM, Marco d'Itri wrote:
> On Feb 23, Jonathan Dowland wrote:
>
>> But you aren't planning on running openrc at all, are you?
> Who is? Seriously, would you mind stepping forward?
>
> http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc&show_installed=on&
On 02/23/2014 07:32 PM, Jonathan Dowland wrote:
>
>
>> On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz
>> wrote:
>>
>> I agree and understand that this was the way to go back in the old
>> days, but we shouldn't be using that on current setups.
>
> But you aren't planning on running openrc
Please do not CC me, I am subscribed to the list.
On Sun, Feb 23, 2014 at 12:47:44PM +0100, John Paul Adrian Glaubitz
wrote:
> On 02/23/2014 12:32 PM, Jonathan Dowland wrote:
> > But you aren't planning on running openrc at all, are you?
>
> No, and I don't see any compelling reason why I should.
On 02/23/2014 12:32 PM, Jonathan Dowland wrote:
>> I agree and understand that this was the way to go back in the old
>> days, but we shouldn't be using that on current setups.
>
> But you aren't planning on running openrc at all, are you?
No, and I don't see any compelling reason why I should. W
On Feb 23, Jonathan Dowland wrote:
> But you aren't planning on running openrc at all, are you?
Who is? Seriously, would you mind stepping forward?
http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_da
> On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz
> wrote:
>
> I agree and understand that this was the way to go back in the old
> days, but we shouldn't be using that on current setups.
But you aren't planning on running openrc at all, are you?
--
To UNSUBSCRIBE, email to debian-devel-
Hi,
John Paul Adrian Glaubitz:
> Kevin, I don't think you understand the reasoning behind this. Again,
> the problem the init system has to solve here is being able to track a
> process with a 100% accuracy, so whatever automated mechanisms you have
> configured when certain situations occur, they
On 02/21/2014 11:38 PM, Kevin Chadwick wrote:
> previously on this list hero...@gentoo.org contributed:
>
>>> And grepping through the output of "ps" or similar is not what
>>> I would consider reliable and robust either.
>>
>> Nod. grepping `ps` is what we should avoid at all cost.
>
> All cos
previously on this list hero...@gentoo.org contributed:
> > And grepping through the output of "ps" or similar is not what
> > I would consider reliable and robust either.
>
> Nod. grepping `ps` is what we should avoid at all cost.
All cost? While I like OpenRC and thanks to Gentoo for it and
Dear Adrian,
John Paul Adrian Glaubitz writes:
> On 02/21/2014 01:00 PM, hero...@gentoo.org wrote:
>>> So, OpenRC actually also relies on files - like System V Init - to
>>> track the state of a service? Isn't that approach somewhat unreliable
>>> and hacky?
>>
>> I bet you are going to tell me
On 02/21/2014 01:00 PM, hero...@gentoo.org wrote:
>> So, OpenRC actually also relies on files - like System V Init - to
>> track the state of a service? Isn't that approach somewhat unreliable
>> and hacky?
>
> I bet you are going to tell me the only reliable and non-hacky way to
> track the state
Dear Adrian,
John Paul Adrian Glaubitz writes:
> So, OpenRC actually also relies on files - like System V Init - to
> track the state of a service? Isn't that approach somewhat unreliable
> and hacky?
I bet you are going to tell me the only reliable and non-hacky way to
track the state of a ser
On 02/21/2014 04:20 AM, hero...@gentoo.org wrote:
> OpenRC needs a proper directory structure in /run/openrc to track the
> status of services. It is handled by init.sh and friends, you may need
> to hack that.
So, OpenRC actually also relies on files - like System V Init - to
track the state of a
On 20/02/14 19:37, Ondřej Surý wrote:
> I have split openrc into openrc and openrc-sysv moving the conflicting
> parts to openrc-sysv on my system, and it install just fine
If sysv-rc's invoke-rc.d and update-rc.d should be treated as generic
glue shared by multiple inits (which they probably shou
Hey Ondřej,
Ondřej Surý writes:
> I have split openrc into openrc and openrc-sysv moving the conflicting
> parts to openrc-sysv on my system, and it install just fine, but running
> script with /sbin/openrc-run needs:
>
> mkdir -p /run/openrc
> touch /run/openrc/softlevel
>
> and then it still d
On Thu, Feb 20, 2014, at 17:39, Thomas Goirand wrote:
> There's of course dependencies in OpenRC. You have the choice: either
> you keep the LSB headers, either you write it the OpenRC way (IMO,
> prefered...). In OpenRC, you just use functions of the openrc-run
> "interpreter". For example:
Well,
Ansgar Burchardt writes:
> On 02/20/2014 15:28, Thomas Goirand wrote:
>> Also, we have an ALIVE UPSTREAM TEAM, and an evolving project, which is
>> IMO important (is there anyone still working on sysv-rc apart from a
>> few Debian maintainers? my understanding is: we're alone now...).
> Doesn't
Ansgar Burchardt writes:
> On 02/20/2014 09:57, gregor herrmann wrote:
>> On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
>>> That package does currently depend on
>>> perl, though, which isn't appropriate for an essential package.
>>> ... The dependency is because
>>> deb-systemd-helper
On 02/20/2014 10:45 PM, Didier 'OdyX' Raboud wrote:
> Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit :
>> On 02/20/2014 09:02 PM, Tom H wrote:
>>> What features does sysvinit+openrc have that
>>> sysvinit+sysv-rc+insserv doesn't have?
>>
>> Just to name a few:
>> - getting rid of the ug
On 02/20/2014 15:28, Thomas Goirand wrote:
> On 02/20/2014 09:02 PM, Tom H wrote:
>> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
>> doesn't have?
>
> Just to name a few:
> - getting rid of the ugly LSB headers
> - cgroup supports to kill processes
I'm curious: does OpenR
Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit :
> On 02/20/2014 09:02 PM, Tom H wrote:
> > What features does sysvinit+openrc have that
> > sysvinit+sysv-rc+insserv doesn't have?
>
> Just to name a few:
> - getting rid of the ugly LSB headers
They might be ugly, but they encode the d
On 02/20/2014 09:02 PM, Tom H wrote:
> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
> doesn't have?
Just to name a few:
- getting rid of the ugly LSB headers
- cgroup supports to kill processes
- rc_hotplug (a hotplugged service is one started by a dynamic dev
manager when
On Thu, 20 Feb 2014 14:19:30 +0900, hero...@gentoo.org wrote:
> Tollef Fog Heen writes:
>>
>> It's probably better to just contribute your changes to the sysv-rc
>> version and so make that one able to manage openrc in addition to the
>> others it already knows how to. No point in forking it.
>
>
On 02/20/2014 02:10 AM, Kevin Chadwick wrote:
> Do people use all those runlevels?
As much as I know, there's only 4 in use (using names of OpenRC here,
since OpenRC has named runlevels):
- shutdown (runlevel 0)
- recovery (runlevel 1)
- reboot (runlevel 6)
- default (often, everything else, but m
On Thu, 20 Feb 2014 10:52:12 +0100, Ansgar Burchardt wrote:
> On 02/20/2014 09:57, gregor herrmann wrote:
> > On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
> >> ... The dependency is because
> >> deb-systemd-helper uses a bunch of modules that are not currently in
> >> perl-core (File::
Hi,
On 02/20/2014 09:57, gregor herrmann wrote:
> On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
>> That package does currently depend on
>> perl, though, which isn't appropriate for an essential package.
>> ... The dependency is because
>> deb-systemd-helper uses a bunch of modules that
On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
> That package does currently depend on
> perl, though, which isn't appropriate for an essential package.
> ... The dependency is because
> deb-systemd-helper uses a bunch of modules that are not currently in
> perl-core (File::Path, File::B
hero...@gentoo.org writes:
> Forking was a decision made by me in the early phase of packaging
> OpenRC. At that time I referred to the way file-rc handled update-rc.d
> as in
> sysvinit: /usr/share/sysvinit/update-rc.d
> A central package providing update-rc.d and invoke-rc.d is nice. Thou
Hi Tollef,
Tollef Fog Heen writes:
> It's probably better to just contribute your changes to the sysv-rc
> version and so make that one able to manage openrc in addition to the
> others it already knows how to. No point in forking it.
Forking was a decision made by me in the early phase of pac
]] Thomas Goirand
> How come? I just took what was in the sysinit package! Or probably, what
> you are talking about is new features, which I should merge it back into
> the OpenRC version?
It's probably better to just contribute your changes to the sysv-rc
version and so make that one able to m
previously on this list Thomas Goirand contributed:
> So, systemd is still using /etc/rc?.d. Could you tell exactly what it
> uses out of /etc/rc?.d, and what for? Does it only needs to see them as
> S??script-name in runlevel 2 or 4 (or whatever it uses...)?
>
> If systemd needs links in /etc/rc
On Wed, Feb 19, 2014 at 03:45:12PM +, Dimitri John Ledkov wrote:
> On 19 February 2014 15:28, Ondřej Surý wrote:
> > are you aware that media are already quoting your blogpost as official
> > announcement of next Debian codename?
> >
>
> Nah, wasn't aware =) I blame Neil, I thought he still w
Hi,
The Wanderer:
> > Nah, wasn't aware =) I blame Neil, I thought he still was a release
> > manager ;-) Any reason, not to make it official? =)
>
> Well, back in 2002 there was a probably-joking sort-of decision that
> "zurg" should be the codename of the release where the Hurd and *BSD
> ports
On 02/19/2014 11:53 PM, Simon McVittie wrote:
> I suspect the right thing would be to share one implementation of
> update-rc.d(8), invoke-rc.d(8) and possibly service(8) between all
> supported init implementations, provided by either src:sysvinit or
> src:init-system-helpers.
Surprisingly, "serv
On 02/19/2014 10:47 PM, Michael Biebl wrote:
> Am 19.02.2014 00:52, schrieb Russ Allbery:
>> Henrique de Moraes Holschuh writes:
>>
>>> They *HAVE* to be provided by the active init system. They are an
>>> impedance matching layer (aka stable API) used by maintainer scripts to
>>> interface with
On Wed, Feb 19, 2014, at 17:09, Dimitri John Ledkov wrote:
> On 19 February 2014 16:05, Ondřej Surý wrote:
> > On Wed, Feb 19, 2014, at 16:57, The Wanderer wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
> >>
> >> > On 1
On 19 February 2014 16:05, Ondřej Surý wrote:
> On Wed, Feb 19, 2014, at 16:57, The Wanderer wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
>>
>> > On 19 February 2014 15:28, Ondřej Surý wrote:
>> >
>> >> Dimitri,
>>
>> >> are
On 19 February 2014 15:57, The Wanderer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
>
>> On 19 February 2014 15:28, Ondřej Surý wrote:
>>
>>> Dimitri,
>
>>> are you aware that media are already quoting your blogpost as
>>> offi
On Wed, Feb 19, 2014, at 16:57, The Wanderer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
>
> > On 19 February 2014 15:28, Ondřej Surý wrote:
> >
> >> Dimitri,
>
> >> are you aware that media are already quoting your blogpost
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
> On 19 February 2014 15:28, Ondřej Surý wrote:
>
>> Dimitri,
>> are you aware that media are already quoting your blogpost as
>> official announcement of next Debian codename?
>
> Nah, wasn't a
On 19/02/14 15:09, Thomas Goirand wrote:
> First, yes, OpenRC uses /etc/runlevel, with the folders below that being
> the *names* of the runlevel (which IMO is a way more user friendly than
> just numbers). FYI, we have: shutdown=0, recovery=1, reboot=6, and
> everything-else=default. So we do have
On 19 February 2014 15:28, Ondřej Surý wrote:
> Dimitri,
>
> On Wed, Feb 19, 2014, at 12:57, Dimitri John Ledkov wrote:
>> On 19 February 2014 11:22, Neil McGovern wrote:
>> > On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
>> >> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McG
Dimitri,
On Wed, Feb 19, 2014, at 12:57, Dimitri John Ledkov wrote:
> On 19 February 2014 11:22, Neil McGovern wrote:
> > On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
> >> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> >> > On Tue, Feb 18, 2014 at 07:18:30PM
On 02/19/2014 10:44 PM, Michael Biebl wrote:
> I'd like to add that switching to openrc breaks the SysV/LSB support in
> systemd. Openrc doesn't use the /etc/rc?.d/ directories to create the
> symlinks which signal if a service is active for a given runlevel.
> (those symlinks are created in /etc/r
Am 19.02.2014 00:52, schrieb Russ Allbery:
> Henrique de Moraes Holschuh writes:
>
>> They *HAVE* to be provided by the active init system. They are an
>> impedance matching layer (aka stable API) used by maintainer scripts to
>> interface with the active init system.
>
> If you look at the exi
Am 18.02.2014 19:18, schrieb Didier 'OdyX' Raboud:
> Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
>> On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
>>> On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
Once I consider OpenRC ready for it, would it be ok to jus
On 19 February 2014 11:22, Neil McGovern wrote:
> On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
>> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
>> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
>> > > [0] Can we haz a release name?
>> >
On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> > > [0] Can we haz a release name?
> > >
> >
> > Sure. It's Debian 8.0, "zurg". [0]
> >
>
On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> > [0] Can we haz a release name?
> >
>
> Sure. It's Debian 8.0, "zurg". [0]
>
> Neil
> [0] Note: may be a lie.
Umm, Debian 9.0?
--
"If you're not careful, t
Hi,
Thomas Goirand:
> > [0] Can we haz a release name?
>
> It's been years that I've been asking that we have the release name a
> way sooner. Ideally, one release earlier, so that we can prepare for the
> new name soon enough (and not fix things during the freeze). But the
> release team doesn't
Thomas Goirand writes:
> On 02/19/2014 08:05 AM, Henrique de Moraes Holschuh wrote:
>> On Tue, 18 Feb 2014, Russ Allbery wrote:
>>> There are some advantages to providing only one version with knowledge
>>> of all of the init systems given that we're supporting init system
>>> switching, and ther
Hi,
I'm replying to everyone in a single mail, I hope that's fine. I'm
therefore a bit repeating myself, sorry for that.
On 02/19/2014 02:18 AM, Didier 'OdyX' Raboud wrote:
> Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
>> On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
>>> On
Apparently sysvinit scripts must be retained anyway for a smooth
migration to jessie; also for easy backporting of jessie packages to
wheezy, and maybe other reasons. Non-Linux ports are likely to use
those SysV init scripts, though we might invoke them from something
other than sysvinit.
I know
On Tue, 18 Feb 2014, Russ Allbery wrote:
> Henrique de Moraes Holschuh writes:
> > They *HAVE* to be provided by the active init system. They are an
> > impedance matching layer (aka stable API) used by maintainer scripts to
> > interface with the active init system.
>
> If you look at the exist
Henrique de Moraes Holschuh writes:
> They *HAVE* to be provided by the active init system. They are an
> impedance matching layer (aka stable API) used by maintainer scripts to
> interface with the active init system.
If you look at the existing implementation, you'll find that the version
pro
On Tue, 18 Feb 2014, Tollef Fog Heen wrote:
> > Once I consider OpenRC ready for it, would it be ok to just replace
> > sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>
> No, update-rc.d and invoke-rc.d still need to be provided by something.
They *HAVE* to be provided by t
On 02/18/2014 03:31 PM, Neil McGovern wrote:
> On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
>> [0] Can we haz a release name?
>>
> Sure. It's Debian 8.0, "zurg". [0]
finally one of the 'bad' guys!
[*] as a release, sid don't apply
>
> Neil
> [0] Note: may be a lie.
--
On Wed, Feb 19, 2014 at 01:11:21AM +0800, Thomas Goirand wrote:
> Actually, thinking about it a 2nd time, I think there would be a major
> drawback in delaying to Jessie +1. If we decide that sysv-rc goes away,
> then starting at the Jessie release, we don't have to care anymore about
> LSB header
1 - 100 of 160 matches
Mail list logo
