Bug#590895: Bug#717531: marked as done (/sbin/shutdown: shutdown -P sets INIT_HALT to POWERDOWN instead of POWEROFF) [and 1 more messages]
Control: reopen -1 = Control: tag -1 + fixed-upstream > From: Jesse Smith > To: n-cl...@bugs.debian.org > Subject: Fixed upstream > Date: Sun, 28 Oct 2018 16:20:36 -0300 > > This bug has been address upstream. Thanks, it's great that you're taking an interest, but I'm afriad closing the bug in the Debian BTS this way is premature. The fix is not in Debian yet. These bugs will be marked closed by the corresponding upload to Debian, assuming that the debian/changelog mentions them. The `fixed-upstream' tag is used for this state. 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.
Bug#811377: closed by Dmitry Bogatov (Bug#811377: fixed in sysvinit 2.88dsf-60)
Axel Beckert writes ("Re: Bug#811377: closed by Dmitry Bogatov
(Bug#811377: fixed in sysvinit 2.88dsf-60)"):
> Yes, by default all DDs, but only DDs can push to a repo under
> /debian/. But in comparison to Alioth, it's easy to add write access
> for single guest accounts to a single repo.
>
> If Ian and Benda don't oppose, I'd give Dmitry write access to
> /debian/sysvinit/.
Please do.
I dont have time right now but can you please introduce Dmitry for me
on debian-init-diversity ? AIUI he's subscribed to the list.
It might be worth mentioning that he did an upload to experimental
intending to adopt the package, unaware of our efforts (in part
because we failed to write to this RFA bug about them), but that we
are welcoming him, or some such.
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.
Bug#586709: closed by Thomas Goirand
Jesse Smith writes ("Bug#586709: closed by Thomas Goirand"):
> That's just the thing, it is not a bug in this package. The bug exists
> in the init scripts, not in the sysvinit package.
On my stretch system here /etc/init.d/halt is in the `initscripts'
package which comes from the `sysvinit' source package. So I think
this is a bug in the sysvinit source package, in Debian, at least.
That it's a bug in just that one package is good because if halt
sometimes does its work by indirecting via init(8) and
/etc/init.d/halt, then it is more convenient to improve the
communication if both things are in the same package.
/etc/init.d/halt is a conffile so if we extend the protocol by which
it receives its instructions we also need to think about backward
compatibility in some sense.
Ian.
Bug#907199: Should the weboob package stay in Debian?
Chris Lamb writes ("Re: Should the weboob package stay in Debian?"):
> I was led to believe — althought naturally feel very free to
> correct me — that the AH team were (quite correctly,) handling this
> issue and thus I have not been taking action on it myself as
> leader@.
>
> I therefore also eagerly their opinion and/or correction this
> matter.
Please see the AH team's response here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907199#47
ISTM that the AH team have done a very helpful job, providing a clear
opinion about both: (i) the suitability for Debian of the package in
its current state; and (ii) the proper way to implement that,
sociopolitically.
Personally even though I think this package is unacceptable in its
current state, our tradition in Debian would normally be to leave the
package in old releases and remove it only from new ones.
So, should the next thing be an RM bug requesting the package be
removed from unstable ?
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.
Bug#586709: Think I found the problem
Jesse Smith writes ("Bug#586709: Think I found the problem"):
> [implementation details]
Thanks for looking at this bug. I'm afraid I don't think I agree that
it should be closed, though.
AFAICT the user's complaint is that, when halt or poweroff actually
invoke shutdown, the actual halt/poweroff action is chosen differently
to the situation when halt or poweroff does the work itself.
That seems contrary to the behaviour described in halt(8). So at the
very least the manpage is wrong.
However:
I took a look at halt(8), shutdown(8) and the comment in
/etc/default/halt. Frankly, the situation is confusing and
ill-documented. The interactions of the various options to halt, and
the various options to shutdown (which, confusingly, use some of the
same lowercase letters for different things) are not properly
explained.
I think the best solution here would *not* be to attempt to describe
the current actual behaviour in the manpages. Rather, it would be to
try to write down what the desired behaviour would be, and then
document and implement it.
ISTM that one key principle of that desired behaviour is that the
ultimate stopping behaviour of halt/reboot/poweroff should be the
same, regardless of whether it works by calling shutdown, or by doing
the work itself right away.
> Long answer: The script is basically set up to work on auto-pilot and
> use /etc/default/halt as the only way to pass in parameters.
If necessary (which seems likely), halt(8) could leave a dropping in
/run or something to tell the init script what to do.
Thanks,
Ian.
Bug#865086: [Pkg-xen-devel] Bug#865086: xen-hypervisor-4.8-amd64: Default grub entry broken with locales (how to reproduce)
Hans van Kranenburg writes ("[Pkg-xen-devel] Bug#865086:
xen-hypervisor-4.8-amd64: Default grub entry broken with locales (how to
reproduce)"):
> What am I doing wrong, so that the first test already doesn't give me:
> "Debian GNU/Linux, met Xen-hypervisor"
You are missing the -d option to gettext.
root@thule:~# LANGUAGE=nl_NL.UTF-8 LANG=nl_NL.UTF-8 gettext -d grub '%s, with
Xen hypervisor'; echo
%s, met Xen-hypervisor
root@thule:~# LANGUAGE=nl_NL.UTF-8 LANG=nl_NL.UTF-8 TEXTDOMAIN=grub gettext
'%s, with Xen hypervisor'; echo
%s, met Xen-hypervisor
To reproduce the bug you have to not have GRUB_TERMINAL set (or set to
`gfxterm'), because grub-mkconfig thinks that other GRUB_TERMINAL
values including `serial' preclude non-ASCII characters, and that
causes it to set LANG=C. (Look in /etc/default/grub.)
Ian.
Bug#906119: Should the weboob package stay in Debian?
Ian Jackson writes ("Re: Should the weboob package stay in Debian?"):
> I look forward to hearing from the Debian maintainer, who I think is
> the first point of contact for the management of the package in
> Debian.
I am concerned about the lack of progress. I would be grateful for
advice on what I should do next.
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.
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Tollef Fog Heen writes ("Bug#904302: Whether vendor-specific patch series
should be permitted in the archive"):
> Second draft:
...
> The Committee recognises that there is a need for packages to behave
> differently when built on different distributions, but this should be
> done by using different source packages, or as part of the build
> process, using current and future practices such as patches with
> conditional behaviour, patching of files during the build, rather than
> at source unpacking time.
This is all good but can I suggest using the phrase `differing source
packages' rather than `different' ? `Different' might mean source
packages with different source package name. `Differing' more clearly
refers to source packages of the same name but which are different to
each other.
Thanks,
Ian.
Bug#880554: #880554: max grant frames problem
Control: retitle -1 max grant frames problem (domu freeze with linux-image-4.9.0-4-amd64) Control: severity -1 important Control: reassign -1 src:xen 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9 Just gardening here. (i) Bug title should mention grant frames. (ii) This does not affect all use cases and is not, IMO, RC. Although we should certainly see if we can improve it. (iii) Britney is confused because the bug was reassigned to xen-hypervisor-4.8-amd64 and thinks that updating to the 4.11-based packages from sid would help reduce RC bugs since they lack that .deb. This is wrong, of course. For this reason in general bugs should be reported against src:xen rather than against binary packages with Xen versions in their package name. 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.
Bug#911045: xenstore-utils: removal of xenstore-utils makes files disappear from xen-utils-common
Control: severity -1 normal
Control: retitle -1 xenstore-utils should declare Breaks old xen-utils-common
Ian Jackson writes ("Re: xenstore-utils: removal of xenstore-utils makes files
disappear from xen-utils-common"):
> Indeed I looked at the log and it does show a downgrade, not a
> removal, of xenstore-utils.
As discussed, I don't think this is an RC bug. We should improve it
though at some point, by adding a Breaks, as that is straightforward.
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.
Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Please mount cgroup automatically
Thorsten Glaser writes ("Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Please
mount cgroup automatically"):
> On Wed, 17 Oct 2018, Ian Jackson wrote:
> > I notice that on my laptop I have some binfmt_misc filesystem mounted.
> > I'm pretty sure I don't use anything that uses binfmt_misc. I also
> > have something called pstore. IDK what that is. It's emty so I guess
> > I'm not using it.
>
> I’m a bit concerned about all these.
>
> They increase the attack surface, they need resources
> (especially on older or embedded-ish architectures),
> and they clutter the visual output of, if not df(1),
> then at least mount(8), to a point where one requires
> manual postprocessing to make it legible.
Well, these are reasonable points. Certainly I don't care enough to
strongly advocate getting rid of the cgroupfs-mount package and you
seem to care enough to advocate keeping it.
If you think we should adopt a similar approach for other kernel
filesystems then I guess you might want to go to d-policy about that.
Regards,
Ian.
Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Please mount cgroup automatically
Thorsten Glaser writes ("Bug#769494: [Pkg-sysvinit-devel] Bug#769494: Please
mount cgroup automatically"):
> On Wed, 17 Oct 2018, Daniel Abrecht wrote:
> > I don't think mounting cgroup is sysvinits job. Mounting cgroups can be
> > done using /etc/fstab and/or using the cgroupfs-mount package. I don't
> > mind it being always added though.
>
> Why? I mean, what for? I run dozens of systems without it.
Always mounting it would simplify things somewhat, overall. There
would be a very small additional complexity on systems that didn't
need it, but a quite large benefit in not having to maintain a
separate mount-it package and so on. In general this is how we handle
these kernel filesystems, usually (but not invariably - see the
special xen fs).
This is all assuming that there aren't any significant downsides to
mounting it.
I notice that on my laptop I have some binfmt_misc filesystem mounted.
I'm pretty sure I don't use anything that uses binfmt_misc. I also
have something called pstore. IDK what that is. It's emty so I guess
I'm not using it.
This all seems harmless enough. Am I wrong about cgroup ?
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.
Bug#769494: Please mount cgroup automatically
Daniel Abrecht writes ("Bug#769494: Please mount cgroup automatically"):
> I don't think mounting cgroup is sysvinits job. Mounting cgroups can be
> done using /etc/fstab and/or using the cgroupfs-mount package. I don't
> mind it being always added though.
Thanks for your message.
I confess I am very ignorant but I don't understand why it would be a
bad idea for this to be mounted on all systems.
If the existence of cgroupfs-mount is just there to do this, because
sysvinit doesn't, it seems like a lot of trouble. Maybe it would be
better to have sysvinit do it, always, and then we could get rid of
cgroupfs-mount and packages that wanted this facility wouldn't need to
write anything in their control file.
OTOH the current situation sounds tolerable.
I have CC'd `cgroupfs-mo...@packages.debian.org' which is the
maintainers of that package, so that they can have an opinion. (I'm
afraid this mail will come across as a bit ignorant because I'm not
really in a position to do any proper research like reading the rest
of this bug or the cgroupfs-mount package description.)
> This is my first mail to the debian bug tracker, I hope I was able to
> help and to give some new helpful perspectives on this matter.
Thank you for your contribution to Debian. I thought your message was
very helpful, even if I don't know that I 100% agree with your
conclusion :-).
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.
Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
Russ Allbery writes ("Bug#911165: debian-policy: drop requirement to ship
sysvinit init script with same name"):
> This is not the sort of thing that we should be dropping on an ad hoc
> basis given the project decision to support multiple init systems, since
> if we give up this principle it will be *extremely* hard to re-establish
> it.
>
> That doesn't mean that we can't decide to drop formal sysvinit support.
> It does mean that we should do this properly, as a project-wide decision,
> which is way, WAY beyond the scope of Policy and is *absolutely not*
> something that we're going to be able to decide here on this mailing list
> or in this bug report.
Needless to say I agree with all of this.
Obviously when there are situations where providing an init script is
actually wrong (because under sysvinit or other systems the daemon is
started some other way), the init script should not be provided.
In the existing text, this could be done as follows:
| However, any package integrating with other init systems must also
| be backwards-compatible with sysvinit
+ | , usually
| by providing a SysV-style init
| script with the same name as and equivalent functionality to any
| init-specific job
As for the Russ's point about exact equivalence, that would be dealt
with by something like this:
| script with the same name as and
+ | roughly
| equivalent functionality to any
| init-specific job
Ian.
Bug#911176: [Pkg-sysvinit-devel] Bug#911176: upgrade loops indefinitely
Petter Reinholdtsen writes ("Bug#911176: [Pkg-sysvinit-devel] Bug#911176:
upgrade loops indefinitely"):
>
> Note, it is unlikely the problem is in initscripts. It is more likely
> to be an incorrect dependency in one of the other init.d scripts
> involved. When it is known which, I recommend to reassign this bug to
> the correct package.
Even so, surely insserv shouldn't just spin. It should break the
cycle (perhaps badly) and be able to carry on.
I've asked rjk on irc for a copy of the /etc/init.d, but:
> I further recommend to have a look at the output from
> /usr/share/insserv/check-initd-order, and to wrap up the output from
> /usr/share/insserv/make-testsuite as an attachment to this bug to allow
> anyone to try to reproduce the problem.
Cool, I didn't know about that. Much better.
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.
Bug#776413: The priority of the ed package
What I don't understand is: why are we even having this conversation ? What good reason can possibly have motivated #416585 ? Certainly not the tiny use of disk space in small installs. The only motivation I can guess at is a desire to be tidy and delete "obsolete" things. That would be a very very bad reason. 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.
Bug#776413: The priority of the ed package
Ian Jackson writes ("Bug#776413: The priority of the ed package"):
> Bastian Blank writes ("Re: Bug#776413: The priority of the ed package"):
> > Serial lines have absolutely no problem with vim or similar stuff. ANSI
> > command sequences work on all of them. You may need to restrict
> > yourself to 80x25.
>
> You mean `you may need to make sure that all of your relevant terminal
> windows are exactly 80x25 or risk data loss'. I hop I don't need to
> explain why
that is a bad plan.
Ian.
Bug#776413: The priority of the ed package
Ian Jackson writes ("Re: Bug#776413: The priority of the ed package"):
> I don't think ex is in the base system. Are you suggesting that an
> implementation of it should be added ? On my system here it seems to
> be provided by vim.tiny and /usr/bin/ex is 20x the size of /bin/ed.
Another reason to want ed is that in some circumstances there is only
room for ed. So users familiar with these situations become used to
using `ed' which is more likely to be available.
-rwxr-xr-x 1 root root 46572 Feb 25 2014 /bin/ed*
The binary package is about 55k depending on arch.
Ian.
Bug#776413: The priority of the ed package
Bastian Blank writes ("Re: Bug#776413: The priority of the ed package"):
> On Tue, Oct 16, 2018 at 11:49:58AM +0100, Ian Jackson wrote:
> > This makes it sound theoretical, or a question of breaking people's
> > `finger macros'. That is indeed annoying. But there is a much more
> > serious practical point, which Paul Hardy touches on.
>
> How many people are using "ed" and not for example the still installed
> "ex"?
I don't think ex is in the base system. Are you suggesting that an
implementation of it should be added ? On my system here it seems to
be provided by vim.tiny and /usr/bin/ex is 20x the size of /bin/ed.
> Serial lines have absolutely no problem with vim or similar stuff. ANSI
> command sequences work on all of them. You may need to restrict
> yourself to 80x25.
You mean `you may need to make sure that all of your relevant terminal
windows are exactly 80x25 or risk data loss'. I hop I don't need to
explain why
> > Conversely, ed works perfectly. It can also be used as a pager (since
> > less doesn't work properly either).
>
> We have "more".
At least `more' is in the base system...
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.
Bug#776413: The priority of the ed package
Lev Lamberov writes ("Bug#776413: The priority of the ed package"):
> Some time ago (see, #416585) the priority of the ed package has been
> changed to "optional", but ed is still a part of POSIX standard. For me
> personally the main issue here is the interpretation of "Unix-like" in
> the Debian Policy: "Important programs, including those which one would
> expect to find on any Unix-like system."
This makes it sound theoretical, or a question of breaking people's
`finger macros'. That is indeed annoying. But there is a much more
serious practical point, which Paul Hardy touches on.
There are still situations, even in modern systems, where the terminal
connection is limited to a serial line or equivalent. In that
situation full-screen editors tend to malfunction because they do not
know the screen size (or, sometimes, terminal type).
Screen size mismatches can cause cursor positioning errors and thereby
mislead the user into making wrong edits. This is particularly true
of editors like vi which make highly optimised use of the terminal,
minimising the amount of redraw. I have actually experienced this,
although luckily it did not lead to any serious lossage. [1]
Conversely, ed works perfectly. It can also be used as a pager (since
less doesn't work properly either).
Therefore since forever I am in the habit of using ed on serial
terminals. I have generally only ed on the serial console of chiark,
for example. That is a situation where I would not trusted nvi or vim
or emacs (all of which are of course available) to do the right thing.
I have also used ed on the serial console of a small embedded computer
for similar reasons.
This problem tends to arise in circumstances where it is inconvenient
to install ed. On a recent occasion fixing another broken install I
had to resort to perl -i~ to edit /etc/apt/sources.list because ed
wasn't installed and I didn't want to trust nano or vi.
ed is also really good at handling cut-and-paste in both directions -
avoiding insertions of newlines, furniture, prompts, line wrap
indicators, etc.. That often turns out to be helpful in the
same situations.
So not having ed in the base system is a real nuisance.
[1] The demo. Steps to reproduce:
1. Open an 80x24 xterm on Debian stretch
xterm -geometry 80x24 &
2. In that terminal, set up the demo environment
yes | nl -ba | head -50 >t
stty rows 80
Now you are simulating a serial line setup where the window
on the computer at the near end of the line (ie, the one
you are physically sat at and whose keyboard you are using)
is smaller than believed by the remote computer (the embedded
computer, or the machine in the colo, where you are trying to
fix things by editing files).
3. Run your favourite editor
nano t
vim t
emacs -nw t
In particular, with vim: observe that what seems to be displayed is
lines 28 onwards. Say `j' twice to go to line 30, `i' to insert at
line 30, insert the letter `x', press ESC, ZZ. If you now
grep x t
you will see that it was inserted at line 3. The file looks nothing
like it did on screen.
With nano: you will see an apparently normal nano display. Try
page-down a couple of times and observe that it is impossible to view
the rest of the file. If you then type some inserting characters they
appear in the menu, obscuring how to exit. If you say ^X, remembering
that that is how to exit, you are offered No or Cancel but the
question is missing.
With emacs: you will see an apparently blank file.
Analysis:
None of these programs are expected to work properly in this
situation. The displays are very seriously misleading and will
generally lead to the user corrupting the file if they don't notice.
In the case of nano one might notice too late that things are going
wrong and be stuck in the program because the reminder of the unusual
exit keystroke has gone!
Generally the symptoms are less bad when the terminal is bigger than
the editor thinks, but there is certainly no guarantee by any of these
programs that they will not seriously malfunction in that case. (Such
a guarantee would be almost impossible to make since it would depend
on unknowable terminal behaviours.)
Careful and experienced users will have learned to avoid all full
screen programs over ad-hoc serial sessions. If that is too
inconvenient, it is possible to manually `stty' to set the terminal,
being sure to get the numbers right, or rely on a program like
resize(1)). But then one must remember not to resize the window !
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.
Bug#911045: xenstore-utils: removal of xenstore-utils makes files disappear from xen-utils-common
Ian Jackson writes ("Re: xenstore-utils: removal of xenstore-utils makes files
disappear from xen-utils-common"):
> > The installation sequence to reproduce this problem is
> >
> > apt-get install xen-utils-common/stretch
> > # (1)
> > apt-get install xenstore-utils/sid
> > apt-get remove xenstore-utils
> > # (2)
>
> But this is not possible because xen-utils-common Depends on
> xenstore-utils (even in stretch). You could in theory upgrade only
> xenstore-utils and then downgrade it again, to make the files
> disappear, but I don't think that is supported. And in practice
> no-one would do that.
>
> So I don't think this is a bug we care about.
Indeed I looked at the log and it does show a downgrade, not a
removal, of xenstore-utils.
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.
Bug#911045: xenstore-utils: removal of xenstore-utils makes files disappear from xen-utils-common
> The installation sequence to reproduce this problem is > > apt-get install xen-utils-common/stretch > # (1) > apt-get install xenstore-utils/sid > apt-get remove xenstore-utils > # (2) But this is not possible because xen-utils-common Depends on xenstore-utils (even in stretch). You could in theory upgrade only xenstore-utils and then downgrade it again, to make the files disappear, but I don't think that is supported. And in practice no-one would do that. So I don't think this is a bug we care about. 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.
Bug#904248: Beginnings of a patch to add netbase to build-essential
Josh Triplett writes ("Bug#904248: Beginnings of a patch to add netbase to
build-essential"):
> On Mon, 15 Oct 2018 13:39:32 +0100 Ian Jackson
> wrote:
> > My proposed wording about "longstanding and conventionally available
> > service and protocol names and numbers" says that if the admin has
> > modified the file they need to make sure their modified version isn't
> > toally borked.
>
> Which effectively means the admin should never delete any existing entry
> in the file, only add their own.
It's a config file. If you make semantically unwise changes to a
config file you get to keep all the remaining pieces. I'm not sure
why that is controversial ?
> It doesn't seem reasonable for a package to require a particular entry
> in a conffile in order to build. Packages should contain that
> information themselves.
Looking up protocols and services entries at build time was once
regarded as good practice. And there is nothing particularly wrong
with it.
> Much like /usr/share/misc/pci.ids and other such databases that record
> the state of the real world and standards committees, editing these
> files at all seems questionable. Suppose, hypothetically, that these
> files all moved to /usr/share/misc/ , and then libnss_files.so learned
> to read both /etc/$file and /usr/share/misc/$file , with the former not
> existing by default? (We could also switch to a faster lookup mechanism,
> but let's not change too many things simultaneously.)
This is all a lovely hypothetical world.
> (This is separate from the problem that netbase should *still* not be
> build-essential, as several have said on this thread. Personally, I'm
> leaning increasingly in the direction of "even an explicit build-depends
> on netbase should be treated as a sign of a bug in the package".)
You don't seem to be addressing the same situation as I am at all.
And you don't have any answer to gregor herrmann's point that these
failures are not uncommon. I don't understand what the huge objection
is to this pretty harmless package.
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.
Bug#904248: Beginnings of a patch to add netbase to build-essential
Bill Allombert writes ("Bug#904248: Beginnings of a patch to add netbase to
build-essential"):
> What about the fact that these files are conffiles ?
What about it ?
My proposed wording about "longstanding and conventionally available
service and protocol names and numbers" says that if the admin has
modified the file they need to make sure their modified version isn't
toally borked.
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.
Bug#910446: NMU diff (substantive patches in git-format-patch form)
Guido Günther writes ("Re: Bug#910446: NMU diff (substantive patches in
git-format-patch form)"):
> It's not that much trouble for me but rather sad that people spent time
> on (in this case) just tedious work while they could fix other stuff
> in the same time since the maintainer is already on it.
Ah. Well, then, thanks for your consideration.
I hope you are able to use most of what I did. I expect if you rebase
my series onto your master with a conflict strategy of just taking
master's version, you'll have most of it done.
As an aside, I looked 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 emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#776413: Policy violation: ed priority "optional", should be "important"
Paul Hardy writes ("Bug#776413: Policy violation: ed priority "optional",
should be "important""):
> I know that the package priority is up to the FTP Masters and not up
> to any of us. I just mention the above as input for the ed maintainer
> to discuss with the FTP Masters if so desired.
I thought the bug that ed was not in the default install had been
fixed. I agree that it ought to be in all but the most minimal
installations.
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.
Bug#910446: NMU diff (substantive patches in git-format-patch form)
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 myself, right away, because this is an RC
> > bug which has triggered the autoremover to want to remove dgit.
> >
> > Following the recommendation in dev ref 5.11.1, I have not use
> > DELAYED; and because I doubt that actually uploading it now will cause
> > you any difficulty. I hope that's OK.
> >
> > The patches I made are attached. You can also find this as a git
> > branch, here:
...>
> That's actually not what I prefer since I
Sorry about that. But,
> - said I'm about to fix this
I did look in the bug [1] before starting work, this lunchtime UK
time, and there was no response there.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910446
I have just checked the bug again, and your message to it crossed with
my decision to go ahead with the upload. The timestamp on the
relevant .changes file shows that I did my formal build-for-upload at
14:28 UTC. I and evidently spent a few minutes getting my NMU diff
email into shape and I sent that email at 14:36 and did the actual
dgit push at 14:37.
Your message to the bug was at 14:31 UTC. I confess didn't check the
bug again in the 9 minutes between `dgit sbuild' and `dgit push'.
To be honest, if you had said any time in the past week, in the bug,
that you were intending to fix it I would have been quite happy to
leave the work to you. But there was nothing from you in the bug and
the upstream git server (which I was able to see via http, even if the
git interface was giving me trouble) showed no recent activiy.
> - there's plenty of time until the autoremoval hits us
I'm generally quite busy and I had time and headspace to do this
technical work now. I wasn't confident that that would occur again in
the next few weeks.
I'm sorry to be told that I have engaged in "sub par interaction". I
was trying to help. Can you explain to me what concrete problem my
action has caused you ?
I appreciate that being the recipient, several times a year, of
autoremoval notifications (not just from gbp) is a hazard of sitting
on top of a large dependency stack. But it would be nice to be able
to at least fix these things oneself without being criticised.
It would be really helpful if people would respond to RC bugs *before*
their entire reverse dependency stack has received an `autoremoval'
email.
I guess I can be criticised for not emailing the bug before starting
work. Looking at my irc transcript it looks like I started at 12:00
UTC or so. Of course once one has started on something like this it
is very discouraging to be told to stop and throw one's work away -
and I guess your message to the bug was prompted by the autoremoval
mail which had been sent ovrnight, so an additional mail from me would
have waited anyway. So probably in this case if I had emailed the bug
at 12:00ish UTC it would have made no difference.
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.
Bug#910446: NMU diff (substantive patches in git-format-patch form)
Hi. I fixed this bug, and some other FTBFS, and am about to upload
the result. I'm doing this myself, right away, because this is an RC
bug which has triggered the autoremover to want to remove dgit.
Following the recommendation in dev ref 5.11.1, I have not use
DELAYED; and because I doubt that actually uploading it now will cause
you any difficulty. I hope that's OK.
The patches I made are attached. You can also find this as a git
branch, here:
git://git.chiark.greenend.org.uk/~ianmdlvl/git-buildpackage.git -b dgit/sid
(commit hash 0259f5979f5adf1a4826344813a1b0294a01638b)
https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=git-buildpackage.git;a=shortlog;h=refs/heads/dgit/sid
or of course from the Debian archive and dgit git server with
dgit clone git-buildpackage
or in a git working tree of git-buildpackage
dgit fetch
(which will produce a ref remotes/dgit/dgit/sid).
Unfortunately my git branch is based not on the upstream history but
on the .dsc imported by dgit (because the last upload to sid was
.dsc-based rather than done with dgit push). I did try to fetch from
the upstream git server git.sigxcpu.org but I got very long delays and
strange errors and a semi-corrupted git repository (!). Sadly I was
not able to reproduce the malfunction to report it, but it scared me
off.
You should be able to rebase my series without trouble onto your own
history, though.
I hope you find this helpful and that rebasing the regexp fixes onto
your master tip is not too tiresome. I left them as the 11 separate
commits as I thought that would be more convenient.
Regards,
Ian.
>From d20c8b1efd7198af5be7836c9777c5982dd117b1 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Sun, 14 Oct 2018 13:34:04 +0100
Subject: [PATCH 01/20] .gitignore: Fetch from vcs-git (upstream)
https://git.sigxcpu.org/cgit/git-buildpackage/plain/.gitignore
This file was left out of the source package due to this bug:
#908747 Default -I and -i option should not exclude .ignore
Signed-off-by: Ian Jackson
---
.gitignore | 30 ++
1 file changed, 30 insertions(+)
create mode 100644 .gitignore
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..94c9c6e
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,30 @@
+*.pyc
+.noseids
+.coverage
+.tox/
+.ropeproject/
+coverage.xml
+gbp/version.py
+build/
+gbp.egg-info/
+nosetests.xml
+*~
+*.sw?
+\#*#
+.#*
+
+docs/*.1
+docs/*.5
+docs/buildxref/
+docs/manual-html/
+docs/manpage.links
+docs/manpage.refs
+docs/version.ent
+
+debian/git-buildpackage*.debhelper*
+debian/python-module-stampdir/
+debian/files
+debian/git-buildpackage*.substvars
+debian/git-buildpackage/
+debian/git-buildpackage-rpm/
+debian/tmp/
--
2.11.0
>From ce37f3d6396387d55af43b2372351d63a6530a23 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Sun, 14 Oct 2018 13:36:50 +0100
Subject: [PATCH 02/20] .gitignore: Add .pybuild
Signed-off-by: Ian Jackson
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 94c9c6e..3b0f8d6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,5 @@
*.pyc
+.pybuild
.noseids
.coverage
.tox/
--
2.11.0
>From 646c33a7c86e5d2a5532a9b67396a80a963b029c Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Sun, 14 Oct 2018 14:32:32 +0100
Subject: [PATCH 03/20] rfc822_date_to_git: Fix docstring for new
dateutil.parser.parse
dateutil.parser.parse now, on failure, throws ValueError containing a
tuple - now it has the troublesome string too.
This causes the tests to fail in Debian sid.
Signed-off-by: Ian Jackson
---
gbp/git/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gbp/git/__init__.py b/gbp/git/__init__.py
index b3bc599..4bb8588 100644
--- a/gbp/git/__init__.py
+++ b/gbp/git/__init__.py
@@ -41,7 +41,7 @@ def rfc822_date_to_git(rfc822_date, fuzzy=False):
>>> rfc822_date_to_git('So, 26 Feb 1998 8:50:00 +0100')
Traceback (most recent call last):
...
-ValueError: Unknown string format
+ValueError: ('Unknown string format:', 'So, 26 Feb 1998 8:50:00 +0100')
>>> rfc822_date_to_git('So, 26 Feb 1998 8:50:00 +0100', fuzzy=True)
'888479400 +0100'
"""
--
2.11.0
>From 8df9c5df4e01c34fac368840ab78fb592461e73b Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Sun, 14 Oct 2018 14:52:28 +0100
Subject: [PATCH 04/20] Makefile: Set HOME when running tests
A nonexistent directory is sufficient.
Otherwise the tests can pick up the user's git configuration, which is
undesirable. For example, I have
[branch]
autoSetupMerge = false
which causes this test
>>> clone.create_branch('foo', 'origin/foo')
>>> clone.get_merge_branch('foo')
'origin/foo'
to fail.
Signed-off-by: Ian Jackson
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index e791e9f..908d992 100644
--- a/Makefile
+++ b/Makefile
@@ -14,6 +14
Bug#910783: Remove doc-base recommendation
Andrey Rahmatullin writes ("Bug#910783: Remove doc-base recommendation"):
> Package: debian-policy
> Version: 4.2.1.2
> Severity: normal
>
> It seems to me that the consensus is that doc-base is not actually useful and
> so 9.10. Registering Documents using doc-base can be dropped.
>
> lintian has an I: possible-documentation-but-no-doc-base-registration tag,
> with
> 1872 emitted currently:
> https://lintian.debian.org/tags/possible-documentation-
> but-no-doc-base-registration.html
>
> Note that doc-base is also mentioned in 11.5: "Web Applications should try to
> avoid storing files in the Web Document Root. Instead they should use the
> /usr/share/doc/package directory for documents and register the Web
> Application
> via the doc-base package."
The problem with doc-base is not that it is a bad idea, it's that it's
not comprehensive enough.
I suggest that instead of abandoning it, we should bump the lintian
message to a warning.
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.
Bug#910737: dpkg-source -b /path/to/somewhere should not delete somewhere.orig
Guillem Jover writes ("Re: Bug#910737: dpkg-source -b /path/to/somewhere should
not delete somewhere.orig"):
> Well, this is the documented behavior for source format 1.0 (it does
> not apply to newer source formats) which has acted like this since its
> introduction in dpkg 1.3.0:
>
>
>
I'm very prepared to believe this is my bug.
> Even considering changing this seems too painful, when the easy way
> forward is to just switch to one of the new source formats. So I'm
> inclined to just close this, as one of the known historic warts of
> the 1.0 format.
I think it would be better to change the default from -sA to -sa,
even if nothing else is done.
Even better would be to change the spec for -sa/-sA/-sp to use a
temporary directory for the orig unupack.
Leaving aside the supposed merits of the new source formats, which I
don't entirely agree with: it is not in general feasible to change to
newer source formats. Someone doing QA work (especially NMUs), or a
downstream, is often not in a position to change the source format.
They need to be able to work with what they are given.
Ian.
Bug#910705: Bug#910687: dgit: build-source and push-source disregard -wc
Sean Whitton writes ("Bug#910705: Bug#910687: dgit: build-source and
push-source disregard -wc"):
> I'm pretty sure this is a straightforward bug -- unless --ignore-dirty
> or --include-dirty is specified, push-source and build-source are meant
> to error out if the tree is dirty.
There are three levels of dirtiness: contains uncommitted changes to
tracked files; contains untracked but ignored files; contains
untracked and un-ignored files.
Currently dgit only *complains* about uncommitted changes to tracked
files.
Untracked files of both kinds are deleted by -wg[f] - except that if
dgit uses a playtree it doesn't need to clean at all so it doesn't and
the files are not included but also not deleted.
That -wc does not spot untracked files is clearly a bug. But it would
be sensible to have a variant that tolerates ignored untracked files.
What -wd[d] ought to do about untracked files - especially un-ignored
ones - is far from clear. It runs rules clean and then hopefully the
build products are deleted, but clean targets are often buggy.
gitignore files are often missing or incomplete.
Hence my suggestion for -wd[d] by default to trip on untracked
unignored files, but to ignore untracked ignored ones. An ignored
file has been deliberately marked to be excluded from the source
code. And there should be an option to allow un-ignored ones too.
The underlying thing going on here is that when making a source
package the user might reasonably want to simply not include the junk
that is cluttering their tree, rather than having dgit insist on it
being either deleted or included in the output.
Ian.
Bug#910705: Bug#910687: dgit: build-source and push-source disregard -wc
Ian Jackson writes ("Re: Bug#910687: dgit: build-source and push-source
disregard -wc"):
> I think in fact that this needs to be more general. For example, with
> --clean=dpkg-source: if dpkg-source leaves untracked files, this
> should be detected. I think this check should happen any time dgit
> builds a source package.
I made this table. You'll need a wide window and a fixed-width font
and 8-column tabs.
In summary:
dgit used to always clean the tree. But push-source and build-source
don't need to (when working in a playtree, ie without
--include-dirty), so don't. I think we need to reintroduce some
variant of tree cleaning to those operations.
But I'm not really convinced that push-source and build-source ought
ever to run rules clean. So I think we need a new interpretation of
clean modes: ie, the source builds should look at the clean mode and
do *something*: and that something will be to check that it doesn't
look like a git-add was forgotten.
And then I think we need a way to override this. Given the special
nature of the various cases, I think that is going to be some new
clean modes which are varients of existing ones.
Ian.
/: = without --include-dirty
i: = with --include-dirty
ACTION ON BINARIES BUILD
ACTION ON SOURCE BUILD
ignored files unignored files
ignored files unignored files
(These are gitignored files (These are un-ignored files,
which could have resulted maybe from a build (buggy
from a build without there gitignore), or maybe
being any bug.) forgot to git add)
quite possibly present hopefully not present
often present in non-dgit pkgs
dpkg-source } (runs rules clean) (runs rules clean)
(used to run rules clean) (used to run rules clean)
dpkg-source-d } /: disregarded /: disregarded
do we want rules clean ?do we want rules clean ?
i: used*i: used*
without, makes check less good without, makes check less good
(These are (These are un-gitignored
/: disregarded /: disregarded
gitignored filesfiles left by rules clean.
i: used*i: used*
left by rules clean;Either buggy clean or
probably a bug but forgot to git add.)
not one we care about)
/: ** should trip **
/: ** should trip **
** wddu ? ** ** want opt to disregard **
** want opt to disregard **
aka --dpkg-source,untracked
git } deleted deleted
/: disregarded /: disregarded
git-ff }
would be fine to delete but
** better to trip ? **
** want opt to disregard **
i: used*i: used*
check trips trips
/: disregarded /: disregarded
i: used*i: used*
both: ** should trip ** both: ** should trip **
** wci ? **
** want opt to tolerate (only) ignored files **
aka --clean=check,ignore
none/: disregarded /: disregarded
/: disregarded /: disregarded
i: used*i: used*
Bug#796257: dpkg-dev: dpkg-source does not respect permissions from tarball when umask is set to 0002
Stéphane writes: > Concerning #390915, I don't agree with the way the original (LP > #51468) bug was fixed. Again, plain tar behaves correctly IMHO. Sorry that I didn't reply at the time. I found this bug again now. I still think that the fix in #390915 is correct. Unpacking source code definitely ought to respect the user's umask. Otherwise the source will not be writeable to their collaborators, as intended. That tar (often, depending on options) behaves differently is because tar is trying to be several different kinds of utility in one. I think a package build where the output file permissions depend on the user's umask is a buggy package build. (And this is not just a reproducibility issue.) This is what we have dh_fixperms for: to manage the difference between source file and intermediate build product permissions (which should respect the user's umask) and binary-package-in-preparation permissions (which need to be those intended for the output package). Does that make sense ? 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.
Bug#645157: dpkg-source: handling of symlinks to external files
I stumbled across this bug. Paul writes: > And more fundamentally, dpkg-dev should never extract or follow > symlinks that point outside the source package. That includes all > absolute ones and any relative ones with too many .. in their link > target. Even if dpkg-source doesn't write to them during unpack, > they could have some other impact on the user's system if they > access them thinking that since Debian source packages are > self-contained they should be safe. I agree with this. Raphaël writes: > dpkg-source delegates extraction to tar. It can't easily cherry-pick > what to extract... It could search the tree for bad links after extraction but before exiting status 0. Or we could request that tar grow an option like rsync's --safe-links. 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.
Bug#910740: dgit: please enable make --include-dirty work with --build-products-dir
Mattia Rizzolo writes ("Bug#910740: dgit: please enable make --include-dirty
work with --build-products-dir"):
> Package: dgit
> Version: 7.1
> Severity: wishlist
> Control: block -1 by 910737 865426
>
> As requested in Bug#910725 ("something eats ../foo_1.2.3.orig.tar.gz")
> I'm opening this bug here to track the re-enabling of this feature,
> after the relevant dpkg-source bugs have been fixed.
Thanks. For my reference, the place that needs to be fixed is
build_source, by the error message about this not being supported.
My proposed implemntation is for dgit run dpkg-source in the bpd,
passing the absolute path of $maindir as the argument to -b.
Ian.
Bug#910737: dpkg-source -b /path/to/somewhere should not delete somewhere.orig
mason.orig/debian/po/ru.po /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/debian/po/sv.po /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/debian/po/templates.pot /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/debian/po/tr.po /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/debian/po/vi.po /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/debian/po/zh_CN.po /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/debian/postinst /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/debian/postrm /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/debian/rules /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/debian/templates /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/debian/watch /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/firewall /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/mason /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/mason-decide /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/mason-gui-text /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/mason-gui-text.1 /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/mason.1 /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/masonlib /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/masonrc /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/samlib /home/ian/things/Dgit/Bugs/910725/abspath/mason.orig/ttt dpkg-source: info: use the '3.0 (quilt)' format to have separate and documented changes to upstream files, see dpkg-source(1) dpkg-source: info: building mason in mason_1.0.0-12.4.dsc zealot:bpd> ls ../mason.orig /bin/ls: cannot access '../mason.orig': No such file or directory zealot:bpd> -- 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.
Bug#910725: dgit: something eats ../foo_1.2.3.orig.tar.gz
Control: tags -1 pending
Mattia Rizzolo writes ("Bug#910725: dgit: something eats
../foo_1.2.3.orig.tar.gz"):
> Thanks for prodding here. Indeed, trying to reproduce cleanly revealed
> that it is more involved than suspected.
Thanks. Oh god, this is a horror. As I wrote on irc, I'm going to
"fix" this by forbidding --include-dirty with bpd not set to ..
The reasons are explained in the comment in the commit below.
Sorry.
OTOH if dpkg-source were better, this would be fairly
straightforward. Any of the following would suffice:
(i) New option: dpkg-source --build-products-dir
(ii) fix: dpkg-source -b /absolute/path
(iii) fix: dpkg-source -b symlink-to-somewhere
NB that while having (i) for dpkg-buildpackage would be great, for
these purposes having it for dpkg-source would suffice.
Currently (ii) and (iii) seems to malfunction, although I didn't
investigate very systematically. It is probably a bug that they are
not currently rejected, at the very least. I haven't looked for
existing bugs against dpkg-dev about (ii) and (iii).
As discussed on irc, please do file (a) appropriate bug(s) against
dpkg-dev, and (b) a bug against dgit asking for --include-dirty
--build-products-dir to work, blocked by (a).
Regards,
Ian.
commit 7e5b054e22287250c05d43501d40b163ef3fec69
Author: Ian Jackson
Date: Wed Oct 10 13:40:46 2018 +0100
dgit: Forbid source building with --include-dirty non-.. bpd
Right now, this does bizarre damage to ..
Fixing this is very hard without bpd support in dpkg-source.
Closes:#910725.
Signed-off-by: Ian Jackson
diff --git a/dgit b/dgit
index 8cea07b7..d443c34d 100755
--- a/dgit
+++ b/dgit
@@ -6567,6 +6567,24 @@ sub build_source {
}
} else {
$leafdir = basename $maindir;
+
+ if ($buildproductsdir ne '..') {
+ # Well, we are going to run dpkg-source -b which consumes
+ # origs from .. and generates output there. To make this
+ # work when the bpd is not .. , we would have to (i) link
+ # origs from bpd to .. , (ii) check for files that
+ # dpkg-source -b would/might overwrite, and afterwards
+ # (iii) move all the outputs back to the bpd (iv) except
+ # for the origs which should be deleted from .. if they
+ # weren't there beforehand. And if there is an error and
+ # we don't run to completion we would necessarily leave a
+ # mess. This is too much. The real way to fix this
+ # is for dpkg-source to have bpd support.
+ confess unless $includedirty;
+ fail __
+ "--include-dirty not supported with --build-products-dir, sorry";
+ }
+
changedir '..';
}
runcmd_ordryrun_local @cmd, $leafdir;
Bug#910687: dgit: crash with perl backtrace
Mattia Rizzolo writes ("Bug#910687: dgit: crash with perl backtrace"):
> On Wed, Oct 10, 2018 at 11:51:24AM +0100, Ian Jackson wrote:
> > That seems coherent. Unless you think --include-dirty should turn
> > --clean=check into --clean=none ? That seems unwise.
>
> ACK
>
> > Consider --clean=dpkg-source --ignore-dirty, which means to run the
> > rules clean target and then tolerate uncommitted stuff.
>
> That's -wd/-wdd. Mhh, You have a point here, I should try that in the
> future. I like -wc because it's impossibly quick and usually it's the
> state I find myself in while working.
Err, sorry, when I said "consider" I meant "think about this case in
the context of the interaction between --clean=* and --ignore-dirty".
Not "please think about using -wd yourself".
-wd is v. annoying :-). It's slow and with anyone else's package it's
likely to be buggy too. Now that we have version control and *ignore
files, clean targets in makefiles are IMO obsolete.
> > I think this is because the algorithm used by dgit for quilt
> > linearisation implicitly assumes that it can use the
> > debian/source/format from your git tree. I think trying to work with
> > an uncommitted change to debian/source/format is sufficiently weird
> > that I don't mind that it goes wrong.
>
> That's a fair assumption.
> You mentioned somewhere that you could add at least a warning when
> d/source/format has uncommitted changes (or is present but untracked).
> I think I would find that useful.
OK, thanks for the feedback. I'll see if that is straightforward.
> > --include-dirty, maybe something like this:
> >
> > Changes not committed to git are not taken into account by dgit's
> > quilt fixup (see `FORMAT 3.0 (QUILT)' in dgit(7). So you may need
> > to run dpkg-source --commit yourself.
> >
> > ?
>
> I must admit that I haven't recently read dgit's documnetation (as I did
> last year, and costantly re-reading documentation you already read is
> quite boring), so I wouldn't have noticed.
> But perhaps making that point explicit could help others in the future.
Hah :-). Thanks for your input.
Ian.
Bug#910725: dgit: something eats ../foo_1.2.3.orig.tar.gz
Mattia Rizzolo writes ("Bug#910725: dgit: something eats
../foo_1.2.3.orig.tar.gz"):
> It's just a rendomly named directory. I like to keep a directory named
> the same as the package it is going to contain. So:
> ~/devel/debian/QA/mason ← random directory. I usually mkdir that
> directory, then cd in, `apt source -d $pkg` ($pkg == mason here),
> then `debcheckout -a $pkg`, or `dgit clone $pkg` in this case,
> which is going to create
> ~/devel/debian/QA/mason/mason ← git checkout of the mason package.
>
> The files that are shown there are there from previous work on that
> package, whatever that work might be.
No, I meant, what is is mason/mason. From your message the answer is
`the result of dgit clone mason' ? If that were true you wouldn't
need --include-dirty.
I want to be able to repro this bug. Can you give me a formal set of
"steps to reproduce" which start from an empty directory and use only
public data sources ?
When I file a bug that I can repro, I write `steps to reproduce' at
the same time as actually testing them. That avoids accidentally
leaving something out.
I mean, your other bug report gives me some hints about what might be
in mason/mason, but it would involve guessing which can be quite time
consuming and annoying.
Thanks,
Ian.
Bug#910705: Bug#910687: dgit: build-source and push-source disregard -wc
Mattia Rizzolo writes ("Re: Bug#910687: dgit: build-source and push-source
disregard -wc"):
> On Wed, Oct 10, 2018 at 11:34:40AM +0100, Ian Jackson wrote:
> > You never made a commit like that. The dgit import isn't because it
> > doesn't have debian/patches because it was an import of a
> > 1.0-with-diff package.
>
> Ohh, I see. I was missing this detail!
> What would you think of importing the .diff.gz in a different commit
> then? I think it would also appear a tad cleaner in the history (just
> throwing out an irrelevant idea).
dgit already imports the diff as a separate commit. Look at your
history :-). The problem is that that commit is before any change to
debian/source/format so its parent is not a `3.0 (quilt)'
patches-unapplied tree.
In your position I would have left well enough alone and kept the
package in 1.0 with diff.
Ian.
Bug#910725: dgit: something eats ../foo_1.2.3.orig.tar.gz
Mattia Rizzolo writes ("Bug#910725: dgit: something eats
../foo_1.2.3.orig.tar.gz"):
> Package: dgit
> Version: 7.10
> Severity: important
Hi. I will investigate this later. In the meantime,
> mattia@warren ~/devel/debian/QA/mason % ls
> mason mason_1.0.0-12.3.diff.gz mason_1.0.0-12.3.dsc
> mason_1.0.0-12.4_amd64.build mason_1.0.0-12.4.diff.gz mason_1.0.0-12.4.dsc
> mattia@warren ~/devel/debian/QA/mason % apt source -d mason
> Reading package lists... Done
> Skipping already downloaded file 'mason_1.0.0-12.4.dsc'
> Skipping already downloaded file 'mason_1.0.0-12.4.diff.gz'
> Need to get 507 kB of source archives.
> Get:1 http://debian.anycast-test.mirrors.debian.org/debian unstable/main
> mason 1.0.0-12.4 (tar) [507 kB]
> Fetched 507 kB in 1s (803 kB/s)
> Download complete and in download only mode
> mattia@warren ~/devel/debian/QA/mason % cd mason
> mattia@warren ~/devel/debian/QA/mason/mason (git)-[dgit/sid] % dgit
> --include-dirty build-source
Can you please tell me exactly what is in this `mason' directory here,
so that will be able to repro ? Your transcript doesn't seem to show
you creating it from anything that I have.
Regards,
Ian.
Bug#910687: dgit: crash with perl backtrace
Mattia Rizzolo writes ("Re: Bug#910687: dgit: crash with perl backtrace"):
> On Tue, Oct 09, 2018 at 11:44:34PM +0100, Ian Jackson wrote:
> > I think this diff will fix it. You can apply it directly with patch
> > to dgit in your /usr/bin if you like.
>
> Right, with your patch I see it's not crashing anymore.
>
> However I also see that:
> * without --include-dirty, it's completely ignoring the added
>d/source/format file
This is indeed wrong. I think fixing "dgit: build-source and
push-source disregard -wc" the way I plan to would fix this too.
> * with --iclude-dirty is giving up with
> error: tree contains uncommitted files and --clean=check specified
That seems coherent. Unless you think --include-dirty should turn
--clean=check into --clean=none ? That seems unwise.
Consider --clean=dpkg-source --ignore-dirty, which means to run the
rules clean target and then tolerate uncommitted stuff.
> * without -wc and with --include-dirty, it tries to its quilt
>linearisation, but it fails with:
I think this is because the algorithm used by dgit for quilt
linearisation implicitly assumes that it can use the
debian/source/format from your git tree. I think trying to work with
an uncommitted change to debian/source/format is sufficiently weird
that I don't mind that it goes wrong.
The other question is what you expected dgit's quilt linearisation to
do for you. If you use --include-dirty with a tree with
dpkg-source-uncommitted changes, I think you'll get the same error.
There is no way round this because dgit's quilt fixup generates
a *commit* containing the added patches. It wouldn't make sense to
commit patches for uncommitted changes.
That --include-dirty does not cause dgit to try to do quilt fixup for
uncommitted changes is perhaps implicit in
https://manpages.debian.org/unstable/dgit/dgit.7.en.html#FORMAT_3.0_(QUILT)
and the description of `dgit quilt-fixup' in
https://manpages.debian.org/unstable/dgit/dgit.1.en.html
but perhaps something should be included in the discussion of
--include-dirty, maybe something like this:
Changes not committed to git are not taken into account by dgit's
quilt fixup (see `FORMAT 3.0 (QUILT)' in dgit(7). So you may need
to run dpkg-source --commit yourself.
?
> I'm not sure if I'm doing something in a way I'm not supposed to do
> here.
> Note that I already worked around this bug yesterday by manually calling
> dpkg-source --commit and git commit the resulting quilt patch, at which
> point dgit goes back behaving the way I know it.
Right, that was you manually constructing the patches-applied git branch
which is what dgit works with.
Thanks,
Ian.
Bug#910705: Bug#910687: dgit: build-source and push-source disregard -wc
Mattia Rizzolo writes ("Re: Bug#910687: dgit: build-source and push-source
disregard -wc"):
> Right. I also thought about it later, and decided to try with
> --include-dirty.
> What I had expected, especially using -wc, was to give up istantly with
> a "your working tree is dirty" message, and to go on including my
> uncomitted changes with --include-dirty.
Mmm, that seems like reasonable expectations - at least the first
half. I didn't try with --include-dirty. You were intending to push,
right ? You can't push with --includ-dirty.
> But from what you say it is going to do neither.
I think with --include-dirty it might do what you expected. With that
option it builds the source package from your own working tree.
> > I infer that you want to do `3.0 (quilt)' with this package, and
> > you're using git, so you will need a git workflow tool. Which one are
> > you intending to use ? Perhaps the real problem is that you intend to
> > use git-debrebase but forgot to convert the branch (with git-debrebase
> > convert-from-dgit-view) ? Or that you intend to use gbp pq but didn't
> > make a pq branch and export it ?
>
> I only wanted to move to 3.0 out of dislike for 1.0. I don't really
> care about any patch regime here (after all, it's a one-time QA upload
> I'm doing). So, the single patch provided to me by dpkg-source --commit
> is more than great.
IMO 1.0 with diff has some compelling advantages over 3.0
single-debian-patch. One of them is that there is none of this
committing patches nonsense.
> I think that for that, the usual quilt linearisation that I saw dgit
> doing in the past is cool enough.
dgit's quilt linearisation requires that your tree is a linear (or at
least linearisable) sequence of commits on top of { the original
upstream source + your debian/ directory + whatever patches are in
d/patches already applied }.
You never made a commit like that. The dgit import isn't because it
doesn't have debian/patches because it was an import of a
1.0-with-diff package.
Or to put it another way, dgit quilt fixup transforms a branch which
is a patches-applied git tree plus some additional commits into a new
patches-applied git tree whose operative files are the same. But you
had no patches-applied git tree to start with.
> > But having done that IDK how you would rebase onto a new upstream
> > version. You'll definitely need a workflow tool for that (or I guess
> > you could do it by hand with raw git runes if you had iron
> > concentration and an iron constitution).
>
> Once the patch is committed in quilt, I'd expect to use any random tool
> for rebasing the patches? I mean, the issue you are referring to here
> sounds very orthogonal from the title of this bug report.
Yes, it is orthogonal. I'm trying to find out what you were trying to
do and why and maybe give helpful advice (via docs or direct to
you...)
You say `use any random tool for rebasing the patches' but what tool
would that be ? I don't think gbp pq can operate on a patches-applied
tree, can it ?
> Again, for clearity, I'd expect:
> * -wc to always stop *any* command from running if the working tree is
>not fully committed
I think in fact that this needs to be more general. For example, with
--clean=dpkg-source: if dpkg-source leaves untracked files, this
should be detected. I think this check should happen any time dgit
builds a source package.
> * --include-dirty to do some magic to include the untracked files in
> whatever dgit is going to do
I think that should already work.
Anyway, thanks for exploring all this with me.
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.
Bug#910687: dgit: crash with perl backtrace
Control: clone -1 -2
Control: retitle -2 build-source and push-source disregard -wc
Control: tags -2 - patch
Control: severity -2 normal
Mattia Rizzolo writes ("Bug#910687: dgit: crash with perl backtrace"):
> I'm now already falling asleep, I'll try to apply your patch tomorrow and
> report back :)
FYI, I discovered some other weirdness with what you were trying to
do.
Firstly, from your transcript, you didn't commit debian/source/format.
It's an un-ignored un-tracked file. dgit nowadays always builds
source packages in a private area and bases them on your git tree.
The result is that if you do what you did it will (i) notice the
debian/source/format in the working tree and decide to do quilt
linearisation (ii) call dpkg-source --commit in the private area in a
clean tree with no debian/source/format. The result is a 1.0 package.
This is arguably a bug. But the only thing dgit could sensibly do
would be to spot that yuu did this and stop with a complaint.
I experimented with committing debian/source/options. If I do that
dgit makes a hamfisted attempt at quilt linearisation: again, it
attempts to call dpkg-source --commit starting at a commit which does
not have debian/source/format. I will fix dgit to stop quilt
linearisation when it encounters a change to debian/source/format, and
you would then get this error message:
dgit: error: quilt fixup cannot be linear. Stopped at:
dgit: 45a228db..d5c44c79: changed debian/source/format
along with some essentially useless suggestions.
What you are asking dgit to do is rather outside of its scope. The
quilt linearisation feature is intended to support an NMUer or user
adding a few commits on top. It is not intended as a general puprose
git workflow and delta queue management tool. It certainly isn't
intended for converting from 1.0-with-diff to `3.0 (quilt)'.
I infer that you want to do `3.0 (quilt)' with this package, and
you're using git, so you will need a git workflow tool. Which one are
you intending to use ? Perhaps the real problem is that you intend to
use git-debrebase but forgot to convert the branch (with git-debrebase
convert-from-dgit-view) ? Or that you intend to use gbp pq but didn't
make a pq branch and export it ?
Having said all that, I experimented with rebasing the little stub
branch so that the dgit-generated diff import commit was *after* my
change to add debian/source/format. That resulted in a branch that
dgit was able to do quilt linearisation on. The single patch that
comes out is of course the patch form of the dgit diff import commit.
But having done that IDK how you would rebase onto a new upstream
version. You'll definitely need a workflow tool for that (or I guess
you could do it by hand with raw git runes if you had iron
concentration and an iron constitution).
Also, arguably something should have stopped you proceeding with an
untracked unignored files (perhaps, especially as you specified -wc).
But the clean mode is basically ignored with build-source (and
push-source) since the tree does not need to be cleaned. But spotting
uncommitted files is important. I'm not sure exactly what to do about
this but I have cloned this bug to track this issue. It seems odd to
say that --clean=check ought to make build-source and push-source
check for loose files, even though they usually don't actually clean
the tree at all. Perhaps there should be a separate check which
doesn't depend on the clean mode ?
Regards,
Ian.
Bug#910687: dgit: crash with perl backtrace
Control: tags -1 + patch
Mattia Rizzolo writes ("Bug#910687: dgit: crash with perl backtrace"):
> Package: dgit
> Version: 7.0
> Severity: important
Sorry about this.
I think this diff will fix it. You can apply it directly with patch
to dgit in your /usr/bin if you like.
I will make a release with the fix RSN.
Regards,
Ian.
diff --git a/dgit b/dgit
index 4cc56845..19b9eb2c 100755
--- a/dgit
+++ b/dgit
@@ -379,6 +379,10 @@ sub branch_is_gdr ($) {
printdebug "branch_is_gdr $walk ?-octopus NO\n";
return 0;
}
+ if (!@parents) {
+ printdebug "branch_is_gdr $walk origin\n";
+ return 0;
+ }
if ($get_patches->($walk) ne $tip_patches) {
# Our parent added, removed, or edited patches, and wasn't
# a gdr make-patches commit. gdr make-patches probably
Bug#904558: What should happen when maintscripts fail to restart a service
Wouter Verhelst writes ("Re: Bug#904558: What should happen when maintscripts
fail to restart a service"):
> Perhaps the error handler should also be configurable by policy-rc.d, as
> I hinted to before.
I think this is a key point. We do not have to make a single decision
which everyone has to be happy with. We can instead continue to be
all things to all people.
I think the best answer would be:
* Individual maintainers decide for themselves whether to treat
service (re)start failure as postinst failure, based on their own
perception; maintainers may make different decisions for different
init systems.
* If the maintainer has no particular reason to diverge the right
answer is usually to fail the postinst with init systems that do
not provide service supervision; but to not fail the postinst with
ones that do. (I think from earlier messages that this is how the
default implementations already work.)
* The administrator should be able to override this policy question
globally for the whole system, or on a per-package basis.
This is probably a manageable amount of actual work: the prescription
for individual package sis roughly what they do right now.
The support for configuration in something like policy-rc.d has a few
design decisions to be made but doesn't seem really difficult. Also
nothing blocks on it. The TC would simply be saying "this would be a
good thing to have".
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.
Bug#906317: dgit: consider demoting git-buildpackage to recommends
Hector Oron writes ("Bug#906317: dgit: consider demoting git-buildpackage to
recommends"):
> As I understood, DSA team had some concerns for security reasons since
> porterboxes are meant to be used to debug package build failures and
> not used for anything else, so it is much preferred a 'push' scenario
> where developers push the code to porterboxes, rather than 'pull',
> being `apt-get source` the unique exception to that unwritten policy.
That concern seems to be related to #790093 and the presence of dgit
at all, rather than the Depends on git-buildpackage ?
> So developers would like to use `dgit push` from porterboxes, however
> getting that functionality also opens a can of worms, allowing for
> pulls as well.
This is probably out of context for this bug, but:
I think developers ought not to run `dgit push' on a porterbox because
that would involve exposing their private key (via gpg agent at least)
to the porterbox. It would be better to run `dgit rpush' on their own
machine. In practice do man people try to upload directly from a
porterbox anyway ?
I confess I haven't looked at what howtos etc. we provide to porters.
Maybe we should have a `how to be a porter' guide which covers finding
a machine, proper gitish source code management, BTS interaction, etc.
(That would I think inevitably result in advising the user to run
`dgit clone' on the porterbox for the same reasons that in a legacy
source-package-based workflow they would say `apt source'. Hence the
desire to fix #790093.)
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.
Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]
Sam Hartman writes ("Bug#904302: Whether vendor-specific patch series should be
permitted in the archive [and 1 more messages]"):
> So imagine that Ubuntu and several other downstreams care more about
> security and hardening than they do about backward compatibility and
> they choose to change a number of gcc and other tool defaults in support
> of that. I realize my example is not entirely hypothetical, but I want
> to emphasize I have not researched to get all the details right, because
> it doesn't matter.
>
> Especially if multiple downstreams or individual users who build from
> source might want the change, I think carrying the delta in the Debian
> source package can be valuable. It needs to be balanced against a lot
> of other concerns.
I agree that carrying a switch-on-able delta in the Debian package
would be a good thing there. So, the meat of the change should
definitely go to Debian or maybe even to upstream as a
--with-extra-hardening configure option or some such.
This should be enabled via DEB_BUILD_OPTIONS, or a commented-out line
in the rules file, or by reading /etc/compilers/hardening-enabled at
build- or runtime, or something. Not by looking at `the vendor'.
A scenario why this is needed can be seen from this scenario:
Suppose someone wants to try to maintain a distro which is like
Debian, but which takes some subset of packages from Raspbian.
The obvious way to do this is to import most packages from Debian and
the other packages from Raspbian, and to fix up the bugs which occur
at the interface.
If packages in Debian and Raspbian use dpkg-vendor --is raspbian to
decide whether to do the Raspbian thing, then there is no way to make
this work because there is no correct answer: the answer to whether a
package should do the Raspbian thing depends not only on which distro
we are building or running on, but on which package it is.
In practice if I were maintaining that distro I would be tempted do
some kind of hideous hack to make the output of dpkg-vendor depend on
the name of package we were building. Because how else will I do it ?
Playing whack-a-mole with dpkg-vendor calls would be impractical.
If the Raspbian-specific features are enabled by carrying a changed
source package in Raspbian, then things will mostly DTRT and generally
problems will occur only when the delta-enablement is done via some
kind of indirection, and the indirection messily crosses the `cutoff'
between the Raspbian-originated and Debian-originated packages.
Ie I only have to manually fix the problems that irreducible, not ones
introduced by ill-advised calls to dpkg-vendor.
> And yes, in many cases dgit is the answer. That said, if I were
> maintaining the same package both for Debian and for the downstream I
> work on, I might well value having a single source tree enough to use
> dpkg-vendor or lsb-release or something to switch.
In that case, that is convenient for you but it is wrong for your
downstreams and users. We should be discouraging such tradeoffs.
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.
Bug#790093: No TOFU for git server host key
Ian Jackson writes ("No TOFU for git server host key"):
> I think now would be a good time to look at #790093 again. Would
> anyone from the DSA team with the requisite TLS knowledge be available
> to get together with me to sketch out a solution ?
Ping ?
I think we are nearing the end of our opportunity to improve this in
buster.
Thanks,
Ian.
Bug#906317: dgit: consider demoting git-buildpackage to recommends
Control: tags -1 + moreinfo
Ian Jackson writes ("Re: Bug#906317: dgit: consider demoting git-buildpackage
to recommends"):
> So I'm inclined to think that the subset of dgit's functionality which
> is useable without gbp pq is too small for your use case (and too
> small to make it sensible to demote this depends). But I'm happy to
> talk about it some more.
...
> What is the concern with git-buildpackage ? I understand that it's a
> big piece of software but it contains many important tools for
> managing many styles of Debian packaging git branch. I wasn't aware
> that it had significant functionality of a kind that would be
> undesirable on a porterbox.
Regards,
Ian.
Bug#905433: git-debrebase: debrebase new-upstream fails with "uninitialized value"
Sean Whitton writes ("Bug#905433: git-debrebase: debrebase new-upstream fails
with "uninitialized value""):
> On Sun 19 Aug 2018 at 08:51PM +0100, Ian Jackson wrote:
> > I think
> > convert-from-unpatched-upstream-source
> > convert-from-unpatched-upstream
> > have the same problem as
> > convert-from-unpatched
> > TBH.
>
> Could you say why you think this, please?
Because I think "unpatched" in any case means that it is the upstream
source which is unpatched because patches are always to upstream
source, so the extra words don't help. Or to put it another way
"upstream" is ambiguous and may refer to what gdr(5) calls `upstream
files' or what it calls `upstream'.
To me "unpatched" is ambiguous: it can mean that the delta queue does
not exist, or that it exists but has not been applied. But luckily
that doesn't matter ...
> > Maybe the answer is to provide aliases.
> > convert-from-gbp
> > convert-from-unpatched
> > ?
>
> I.e. these would both be aliases for a command called
> convert-from-unapplied?
Right. The key points are that:
* gbp format is the same as package-with-unapplied-delta-queue
format, modulo .gitignore (which apparently most people don't
touch).
* If there is no delta queue then the algorithm for converting a
package-with-unapplied-delta-queue will DTRT.
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.
Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]
Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should be
permitted in the archive"):
> On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote:
> > IMO policy should recomend the use of separate source packages as the
> > prefered solution to the problem that vendor-specific patch series were
> > supposed to address.
>
> In this case please make an explicit decision on whether build-time
> patching is the recommended replacement for vendor-specific patch
> series, or what kinds of build-time patching will no longer be
> permitted.
Surely the TC can recommend X without outlawing Y.
> It is not clear at all which of the above exactly you want to have
> removed from the archive and moved as permanent deltas downstream.
Speaking personally, I think that packages should almost never look at
dpkg-vendor (or equivalent, eg looking at lsb_release). Any switching
on vendor is probably a bug. The reasons why switching on vendor is
probably wrong have been rehearsed earlier in this discussion.
But I am not asking the TC to outlaw the use of dpkg-vendor et al
because:
* The dpkg vendor series feature is uniquely weird and bad. (Both in
principle, and because of what are arguably lesser design bugs.)
* Unlike the dpkg vendor series feature, the use of dpkg-vendor (or
equivalent) at build- or run-time is not directly in the way of my
project to improve our source code management processes.
* I think an effort to outlaw switching based on vendor would
generate a much bigger fight which is not worth having.
* I hope that my programme of making it easier to handle divergence
properly, by having actually different source code, and carrying
that delta indefinitely, will tempt people away from these kind of
vendor-switching approaches.
Another way to look at this is that in general, where possible, I
think transitions to new things should be done by making the new thing
attractive rather than by going around forbidding or breaking the old
thing.
Sadly the vendor series feature is too broken, and causes too many
problems for others, for that. The problems of switching on vendor
are real but much less severe so taking the carrot rather than stick
approach is much more sensible.
But of course a body like the TC should certainly recommend good
practices rather than troublesome ones.
> The TC was asked to make a decision, and a decision turning a clear
> situation into a blurry "it is permitted but kinda recommended against"
> would only create future conflicts.
We have a lot of things in Debian where one approach is recommended,
but other approaches are permitted or tolerated. This does not in
general seem to result in conflicts.
> A 1:1 vendor-specific patch series -> build-time patching change
> would be a mostly technical change. As already said this could
> even be implemented before buster.
Because I think dpkg-vendor is the wrong answer, I don't want the TC
to recommend that.
Philip Hands writes ("Bug#904302: Whether vendor-specific patch series should
be permitted in the archive"):
> However if someone reads the prohibition against vendor-specific patch
> series, and is left wondering what is the best way to deal with this
> situation, then it would probably be helpful to give them a hint.
Quite.
Ian.
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Philip Hands writes ("Re: Bug#904302: Whether vendor-specific patch series
should be permitted in the archive"):
> IMO policy should recomend the use of separate source packages as the
> prefered solution to the problem that vendor-specific patch series were
> supposed to address.
That would be great. (I suspect that it is rather controversial,
though, even though I think it is obviously correct...)
If there is consensus in the TC that this is the best approach,
putting something about it in the TC resolution as a recommendation
would have about as much weight as putting it in policy, and avoid
jurisdictional questions.
Ian.
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should be
permitted in the archive"):
> On Wed, Sep 19, 2018 at 02:39:23PM +0200, Philip Hands wrote:
> > The Committee therefore resolves that:
> >
> > 1. Any use of dpkg's vendor-specific patch series feature is a bug for
> > packages in the Debian archive (including contrib and non-free),
>
> This misses an important part of the previous proposal:
I think Phil was just intending to leave the recitals part alone, and
proposing only a change to the operative part - not to delete the
recitals.
> The Committee recognises that there is a need for packages to behave
> differently when built on different distributions, but this should be
> done as part of the build process, using current and future practices
> such as patches with conditional behaviour, patching of files during the
> build, rather than at source unpacking time.
However, now that we are talking about the recitals I would like to
suggest that the recitals should include *maintaining different source
packages in different distributions* as one of the suggested options.
IMO it is far superior to patches which are conditional (at runtime or
at build-time) on dpkg-vendor and I would not like to see that
perpetuated.
Ian.
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Sean Whitton writes ("Bug#904302: Whether vendor-specific patch series should
be permitted in the archive"):
> I would be grateful if you would micromanage just enough that there
> isn't anything controversial left for people to disagree about :)
That seems like a generally good rule for TC decisions. It avoids
another aspect of the same issue coming back to the TC; and it avoids
setting in stone things that haven't been thought through in the TC
context (and which are best answered by whatever the usual process
is),
In this case I don't think the details (of the transition away from
use of this feature, or the policy wording) are controversial; except
that the timetable, and the consequences at various times for a
package that still has a vendor series, might well be.
No-one seems to have proposed anything but "bug, RC after buster", but
of course opponents of the change are focusing on that and if the TC
just says "these are a bad thing" then an opponent of the change might
well reasonably say "OK I agree this is a bug but it is not RC" or "I
intend to fix this in buster+2".
So, borrowing Phil's text and editing slightly:
1. Presence of any dpkg vendor-specific patch series is a bug for
packages in the Debian archive (including contrib and non-free).
Such a bug should be considered release critical, but not until
after the release of Buster.
The consequences for what to write in policy, want to do in lintian,
how the release team should handle these bugs, etc., all follow
clearly from that text, except for implementaion details that can be
thrashed out in the relevant fora.
I changed "use of [the] feature" to "presence of [the] series" to
avoid the possibility that someone would disingenuously argue that a
series.ubuntu file, in a package in Debian, is not "use" of the
feature.
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.
Bug#910221: dgit: missing dependency on git-debrebase for sbuild
Control: retitle -1 dgit cannot handle git-debrebase ENOENT
Felipe Sateler writes ("Bug#910221: dgit: missing dependency on git-debrebase
for sbuild"):
> dgit cannot do sbuild without git-debrebase:
>
> % dgit sbuild
> Format `3.0 (quilt)', need to check/update patch stack
> dgit: failed command: git-debrebase --noop-ok -funclean-mixed
> -funclean-ordering make-patches --quiet-would-amend
>
> dgit: error: failed to fork/exec: No such file or directory
Oops! I thought I had handled that but evidently not.
Thanks for the report.
You can work around this by saying
dgit --git-debrebase=true
(yes, really). Or of course by installing git-debrebase, which will
be harmless, and is I guess what you did.
Regards,
Ian.
Bug#907953: network-manager-strongswan FTBFS with glib 2.58
Harald Dunkel writes ("Re: network-manager-strongswan FTBFS with glib 2.58"):
> I have created a new source package. It just disables the error message.
> When upstream releases a fixed version, this patch can be removed again.
>
> Ian, would you mind to sponsor an upload? I have signed the new tag
> debian/1.4.4-2.
Done, 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.
Bug#904302: That's a free software issue!
Anonymous writes ("Bug#904302: That's a free software issue!"):
> If Debian want patches it has to support this process with tools. The
> attitude Debian owns all source packages is wrong. Sharing source
> packages among different vendors is more efficient. Different patch
> series may be the best solution in some cases.
I do agree with the underlying ideology behind these ideas. I think
code sharing between different distros in the Debianish ecosystem is
very important and I certainly don't think that `Debian owns all
source packages', whatever that means.
Indeed, in my technical Debian work I am writing tools which I hope
will support people who want to diverge from Debian, and retain and
carry those divergences in the long term. I have long been frustrated
that it is too difficult to do this.
The problem I have with the vendor series feature is narrower and more
technical. For all the reasons I and others have explained, I think
the vendor series feature is a very poor way to support divergence and
diversity. It does more harm than good.
The background to this is that I think that Debian source packages,
which I designed in the mid 1990s and which were since extended with
`3.0 (quilt)' [1], are a clumsy system which has been obsoleted by the
new generation of distributed version control systems, especially git.
.dsc format source packages are bad enough for the newcomer to Debian,
without the very weird vendor patch series feature. And the vendor
patch series feature makes migration to better source code management
tools harder.
So in summary I think the real way to promote divergence by Debian's
derivatives, and code sharing amongst derivatives, is to use to the
full the features of very capable modern revision control systems.
TBH I don't expect this to convince you. And I found many of your
comments rather overblown. It would be helpful if you could avoid
wild accusations.
But, if you really want to help promote software freedom for Debian's
derivatives and users, by addressing issues to do with package source
code management tooling: please consider trying out dgit and maybe
suggesting it to Debian's downstreams as a way to get the source code
from Debian.
Please also consider advocating that Debian maintainers should use
dgit for their uploads. If you're very keen you could come and help
out with work on making git-debrebase become a useful tool for
downstreams.
Ian.
[1] To be clear, although I have a lot of criticisms of `3.0 (quilt)',
it is much better than what was being widely done in Debian
beforehand.
Bug#909668: Acknowledgement (FTBFS in buster and sid (probably, due to gcc-8))
On my 4.11-based rework branch I found that the following upstream commits were needed: 437e00fea04becc91c1b6bc1c0baa636b067a5cc tools/kdd: mute spurious gcc warning e1b7eb92d3ec6ce3ca68cffb36a148eb59f59613 tools: Move ARRAY_SIZE() into xen-tools/libs.h [ this is needed for BUILD_BUG_ON, which is used by the next patch ] b8f33431f3dd23fb43a879f4bdb4283fdc9465ad libxl/arm: Fix build on arm64 + acpi w/ gcc 8.2 For Xen 4.8 based packages, it may also be necessary to have 5f28de0b0e474e01931b719fa27ca30b8aa446e0 libxl: compilation warning fix for arm & aarch64 but that fix is in the upstream 4.11 branch. 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.
Bug#907835: [Pkg-xen-devel] Bug#907835: newer version in stable
Antoine Beaupré writes ("Re: [Pkg-xen-devel] Bug#907835: newer version in
stable"):
> It's been two weeks and stable still has a newer version than unstable,
> which suffers from four security issues fixed in stable.
>
> I understand you might have other plans in the long term, but in the
> meantime, why not just upload deb9u10 to unstable?
I went to do this but sadly, it no longer builds due to gcc8. There
are upstream patches that could be cherry-picked but it's certainly no
longer simply a matter of importing the security update.
I am going to look at these failures since they are blocking my
package refactoring work and I expect that as an output I will produce
a list of upstream commits to cherry pick, which I will send to this
bug.
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.
Bug#909668: FTBFS in buster and sid (probably, due to gcc-8)
ent -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .xc_pm.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -g -O2 -fdebug-prefix-map=/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273=. -fstack-protector-strong -Wformat -Werror=format-security -I../../xen/common/libelf -Werror -Wmissing-prototypes -I. -I./include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/include -D__XEN_TOOLS__ -pthread -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/libs/toollog/include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/libs/evtchn/include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/include -include /<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/config.h -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/libs/call/include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/libs/foreignmemory/include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/libs/gnttab/include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/libs/gnttab/include -I/<>/xen-4.8.4+xsa273+shim4.10.1+xsa273/debian/build/build-utils_amd64/tools/libxc/../../tools/include -c -o xc_pm.o xc_pm.c xc_pm.c: In function 'xc_set_cpufreq_gov': xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN); ^~~~ cc1: all warnings being treated as errors 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.
Bug#902809: want dgit smash-working-tree-timestamps [and 1 more messages]
Ian Jackson writes ("Re: want dgit smash-working-tree-timestamps [and 1 more
messages]"):
> Certainly it's a workaround. My goal is to make it easy for people
> who want to modify the way their systems work, to work around bugs
> they find in Debian.
>
> Certainly no Debian package maintainer ought to need this script for
> their own package.
Well, I just encountered this situation in a package I maintain
myself (with my work hat on, even!). (#909667 in src:xen.)
Even in that case, having this script would have been helpful. It
would have allowed me to instantly and reliably test my hypothesis as
to the cause. As it was I guessed the right file to touch.
> That line of code is complicated and encapsulates a significant amount
> of thought about exactly what the right behaviour is.
>
> But, if I can't change your mind I'll just put the script in dgit.
So, would you care to let me know which way I should deal with this ?
I still think this script is relevant to anyone using git for
Debian-style packages (and, maybe, to anyone using git at all). It
certainly doesn't depend on the need to deal both with git and with
source packages (which is what dgit helps with).
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.
Bug#909667: FTBFS depending on source tree timestamps
Package: xen Version: 4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1 Severity: important I did a series of manipulations in git, including dgit clone, followed by dgit fetch experimental. The package failed to build, with dpkg-buildpackage -nc -uc -b because it tried to update debian/control and the update failed because it said the version was wrong. touch debian/control "fixed" it. 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.
Bug#907199: Should the weboob package stay in Debian?
Martín Ferrari writes ("Re: Should the weboob package stay in Debian?"):
> I am writing on behalf of the Anti-Harassment team, as our input has
> been requested on this issue.
Thanks for your considered and helpful response.
>our recommendation would be to either work with
> upstream on correcting these issues, forking and/or patching it, or just
> removing the package. There is still enough time to find a solution that
> respects our users and our community while keeping a useful piece of
> software in the archive.
That would be great.
Speaking personally I am definitely willing to talk to anyone about
this but ... experience suggests that, despite my best efforts, my
communication style does not lead to happiness in these kind of
situations. I think it would be best if someone else would take the
lead in negotiations.
OTOH if it is necessary to diverge from upstream: I have a lot of
experience with build systems and version control systems and could
probably help with the technical work. I would be tempted to write a
git-filter-branch script, because that would produce a
probably-useable git history and make it easier to handle future
upstream updates.
I am happy to do that technical work if we can agree, within Debian
(including, obviously, the Debian maintainer) on the basic shape.
I look forward to hearing from the Debian maintainer, who I think is
the first point of contact for the management of the package in
Debian.
Thanks,
Ian.
Bug#909550: possible conflict over the /usr/bin/ia namespace
Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia namespace"):
> On 2018-09-25 14:22:44, Ian Jackson wrote:
> > If you can't get a better idea I would suggest
> > << 0.242+git20151019-1.1~
> > which is all versions until the next draft(~)-of-an-nmu (.1).
>
> But wouldn't <= 0.242+git20151019-1~ be as effective? Why does it need
> to be < These 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.
Bug#909550: possible conflict over the /usr/bin/ia namespace
Ian Jackson writes ("Re: possible conflict over the /usr/bin/ia namespace"):
> Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia
> namespace"):
> > On 2018-09-25 14:22:44, Ian Jackson wrote:
> > > If you can't get a better idea I would suggest
> > > << 0.242+git20151019-1.1~
> > > which is all versions until the next draft(~)-of-an-nmu (.1).
> >
> > But wouldn't <= 0.242+git20151019-1~ be as effective? Why does it need
> > to be <
> 0.242+git20151019-1 is not <= 0.242+git20151019-1~ so that is
> definitely wrong. Maybe you meant <= 0.242+git20151019-1.1~ ?
> But if I were preparing an NMU I would be intending to use
> 0.242+git20151019-1.1 as the nmu version; and my draft packages would
> be called precisely 0.242+git20151019-1.1~ and don't want to be
> conflicted against. Hence 0.242+git20151019-1.1~
I mean, hence << 0.242+git20151019-1.1~
Ian.
Bug#909550: possible conflict over the /usr/bin/ia namespace
Iain Learmonth writes ("Re: possible conflict over the /usr/bin/ia namespace"):
> On 25/09/18 14:16, Antoine Beaupré wrote:
> > ... but it hasn't been migrated to Salsa. Would you be okay to move this
> > in the Python module's team umbrella (as opposed to simply collab-maint)?
>
> The whole salsa thing is not something that I've been able to keep up
> with. I have git repos locally and I've been moving things to salsa as
> and when I do updates. You probably shouldn't trust what is on salsa
> anyway unless we all start using signed commits and tags. The archive is
> the only true record of packages.
For packages maintained by very small (or unitary) teams with limited
collaboration, ad-hoc sharing via personal git repos works OK. And of
course you can share your git branch more formally with everyone,
in step with the archive, and with reasonable security, by using `dgit
push'.
> Ok, I will close that in approx 15 minutes. (:
Yay :-). Please use dgit push, so that you share your
actually-uploaded git branch as well as just the package.
Thanks,
Ian.
(back onto the dgit plug hobby-horse)
Bug#909550: possible conflict over the /usr/bin/ia namespace
Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia namespace"):
> Makes sense. How about:
>
> Conflicts: python-duckduckgo2 (<= 0.242+git20151019-1)
>
> This way we assume any newer upload of the package will remove ia?
That's not a good choice because it excludes (local) backports,
security updates, etc., which tend to add +something to versions.
If you can't get a better idea I would suggest
<< 0.242+git20151019-1.1~
which is all versions until the next draft(~)-of-an-nmu (.1).
Ian.
Bug#909550: possible conflict over the /usr/bin/ia namespace
Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia namespace"):
> Great! I would be happy to help with that if you need any assistance.
> In the meantime, should I just upload IA to NEW? :)
You need to coordinate the transition for the /usr/bin/ia filename. I
think that means your new internet-archive package should probably
Conflict: python-duckduckgo2 (<< version-without-ia~)
That can probably be uploaded before the new python-duckduckgo2 but
the relevant version number should be agreed. And if you do upload
internet-archive before python-duckduckgo2 is changed there there
should probably be a bug against python-duckduckgo2. I guess that bug
doesn't need to be rc ?
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.
Bug#909192: mate-desktop-environment: Installing sysvinit-core removes mate-desktop-environment
Mike Gabriel writes ("Re: Bug#909192: mate-desktop-environment: Installing
sysvinit-core removes mate-desktop-environment"):
> many thanks for all this background info. I might have a potential
> contract to get this solved in the loop, so, I may probably return to
> it soon (or not so soon). Let's see...
Can you let us know when you will know whether this is going to
transpire ?
Also, we had an IRC conversation on #debian-devel about pam_systemd
and the dbus user service. I think it contains a lot of useful
information particularly from smcv. See below.
This is a transcript of #debian-devel manually edited to remove other
conversations, and also to remove unconstructive comments (of which
unfortunately there were some).
Ian.
15:40 is it so that desktop envs that depend on DBus user sessions,
can't run on SysV systems anymore?
15:40 see #909192
15:40 -zwiebelbot:#debian-devel- Debian#909192: mate-desktop-environment:
Installing sysvinit-core removes mate-desktop-environment -
https://bugs.debian.org/909192
15:40 if people can contribute to finding a solution, I'd be happy
for posts sent directly to the bug. Thanks.
15:41 sunweaver: This seems like some kind of mistake.
15:41 What is `dbus-user-session' ? It sounds like a thing that could
be provided without trouble on sysvinit systems.
15:41 I mean, I probably have one right here (although stretch, not
buster)
15:42 sunweaver: "It has a dependency on systemd's userspace part, but
not on systemd as PID one."
15:42 I think that is possibly a reference to systemd-logind ?
15:42 I don't see why a dbus user session would depend on that.
15:42 I guess so, too.
15:43 Also "systemd" is not the pid 1 part.
15:43 Diziet: Because they didn't want to implement their own session
management?
15:43 So I don't see why "systemd" and "sysvinit-core" aren't
coinstallable.
15:43 I have them both here on my laptop which is using systemd-logind
(stretch, again).
15:43 ansgar: I'm not sure what you mean by session management. This
all works in stretch.
15:44 sunweaver: It depends on libpam-systemd which depends on
systemd-sysv
15:44 yes, "systemd" is not the pid 1 part
15:44 so the problem is not the chain in the last email
15:44 Diziet: I assume we aren't talking about stretch.
15:44 ansgar: Indeed I think that bug isn't.
15:44 Depends: libc6 (>= 2.26), libpam0g (>= 0.99.7.1), systemd (=
239-9), libpam-runtime (>= 1.0.1-6), dbus, systemd-shim (>= 10-4~) |
systemd-sysv
15:45 But knowing how this all works in at least one stretch system is
probably helpful because then one can see what has changed and try to make it
work like it did in stretch.
15:45 Oh the problem is that systemd-shim is broken.
15:46 TBH I don't really see why dbus-user-session needs libpam-systemd
15:46 wRAR: notice the (>= 10-4~), see #903295 and #901405
15:46 -zwiebelbot:#debian-devel- Debian#903295: libpam-systemd: Depends:
systemd-shim (>= 10-4~) but it is not going to be installed -
https://bugs.debian.org/903295
15:46 systemd : Breaks: systemd-shim (< 10-4~)
15:46 yup
15:46 -zwiebelbot:#debian-devel- Debian#901405: systemd-shim: Please add a
sysvinit service to create directories on /run at boot -
https://bugs.debian.org/901405
15:46 "systemd-shim is broken" is not something surprising of course
15:46 sunweaver: Do you have time to look at this ?
15:46 wRAR: Indeed but I guess it is fixable.
15:47 sunweaver: I think the most obvious fix is to fix the 3 bugs
listed here https://tracker.debian.org/pkg/systemd-shim
15:47 sunweaver: If someone would prepare a fix I would be happy to
sponsor it.
15:50 I think a long term solution is probably to replace the
automatic session authorisation stuff with something more simple like
membership of a suitable unix group.
15:50 sunweaver: AYT?
15:55 oO(systemd-shim should be RM from debian)
15:57 bigon: It should not, but due to noone (including me) being
willing to spend time on maintaining it that's what will happen in practice (it
already got removed from buster).
15:57 it's broken
15:57 if you want to be able to use login1 D-Bus API without systemd,
people should go for elogin IMVHO
15:59 bigon: What is elogin ?
15:59 gentoo people have extracted logind from systemd source
15:59 Diziet: given that it starts with "e", I suspect something from
gentoo
15:59 well, there
15:59 elogind is systemd-logind with the cgroup manager merged back in.
15:59 (same with eudev where they have extracted udev from systemd)
15:59 And some questionable patches...
16:00 bigon: OK, so can we have that in Debian ?
16:00 If so it could be an alternative dependency to systemd-shim
16:00 I've created a pkg to give it some test (yeah to insomnia)
16:00 bigon: Great.
16:00 #905388
16:00 we can also have xdg-menu in Debian, it seems a lot of people want
it
16:00 but I've absolutely have 0 plans to mantain it
16:00 -zwiebelbot:#debian-devel- Debian#905388: RFP: elogind -- The systemd
project's
Bug#909192: mate-desktop-environment: Installing sysvinit-core removes mate-desktop-environment
Ian Jackson writes ("mate-desktop-environment: Installing sysvinit-core removes
mate-desktop-environment"):
> Long term, systemd-shim is undesirable.
See also #905388, which is about `elogind', a fork of systemd-logind,
which might be easier to maintain.
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.
Bug#909192: mate-desktop-environment: Installing sysvinit-core removes mate-desktop-environment
I think this is not happening because of the dependency on `systemd'. That is indeed not the pid 1 part. The root cause of this is dbus-user-session => libpam-systemd => systemd-shim | systemd-sysv but systemd-shim is RC-buggy. The bugs in systemd-shim that are keeping it out of testing are detailed here https://tracker.debian.org/pkg/systemd-shim and are currently (I think): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901404 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901405 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895292 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893819 I would be happy to sponsor an upload to fix this. Long term, systemd-shim is undesirable. AIUI the main functionality needed by the desktop environments that is provided by systemd-logind is permissions handling: specifically, arranging that the user currently logged in on the console can do certaain things. An alternative approach that would probably satisfy sysvinit users would be to simply add, as a matter of configuration, appropriate users to a Unix group with equivalent power. 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.
Bug#908933: debian-policy: typo in document in section 3.4 page no 15 line number 16 needs improvement.
Ian Jackson writes ("Re: Bug#908933: debian-policy: typo in document in section
3.4 page no 15 line number 16 needs improvement."):
> However, I looked at
> /usr/share/doc/debian-policy/policy.pdf.gz
> from debian-policy_4.2.1.1_all.deb with mupdf on my stretch i386
> system, and it looks absolutely fine. See attached policy-ok.png.
Also, look at the word "verbatim" in s3.4, 2nd para, 3rd line, 3rd
word. In the screenshot the gap after the v is rather too big. But
in my mupdf it is fine. Also, "volunteers" in the last line befopre
s3.4.
Unless someone with more knowledge of pdf etc. is able to say
otherwise, I think this is a rendering bug in Adobe Reader.
To the bug submitter: I recommend you stop using a proprietary pdf
reader. Adobe's stuff has some bad antifeatures, bad security
properties, and so on, as well as being proprietary, and, apparently,
buggy. The Free Software alternatives, in Debian, are really good.
Ian.
Bug#908933: debian-policy: typo in document in section 3.4 page no 15 line number 16 needs improvement.
Sean Whitton writes ("Bug#908933: debian-policy: typo in document in section
3.4 page no 15 line number 16 needs improvement."):
> On Wed 19 Sep 2018 at 09:50AM +0530, Jaikumar Sharma wrote:
> > I've attached another screeshot again where original word is as it is
> > as part of debian policy document and have added the same word just
> > below it. Can you please spot/see now the difference?
>
> I can see that the spacing before the 'i' is larger in the Policy text
> than in the superimposed text, but it is not suggestive of a bug.
I have looked at the most recent screenshot in this bug report and I
agree that in that screenshot `administrivia' has bad kerning just
before the final i.
However, I looked at
/usr/share/doc/debian-policy/policy.pdf.gz
from debian-policy_4.2.1.1_all.deb with mupdf on my stretch i386
system, and it looks absolutely fine. See attached policy-ok.png.
I also looked at it in xpdf on stretch. I even looked in evince,
although I find it maddening. It all seems fine.
I notice that the screenshot is from Adobe Reader.
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.
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Philip Hands writes ("Bug#904302: Whether vendor-specific patch series should
be permitted in the archive"):
> Possibly also with something like this?:
>
> Post-Buster this should be implemented in Debian Policy by
> declaring that a package MUST NOT contain a non-default series
> file.
>
> The approach adopted to allow existing usage is left to the
> discretion of the Policy Maintainers.
Nit-picking, you might want to say
The approach adopted to tolerating existing usage before then
is left to the discretion of the Policy Maintainers.
Ian.
Bug#904558: What should happen when maintscripts fail to restart a service
Stuart Prescott writes ("Bug#904558: What should happen when maintscripts fail
to restart a service"):
> Ian Jackson wrote:
> > When I wrote that, it didn't occur to me that anyone would think that
> > a failure by a postinst script to perform an intended operation should
> > be treated any other way than a failure of the postinst script.
>
> That was perhaps also written before we started to realise that maintainer
> scripts are actually best avoided
I don't think that makes any difference.
Whether things are implemented by handcoded code in postinst, or
dh-generated templatey postinst, or some kind of declarative system,
is important for manageability of our codebase etc. etc.
But it doesn't have any bearing on what the error handling should be
like. Any kind of declarative or automatic system or whatever ought
to have similar error handling: failure to perform an intended
function is an error and should not be ignored.
See for example the handling of errors which occur during trigger
processing.
One of the things that I am most proud of in dpkg is the comprehensive
and thoughtful error behaviours.
> > If the postinst fails, then the user has the opportunity to fix the
> > root cause and rerun dpkg-source --configure --pending. That will
> > then repair the system completely.
>
> \u2026 causing a snowball of errors in an awkward half-upgraded
> environment is nasty.
>
> The problem comes when you don't yet have the right tools installed to be
> able to fix the problem. We see that scenario often enough in #debian where
> someone has a failed upgrade and we try to collect more information via
> pastebinit, strace, traceroute, netcat, gdb, etc; we frequently discover
> that the relevant tool isn't installed and because apt is sufficiently
> unhappy about broken packages and a half-completed upgrade, you can't ask it
> to install the tool at that point in time.
This is a bug in apt, plain and simple.
Of course it is a design error, but that does not make it a bug.
There is nothing conceptually incoherent in installing strace while
cupsd and its dependencies are broken. dpkg will happily do it.
I agree that in the absence of a fix to this, some workarounds would
be good. Perhaps
dpkg --configure --force-postinst-fail broken-package
?
> In the upgrade scenario, while you're trying to fix one particular
> problem, you're also in a completely untested half-upgraded
> situation and so latent bugs in any number of other tools may also
> be exposed.
dpkg is designed so that it is in general only the _configuration_ of
other packages which is blocked, not their actual upgrade. So
hopefully you should be in a reasonably coherent state.
> So while ignoring errors is wrong, so is making it harder to fix them. This
> isn't a question of absolutes.
As I say I think it is a bug in apt that when you have an error, apt
makes it hard to fix the error by insisting that you can't do anything
(even install diagnosis tools) until you have fixed the error (which
you can't do).
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.
Bug#904558: What should happen when maintscripts fail to restart a service
Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts fail
to restart a service"):
> Ian Jackson:
> > There may be good reasons not to treat daemon startup failure as a
> > postinst failure, but the argument above is not one of them.
>
> I think this is the core question. I largely agree with Ian here that
> having postinsts fail is not that big a deal if they can't make forward
> progress, but also we're being asked to advice on what happens when a
> maintainer script fails to restart a service. I disagree with him on
> whether failure to start/restart a service should be considered a
> configuration failure.
I think whether it is a configuration failure depends on ...
> I think the general rule should be that the success/failure of the
> postinst script should signal whether the package considers itself ready
> to provide whatever API it exists to provide (disregarding the case of
> Essential packages here, since those are special).
... that. I think I'm in agreement with you on that. But ...
> This means that failure to start a daemon should generally not cause the
> postinst to fail.
... I disagree with that. I think that in the usual case, if the
daemon is broken, and the package's purpose is to provide that daemon
service, then the package probably isn't providing its API.
Maybe part of the difficulty we are having with this conversation is
that we are lacking in examples. This bug and the "parents" #780403
and #802501 are all entirely abstract.
Would someone care to give some examples of packages which with both
behaviours ?
Also:
> The API provided by a package being in the configured state is not
> whether the relevant daemon is running or not; that is runtime and can
> and will change many times while the package is in the configured state,
> so dpkg dependencies are not useful for expressing "this service must be
> running".
I disagree with this.
dpkg dependencies are not just about what sets of packages can be
coinstalled. They also imply sequencing of package setup. And since
starting daemons is part of package setup, dpkg dependencies imply a
sequencing of daemon startup.
That is actually necessary in the case where the startup of daemon B
can only successfully completed if daemon A is up,
> (There's also the case where the service is running on a
> separate host, which is often the case for services such as databases
> and where the use of Depends is inappropriate.)
In that case, there would be a Recommends or Suggests instead, I would
have thought.
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.
Bug#909118: /proc not mounted before use
George Taylor writes ("Re: Bug#909118: /proc not mounted before use"):
> On 18/09/2018, Ian Jackson wrote:
> > Thanks. Have you tried this on a system _with_ a Debian-generated
> > initramfs ?
>
> Yes, on a Debian 9 VM. When using initramfs /proc/stat exists at that
> point and so the uname test never happens.
Great, thanks.
(I hope you don't mind that I'm CCing this to the bug so there's a
record of your reply.)
Ian.
Bug#909118: /proc not mounted before use
Control: tags -1 patch
George Taylor writes ("Bug#909118: /proc not mounted before use"):
> I suggest replacing elif with a simple else.
Thanks. Have you tried this on a system _with_ a Debian-generated
initramfs ?
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.
Bug#904558: What should happen when maintscripts fail to restart a service
Margarita Manterola writes ("Bug#904558: What should happen when maintscripts
fail to restart a service"):
> Sorry that it took so long to get back to this bug. The other bug took
> all the attention.
...
> If a postinst fails (for whatever reason), the package is left in a
> broken state (Failed-Config) which in general makes the package
> management system unhappy.
The other effect is that the package's dependencies are not
configured, so their postinsts do not experience a broken situation.
> It seems that the only reason why one may want to do this is to call
> the attention of the sysadmin so that they can solve the problem.
> However, in a world where a large number of users are running automatic
> updates, leaving the package management system in a broken state is
> pretty sad, not very visible and rather confusing for the user when
> they finally encounter it.
>
> Is there an another use case for leaving the package in Failed-Config
> that we missed?
If you deliberately cause the postinst to succeed when the package is
nonfunctional, then the package's r-dependencies will be configured
(ie have their postinsts run) in the broken state.
The r-dependencies' postinsts may then do wrong things. They may
leave the r-dependencies in anomalous states. If one takes the
argument you make above to its logical conclusion, all those postinsts
should also report success.
The result is system where the only thing that is happy is the package
management systme, and the records of the root cause of the problem,
and how the failed operations might be reattempted, have been lost.
I guess you will infer from what I write above that "reporting errors
causes the next layer to be unhappy", and "reporting errors causes the
user to be unhappy" to be extraordinarily bad arguments.
There may be good reasons not to treat daemon startup failure as a
postinst failure, but the argument above is not one of them.
> It's unclear why the service (re)start needs to be a special case.
Service (re)starts are more likely to fail for unrelated reasons.
Also some packages are able to provide much of their intended API even
without the daemon.
I think the general rule of thumb should be that a daemon startup
failure should be treated as a configuration failure.
I'm content with a situation where maintainers Feel free to diverge
from this if there are reasons to do so.
> I personally think that it would make sense for the policy to at least
> recommend what should happen with regards to maintainer scripts and
> typical operations that are performed in them.
There is already a section on error handling in scripts, which (IMO
correctly) says that shell scripts should use set -e.
When I wrote that, it didn't occur to me that anyone would think that
a failure by a postinst script to perform an intended operation should
be treated any other way than a failure of the postinst script.
(In the usual case. There are of course lots of situations where the
right approach is some kind of error recovery, or the operation was
attempted "just in case", or something, in which case more subtle
error handling is called for.)
> And, while I'm open to be convinced otherwise, I don't see any benefit
> from postinst (particularly postinst + configure) ever failing.
Frankly I'm disturbed to be reading this, here. See above.
If the postinst fails, then the user has the opportunity to fix the
root cause and rerun dpkg-source --configure --pending. That will
then repair the system completely.
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.
Bug#902809: want dgit smash-working-tree-timestamps [and 1 more messages]
Mattia Rizzolo writes ("Re: want dgit smash-working-tree-timestamps [and 1 more
messages]"):
> On Sat, Sep 15, 2018 at 09:00:26AM -0700, Sean Whitton wrote:
> > I guess that experience using the script to avoid FTBFS will reveal
> > whether this behaviour needs to be tweaked; we probably shouldn't
> > overthink it.
>
> I think that's just a straight plain workaround, and that things should
> be properly fixed instead.
Certainly it's a workaround. My goal is to make it easy for people
who want to modify the way their systems work, to work around bugs
they find in Debian.
Certainly no Debian package maintainer ought to need this script for
their own package.
> Sorry, that's a wontfix for me. Even if I was not convinced this is not
> something that should be advocated, that would simply be too short to be
> called a script… It's literally a single line of code.
That line of code is complicated and encapsulates a significant amount
of thought about exactly what the right behaviour is.
But, if I can't change your mind I'll just put the script in dgit.
Ian.
Bug#896698: deprecating needs-recommends
Michael Biebl writes ("Re: deprecating needs-recommends"):
> I have a package (firewalld) which has optional dependencies like ipset
> or ebtables. If those are not installed, firewalld will log a warning
> and continue with the functionality disabled.
...
> Now, if needs-recommends is going to be deprecated/removed, I'll have to
> specify the Recommends twice: once in debian/tests/control and
> debian/control and I don't like this duplication as this is prone to get
> out-of-sync.
>
> Just wanted to provide a data point why it might be useful to keep
> needs-recommends.
I have found that in practice, debian/tests/control often has too much
stuff in it that needs to be kept in step with the rest of the
package, to handle this manually.
So instead, when things get nontrivial, I have a script to update
debian/tests/control. Well, really, I generate it from template(s)
and other information found in the source.
I think your case is just an example of this kind of problem.
Unlike d/control it is not a big problem d/t/control is not updated.
My approach to detecting a failure to rerun the d/t/control generator
is to have a test which runs the generator and fails if the output is
not identical to the current file. So not updating the test list is
itself a test failure.
I commit the resulting d/t/control to git. This is slightly ugly but
not a practical problem. In particular, any merge conflicts are
easily resolved by rerunning the generator.
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.
Bug#908742: Want way to reset tar-ignore list
Guillem Jover writes ("Re: Bug#908742: Want way to reset tar-ignore list"):
> Hmm, I found this bug description and the problem from the referenced
> bug to be a bit of a mismatch. I checked the notmuch referenced history
> where I noticed in commit 514fb397c9f7cfc80f0b14bd28bb2acdb4cd30ca that
> the problem was the standalone tar-ignore option. The current options
> file now contains:
>
> ,--- debian/source/options
> single-debian-patch
> tar-ignore=.git
> tar-ignore=performance-test/download/*.tar.xz
> `---
Yes. From the point of view of dgit's call to dpkg-source, that's a
workaround, really. (From the point of view of other uses of notmuch
I think it is a bugfix, or a workaround for #908747, depending on how
you look at things.)
> With that in mind, I'm not sure whether your request is to ignore
> *only* those standalone tar-ignore options or any of them regarldess
> of these taking an argument or not?
No, dgit wants to completely control the ignore list.
> Because I'd think in general you'd want to honor the ignore rules from
> the source package itself, except for the dpkg-source defaults. OTOH I
> guess those same ignores would be covered by things such as .gitignore
> or similar VCS-specific files.
dgit is working from a git commit and therefore has a git tree object
which already contains exactly the right set of files. (That tree
object may have been influenced by .gitignore but that happened
earlier.) dgit needs to convert that into a source package, so it
calls dpkg-source.
So dgit needs represent in the source package exactly all files that
are in the tree object, regardless of the contents of the
debian/source/options.
If the tree object contains files which were ignored by a tar-ignore
implied by debian/source/options, then that is arguably some kind of
bug, but dgit needs to be able to work with buggy source packages
which appear in the actually-existing archive, and with commits (and
trees) made by downstream users who do not understand (or perhaps even
agree with) the maintainer's debian/source/options and the implied
tar-ignore.
> I think both options, never-add-tar-ignore-defaults-even-if-specified
> and clear-all-tar-ignore are valid, and I might add both, just wanted
> to make sure I understand which one you are requesting here.
So I think I want --clear-all-tar-ignore.
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.
Bug#908747: Default -I and -i option should not exclude .ignore
Julian Andres Klode writes ("Re: Bug#908747: Default -I and -i option should
not exclude .ignore"):
> On Thu, Sep 13, 2018 at 12:26:27PM +0100, Ian Jackson wrote:
> > The result of this default is that many source packages in the Debian
> > archive are incomplete. [...]
>
> By the same reason, you could argue that not shipping .git is a DFSG/GPL
> violation. ignore files are things that integrate the source code with
> the version control system.
This is an interesting argument but it is probably sensible to defer
it for another day. (If you do subscribe to that argument, I guess
you would always use dgit, or always push your git branch to salsa
with appropriate signed tags.)
Looking more narrowly, it seems to me that: including the .gitignore
(say) is sometimes helpful, and never harmful. So stripping it out is
simply a mistake.
It is helpful, for example, if the user does
apt-get source && cd $p && git init && git add . && git commit
so they can work under version control. This is a common approach to
work around the fact that Debian still often does not publish a
useable branch. Including the .gitignore is helpful for a user
using dgit to fetch a not-uploaded-with-dgit package (because dgit
ends up doing something a bit like that git add.) It is helpful when
handling nmus, sponsorship, etc. because it means the source package
is more like the git repository.
Do you agree ?
Whereas including the .git/ directory is currently forbidden in
Debian. That is surely a separate, much wider, debate, which I would
be happy to have with you - indeed, I am sympathetic - but not in this
bug report.
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.
Bug#908417: dgit does not handle debian/.gitignore missing from source package
David Bremner writes ("Re: Bug#908417: dgit does not handle debian/.gitignore
missing from source package"):
> They're wrong for dgit, and maybe for DFSG, but not for building
> throwaway source packages that are not distributed.
Not to detract from your other comments, but:
For a throwaway source package I think you don't care if it has a .git
directory and your whole revision history ?
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.
Bug#908417: dgit does not handle debian/.gitignore missing from source package
Ian Jackson writes ("Re: Bug#908417: dgit does not handle debian/.gitignore
missing from source package"):
> I will file a bug against dpkg requesting a command line option which
> resets the tar-ignore list.
I've just filed
#908742 Want way to reset tar-ignore list
> Even if and when that is all done, you will still have the problem
> that source packages built in whatever way generated the errors above
> will still be wrong: they will wrongly lack debian/.gitignore.
It occurs to me that I think you can give a value for the tar-ignore
option. So maybe you can say tar-ignore=.git ?
Probably, then, you want to put into debian/source/options the output
from
dgit print-dpkg-source-ignores
which is currently
-i(?:^|/)\.git(?:/|$) -I.git
It might change if we find bugs in it. That has happened once
already. But if your package doesn't contain files for which that
rune is buggy, I think you should be OK.
HTH.
I hvae also filed
Bug#908747 Default -I and -i option should not exclude .ignore
about the root cause of all of this. I expect that to be
controversial and slow to fix.
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.
Bug#908747: Default -I and -i option should not exclude .ignore
Package: dpkg-dev
Version: 1.19.0.5
When the source provided to dpkg-source contains a .ignore file,
eg a .gitignore, .hgignore, .cvsignore, then that file is part of the
source code as the maintainer works with it. It should be retained in
the source package.
Likewise if the Debian maintainer makes changes to .ignore in
their vcs, then those changes are part of the source as the maintainer
works with it, and in `3.0 (quilt)' should be represented as a patch.
The result of this default is that many source packages in the Debian
archive are incomplete. This is IMO a DFSG violation (and where
relevant a GPL violation). Although it is probably legally de
minimis, this should be fixed.
Changing this has compatibility implications. Many tools assume the
existing behaviour. I suggest the following transition plan:
* Introduce a new option --new-ignores which causes -I and -i without
further arguments to exclude *only* vcs-maintained metadata (.git,
.hg, CVS etc.) and including all files which are usually committed
to the relevant vcs. Make an environment variable to do the same
thing.
* Start printing a warning when -I or -i is passed on the command
line without a value and without --new-ignores.
* Always treat -I and -i found in debian/source/options the new way.
(there are no compatibility implications in this case).
* In bullseye, always do the new thing and make --new-ignores a
no-op.
But maybe you have a better plan.
This is related to, but distinct from,
#908742 Want way to reset tar-ignore list
which I think ought to be uncontroversial and can be done immediately.
Thanks,
Ian.
[1] Looking at the list in @tar_ignore_default_pattern in stretch, I
think the ones which need to be removed from the list (and thus kept
in source packages) include at least these
.bzrignore
.cvsignore
.gitattributes
.gitignore
.gitmodules
.gitreview
.hgignore
.mtn-ignore
.mailmap
and possibly these
.arch-ids
.arch-inventory
.be
.bzr.backup
.bzr.tags
.deps
.hgsigs
.hgtags
and maybe these (but I think not):
.shelf
_MTN
_darcs
{arch}
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.
Bug#908742: Want way to reset tar-ignore list
Package: dpkg-dev Version: 1.19.0.5 Control: block 908417 by -1 Recently a dgit user complained that if their package has a tar-ignore in debian/source/options, things go wrong. See #908417. dgit needs to run dpkg-source in such a way that all things in the input directory end up in the source package, except precisely the top-level .git directory. To do this it passes a slew of -I and -i options to dpkg-source. But if the source package contains a tar-ignore option in debian/source/options, this does not work, because the -I options stack up. Simply having the user remove tar-ignore from the source package's debian/source/options is IMO best, but as you see in #908417 that does have downsides. If dpkg-source provided a --reset-tar-ignore option which cancelled all previous --tar-ignore options (including those from debian/source/options), then dgit could pass that option and everything would work right. So, please could you provide such an option. 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.
Bug#908417: dgit does not handle debian/.gitignore missing from source package
David Bremner writes ("Bug#908417: dgit does not handle debian/.gitignore
missing from source package"):
> As another example, since I removed tar-ignore from notmuch, I have
>
> W: notmuch source: diff-contains-git-control-dir
> .git/dgit/unpack/notmuch-0.27/.git
> E: notmuch source: source-contains-unsafe-symlink
> .git/dgit/unpack/notmuch-0.27/.git/objects
Certainly that is wrong.
I think this would happen if you ran dpkg-source -b (or some tool that
calls it but is ignorant of git) in a git working tree without
relevant -I options. I think my answer is "don't do that then".
I will file a bug against dpkg requesting a command line option which
resets the tar-ignore list.
Even if and when that is all done, you will still have the problem
that source packages built in whatever way generated the errors above
will still be wrong: they will wrongly lack debian/.gitignore.
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.
Bug#908323: gtk+3.0 breaks libgtk3-perl autopkgtest
gregor herrmann writes ("Re: Bug#908323: gtk+3.0 breaks libgtk3-perl
autopkgtest"):
> I was wondering if we should just add a build-dependency and
> dependency on gir1.2-gdkpixbuf-2.0, like we do for other
> gir*-packages, now that we need to use it explicitly since some
> definitions have been split out into it.
>
> (Currently it doesn't change anything, as it's pulled in anyway, but
> it's maybe more "correct" and would also help for the autopkgtest
> situation.)
Think about likely future changes, such as: package reorganisation in
the *gir*gdk*pixbuf* packages; new versions of those packages (which
might result in new binary package names but not new -dev package
names);e tc.
Putting the binary packages in a hint-testsuite-triggers test would
mean that your package tests would still mostly work even if the
binary package names changed, provided the -dev package(s) are the
same or are still pulled in. You could update the
hint-testsuite-triggers for the new binaries at your leisure.
Ian.
Bug#908323: gtk+3.0 breaks libgtk3-perl autopkgtest
Jeremy Bicha writes ("Re: gtk+3.0 breaks libgtk3-perl autopkgtest"):
> The change that triggered this failure seems to be in gdk-pixbuf not
> gtk3, but gdk-pixbuf is not a direct dependency of libgtk3-perl.
Maybe libgtk3-perl needs to have a dummy test with
hint-testsuite-triggers and depending on gdk-pixbuf (and probably
others too).
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.
Bug#448184: Eterm and UTF-8
I looked at this, prompted by Jose Antonio Jimenez Madrid.
I discovered that:
* configure.ac appears to have support for the utf-8 multibyte
encoding, calling it `unicode', but in upstream it tries to detect
whether to enable it by calling xlfonts and seeing if the output
contains the string `iso-10646'! In the Debian package this is
overridden.
* In the source code this encoding is spelled variously utf-8,
UTF-8, UTF8, iso-10646, etc. Sometimes as strings, which are then
compared.
* There is one function which compares the system locale's encoding
with a list of strings including "UTF8". Of course that would be
"UTF-8". But fixing that does not help because:
* Eventually we find this code:
if (!strcasecmp(str, "utf8") || !strcasecmp(str, "ucs2")) {
encoding_method = UCS2;
multichar_decode = latin1;
} else if (..
* encoding_method is used by a state machine in
screen.c:scr_add_lines, to decode terminal characters for writing
into the screen array. The state machine is an interleaved
mixture of different multibyte character decoders does not contain
a UTF-8 decoder.
* After all that I decided not to look at the encoding side.
I think that to fix this one would have to, _at least_:
* Sort out all of the names of the encodings so that the plumbing
and configuration works
* Add a UTF-8 decoder to screen.c
Very likely there is no UTF-8 encoder either.
It would probably be easier and more fruitful to add the wanted
features (or UI frills) from eterm to another terminal emulator.
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.
Bug#907199: weboob, Gratuitous sexual references
Thanks for your mail and your attention.
Chris Lamb writes ("Re: Bug#907199: weboob, Gratuitous sexual references"):
> Just as one example from your previous message, you appear to reject
> working with upstream constructively on this, despite a solution
> involving them being beneficial to the entire free software ecosystem
> (not to mention avoiding rehashing a quite tedious and painfully
> predictable debate within Debian itself).
Well, others have definitely been trying that. There is an issue in
the upstream tracker (mentioned in the footnote of Niels's message);
https://git.weboob.org/weboob/devel/issues/154
This was reported in early August and has had no responses from the
upstream maintainers, despite several pings from other people. I
think it is clear that upstream are aware of the complaint but are not
dealing with it (perhaps because it's no fun, or perhaps as deliberate
strategy).
I believe there have also been contacts between the Debian maintainer
and upstream, recently but well before that issue, but again those
don't seem to have produced an outcome I am happy with.
In this context, there is of course this blog posting. But it's from
2013, and maybe views have changed. Certainly I myself have done or
said things 5 years ago which I would take a very different line on
today.
http://laurent.bachelier.name/2013/12/weboob-the-asshole-detector/
So it's true that we don't know for sure what upstream's current view
is on this situation, but that's not because no-one has tried to talk
to them about it.
There is also the issue that I think it would not be a particularly
good idea for me to try to make overtures to upstream. As you note,
my communication style tends to put people's backs up. Happily, other
people have been trying, and it seems better for me not to put my oar
in.
So ultimately I don't know what other efforts you think ought to be
made. If you advise that it would be better for me to try a direct
contact with upstream then I am happy to do so. In which case I would
appreciate a (private) review from someone of my proposed messages.
> You also do not appear to have looped AH in on this, despite them being
> almost-certainly having some kind of viewpoint and de facto weight,
> if not a de jure one.
Did you overlook this email ?
From: Ian Jackson
To: lea...@debian.org
CC: antiharassm...@debian.org
Subject: web-oob "gratuituous sexual references" issue now with d-release
Message-ID: <23422.37882.517223.718...@chiark.greenend.org.uk>
Date: Thu, 23 Aug 2018 12:01:14 +0100
Hi. I thought I should let you know that this is now with the Release
Team. I have asked the RT to rule on the RCness of my bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906119
ITYSBT, in case you want to make some kind of representations to the
Release Team.
Regards,
Ian.
I didn't receive any reply. I also note that you yourself didn't
forward my message to AH as far as I can see. I will do that with
this email, CCing you, right after I send it.
> As an important aside (and I'd like to underline that I don't really
> subscribe to this view myself) it is regrettable that your framing the
> idea of a GR at the moment can be interpreted as an ultimatum or - even
> more tragically - as a threat.
I can see why people might see things that way.
I would be interested to hear from you, how I should ask questions
like:
"does the DPL think there are other useful avenues that we should
try, before a GR"
or
"how would the release team view a GR with an advisory text"
?
But perhaps your comment is directed to my earlier messagess. I do
have a tendency to map out the future possible paths of a dispute
which is perhaps not very helpful. But I think in this case surely
most people could see where this is probably heading.
Anyway, right now I feel I am running out of options. I don't think
delaying resolving this issue is helping very much.
> Putting it another way, whilst drafting a GR is always technically an
> option for a Developer to persue, I highly suspect one gets far more
> traction, collaboration and "buy-in" with the rest of the Debian
> community if one is far less explicit about it.
Thanks for the feedback. I look forward to your advice on the
key question I ask above, namely: what do you think I should do next ?
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.
Bug#908417: dgit does not handle debian/.gitignore missing from source package
Control: retitle -1 do something about tar-ignore in d/s/options
David Bremner writes ("Re: Bug#908417: dgit does not handle debian/.gitignore
missing from source package"):
> Sean Whitton writes:
> > Based on discussion on IRC, I believe that the problem is that the
> > options that dgit passes to dpkg-source, while sufficient to ensure that
> > .gitignore is included in the resultant source package, are not
> > sufficient to ensure that debian/.gitignore is included. I.e. they do
> > not properly override tar-ignore.
Oh. I see.
I hvve just RTFM dpkg-source(1) again (but not yet UTSL) and there
doesn't seem to be a way to reset the list of -I options.
I think the best I can do, therefore, is to detect this situation and
print a warning. It has to be only a warning, because if the rogue -I
does not match any files in the tree then it is harmless - and this
situation will arise when NMUing a non-dgit-pushed package with such a
rogue -I.
(Of course a package with such a rogue -I is probably excluding parts
of the source code from the .dsc and is therefore a DFSG violation and
maybe a copyleft violation, although in the case of .gitignore quite a
minimal one.)
It might be a good idea to have a passlist of known-good options and
warn on any others. But tar-ignore should be handled specially
because the warning can explain the likely consequences (and the fix,
although the fix - removing the option - is obvious and harmless).
It would be possible in principle to detect whether any files in the
git tree would match the rogue ignore - but not without reimplementing
dpkg-source's matching logic.
Ideally dgit should tolerate a tar-ignore which matches exactly .git
in the toplevel but that's even more work because it would involve
predicting the things which a regexp matches.
David, would a warning have been sufficient, to avoid this being a
significant inconvenience to you ? Something like this perhsps:
debian/source/options contains a tar-ignore option.
If this option matches anything, dpkg-source's source
package will differs from your git tree, and dgit push will fail.
tar-ignore is not needed with dgit push, so you can remove it.
> > David, could you provide steps to reproduce? I.e. a repository and a
> > git commit hash.
>
> Hash: 8feec188a0bb3ed5dcda2c0e22c7645ca0d8f618
> Repo: https://git.notmuchmail.org/git/notmuch
>
> If you look at branch release, you can see the dgit created merge after
> that commit, and before the actual archive tag.
Thanks. I will look at this.
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.
Bug#908417: dgit does not handle debian/.gitignore missing from source package
Ian Jackson writes ("Re: Bug#908417: dgit does not handle debian/.gitignore
missing from source package"):
> I'm sorry to be dim, but I don't understand what you think the bug in
> dgit is ? dgit's design principle is that the source package and git
> tree are idnntical. Are you arguing that this is not correct ?
>
> Or is the problem that dgit cannot be used to nmu a package with
> tar-ignore in debian/source/options ? dgit passes an explicit -I
> option to dpkg-source which I think should override
> debian/source/options. And if the uploader did not use dgit push then
> the .gitignore would be missing anyway.
Also, it's possible that --quilt=dpm could be used to work around the
problem, although that seems much less desirable than removing
tar-exclude from debian/source/options...
(I guess you weren't using --quilt-gbp since that would make a patch
for .gitignore in the dgit view.)
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.
Bug#908417: dgit does not handle debian/.gitignore missing from source package
David Bremner writes ("Bug#908417: dgit does not handle debian/.gitignore
missing from source package"):
> Package: dgit
> Version: 6.11
> Severity: normal
>
> notmuch had until recently "tar-ignore" in debian/source/options so
> that a default set of VCS related things is dropped from the source
> package, and (still has) a debian/.gitignore. This means that dgit is
> sad because the source packagee does not match the git view, and
> e.g. push-source fails.
I'm sorry to be dim, but I don't understand what you think the bug in
dgit is ? dgit's design principle is that the source package and git
tree are idnntical. Are you arguing that this is not correct ?
Or is the problem that dgit cannot be used to nmu a package with
tar-ignore in debian/source/options ? dgit passes an explicit -I
option to dpkg-source which I think should override
debian/source/options. And if the uploader did not use dgit push then
the .gitignore would be missing anyway.
Ian.
Bug#907199: weboob, Gratuitous sexual references
Niels Thykier writes ("Re: Bug#907199: weboob, Gratuitous sexual references"):
> I think the Release Team is the wrong authority for this enquiry.
>
> As I understand it, you feel that weboob (in its current condition) is
> in conflict with Debian's values (e.g. the CoC or the diversity
> statement). The reason why I suspect the release team is the wrong
> authority is that other packages violating Debian's values (namely the
> DFSG) are not shipped in Debian *at all* (i.e. it is not in "main"
> regardless of suite).
Thanks for your consideration. I see where you are coming from.
In this case (and ones like it) I think it would do disproportionate
damage to remove the package from stable suites. So treating this bug
as RC would get quite close to the right practical effect. (As for
unstable, I think it should probably be removed unless it is useful to
keep it there while work is done on fixing this bug.)
> Secondly, even if we *could* make the decision for weboob (or the scope
> of our powers are sufficient for you in this case), I think the project
> is much better served having a separate authority on whether something
> is in line with the CoC/Diversity statement.
I see some force in this argument. (Although I disagree with your
characterisation of this as a "non-package related issue". The
problem is precisely with the content of the package. But it is a
social rather than a technical problem.)
I think I need to look elsewhere. I don't think the Technical
Committee is the right body.
Niels would the RT have a problem with a request (from an appropriate
body, or from the members via a 1:1 GR) to treat this as an RC bug for
release team purposes ? I mean, would you feel that such a request
would be stepping on your toes, or would you welcome it for its
clarity ?
Your suggestion that there might be a "separate authority" does
suggest to me the possibility that you think this is, consitutionally,
something that "no-one else has responsibility for", ie it is in the
DPL's bailiwick and as-yet-undelegated.
Or maybe you think it's ftpmaster's responsibility. Sadly I don't
think it would be a good idea to ask the ftpmaster team to be bear the
political weight of what is going to be a controversial decision
whatever way it goes.
Chris, what do you think ? I think I have nearly run out of things to
try that aren't a GR. I'm sure I can get sponsors for a GR, and help
drafting it. I also hope that it would be sufficient for the GRa to
state some non-binding opinions, which I guess the maintainer and/or
core teams would probably choose to follow. I would not want to try
to decide this on a supermajority.
> Note: Personally, I would very much prefer that upstream accepted
> https://git.weboob.org/weboob/devel/issues/154 and removed the remaining
> insults (if any), so we could put all of this behind us.
That would indeed be great. But it does not seem to be likely.
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.
Bug#908291: developers-reference, section 5.11.4: Add a note on versioning scheme when reverting an NMU
Sean Whitton writes ("Bug#908291: developers-reference, section 5.11.4: Add a
note on versioning scheme when reverting an NMU"):
> On Fri 07 Sep 2018 at 10:48PM -0700, Joseph Herlant wrote:
> > I took the liberty to provide a patch via a MR:
> > https://salsa.debian.org/debian/developers-reference/merge_requests/4
> >
> > Let me know if adding that paragraph would be ok and if the
> > wording is correct. I'm not sure on how to handle the po
> > files. Let me know if I can help on that too.
>
> LGTM -- it matches the recent change to Policy about this.
Maybe adding a link or xref to policy 5.6.12.1 would be helpful.
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.
Bug#908155: Coordination with upstream developers not universally applied
Thorsten Glaser writes ("Re: Bug#908155: Coordination with upstream developers
not universally applied"):
> Yes, but that does not mean we should make it permitted by the rules
> to slack in that \u201Cduty\u201D.
I find this rhetoric, that overwhelmed maintainers who are not able to
deal individually with every bug report, are "slacking" in their
"duty", quite objectionable, I'm afraid.
> Ian Jackson ,
> > What did you think of the text I proposed just over <- there, that
> > Moritz was happy with ?
>
> Just answering because of this: I think it way too lax still.
You should perhaps propose a countertext, but given what you say above
I doubt it would find consensus.
Ian.
Bug#908155: Coordination with upstream developers not universally applied
Thorsten Glaser writes ("Re: Bug#908155: Coordination with upstream developers
not universally applied"):
> As long as it\u2019s a \u201Cshould\u201D in the same sense as
> \u201Cshould fix bugs in their packages\u201D, and package
> maintainers keep an eye on users\u2019 bug reports and, when
> necessary, help them (providing infos to upstream, packages to test
> to users who can\u2019t (easily) build themselves, and, yes,
> definitely *also* forward bugs upstream, occasionally.
>
> Does this sound like an option?
In some packages this will not be possible at least for some bug
reports. You've seen the poor quality and hard-to-follow-up bug
reports that some packages get in large numbers. And it is precisely
the bug reporters who would need the most help to deal with upstream,
where doing the work for them is the most difficult.
We will just have to accept that not all bug reports will be properly
investigated. We should focus our effort on the bug reports that are
most likely to lead to improvements in the software, given available
levels of effort. And we should therefore not write things in our
documents that discourage maintainers from prioritising appropriately.
I get the impression that you are looking at this from the point of
view of the user, who wants their bug fixed, and is perhaps not able
or willing to report it upstream. Such a user does have a problem,
and when one is such a user, it is frustrating.
But, the main point of bug reports, from Debian's point of view, is
not to help users. As the Information for GNU maintainers has it:
The main purpose of bug reports is to help you contribute to the
community by improving the next version of the program. Many of the
people who report bugs don't realize this - they think that the
point is for you to help them individually. Some will ask you to
focus on that instead of on making the program better. If you
comply with their wishes, you will have been distracted from the job
of maintaining the program.
This means that many users will go un-helped. That is, sadly,
inevitable. We in Debian cannot possibly be the support desk for all
our users. The more successful we become, the less possible that is.
Our responsibility is to enable others, nearer the users, to help
them, by making our software Free and accessible, by providing
appropriate documentation, by (scaleable) outreach activities, and so
on.
What did you think of the text I proposed just over <- there, that
Moritz was happy with ?
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.
