Paul Wise wrote:
>On Tue, Jul 9, 2019 at 7:42 AM Colin Watson wrote:
>
>>A memory-safe language with good testing support and a good testing
>>culture would be great, though it does also need to work on every
>>Debian architecture, which IIRC Rust doesn't quite; we've kicked
>>
Theodore Ts'o wrote:
[...]
> Thanks, that's really helpful. One of the really frustrating things
> I've found about trying to use dh is that there is a real lack of
> examples which are more complicated than:
> #!/usr/bin/make -f
> #
> # See? dh is easy-peasy!
> %:
> dh $@
> Sure,
Theodore Ts'o writes ("Re: The noudeb build profile and dh-only rules files"):
> Thanks, that's really helpful. One of the really frustrating things
> I've found about trying to use dh is that there is a real lack of
> examples which are more complicated than:
...
> # S
On Tue, Jul 09, 2019 at 12:24:40PM +0200, Simon Richter wrote:
> Your proposal of generating some of the fields doesn't affect the API
> itself, as long as the fields are populated at the right time. We don't
> have a mechanism for updating the control file at build time, because any
> part of the
On Tue, 09 Jul 2019, Simon Richter wrote:
> Your proposal of generating some of the fields doesn't affect the API
> itself, as long as the fields are populated at the right time. We don't
> have a mechanism for updating the control file at build time, because any
> part of the build process that
Hi,
On Tue, Jul 09, 2019 at 06:12:00AM +, Niels Thykier wrote:
> Instead, I have been toying with the idea of treating d/control as
> something we generate. While not entirely novel in itself, once you
> start generating d/control, you can do interesting rewrites such as:
I've started work
Simon McVittie:
> On Mon, 08 Jul 2019 at 19:23:39 +0100, Colin Watson wrote:
> [...]
>> If the udeb stanzas in debian/control have "Build-Profiles: ",
>> then debhelper will honour that when deciding which packages to build,
>> so yes, anything built into debhelper should just work.
>
> Treating
On Mon, Jul 08, 2019 at 07:28:50PM +0100, Colin Watson wrote:
>
> Per my other reply, you may find that it isn't that painful after all
> once you find the right approach. For instance, while a separate udeb
> build pass does make
>
On Tue, Jul 9, 2019 at 7:42 AM Colin Watson wrote:
>A memory-safe language with good testing support and a good testing
>culture would be great, though it does also need to work on every
>Debian architecture, which IIRC Rust doesn't quite; we've kicked
>around the idea of maybe a
Am 08.07.19 um 22:04 schrieb Moritz Mühlenhoff:
> Theodore Ts'o schrieb:
>> Back in the days of boot/root installation floppies, saving every last
>> byte was clearly important.
>
> It's probably worth discussing/investigating whether udebs in general still
> make sense for d-i in 2019?
>
> It
On Mon, Jul 08, 2019 at 10:04:06PM +0200, Moritz Mühlenhoff wrote:
> Theodore Ts'o schrieb:
> > Back in the days of boot/root installation floppies, saving every last
> > byte was clearly important.
>
> It's probably worth discussing/investigating whether udebs in general still
> make sense for
On Mon, 08 Jul 2019 at 19:23:39 +0100, Colin Watson wrote:
> On Mon, Jul 08, 2019 at 01:25:32PM -0400, Theodore Ts'o wrote:
> > How important is noudeb, and why is defined in the first place?
>
> I'm afraid memory has failed me in terms of why it was defined, other
> than perhaps performance for
Theodore Ts'o, le lun. 08 juil. 2019 14:10:13 -0400, a ecrit:
> and it also avoids the double-compilation build time extension. (I
> assume that's what you were referring to when you mentioned "avoid the
> two-times-longer build time", right?)
Yes.
Samuel
Theodore Ts'o schrieb:
> Back in the days of boot/root installation floppies, saving every last
> byte was clearly important.
It's probably worth discussing/investigating whether udebs in general still
make sense for d-i in 2019?
It was a design choice made 15 years ago, but disk/network
On Mon, Jul 08, 2019 at 07:28:50PM +0100, Colin Watson wrote:
> On Mon, Jul 08, 2019 at 02:10:13PM -0400, Theodore Ts'o wrote:
> > P.S. If anyone thinks that increasing the size of the debian
> > installer by 145k is unacceptable, please let me know now
>
> This is something you'd need to
On Mon, Jul 08, 2019 at 02:10:13PM -0400, Theodore Ts'o wrote:
> On Mon, Jul 08, 2019 at 07:36:30PM +0200, Samuel Thibault wrote:
> > Theodore Ts'o, le lun. 08 juil. 2019 13:25:32 -0400, a ecrit:
> > > How important is noudeb, and why is defined in the first place?
> >
> > My usage of noudeb is
On Mon, Jul 08, 2019 at 01:25:32PM -0400, Theodore Ts'o wrote:
> I'm the middle of an effort to simplify the debian/rules file for
> e2fsprogs so that someday, maybe, I'll be able to convert it to use
> dh. One of the things which I noticed while trying to rip things out
> of debian/rules to make
On Mon, Jul 08, 2019 at 07:36:30PM +0200, Samuel Thibault wrote:
> Hello,
>
> Theodore Ts'o, le lun. 08 juil. 2019 13:25:32 -0400, a ecrit:
> > How important is noudeb, and why is defined in the first place?
>
> My usage of noudeb is mostly to avoid the two-times-longer build time
>
It used to
Hello,
Theodore Ts'o, le lun. 08 juil. 2019 13:25:32 -0400, a ecrit:
> How important is noudeb, and why is defined in the first place?
My usage of noudeb is mostly to avoid the two-times-longer build time
Samuel
I'm the middle of an effort to simplify the debian/rules file for
e2fsprogs so that someday, maybe, I'll be able to convert it to use
dh. One of the things which I noticed while trying to rip things out
of debian/rules to make the dh conversion easier (possible?) was the
support for noudeb.
How
20 matches
Mail list logo
