Ben Finney writes ("Re: Preferred git branch structure when upstream moves from
tarballs to git"):
> Ian Jackson writes:
> > [...] I have not taught dgit how to convert [separate Debian
> > packaging-only repository and upstream source repository] into a git
> > t
Ansgar writes ("Re: Preferred git branch structure when upstream moves from
tarballs to git"):
> On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> > Ansgar writes ("Re: Preferred git branch structure when upstream moves from
> > tarballs to git"):
>
er's branch structure to try to
figure out which version corresponds to what is in the archive.
Have the maintainer's history. This is usually in a format
useful to the maintainer, but it is not standardised. It may be
the packaging history for a whole packaging ecos
Ben Hutchings writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On Thu, 2019-05-02 at 11:23 +0100, Ian Jackson wrote:
> > Sorry for shouting, but, really. It is kind of frustrating to have
> > designed and implemented and de
do not notice if you only use gbp and dput. What is happening there
is that you are uploading a different thing to what you have in git,
and not noticing.
We don't tell people to not use lintian because it produces error
messages, do we ?
Ian.
--
Ian JacksonThese opinions are my own.
If
user
with a useable and correct and standardised git branch which can be
used for building the package, developing patches, and sharing the
results. The problem of streamlining the Debian maintainer's upload
process to be more like "git push" remains.
--
Ian JacksonThese
s saying this stuff?
I think we should have a separate manpage. This kind of conversion
stuff is (hopefully) used rarely.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Gard Spreemann writes ("Preferred git branch structure when upstream moves from
tarballs to git"):
> Recently, upstream has finally started using git. What is the
> recommended way for me to maintain a sane branch structure for the
> packaging repository while starting to use upstream's git master
y pick apart the tag and feed the
results to gpgv (and to work around infelicites in gpgv).
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Boyuan Yang writes ("Re: Reg: Debian Source code"):
> Here are some resources that I am aware of:
>
> * By running "apt source ", you will be able to retrieve the
> source code for that certain source package that corresponds to the
> you indicated.
`dgit clone ' does the same but ensures that
arning about
this at some point, depending on at what stage you invoked dgit.)
See
https://manpages.debian.org/testing/dgit/dgit.7.en.html#GITATTRIBUTES
for a discussion of the issue and
https://manpages.debian.org/testing/dgit/dgit.1.en.html
(search forward for `attrib') for details of what
Init Diversity team
debian-init-divers...@chiark.greenend.org.uk
should be consulted so that the appropriate fixes can be developed.
Finally, this change is rather late wrt the freeze.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.o
If the RC4 were critical to the security properties of your scheme,
then I would be making a much stronger complaint, because RC4 is (of
course) broken (when used as a supposedly cryptographically secure
pseudorandom bitstream generator).
I hope you have found this review helpful.
Regards,
Ian.
on
next boot, assuming that either (i) the entropy estimate provided on
next boot is no bigger than the kernel's entropy counter at shutdown
OR (ii) the kernel's PRNG was at any time properly seeded so that
/dev/random unblocked.
Ian.
--
Ian JacksonThese opinions are my own.
If I
ol design. But my knowledge is rather out of date since I left
academia and I have not reviewed Thorsten's design in detail.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
d RC; and the answer seems to be that
people think it isn't.
I also expect that subject to the constraint that this won't generate
RC bugs, people will be generally happy to have policy write down
roughly what the criteria are for putting in a Build-Conflicts.
Ian.
--
Ian
of feedback
then of course next time I can not write it up as a learning
opportunity for Debian. I can just work around it instead.
Rhonda D'Vine writes ("Re: Removal of linux-base from jessie-backports broke
Xen upstream CI"):
> On 2/13/19 1:09 PM, Ian Jackson wrote:
> >
he setup, so this ought not to cause snapshot any
difficulties.) Thanks to everyone behind snapshot.d.o which is, as
ever, invaluable.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
t (from June!) that I missed;
https://lists.debian.org/debian-backports-announce/2018/07/msg0.html
I have to say I'm not sure this removal is very helpful but then I'm
not helping maintain -backports so I guess my opinion doesn't carry
much weight.
Ian.
--
Ian Jackson
ke the most plausible explanation. I haven't so far found any
explanation somewhere but perhaps I looked in the wrong places.
Q. Why was linux-base removed from jessie-backports ?
Opinions and suggestions welcome.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I ema
it could be easily
> modified to grab the entire history of the package (as defined by it's
> changelog).
Cool, thanks! Have you considered making a package of it ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk
tc or freenode, or email me here.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
rom snapshot in version number order, one
might write something to look inside the package at the changelogs to
try to discern the branch structure. I think the Launchpad folks have
some code which can do this.
Ian.
[1] Caution: may not be true.
--
Ian JacksonThese opinions are my own.
If I
t.
Realistically our sensible choices for the default are
C.UTF-8
One of en_{AU,GB,NZ}.UTF-8
All of these would be better than en_US.UTF-8 for the reasons given
by Adam (although, Adam, really, could you try to be a little less
rude?).
The middle-endian dates and 12-hour clock are particularly p
y package name is sometimes
better than picking a new name.
To Gard: waiting for a few more opinions and then deciding is a good
plan.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
rior package - unless it had some kind of ad-hoc and unreliable
heuristic, perhaps.
Someone who searches for archived bugs for your source package will
find their search results contain bugs for the previous package of the
same name.
Also, using a different name means you do not need to use an epoc
; actually invoked.
I agree that multiple layers of alternatives indirection is
undesirable. But I think these libraries can be made coinstallable
without that.
HTH.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
dreds or thousands of values of fixcvsdiff.
> Either way,
> the fact remains that if untrusted/unsanitised input is being passed
> into your @ARGV, then something is already wrong. It is worth
> noting that it took a real (embarged) RCE exploit to get the wheels in
> motion to ev
Holger Levsen writes ("Re: Potentially insecure Perl scripts"):
> On Thu, Jan 24, 2019 at 03:18:40PM +, Ian Jackson wrote:
> > To the Debian Perl maintainers: [...]
> > To the Debian security team: [...]
>
> I've read the whole thread and am surprised &qu
hypothetical fixed <> (ii) we're probably in a small
minority of a tiny minority here (iii) changing the workaround so it
works for both is easy.
So I think this was a reasonable question to ask, but the answer is
that this is very unlikely to be a significant problem.
Ian.
--
Ian Jackson
Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> Even if we care only about scripts which are part of Debian, rather
> than scripts which people merely expect to run on Debian (and where
> they trust Debian to not blow their leg off), there will probably be
&
lions of scripts.
Even if we care only about scripts which are part of Debian, rather
than scripts which people merely expect to run on Debian (and where
they trust Debian to not blow their leg off), there will probably be
many thousands.
Ian.
--
Ian JacksonThese opinions are my own.
If I em
Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> The right answer is to fix the behaviour to be secure and sane by
> default. We can arrange for an environment variable for people who
> want to turn the crazy back on.
To the Debian Perl maintainers: if I make a
the "formal specification" (such as it is) of the
behaviour of <>.
The right answer is to fix the behaviour to be secure and sane by
default. We can arrange for an environment variable for people who
want to turn the crazy back on.
Ian.
--
Ian JacksonThese opinions a
Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> Vincent Lefevre writes ("Potentially insecure Perl scripts"):
> > I've just reported
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920269
> > against gropdf (also reported up
ami|"
got iwj
$
This is completely mad and IMO the bug is in perl, not in all of the
millions of perl scripts that used <> thinking it was a sensible thing
to write.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
is thread
and also opposite to Debian policy.
Under the circumstances I felt I wouldn't be listened to if I simply
petitioned the maintainers of what is now src:dune again, so I have
escalated this to the TC. See #919951.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you f
Mike Gabriel writes ("Re: quilt + dpkg + debhelper: Handling upstream files
containing spaces"):
> On Mi 09 Jan 2019 16:13:57 CET, Ian Jackson wrote:
> > I do have an idea how to fix this: a source package format
> > `3.0 (rsync)', which could represent any d
is big, then this is not a good
approach.
I do have an idea how to fix this: a source package format
`3.0 (rsync)', which could represent any delta. But that project
is stalled at a conceptual stage, mostly due to the need to support
existing ftpmaster workflow :-/.
Regards,
Ian.
--
Ian
copyright.html#License.
>
> Among other files, that directory contains IVD_Sequences.txt, which
> emacs (among other packages) uses. The license ambiguity for that
> file had been a concern for someone.
Thanks for your work on chasing this up.
Ian.
--
Ian JacksonThese opinions are
y exception for this,
> since it's a single edge case. Instead, I think it's a good use of a
> Lintian override documenting what's going on. Obviously, if Nix becomes
> really popular in the long run, we can then go back and write this into
> Policy.
This is a good appro
ere, but this thread
was about the process anyway. My inclination is to trust Dmitry's
judgement about when to take steps such as those described here.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Mo Zhou writes ("Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED"):
> We (Julia maintainers) reached an agreement to revert the name of NEW
> binary package "libjulia1" back to "libjulia0.7", and upload the ugly
> package to unstable after a week or ten days, in order to bypass the NEW
>
Ian Jackson writes ("Re: Conflict over /usr/bin/dune"):
> https://www.google.com/search?q=dune+software
> https://en.wikipedia.org/wiki/Dune_(software)
> https://www.google.com/search?q=%2Fusr%2Fbin%2Fdune
>
> Under the circumstances it seems obvious that, at the very
dia.org/wiki/Dune_(software)
https://www.google.com/search?q=%2Fusr%2Fbin%2Fdune
Under the circumstances it seems obvious that, at the very least, the
ocaml build tool should not be allowed the name /usr/bin/dune.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address
they
couldn't be bothered to do a Debian file search,
https://www.google.com/search?q=dune+software
https://en.wikipedia.org/wiki/Dune_(software)
https://www.google.com/search?q=%2Fusr%2Fbin%2Fdune
Under the circumstances it seems obvious that no-one should be allowed
the name /usr/bin/dune.
we
want to capture some additional data of this kind, because someone
will pop up and say `my build system is like this and it is fine' or
whatever.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
ot;. :)
And how to define "proper". This is being discussed in more detail in
debian-policy (thread on #824495).
I like your /usr/local taints.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
don't want to change it, but we should avoid that approach where
we can.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
it will be most
convenient to file a separate bug for that.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
e
redirect me if I am wrong.)
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
that means that while a properly planned and executed
transition to mandatory merged-/usr might well have offered overall
technical benefits for the Debian ecosystem, this is not now socially
possible and pressing on is not worth the social costs of being seen
to bulldoze opposition.
Ian.
--
Ian J
Russ Allbery writes ("Re: usrmerge -- plan B?"):
> Ian Jackson writes:
> > We can then have this discussion again early in the bullseye release
> > cycle. If we must.
>
> That idea makes me wince. This will just result in the same thing
> happening again. Let
allegedly
fixed ? I think this is just outsourcing the pain of bad design
choices, frankly.
If we must get to merged-usr on all systems eventually, Adam's
proposed transition plan is much better.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.
tation.
This seems like a good reason to me to override the lintian warning.
In any case, please can we have the package ACCEPTed and bugs filed so
that we can discuss this in the BTS ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
ject to the caveat that the
results from a merged-usr build are not of general applicability and
should be used only in a closed environment where all the target
systems are also merged-usr.
Does that make sense ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Russ Allbery writes ("Re: usrmerge -- plan B?"):
> This is a much better summary of the thread, and I wish that you would
> have said this instead of claiming incorrectly that those same people are
> the ones advocating for a full merge of all systems.
Marco d'Itri writes ("Re: usrmerge -- plan B?
Russ Allbery writes ("Re: usrmerge -- plan B?"):
> Ian Jackson writes:
> >> "We ran into some unanticipated issues when we usrmerged our build
> >> systems, and we think the way to fix that is to force merge every one
> >> of our users' systems.
ice is actually necessary but it seems wise
to write it.)
Excuse the shouting, but, really. It is very unfortunate that I am
having to explain these rather basic principles.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a
Chris Lamb writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes
REJECTED)"):
> Ian Jackson wrote:
> >[..] Compared to REJECT mails:
> > - Discussions in the BTS are more transparent
> > - Discussions in the BTS are better organised
> &
Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> On Nov 22, Ian Jackson wrote:
> > Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > > So far nobody reported anything significant.
> >
> > I hear there was a major free software pr
Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> So far nobody reported anything significant.
I hear there was a major free software project who accidentally
usrmerged their build systems and discovered that they then built
broken packgaes.
Ian.
--
Ian JacksonThese o
Holger Levsen writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes
REJECTED)"):
> On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote:
> > Because:
> > ...
>
> thanks! nice summary.
I replied in my other mail to the things I disagreed with (as
users' systems."
That does seem to be the position that is being advanced. It's quite
striking, isn't it ? At the very least more comprehensive thought and
planning is needed. And very probably more time.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you
d on the grounds that it should be in experimental rather than
unstable. Unless it's an overrideable auto-REJECT of course. As I
say, I'm a fan of those.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Holger Levsen writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
> > Why is any of this a reason for an ftpmaster REJECT ? I still think
> > all of this should be handled as bugs (possibly RC bugs) in the BT
Andreas Henriksson writes ("Re: usrmerge -- plan B?"):
> Here's a dumbed down narrative for you:
Svante's message was pretty bad but yours is even worse.
Would everyone please stop it.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from a
l we have a transition plan
which we can discuss and possibly get rough consensus on. Personally
what I have seen so far gives me little confidence.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Emilio Pozuelo Monfort writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> > On 2018/10/25 12:24, Ian Jackson wrote:
> >> Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> >>> My main concern here is this: AFAICT this package has b
Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> On Nov 20, Adam Borowski wrote:
> > Another question is, why?
>
> It has been documented here long ago: https://wiki.debian.org/UsrMerge .
I looked at that page and it has no rationale.
> You are misconstructing the arguments in favour of merge
Marc Haber writes ("Re: Requesting input for pjproject/asterisk packaging"):
> b. The multi tarball feature of dpkg-source would be helpful for a
> number of other packages, it's about time that someone seriously uses
> it.
I have been using it for Xen in stretch-security and it all WFM.
The runes
package broken in some package like docker and etc.
Please see this page about how to report a bug:
https://www.debian.org/Bugs/Reporting
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
st one important component which *requires* hardcoded paths in
their critical configuration files.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Matthias Klumpp writes ("Re: Our build system may be broken: /bin vs /usr/bin"):
> Ideally the build system would correctly detect an usr-merged system
> and set paths accordingly.
I don't know how that would be possible. If it's determined to
hardcode a path, the correct path to hardcode depends
Enrico Weigelt, metux IT consult writes ("Re: git vs dfsg tarballs"):
> On 19.11.18 13:52, Ian Jackson wrote:
> > I think that most of the workflows recommended in these manpages
> >
> >
> > https://manpages.debian.org/stretch-backports/dgit/dgit
ch package the usrmerge
change is in, so that you can file a bug report. I think that bug
report should be RC.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
e is
generating RC bugs in packages, and should be reverted.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
n.html
ought to have the property I describe above, which I think is
sufficient for you ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
n master but nobody says it has to) and all the changes
> integrated into master and the contributors changes will end up in the
> next release without any "messy" history due to reverts.
Precisely.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
t be a forgery or something, then that
should be done privately and with great care. It should be
accompanied by an apology; and the message should probably be reviewed
for tone and content by someone other than the author.
But I agree that this will almost never be necessary.
Ian.
--
Ian Jackson
Colin Watson writes ("Re: salsa.debian.org: merge requests and such"):
> Honestly, I think it's better for Debian as a whole that people should
> be able to do that kind of bulk cleanup with absolutely minimal
> friction,
I absolutely agree.
The disruption from this kind of thing is minimal, and
We're
talking about a commit that a DD thought was very likely a good idea.
Were they wrong ? It would be nice to have a proper reference.
It might be nice to have clearer guidance about exactly what level of
certainty a DD ought to have before making such a commit.
Ian.
--
Ian JacksonT
Simon McVittie writes ("Re: Should libpam-elogind Provide libpam-systemd ?"):
> I don't want this to turn into "us vs. them", and I'm trying not to get
> drawn into a debate about the merits of these approaches because I can
> already see how much time and motivation that will burn if it happens,
>
Simon McVittie writes ("Re: Should libpam-elogind Provide libpam-systemd ?"):
> On Mon, 05 Nov 2018 at 13:32:40 +, Ian Jackson wrote:
> > pinentry-gnome3 and pulseaudio seem wrong to me. PINs should not be
> > shared between login sessions and sound control should be
So I promised that I would summarise. I found that trying to write a
summary involved me doing a bit of research, and that not everyone in
the thread seemed to agree about everything. To make a coherent
picture I had to make some suppositions, which may well be wrong.
So I'd appreciate a review
lternatives to systemd, please join this mailman list
http://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity
We are particularly in need of more `desktoppy' expertise.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.
ll, one implementation of it at least.)
That seems rather tenuous, compared to the amount of effort involved
in this programme to get rid of the use of embedded md5 copies.
Anyone want to suggest a further or better benefit ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed yo
able feature to
automatically turn an MR into a series of patchbomb emails rather than
one email?)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> Lumin writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> > 1. Isn't "incomplete backtrace" a sensible reason to keep debug symbols?
> >Policy said "should" but
ctually expect to have to update the md5
implementation somehow, there is little practical purpose.
Loosening transitions like this generally makes life easier for users
and downstreams. And our own official backports repo is only one of
our downstreams.
Ian.
--
Ian JacksonThese opinions are m
Russ Allbery writes ("Re: no{thing} build profiles"):
> Minimal installation size is *not* the only goal here. Ease of use and
> lack of surprise is important to. Personally, I'd much rather have
> numerous unused packages installed than to have something break in an
> opaque way when I try to us
Ivan Shmakov writes ("Re: Debian Buster release to partially drop non-systemd
support "):
> Ian Jackson writes:
> > Please come to debian-init-divers...@chiark.greenend.org.uk.
>
> Do you plan to also make that list accessible via NNTP (perhaps
> via
probably
sue you for the money.
TBH I doubt they would get you prosecuted or sue you - because they're
not that kind of people and wouldn't want to harm the free software
community = but I hope you will agree that you should act legally!
Regards,
Ian.
--
Ian JacksonThese opinions are my ow
Is this advocacy subthread really useful ? If we have bugs to report
in systemd stuff we should report them in the BTS, not debate them on
debian-devel.
Adam Borowski writes ("Re: Debian Buster release to partially drop non-systemd
support"):
> On Tue, Oct 16, 2018 at 08:38:06PM +0200, Bastian B
of this also works on a system with
> sysvinit?
Obviously it would be better to make ti work with cron. Ideally it
would go into cron.daily which I assume works with systemd too.
But if you do just the systemd thing, I think if someone sends you a
patch to make it work with cron I think you
KatolaZ writes ("Re: Debian Buster release to partially drop non-systemd
support"):
> The problem that spurred this thread is that sysvinit needs a
> maintainer. That's why some of us are here: our intention is to help
> with maintaining sysvinit in Debian if possible, since we will keep
> maintai
Martin Steigerwald writes ("Re: Debian Buster release to partially drop
non-systemd support"):
> Ian, cc'ing you to make you aware of this discussion, in case you
> aren't, and give you an opportunity to comment on your aim to adopt
> sysvinit package from some time ago.
Thanks. That's very he
for a way to *extend* rather than *specify* the
flake8 ignore list. I found that it is possible to fish the existing
list out of the relevant python module, but I didn't know how to write
such a programmatic thing in setup.cfg.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I em
Guido Günther writes ("Re: Bug#910446: NMU diff (substantive patches in
git-format-patch form)"):
> On Sun, Oct 14, 2018 at 03:36:49PM +0100, Ian Jackson wrote:
> > Hi. I fixed this bug, and some other FTBFS, and am about to upload
> > the result. I'm doing this my
Ian Jackson writes ("Re: Asciidoc transition to the python3 implementation or
just EOL"):
> I know nothing about this. What are the relative advantages and
> disadvantages of asciidoctor vs asciidoc ? Do they process the same
> documents in exactly the same way ?
It occ
201 - 300 of 2524 matches
Mail list logo
