On Wed, Nov 28, 2018 at 11:46:21PM +0200, Adrian Bunk wrote:
> On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote:
> >...
> > Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> > stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
> >...
> I
Lorenz writes:
> Ansgar Burchardt:
>>As a possible alternative: ship the runscript and some metadata (which
>>systemd service(s) and/or sysvinit script(s) this corresponds with;
>>which system users would be needed; ...) either in the service package
>>(preferred long-term) or a "runscripts" packag
Lorenz writes:
> That will work for runit-init, but what about runit-sysv and
> runit-systemd? Let's say I have systemd (as init), runit-systemd and a
> foo daemon installed; and 'runscripts' package ship a run script for
> foo. How can I detect if the user wants to manage foo with runit or with
On 2018-11-27 21:19 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > prepare dual stack packages that use the symbols file magic from
> > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > package
Hi,
sorry for the extended quote, it's for reference in the debian-runit
mailing list (i'm subscribed there and you drop the CC)
Ansgar Burchardt:
>We generally try to avoid tiny packages in the archive; having 1000+
>automatically generated source and binary packages in the archive seems
>like a
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> > $ grep-dctrl -n -sSource:Package -FDepends \
> > -e
> > 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
> >
On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote:
>...
> Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
>...
Is there some rationale documented somewhere why this wasn't used in
Ubun
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> The amount of packages will probably be larger in the current sid,
> but it should not be more than 20 packages.
> Plus there are packages which are using QT_OPENGL_
]] Dmitry Bogatov
> which is provided by `-run' package:
>
> $ dpkg -L wicd-daemon-run
> [...]
> /etc/sv/wicd-daemon/log
> /etc/sv/wicd-daemon/log/run
> /etc/sv/wicd-daemon/run
> /var/log/runit/wicd-daemon
Does it also provide an init script? Else, it's RC b
On Wed, Nov 28, 2018 at 06:48:05PM +, Dmitry Bogatov wrote:
I believed (and still believe, despite of REJECT), that best way is
0. One source package, providing single binary package per runscript.
No, that's horrible. I agree with the REJECT.
On Tue, Nov 27, 2018 at 01:01:12PM +0500, Andrey Rahmatullin wrote:
> On Tue, Nov 27, 2018 at 08:38:56AM +0100, Wouter Verhelst wrote:
> > > > The experimental distribution is a good place for work in
> > > > progress. Maybe the rules for automatic rejects can be relaxed for
> > > > experimental so
Dmitry Bogatov writes:
> I believed (and still believe, despite of REJECT), that best way is
>
> 0. One source package, providing single binary package per runscript.
>
>src:{foo}-run -> bin:{foo}-run -> /etc/sv/{foo}
We generally try to avoid tiny packages in the archive; having 1000+
automat
Package: wnpp
Severity: wishlist
Owner: Debian Med team
* Package name: python-typing-extensions
Version : 3.6.6
Upstream Author : Guido van Rossum, Jukka Lehtosalo, Lukasz Langa, Michael
Lee
* URL :
https://github.com/python/typing/blob/master/typing_extensions/REA
[ Added runit maining list in thread ]
[2018-11-27 19:00] Bastian Blank
> All those *-run packages
> - are tiny (under 100 bytes of content),
> - generated (so why different source packages?) and
> - there sole purpose is providing support for another init system.
>
> Please let's reach consen
On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote:
> Would you be willing to also implement
> Tainted-By: not-built-in-a-chroot
> ?
What do you want to do with that? Even our own stuff not always uses
chroot, why should it?
Bastian
--
Ahead warp factor one, Mr. Sulu.
On Wed, Nov 28, 2018 at 06:40:46PM +0100, Guillem Jover wrote:
> On Wed, 2018-11-28 at 22:13:41 +0500, Andrey Rahmatullin wrote:
> > On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote:
> > > (ischroot(1) is from debianutils which is Essential).
>
> > "On GNU/Linux, chroot detection i
On Wed, 2018-11-28 at 22:13:41 +0500, Andrey Rahmatullin wrote:
> On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote:
> > (ischroot(1) is from debianutils which is Essential).
> "On GNU/Linux, chroot detection is not possible when not root."
I think this was just missed as part of t
On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote:
> Would you be willing to also implement
>
> Tainted-By: not-built-in-a-chroot
That doesn't mean anything. You can build in a bad chroot and you can
build in a clean minimal sid system which is not a chroot but a VM.
> (ischr
On Wed, Nov 28, 2018 at 02:57:52PM +0100, Guillem Jover wrote:
> Hi!
>
> On Wed, 2018-11-28 at 07:52:08 +0500, Alexander E. Patrakov wrote:
> > Well, the buildd configuration change has been reverted. What worries me now
> > is that there is a risk not yet mitigated, coming from personal systems o
On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> $ grep-dctrl -n -sSource:Package -FDepends \
> -e
> 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
> 5\.[0-9.]*\))(?|$),' \
>
> /var/lib/apt/lists/archive.ubuntu.com_u
Hi!
On Wed, 2018-11-28 at 07:52:08 +0500, Alexander E. Patrakov wrote:
> Well, the buildd configuration change has been reverted. What worries me now
> is that there is a risk not yet mitigated, coming from personal systems of
> Debian developers, and we should also check porter boxes.
>
> As lon
On 11/28/18 2:26 PM, Daniel Reichelt wrote:
> On 11/22/18 1:56 PM, Ian Jackson wrote:
>> (Bear in mind of course that happily our build machines
>> *can* be reverted because they are frequently re-imaged.[…])
>
> Using code from a debian package? Some script being hand-knitted using
> hot needles?
On 11/22/18 1:56 PM, Ian Jackson wrote:
> (Bear in mind of course that happily our build machines
> *can* be reverted because they are frequently re-imaged.[…])
Using code from a debian package? Some script being hand-knitted using
hot needles? Anyways, I'm interested in how this is done…"this" me
Hi Steve and all,
On Tue, Nov 27, 2018 at 03:39:58PM -0800, Steve Langasek wrote:
> It is actually fairly easy to answer this question as well: simply identify
> all the packages in the archive that depend on one of the known dual-stack
> libraries, prepare dual stack packages that use the symbols
Hi Steve!
El miércoles, 28 de noviembre de 2018 04:00:52 -03 Steve Langasek escribió:
[snip]
> > At this point I really feel that, except I am missing something, double
> > building is just not a good idea :-/
>
> Ok, I don't think you've understood then. Perhaps a further example from
> the Ub
Package: debootstrap
Version: debootstrap/1.0.110
Severity: serious
Merged /usr is now the default in buster. As discussed on
debian-devel, however, binary packages built on a merged-usr system
are not installable on a non-merged-usr system. I think we would like
ad hoc builds of packages from o
Package: debootstrap
Version: debootstrap/1.0.110~bpo9+1
Severity: serious
In #914208 Simon McVittie writes:
> [merge-/usr] is now the default in stretch-backports' debootstrap
As discussed on debian-devel, however, binary packages built on a
merged-usr system are not installable on a non-merged-
Hey
> Here I agree with Luke Kenneth Casson Leighton’s opinion [1].
>
> I think we should aim to provide the best possible experience with the free
> software ecosystem. The experience with proprietary drivers should be the
> second priority, if priority at all.
>
AFAIU by building Qt with GLES we
On Wed, 2018-11-28 at 09:45 +, Holger Levsen wrote:
> On Wed, Nov 28, 2018 at 07:52:08AM +0500, Alexander E. Patrakov
> wrote:
> As long as there is one Debian Developer (or any other person who has the
> > right to upload binary packages) who has a merged /usr on his system used
> > for build
On Wed, Nov 28, 2018 at 07:52:08AM +0500, Alexander E. Patrakov wrote:
> As long as there is one Debian Developer (or any other person who has the
> right to upload binary packages) who has a merged /usr on his system used
> for building packages, there is a risk of reintroducing the bug through hi
On Wed, Nov 28, 2018 at 07:52:08AM +0500, Alexander E. Patrakov wrote:
As long as there is one Debian Developer (or any other person who has the
> right to upload binary packages) who has a merged /usr on his system used
> for building packages, there is a risk of reintroducing the bug through his
31 matches
Mail list logo
