Bug#933044: dgit: should not require --overwrite when debian/changelog contains the version in unstable

2024-03-20 Thread Ian Jackson
> --overwrite does not trust debian/changelog

Looking at this bug (after much time, sorry) I am confused.  I think
what --overwrite does is precisely to trust the changelog.  Maybe you
meant to say "dgit does not trust ..." which is accurate.  Then the
rest of your message makes sense.  So, let me reply to that:

The reason dgit doesn't trust the changelog by default is that it is
not reliable.  It is quite easy to accidentally create git commits
that mention "1.2.3-1" in the changelog, but which weren't the
actually uploaded "1.2.3-1".  Many maintainer changelog management
workflows do so.  In such a situation, forgetting to pull from the
main branch on salsa might result dgit accidentally overwriting later
changes, if it simply trusts the changelog.

Many maintainers (especially of native packages) who use dgit don't
need --overwrite: as a maintainer you can merge the dgit .dsc import
into your own history.  Then git operates normally and your pushes are
always ff.  This workflow is much less at risk of accidentally
clobbering changes.

In line with dgit's philosophy of trying to help the user avoid
mistakes, and encouraging safer (less error-prone) workflows, I don't
think making --overwrite the default would be a good idea.

In #1050713 I am proposing to add a --trust-changelog option, that
works like --overwrite (without a version).  This will hopefully make
it less scary-sounding and encourage more people to use it rather than
worry.

Does this all make sense ?

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050713: mixed team workflows incl. --overwrite, split brain

2024-03-20 Thread Ian Jackson
Control: severity -1 important

Having thought about it, I propose the following changes to try to
help with this:

1. Provide an alias for --overwrite (without version) called
   something like --trust-changelog, and make that be the primary name.
   That's really what --overwrite (without version) does.

2. Provide a new option --collab-sceptics [1] which implies
   --split-view=always --trust-changelog.

[1] I'm very unusre of the right name.  This option should be used in
two situations:

 (a) The package is team maintained, and you are doing a team upload;
 your teammates don't use dgit (and object to the .dsc import
 commits that can happen in the dgit history (so the maintainer
 history doesn't have the .dsc imports).  So you must hide the
 .dsc imports (which are in the dgit view) and trust the
 changelog.

 (b) You are doing an NMU, and you're doing it from maintainer git,
 but the maintainer doesn't use dgit.  Nevertheless the maintainer
 wants your git commits.  So you want to provide a git branch that
 doesn't have the .dsc import commits (and you must truxt the
 changelog).

The common factors are:

 i.Sharing git history with the maintainer - ish
 ii.   Previous uploader(s) didn't use dgit
 iii.  The maintainer(s) don't want .dsc imports and pseudomerges
   (this isn't a *strictly* necessary condition but it is
   simpler to have one option that does all of this).

Suggestions for names very welcome.  Ideas I had for relevant words:

  [dgit] sceptic
  mixed
  team
  collaborate
  maintainer git

(Some of these eg "mixed" are poor on their own because they've
vague.)

This proposal may still result in .gitignore presence in the .dscs
"flapping": dgit uploads will include it, but many non-dgit maintainer
workflows would exclude it.  See #908747.  I think this is unavoidable
(even, it is desirable that dgit's uploads should include it).

Also, see #933044 (which I don't understand).  I'll reply there.

Ian.  

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1067222: dgit yields unparseable patches when color.ui=always

2024-03-20 Thread Ian Jackson
Control: severity -1 important

Rafael Laboissière writes ("Bug#1067222: dgit yields unparseable patches when 
color.ui=always"):
> Package: dgit
> Version: 11.6
> Severity: normal
...
> I have stumbled on a problem related to this specific Git configuration:
> 
> [color]
> ui = always
> 
> With such a configuration, the internal calls to "git diff" in dgit 
> yield unparseable patches, making dgit unusable.

How exciting.

> Would it be possible to add the option "-c color.ui=never" wherever 
> "git diff" is called in dgit?

Something should definitely be done about this.  Sometimes dgit runs
`git diff` for the benefit of the user in which case it should
probably respect this setting.

Maybe some of the `git diff` calls should be some more plumbingy
command.  There might be other things you could write in your git
config which would affect generated patches, and we ought to override
(or ignore) those too.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1067157: summer not compiled with largefile support

2024-03-19 Thread Ian Jackson
Package: chiark-utils-bin
Version: 6.1.3~iwj2

Seen in a logfile:

+\[inaccessible: Value too large for defined data type]  ?
?  ?  ?  ?./news/news.debug

(Also, we should probably check the time64 situation.)

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1066029: secnet: please correct long description that says that hippotat is not packaged

2024-03-11 Thread Ian Jackson
Tomas Pospisek writes ("Bug#1066029: secnet: please correct long description 
that says that hippotat is not packaged"):
> The secnet long description reads:
> 
> > secnet works well with userv-ipif (allowing it to run without needing root 
> > privilege) and hippotat (not currently in Debian)
> 
> However hippotat seems to be packaged: 
> https://packages.debian.org/search?keywords=hippotat
> 
> Please correct the description.

Hah, thanks for the report :-).  I'll do this next time I work on
secnet, but it may not be soon...

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1064452: dkim-rotate: Errors during --new leave state corrupted

2024-02-24 Thread Ian Jackson
Daniel Gröber writes ("Bug#1064452: dkim-rotate: Errors during --new leave 
state corrupted"):
> I don't think it's entirely necessary to do that. Just have to take care to
> provide new users with an example that doesn't have this ambiguity.

I'm adding a note next ot the directive that invites the user to
uncomment it, which I hope will help.

> FYI:
> You might also want to include an example config in the .7 manpage. I found
> having to dig through the Debian package to find one a bit inconvenient ;)

I'll add a cross-reference to the example files in the SEE ALSO.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1064452: dkim-rotate: Errors during --new leave state corrupted

2024-02-24 Thread Ian Jackson
Control: tags -1 confirmed

Daniel Gröber writes ("Bug#1064452: dkim-rotate: Errors during --new leave 
state corrupted"):
> I'm trying to get started with dkim-rotate, but I hit an error during
> initial provisioning with --new. I use knot for auth DNS so I don't
> have the rndc, hence I tried to override dns_reload in the config. 

Thanks for the report.  I'm sorry it didn't work as expected.

> $ sudo dkim-rotate --status dkim
> dkim-rotate: instance dkim: error: state corrupted! 
> /var/lib/dkim-rotate/dkim/state:5: bad key line

I have reproduced this and will fix it.  I agree that this is a
serious bug and I will try to get it fixed in a stable update.

I'm afraid I don't have a clear workaround for you right now but I
will send you one as soon as I do.

> Seems a bit of a usability problem for new users. I'd recommend not
> commenting out directives in the example config without an
> explaination

Yes.  I may change the syntax too to remove the `;` from the SERIAL,
but that's not entirely trivial since I would want it to be backward
compatible.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1064520: Acknowledgement (felher fork, "culpa", is maintained)

2024-02-23 Thread Ian Jackson
I looked into this a bit more and have suggested to withoutboats
(author of fehler) that they might like to grant crate name ownership
to the "culpa" (fork) maintainers.

https://github.com/withoutboats/fehler/issues/70
-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1064520: felher fork, "culpa", is maintained

2024-02-23 Thread Ian Jackson
Package: rust-fehler
Version: 1.0.0-1+b1
Severity: wishlist

The fehler crate is not presently maintained.  (Rumours[1] point to
the maintainer's employer's policies preventing the maintainer from
contribnuting to FLOSS>0

The package has been picked up by the community as "culpa".
We should consider whether we want to import that.

I reviewed the MR titles of the open and closed MRs so far and looked
at the various summary pages.  I think culpa 1.0.x is compatible with
fehler 1.0.0.  (There are some new features in culpa 1.0.2, but they
are fairly minor.)

IMO it would be fine to have *just* the culpa source package in
Debian, and use it to supply a cargo package called "fehler" for those
dependencies that want that.  I have no idea how that would be done
with eg debcargo.  (One .deb that Provides both?)

Filing this as "wishlist" since the current situation is fine for now.

Ian.

[1] https://lib.rs/crates/culpa

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1064487: hippotat - upcoming rust-nix update.

2024-02-23 Thread Ian Jackson
Peter Green writes ("Bug#1064487: hippotat - upcoming rust-nix update."):
> We are preparing an update of rust-nix to version 0.27, the new version has
> been uploaded to experlmental.

Thank you for this work.

> I was fairly easily able to adapt hippotat to the new version of
> rust-nix, however unfortunately I was not able to easilly make the
> code build with both the old and the new versions.

Ah well.  I do wish upstream would get on with `#[cfg(accessible)]`.

> While I was working on this issue I ran into a couple of other
> issues, so I dealt with those too.
> 
> 1. The package's clean target was not functional, I added manual
> cleanup.
> 2. The packages cargo dependency on lazy-regex was at 2.2, but
> Debian now has 3.x. I relaxed the dependency.
> 
> A debdiff is attatched, if I get no response I will likely NMU this when the
> new rust-nix is uploaded to unstable.

Thanks!

I will incorporate these changes, and that will be a new upstream
version.

Is there any reason I shouldn't upload this to unstable myself right
away?  It won't migrate immediately, obviously but I think that's OK.

One final thing.  Can you formally confirm that you're happy for me to
commit and distribute these changes - specifically, can you confirm
the statements in the Developer Certificate of Origin ?  (attached)

In a situtation like this where a contributor has provided a
portmanteau patch, I would normally split it myself and put the author
in the commits' "author" metadata and myself in the "committer", but I
could leave your name out of the git history if you prefer.

For reference, on you would be welcome to contribute via gitlab MR
instead of BTS and debdiff, but I understand why that isn't likely to
be so convenient when trying to update nix in Debian.

Regards,
Ian.

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.



-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.


Bug#1064014: dgit - unable to import dscs due to server issues.

2024-02-15 Thread Ian Jackson
Peter Green writes ("Bug#1064014: dgit - unable to import dscs due to server 
issues."):
> Package: dgit
> 
> Something seems to be wrong with the dgit infrastructure, I've been unable to
> import any dscs from Debian that include a dgit: header for a week or two now.
> I get messages like

Hrm.  Can you point me to an example dsc (eg dgit.dsc?) and semd me
the output with -D ?

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1063533: Performance with packages with large numbers of tests

2024-02-09 Thread Ian Jackson
Package: autopkgtest
Version: 5.32
Severity: wishlist

tl;dr:

  autopkgtest is slower than it needs to be for packages with many
  tests.  I can see at least one easy opportunity for a potentially
  substantial improvement, and have another more doubtful idea.

Background and factual information:

src:dgit has over a hundred autopkgtests (115 in all right now, but
some don't run in CI due to Restrictions; only 108 run in CI).  This
is convenient for isolating failures.  The tests are grouped into
(currently) 26 stanzas in debian/tests/control.

These tests usually take around 40 minutes to run in a formal run
under autopkgtest.  Sometimes the time taken exceeds the default
1-hour timeout in salsa CI.

Some of the tests are very fast - one or two seconds.  Some take much
longer.

(During a manual run outside autopkgtest, a complete run of the tests
takes about 8 minutes, but that's with CPU parallelism so isn't
comparable.  I haven't done a non-parallel benchmark run.)

Proposal 1:

Observing the logs, I see that even for tests in the same stanza,
autopkgtest prpeares and installs an autopkgtest-satdep package,
between every test.

For short tests, this dominates the execution time.  In the logs eg
 https://salsa.debian.org/dgit-team/dgit/-/jobs/5270905
it seems to take about 6 seconds.

So I think skipping the testbed re-preparation for tests within the
same stanza would save about 6 seconds per such test, or 530-ish
seconds for each run.  Ie, it might cut 20% off the total runtime for
this package.

I'm hoping that this would be relatively straightforward to implement.

Proposal 2:

*Re*installing packages involved with many of the tests seems quite
expensive.  For src:dgit, most of the tests involve installing
dgit.deb.  dgit and its dependencies seem to take about 20s to
install.

If the test stanzas could be sequenced into "chains" where each test
is has a monotonically longer dependency list, the intervening satdep
installation, to get from one test stanza in the chain, to the nest
stanza, wouldn't need to involve *reinstalling* anything.

I'm not sure how much time this would save.  Also it's not clear to me
that this would always be 100% faithful.  After dependency resolution
is not monotonic: an extra dependency might result in *deinstallation*
of packages.

So this proposal is more fanciful but I thought I would share it
anyway.

Regards,c
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1005765: dgit doesn't handle upstream files with CRLF well

2024-02-09 Thread Ian Jackson
Control: close -1

Thanks for the report.  But, having reviewed this bug, I think all of
dgit's behaviour here is correct.

What's wrong is that the git tree and .orig have mismatched line
ending conventions.

I've conjectured that this is tolerated by other tooling (eg
git-buildpackage) because git has been configured to do automatic line
ending conversion.  That's not a good approach, because that
configuration is local to particular git trees, so different people
see different working trees for the same commit.

Probably, the git tree should be changed to match the upstream source
code.  The other alternative is not to use the upstream .orig, but
rather use one that you've converted to Unix line endings.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1061866: adns: NMU diff for 64-bit time_t transition

2024-02-07 Thread Ian Jackson
Control: severity -1 important

Ian Jackson writes ("Re: Bug#1061866: adns: NMU diff for 64-bit time_t 
transition"):
> I have just got an alert saying adns is now scheduled for autoremoval
> due to #1061866.
> 
> My understanding was that you were intending to NMU to unstable after
> "several days".  I have been holding off making an upload myself so as
> not to interfere.

I'm not sure if I should:

 (i) wait

 (ii) apply that patch (on top of what's in experimental)
  and upload to experimental

 (iii) apply that patch on top of what's in experimental
   and upload the result to sid.

For now I am going to downgrade this bug in the hope that the current
answer is (i).

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1063342: libcurl now rejects HTTP/1.0 responses to HEAD containing body

2024-02-06 Thread Ian Jackson
Package: libcurl3-gnutls
Version: 8.6.0-1

tl;dr: I found a regression in bug-compatibility but I have no idea if
   it should be considered a problem.

Hi.

I investigated the failing dgit autopkgtest, which is (at leasat one
of the reasons) preventing src:curl from migrating.

I found that the root cause was that dgit's test suite has a stunt
http server which mishandles HTTP HEAD requests: it doesn't look at
the request method at all, so it responds to HEAD the same as GET,
with a body.  So that is wrong.

The new libcurl rejects this, with a "Weird server reply" error.

I have filed the bug in the test case's stunt httpd as #1063341 (with
severity serious) and we will fix it in src:dgit soon.

However, I wonder whether this behavioural change in curl is
intentional or desirable.  It seems to me that it might pose a
compatibility hazard.  I know that compatibility, even with broken
peers, is often important in the web space.

I haven't tested the behaviour with HTTP/1.1.  HTTP/1.1 has different
framing arrangements: depending on the framing, a similar bug in a
server would result in a framing error so such a buggy server wouldn't
survive.  But with HTTP/1.0, a response which erroneously includes the
body is unambiguous and parseable.

I don't know if HTTP/1.0 is common enough, and compatibility with such
buggy HTTP servers important enough, to be concerned.  I thought I
would file this bug to inform you about the situation and let you
decide.  I hope you find that helpful.

Please downgrade, close, or forward to upstream, or upgrade, this bug,
as seems appropriate.

Thanks for your attention and your maintenance of this critical
package.

Regards,
Ian.

30178 read(7, "H", 1)   = 1
 | 0  48H|
30178 read(7, "E", 1)   = 1
 | 0  45E|
30178 read(7, "A", 1)   = 1
 | 0  41A|
30178 read(7, "D", 1)   = 1
 | 0  44D|
30178 read(7, " ", 1)   = 1
 | 0  20 |
30178 read(7, "/", 1)   = 1
 | 0  2f/|
30178 read(7, "p", 1)   = 1
 | 0  70p|
...
30178 write(7, "HTTP/1.0 404 Not found\r\nContent-Type: text/html; 
charset=ISO-8859-1\r\n\r\nhttp://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;>\nhttp://www.w3.org/1999/xhtml\; lang=\"en-US\" 
xml:lang=\"en-US\">\n\nNot found\n\n\n\nNot found\n\n", 426) = 426
 | 0  48 54 54 50 2f 31 2e 30  20 34 30 34 20 4e 6f 74  HTTP/1.0 404 Not |
 | 00010  20 66 6f 75 6e 64 0d 0a  43 6f 6e 74 65 6e 74 2d   found..Content- |
 | 00020  54 79 70 65 3a 20 74 65  78 74 2f 68 74 6d 6c 3b  Type: text/html; |
 | 00030  20 63 68 61 72 73 65 74  3d 49 53 4f 2d 38 38 35   charset=ISO-885 |
 | 00040  39 2d 31 0d 0a 0d 0a 3c  21 44 4f 43 54 59 50 45  9-1.http://www.w3.o |
 | 000e0  72 67 2f 31 39 39 39 2f  78 68 74 6d 6c 22 20 6c  rg/1999/xhtml" l |
 | 000f0  61 6e 67 3d 22 65 6e 2d  55 53 22 20 78 6d 6c 3a  ang="en-US" xml: |
 | 00100  6c 61 6e 67 3d 22 65 6e  2d 55 53 22 3e 0a 3c 68  lang="en-US">..Not  |
 | 00120  66 6f 75 6e 64 3c 2f 74  69 74 6c 65 3e 0a 3c 6d  found.. |
 | 00180  0a 3c 62 6f 64 79 3e 0a  3c 68 31 3e 4e 6f 74 20  ..Not  |
 | 00190  66 6f 75 6e 64 3c 2f 68  31 3e 0a 3c 2f 62 6f 64  found..   |
30178 close(7)      = 0

...

dgit: error: fetch of http://127.0.0.1:40339/pari-extra.git/HEAD failed (Weird 
server reply):

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1063341: dgit test suite stunt http server mishandles HEAD

2024-02-06 Thread Ian Jackson
Package: dgit
Version: 11.5
Severrity: serious

dgit's autopkgtest is failing and this is (at leasat one of the
reasons) preventing src:curl from migrating.  I have investigated one
of the failing tests, dgits `clone-nogit` test case.

This failing test sets up a dummy HTTP server using
libhttp-server-simple-static-perl.  It then runs a dgit operation
which involves dgit using libcurl (via libwww-curl-perl) to access
that server.

The failing HTTP transaction unfolds as follows: dgit asks for a
resource which the test case wants to reply to with 404.
libhttp-server-simple-static-perl doesn't handle that very nicely, so
dgit's stunt HTTP server perl script has ad-hoc code so make a
suitable 404 response.

For simplicity, the stunt server responds using HTTP/1.0.  I straced
it so I could see the actual response (see below).

Observe that the httpd is responding to a HEAD request but it is
supplying a body.  Apparently libcurl treats that as an error now.

The test ought to be fixed.  But I will file a separate bug against
curl in case this is felt to be a compatibility hazard.

(The stunt http server is in src:dgit as tests/http-static-server.)

Ian.

30178 read(7, "H", 1)   = 1
 | 0  48H|
30178 read(7, "E", 1)   = 1
 | 0  45E|
30178 read(7, "A", 1)   = 1
 | 0  41A|
30178 read(7, "D", 1)   = 1
 | 0  44D|
30178 read(7, " ", 1)   = 1
 | 0  20 |
30178 read(7, "/", 1)   = 1
 | 0  2f/|
30178 read(7, "p", 1)   = 1
 | 0  70p|
...
30178 write(7, "HTTP/1.0 404 Not found\r\nContent-Type: text/html; 
charset=ISO-8859-1\r\n\r\nhttp://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;>\nhttp://www.w3.org/1999/xhtml\; lang=\"en-US\" 
xml:lang=\"en-US\">\n\nNot found\n\n\n\nNot found\n\n", 426) = 426
 | 0  48 54 54 50 2f 31 2e 30  20 34 30 34 20 4e 6f 74  HTTP/1.0 404 Not |
 | 00010  20 66 6f 75 6e 64 0d 0a  43 6f 6e 74 65 6e 74 2d   found..Content- |
 | 00020  54 79 70 65 3a 20 74 65  78 74 2f 68 74 6d 6c 3b  Type: text/html; |
 | 00030  20 63 68 61 72 73 65 74  3d 49 53 4f 2d 38 38 35   charset=ISO-885 |
 | 00040  39 2d 31 0d 0a 0d 0a 3c  21 44 4f 43 54 59 50 45  9-1.http://www.w3.o |
 | 000e0  72 67 2f 31 39 39 39 2f  78 68 74 6d 6c 22 20 6c  rg/1999/xhtml" l |
 | 000f0  61 6e 67 3d 22 65 6e 2d  55 53 22 20 78 6d 6c 3a  ang="en-US" xml: |
 | 00100  6c 61 6e 67 3d 22 65 6e  2d 55 53 22 3e 0a 3c 68  lang="en-US">..Not  |
 | 00120  66 6f 75 6e 64 3c 2f 74  69 74 6c 65 3e 0a 3c 6d  found.. |
 | 00180  0a 3c 62 6f 64 79 3e 0a  3c 68 31 3e 4e 6f 74 20  ..Not  |
 | 00190  66 6f 75 6e 64 3c 2f 68  31 3e 0a 3c 2f 62 6f 64  found..   |
30178 close(7)  = 0

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1061866: adns: NMU diff for 64-bit time_t transition

2024-02-06 Thread Ian Jackson
Steve Langasek writes ("Bug#1061866: adns: NMU diff for 64-bit time_t 
transition"):
> Apologies, an oversight in the conversion script caused us to fail to update
> strict versioned dependencies on the previous package name.  Please find
> attached a fixed patch.

Hi.  Thanks for this project.

I have just got an alert saying adns is now scheduled for autoremoval
due to #1061866.

My understanding was that you were intending to NMU to unstable after
"several days".  I have been holding off making an upload myself so as
not to interfere.

FTR, anything which causes autoremoval to be scheduled will attract a
lot of attention, because removal can be a significant setback.
Maintainers such as myself will want to act ASAP to resolve the
situation.

Please advise.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1061866: adns: NMU diff for 64-bit time_t transition

2024-01-29 Thread Ian Jackson
Hi.  Thanks for your work on this.

Steve Langasek writes ("Bug#1061866: adns: NMU diff for 64-bit time_t 
transition"):
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> adns as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).

Thanks.  I have verified that adns.h, and the ABI of adns, is indeed
affected.

> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.

I'm surprised at

+Provides: ${t64:Provides}
+Replaces: libadns1
+Breaks: libadns1 (<< ${source:Version})

I don't know why this isn't just a soname transition.  But I think
probably people more involved in this have thoughyt this through.
(Perhaps this to do with making this a no-op on 64-bit arches.)

> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.

If what I have written doesn't indicate that something has been
overlooked, you should go ahead as planned.  I guess I should avoid
uploading myself.

adns is not an "unusual" package, other than insofar as time_t being
part of an ABI-exposed struct makes it unusual.

HTH.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1061619: read.c OOP_RD_NUL_DISCARD is broken

2024-01-27 Thread Ian Jackson
Package: liboop4
Version: 1.0.1-2.1

Fixes this compiler warning:

  read.c: In function 'on_process':
  read.c:402:38: warning: comparison between pointer and zero character 
constant [-Wpointer-compare]
   notnul < buf+thisrecsz && notnul == '\0';
^~
  read.c:402:31: note: did you mean to dereference the pointer?
   notnul < buf+thisrecsz && notnul == '\0';

History of this fix: See #579604.  I am tidying up my own
program (innduct), which I find it still has a copy of this file.
Comparing the files I find this one difference.  I seem to have fixed
this bug in 2022 without noticing that I ought to be sending the fix
upstream.  So, apologies for the delay reporting this.

Patch attached.

Thanks,
Ian.

>From 732e5f352205cc1d67ee28ea68fa02869aba5551 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Sat, 27 Jan 2024 13:03:00 +
Subject: [PATCH] read.c: Fix missing dereference - bug with OOP_RD_NUL_DISCARD

Fixes this compiler warning:

  read.c: In function 'on_process':
  read.c:402:38: warning: comparison between pointer and zero character 
constant [-Wpointer-compare]
   notnul < buf+thisrecsz && notnul == '\0';
^~
  read.c:402:31: note: did you mean to dereference the pointer?
   notnul < buf+thisrecsz && notnul == '\0';
 ^

I think the impact would be that OOP_RD_NUL_DISCARD would pass through
(fail to discard) all but the first nul in each buffer-full.

I wrote this file originally.  I don't know why I didn't use memchr
instead of this open-coded loop.  But, I'm don't think it's a good
idea to refactor it now.
---
 read.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/read.c b/read.c
index 38cba00..deaadb5 100644
--- a/read.c
+++ b/read.c
@@ -399,7 +399,7 @@ static void *on_process(oop_source *oop, oop_read *rd, int 
try_read) {
   }
   assert(rd->style.nul_mode == OOP_RD_NUL_DISCARD);
   for (notnul= nul+1;
-  notnul < buf+thisrecsz && notnul == '\0';
+  notnul < buf+thisrecsz && *notnul == '\0';
   notnul++);
       thisrecsz-= (notnul-nul);
   checked= nul-buf;
-- 
2.20.1


-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.


Bug#1059417: ed: install (r)ed into /usr/bin

2023-12-24 Thread Ian Jackson
Chris Hofstaedtler writes ("Bug#1059417: ed: install (r)ed into /usr/bin"):
> Your package installs ed and red into /bin. For the ongoing Debian
> UsrMerge effort [1] these should move to /usr/bin in the trixie
> cycle.

Hi.  FTR, I am not the maintainer.

> I'm attaching a trivial patch to implement such a move.
> As explained in debian/changelog, the update-alternatives calls are
> intentionally kept unchanged, to preserve existing user
> configuration.

I assume that you are following a plan developed by Helmut et al, as
part of the overall Debian usrmerge mitigation plan.

I don't think I agree with this change, as provided, because it will
cause ed to move to /usr/bin on downstreams that don't do usrmerge.
And then, without changing the diversion, the package is actually
broken.

I think there could be an affordance in dh_auto_configure that allows
this all to work properly.

I assume there is some reason why we aren't, in Debian, changing
dh_auto_configure to interpret --bindir=/bin as --bindir=/usr/bin.

> If during the trixie cycle your package will undergo structural
> changes or any other file moves, please also see the wiki and upload
> to experimental first when these changes are done.

I don't believe this is planned, but, once again, I am not the
maintainer.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1059388: git-debrebase: found two-parent merge, how to cope?

2023-12-24 Thread Ian Jackson
Hi.

I'm going to reply off the cuff in the hope of getting you unstuck.
If this email doesn't nsuffice I'll take a look at your git
branch.  So please let me know how you get on.

Philipp Kern writes ("Bug#1059388: git-debrebase: found two-parent merge, how 
to cope?"):
> In the absence of a better venue of asking this question (there seems to
> be no mailing list): I have an upstream repository that contains a
> two-parent merge for some reason (https://github.com/twosigma/nsncd, of
> all the things merging a CLA into the repository). dgit bails out with
> this:

In git-debrebase, the upstream branches are supposed to be able to
contain any arbitrary stuff.

gdr is supposed to stop looking in detail at the commit structure as
soon as it finds the anchor, ie the last merge from into Debian.
These must all be done with gdr new-upstream.

> | Format `3.0 (quilt)', need to check/update patch stack
> | examining quilt state (multiple patches, linear mode)
..
> | git-debrebase: error: found unprocessable commit, cannot cope: general 
> two-parent merge (e3de17c274315bab561664ac57e46472670545cf)

I suspect that the upstream branch has been merged directly into your
packaging branch, rather than using git-debrebase --new-upstream ?

> I have so far forced an --anchor manually upon git-debrebase, which
> worked, but is also very tedious to pass everywhere. Is this something
> that will auto-fix itself on the next upstream release because dgit will
> properly discard the history pre the current upstream release? I was at
> least hoping that it would disappear with the first regular upload - but
> this did not happen.
..
> Is there something I can do for dgit to accept the current state of the
> repository as canonical up to the point where the Debian packaging was
> modified/forked off. The snags are upstream's prior packaging as found
> in the upstream repository, which does not seem to be uncommon to me
> either.

I'm not sure using --anchor is wise.  Certainly not routinely.

new-upstream would generate a new anchor, so you could use --anchor
once, assuming you're sure about which commit it is.

But if you merged from upstream *on top* of commits represending the
delta, that won't do the right thing.  It will abolish the delta and
start to try to treat them as part of the upstream, and then your next
attempt to make a source package will fail.

One thing you could try would be an invocation of
  git-debrebase --experimental-merge-resolution new-upstream

Or indeed
  git-debrebase --status


I think if my hypothesis about what has happened to your branch is
correct, my suggested remedy would be to make a new branch starting
just before the mistake, redo all subsequent work "properly" - without
introduce any merges other than via git-debrebase new-upstream.

Then when you have done that the result should be tressame to your
"messed up" branch, but have correct gdr history.

Then "git merge -s ours broken-branch" will make your fixed version ff
from the broken one and from then I hope everything will be fine?
(Maybe I should look up which branch of a completely tree-identical
merge gdr looks at, but I'm hoping that it's the one that is implied
by following the non-contributing parent of git merge -s ours.)


Don't spend too long on wrestling with this.  I can probably fix it up
in an hour or so.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1058701: pm-utils: unauthorised and uncommunicated removal

2023-12-23 Thread Ian Jackson
Joerg Jaspert writes ("Re: pm-utils: unauthorised and uncommunicated removal"):
> It wouldn't have made the review any noticable amount harder.

Fair enough.

> I do suggest fixing those things, Ancient Standard version and debhelper
> 7 do make it *really* easy to accept "This is unmaintained".

Yes.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1058701: pm-utils: unauthorised and uncommunicated removal

2023-12-22 Thread Ian Jackson
Thorsten Alteholz writes ("Re: pm-utils: unauthorised and uncommunicated 
removal"):
> On Thu, 21 Dec 2023, Ian Jackson wrote:
> > I intend to re-upload the last version shortly (and reopen all the
> > bug reports).
> 
> Yes, please do so.

Thanks.  This has now been done.

I chose to *not* fix anything about the package now (not even the
wrong VCS fields, for example) in order to simplify review.

The diff against the version previously in sid, and currently in
testing, is attached.

Regards,
Ian.

diff --git a/debian/changelog b/debian/changelog
index 9dd8325..7469392 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pm-utils (1.4.1-20) unstable; urgency=medium
+
+  * No-change upload to reintroduce to sid following erroneous
+    removal (#1058701).
+
+ -- Ian Jackson   Fri, 22 Dec 2023 22:26:26 
+
+
 pm-utils (1.4.1-19) unstable; urgency=medium
 
   * No-change upload to make myself the maintainer.  I intend to perhaps

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.


Bug#1058701: pm-utils: unauthorised and uncommunicated removal

2023-12-22 Thread Ian Jackson
Hi.  Thanks for your nice email.

Thorsten Alteholz writes ("Re: pm-utils: unauthorised and uncommunicated 
removal"):
> this is sad. The RM bug appeared on the tracker page of the package, in 
> your packages overview, on the ftpmaster removals page (or on the bug 
> page). It was also sent to debian-bugs-dist@lists.debian.org.

Right.  But none of those places actually email the maintainer.

> Where would have been a better place to draw your attention to it?

I think ideally the process would have involved a bug against the
package.  I appreciate that that's not always convenient.

Would it be possible and sensible to improve your tooling to warn you,
or require additional configuration, when you're removing a package
from sid that is still in testing ?  I think that would be an unusual
case.  (But that's just a guess; maybe I'm wrong about how unusual it
is.)  (And apparently this is quite rare and maybe this bug isn't the
right place to discuss such an improvement.)

> Hmm, the standards version is 3.9.7, the VCS URLs point to a no longer 
> existing repository, the last upload was in 2019. This looks rather like 
> an abandoned package. But of course, your mileage may vary

Yes.  I can see how you would think that.  Updating the package to
improve the metadata etc. didn't seem a priority.

For the record, I think your action was perfectly understandable; you
normally don't need to consider whether a removal request is the
result of ill will or conflict.  And, I very much appreciate all the
hard work you do with the day to day of ftpmaster.  It is difficult
for me to express my thanks for that strongly enough.  I understand
that a person who does a lot of work will make the occasional mistake,
too.

I should probably have said all this in my last mail.

> > I intend to re-upload the last version shortly (and reopen all the
> > bug reports).
> 
> Yes, please do so.

Thanks.  That'll probably happen later today.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1059239: All dgit operations should use "sop" for OpenPGP operations

2023-12-21 Thread Ian Jackson
Package: dgit

See
  https://lists.debian.org/debian-devel/2023/12/msg00127.html
and scroll down to "What Can Debian Do About This?".

dgit also calls various other tooling, notably debsign, which it would
be nice to get updated too.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1058701: pm-utils: unauthorised and uncommunicated removal

2023-12-21 Thread Ian Jackson
I have just become aware of #1058701 via the automated email that
resulted from the removal of pm-utils.

As the maintainer of this package, I do not agree with its removal.
It has no RC bugs, is in testing, and is working software.

I am still using this package.  I'm sure others are.  The package *is*
maintained in Debian - I look for significant bugs and if there were
any we would fix them.  That the package hasn't seen much activity
does not mean it doesn't work.

I'm sure that it isn't normal Debian practice to remove a package from
sid without consulting the maintainer.  IMO the correct procedure if a
package is thought to be unreleasable would be to remove it from
testing first. [1]

The submitter of #1058701 notes
| Modern userspace uses systemd to perform suspend/resume instead.

This should be a red flag, indicating that the removal was being
requested by someone who thinks that Debian only supports systemd and
that other more mature software for similar tasks ought to be removed.

I intend to re-upload the last version shortly (and reopen all the
bug reports).

Thanks for your attention.

DAM/CT: I am addressing this mail To you because the behaviour by the
submitter of #1058701 represents behaviour I consider worthy of
disciplinary action, and becauase it appears that there's been a
process failure which allowed this removal to happen without anyone
notifying the maintainer.  It's probably best to deal with these
matters in private.

Ian.

[1] That was attempted in #930869, which is unedifying.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1058043: automatic cleaning should (always) be enabled by default

2023-12-11 Thread Ian Jackson
Package: apt

A friend's laptop's / had become full.  I found 9 gigabytes of
uselessly retained ancient debs in /var/cache/apt/archives.
"apt clean" fixed the problem.

I wondered why my laptop doesn't do this and a small amount of
digging found an etckeeper commit from 2017.  (See below.)
Presumably I discovered this wasn't happening on my laptop and thought
that it was somehow the result of something weird about my setup.
But evidently not, since my friend's install is much more vanilla.

My friend usually uses a GUI package manager.  I could enquire as to
which one.  I usually use "apt" and sometimes "apt-get" aned never use
a GUI package manager.  I don't know if the cache would still be being
maintained properly without my local change - ie, I don't know if the
bug I experienced in 2017 would happen to *me* now, but it doesn't
seem likely that anything has changed very much given the bug reports
I saw.

IMO something should ensure that files in /var/cache/apt are
eventually deleted.  I don't know if there is a thing that is supposed
to do this, but if there is it doesn't always work.  It probably ought
to be part of src:apt, since it's code in that package which is
creating these files.  So that is why I'm filing this bug here.

I searched the BTS for (archived and unarchived) bugs with "clean" in
the title.  Most of them seems to be bug reports (or feature requests)
relating to the behaviour of `apt clean`.

I found #160743 which is a report of the the same outcome, which was
closed after having been only partially resolved.  The mechanisms may
be different nowadays.

Partly, I am filing this bug to document my workaround.  Apparently,
it was sufficient, since `cd /etc && git grep -i clean apt` doesn't
show anything else.  So, my workaround is as follows:

Create the file /apt/apt.conf.d/50actually-clean
containing just this one line:

APT::Periodic::AutocleanInterval 7;

Ian.

commit a6030b5ee990c826550fe5c530c54215817bdf65
Author: root 
Date:   Mon Oct 9 02:12:17 2017 +0100

daily autocommit

diff --git a/.etckeeper b/.etckeeper
index 9167d07..b47e059 100755
--- a/.etckeeper
+++ b/.etckeeper
@@ -434,6 +434,8 @@ maybe chmod 0444 'apt/apt.conf.d/01autoremove-kernels'
 maybe chmod 0644 'apt/apt.conf.d/05etckeeper'
 maybe chmod 0644 'apt/apt.conf.d/20listchanges'
 maybe chmod 0644 'apt/apt.conf.d/20packagekit'
+maybe chgrp 'ian' 'apt/apt.conf.d/50actually-clean'
+maybe chmod 0664 'apt/apt.conf.d/50actually-clean'
 maybe chmod 0644 'apt/apt.conf.d/50apt-file.conf'
 maybe chgrp 'ian' 'apt/apt.conf.d/55aptsquid'
 maybe chmod 0664 'apt/apt.conf.d/55aptsquid'
diff --git a/apt/apt.conf.d/50actually-clean b/apt/apt.conf.d/50actually-clean
new file mode 100644
index 000..8f59382
--- /dev/null
+++ b/apt/apt.conf.d/50actually-clean
@@ -0,0 +1 @@
+APT::Periodic::AutocleanInterval 7;


-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1056656: dgit: Crash while running dgit rpush-source [and 1 more messages]

2023-11-24 Thread Ian Jackson
Hi.  Thanks for the bug report.

Reinhard Tartler writes ("Bug#1056656: dgit: Crash while running dgit 
rpush-source"):
> I've been starting to enjoy `dgit rpush-source` so that I can
> offload my test building from my laptop. This works for many
> repositories/packages, but when it fails, it does so in a way that
> is very hard to diagnose. This is what I end up with:

Hrm.  Obviously it shouldn't do that :-).

>siretart@x1:~$ dgit  rpush-source 
> builder:/home/siretart/packages/golang-github-containers-buildah --new 
> experimental 

Can you provide me a "steps to reproduce" ?

In particular, can you tell me, in
  /home/siretart/packages/golang-github-containers-buildah
what commitid is your HEAD and where can I get it?

What .orig tarballs will I need?

> What's wrong with /usr/bin/dgit line 5544?

That line is trying to bail out due to what it thinks is a violation
of the rpush protocol (between the two dgits).  I think it is crashing
because $i_param{'splitbrain'} is undef but $do_split_brain is set.

I think I'll have to repro this locally to diagnose and fix it.  I
think there are at least two bugs: 1. whatever caused it to take this
error path 2. when this is detected, the attempt to construct the
error message fails so it crashes even worse.

Reinhard Tartler writes ("Bug#1056656: dgit: Crash while running dgit 
rpush-source"):
> Just for the record, in this particular instance, passing the
> argument `--gbp` allowed me to proceed. So I've used this
> invocation:

That's interesting.  I preusme that your branch is in fact in
unapplied (gbp) format?  So your original invocation (without --gbp)
may have been in error.  dgit attempts to detect this mistake and
provide a bespoke error message for it, but (if that's what's
happening here) that isn't working.

> Thanks for providing dgit and its infrastructure. I has really made
> working with debian source packages much more enjoyable!

Thanks for the kind words.  You're welcome.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1056595: dgit: must not override dpkg include lists

2023-11-23 Thread Ian Jackson
Johannes Schauer Marin Rodrigues writes ("Re: Bug#1056595: dgit: must not 
override dpkg include lists"):
> this bug was triggered by julian trying to work on my package sbuild
> in ubuntu.  I usually upload all my packages with "dgit --quilt=gbp
> push-source" and hence the problem julian faces was created.

I'm still not sure what the precise problem is.  Is it that the .dsc
in the Debian archive contains a .gitignore ?

> I'd also have no problem with resolving this particular situation by
> adding an appropriate debian/source/options to sbuild for the next
> upload. Then the same thing would happen independent of whether the
> person building sbuild uses dgit or not.

I think probably that would help.  IIRC there are some strange
interactions between dpkg command line options and d/s/options.
(I can't remember the details offhand.)

dgit does look in d/s/options but mostly to check that there's nothing
there that would make dpkg-source do something that dgit doesn't want.

Maybe some of our documentation (eg, dgit-maint-native(7)) should
recommend creating d/s/options, and maybe dgit ought to check that?

> But would that be future proof as in: will dgit maybe adjust these options in
> the future and if yes, is there something dgit could do to inform me that my
> debian/source/options might be incomplete?

dgit's default behaviour in this area hasn't changed for a very long
time.  It always wants to upload precisely your git tree, and
therefore it must pass dpkg-source options that make it able to
generate such a source package.

I think the only thing that might change is that #908747 might get
fixed, but that also seems unlikely and wouldn't invalidate your
d/s/options anyway.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1056595: dgit: must not override dpkg include lists

2023-11-23 Thread Ian Jackson
Severity: -1 normal

Julian Andres Klode writes ("Bug#1056595: dgit: must not override dpkg include 
lists"):
> dgit overrides the include lists for dpkg, causing packages to include
> additional .gitignore and similar files which dpkg-source -b will
> exclude.

Yes.

This is necessary (1) so that the git trees correspond precisely to
the .dscs (which is the invariant of the dgit git view), and
(2) to comply with our promise to provide people with the source code.

I consider dpkg-source's behaviour, of excluding .gitignore by default,
to be wrong:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747
(You may recall that report, since you commented on it.)

> This creates a significant hurdle to the NMU process and downstream
> distribution maintainers who have to figure out how to reduce the
> delta again, because in both cases, unrelated changes should not
> be present in the diff between the two uploads.

I'm afraid I don't understand your scenario precisely.  I'm
sympathetic to the goal of removing hurdles for NMUers and downstream
maintainers.

> Like I had to spend about 20 minutes or so today trying to figure out
> how to actually get that sorted out for a native package (I was trying
> -i all the time when I should have passed -I), in turn I discovered
> some other process issues but that's beside the point :D

Were you trying to use dgit to make an NMU?  If so what git branch
did you start with?  What options did you give to dgit?

Or, are you the maintainer?  In which case, I'd like to know more
about what went wrong.  Did some NMUer using dgit make an upload that
is causing you trouble?

As background:

I generally recommend that someone doing an NMU which they intend to
upload with dgit, also obtain their baseline package with dgit.  Eg,
see
  https://manpages.debian.org/bookworm/dgit/dgit-nmu-simple.7.en.html
I recommend that users should *not* use the semi-official Debian git
sources because they're not suitable for non-Debian-experts:
  https://diziet.dreamwidth.org/9556.html

Of course if - like you do - you know what you're doing, then you can
start from (eg) a salsa branch.  But then I'm afraid that this problem
with .gitignore may be just another one of the strange Debian things
that you have to know.

Even so, I'm open to ideas of ways to make this wrinkle less annoying.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1056103: dgit fills up my disk with .git/dgit/unpack directories

2023-11-16 Thread Ian Jackson
Control: tags -1 confirmed

Hi.  Thanks for the report.  I'm sorry that you're finding dgit has
done xsomething inconvenient.

gregor herrmann writes ("Bug#1056103: dgit fills up my disk with 
.git/dgit/unpack directories"):
> Recently I noticed that my usage of `dgit --gbp push-source' leaves
> .git/dgit/unpack directories in each touched package directory. Which
> in my case amounts to 1.5 GB below my pkg-perl directory (for more
> than 1100 dgit-pushed packages since 2019).

Ah.  I hadn't really considered this kind of use case.  (I obviously
touch smaller packages, or fewer different packges, or sometbing.)

I think the wasted space ought to be be O(the size of the source
package), although constant factor may be 2 or 3.  Is this not the
case for you ?  If there are cases where dgit has wasted much more
space then that would be straightforwardly buggy I think.

You're right that these directories are not really needed after dgit
has completed.  However, they can be useful for debugging failures.
Another future run of dgit would remove it of course, but would just
leave another one.  And there's no central tracking and they're hidden
in .git so you wouldn't normally see them and know to delete them.

So, yes, I can see the problem and I agree that something better
should be done.

I think there are some tradeoffs involved, so may not entirely
straightforward.  Some thought will be needed.  (Some of the things in
.git/dgit are hardlinked from elsewhere, so it's not as simple as
using TMPDIR instead.)

Perhaps dgit should, by default, clean up this stuff just before it
exits successfully, but leave it behind for debugging failures.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1055528: dgit: perl warning: variable $date masks earlier declaration

2023-11-07 Thread Ian Jackson
ControL: severity -1 normal

Étienne Mollier writes ("Bug#1055528: dgit: perl warning: variable $date masks 
earlier declaration"):
>   $ dgit --help
>   "my" variable $date masks earlier declaration in same scope at 
> /usr/bin/dgit line 2188.
>   main usages:
> dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir]
> dgit [dgit-opts] fetch|pull [dgit-opts] [suite]
> dgit [dgit-opts] build [dpkg-buildpackage-opts]
>   […]
> 
> This is repeatable with any other invocation from my typical
> dgit workflow.  This is not visibly impairing the functionality
> of dgit, hence the minor severity.

Thanks for the report.  This seems like it might be discouraging to
users so I think it warrants a higher severity.

I thought I had taken measures to treat warnings as errors, so err,
not sure how this could have esscaped through testsing.  I will
investigate that as well as fixing the underlying slip.

Regards,
Ian.



Bug#931225: Please make Classic style the default

2023-11-02 Thread Ian Jackson
Four and half years ago I reported what were then already longstanding
and severe bugs in the custom theme we use as the default theme for
the Debian wiki.

I also requested that the default be changed to the "Classic" theme
(which as I understand it is provided by upstream), pending a fix to
those bugs in our own theme.

As I wrote three years ago

> If those who really dislike the Classic theme find it too ugly, then
> I think it would be reasonable to expect those people to maintain
> that theme.  That includes fixing serious defects in a reasonable
> time.

There has been no progress.  No-one authoritative has given the
go-ahead, and said that this change should be made.  But, neither has
anyone authoritative vetoed it.

It appears that no-one with the relevant authority is interested in
this problem.  That's fine; I'm not demanding that anyone do work that
they're not interested in.

However, I wish this problem to be unblocked.  It doesn't seem like
simply changing the default will be very difficult.  So:

I suspect that this default is part of the MoinMoin configuration
files, which we have perhaps modifed.  Or, that it is stored in the
MoinMoin database.  It will probably be obvious from insepcting the
running system where this change has been made.

In either case, I believe DSA would be able to either change the
default themselves, or grant me sufficient technical privilege to make
the change myself.

If I don't hear to the contrary within (say) 28 days, I will ask DSA
to make "Classic" the default theme on wiki.debian.org, or to enable
me to make that change myself.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1054630: dgit - cant import llvm-toolchain-15.

2023-10-29 Thread Ian Jackson
Ian Jackson writes ("Re: Bug#1054630: dgit - cant import llvm-toolchain-15."):
> I'll work on some kind of fix.

I have a fix.  There's some minor reorganisation of the dsc import
code, to make my fix apply to whatever is wrong with the historical
info in the package changelog.  So I won't be backporting this right
away as a stable release update.  I will consider doing that after
it's been in testing for a while.

You should find that you can install the 11.4 .deb, which I intend
to upload later today, directly on whatever system you are using.
Or, build your own from the source; again, after I've uploaded.

Anyway, thanks for the report.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1054630: dgit - cant import llvm-toolchain-15.

2023-10-28 Thread Ian Jackson
Peter Green writes ("Bug#1054630: dgit - cant import llvm-toolchain-15."):
> Correct me if I'm wrong here, but doesn't the import process
> only use information from the topmost changelog entry.

I'm investigsting now.  The faulty changelog entry indeed isn't the
topmost one.  However, dgit needs to use the changelog entry
corresponding to the (first) import of that upstream version, for its
synthetic commits representing the .origs.

(dgit tries to make these stable, as that improves the synthetic git
commit structure.)

I think the best thing is to use dummy data for the authorship, and
the date of the last non-broken changelog entry before the one it
wants.  But perhaps that's too complicated and dgit should just use
today's data and dummy authorship if any of this archaeology fails.

I'll work on some kind of fix.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1054630: dgit - cant import llvm-toolchain-15.

2023-10-27 Thread Ian Jackson
Peter Green writes ("Bug#1054630: dgit - cant import llvm-toolchain-15."):
> Correct me if I'm wrong here, but doesn't the import process
> only use information from the topmost changelog entry.

I believe so.  I'd have to check the code.  I think the top changelog
entry information might be used for the "record in suite" pseudomerge.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1054630: dgit - cant import llvm-toolchain-15.

2023-10-27 Thread Ian Jackson
Peter Green writes ("Bug#1054630: dgit - cant import llvm-toolchain-15."):
> Now on the one hand, the changelog in llvm-toolchain-15 is indeed broken.
> I filed a bug about that.

Thanks.  (FMR that's #1051961)

> On the other hand, the package was accepted by the Debian archive and
> related tooling. Not being able to import it is blocking things up
> for raspbian. I'd appreciate a way to downgrade this error to a
> warning.

*sigh* what a mess.  Quite so.  I might be able to look at this in the
next few days.

It's not 100% straightfrward, because dgit uses that information to
construct the commit messages for the dsc import.  So I think some
dummy information will have to be provided.  Or maybe we should be
using the dsc Maintainer instead.  Presumably the archive is better at
rejecting a missing dsc Maintainer.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1053571: secnet ought to provide a logrotate.d snippet

2023-10-06 Thread Ian Jackson
Package: secnet
Version: 0.6.7

Many of my machines have this ad-hoc.  It ought to be in the package,
tested, etc.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#933017: Please add source link and bug reporting info to footer

2023-10-03 Thread Ian Jackson
Control: reopen -1
Control: retitle -1 Please make page source code link appear in every page 
footer

> From: Thomas Lange 
...
> We have this info not on all web pages but on our startpage www.d.org.

Thanks.  However, I think it should be at the very least in this page:

> [Ian Jackson:]
> > I looked for this information in the footer of this page
> >   https://www.debian.org/legal/privacy
> > and it wasn't there.

Ideally it would be on every page.  Do you agree ?

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1051137: bookworm-pu: package dgit/10.7+deb12u2

2023-09-29 Thread Ian Jackson
Ian Jackson writes ("Bug#1051137: bookworm-pu: package dgit/10.7+deb12u2"):
> Two users separately disscovered a misssing safety catch in dgit:

In the absence of a negative response, and conscious of the upcoming
stable release, I've uploaded this.

dgit push-source spotted that I had botched the suite name in the
d/changelog.  Therefore I made an additional commit to fix that.
Please find attached the incremental diff, and a complete revised diff
of the actual upload.

Thanks,
Ian.

>From f31976ecdc0c4ce1d451bc2f138f0b9d5a3689c1 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Fri, 29 Sep 2023 11:28:51 +0100
Subject: [PATCH] changelog: fix wrong suite

Signed-off-by: Ian Jackson 
---
 debian/changelog | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 55aca1076..14b122146 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-dgit (10.7+deb12u2) unstable; urgency=medium
+dgit (10.7+deb12u2) bookworm; urgency=medium
 
   * Prevent pushing older versions than is in the archive.
 Closes: #1050711.  [Reports from Helmut Grohne and Phil Hands]
-- 
2.20.1

diff --git a/debian/changelog b/debian/changelog
index bf03d2744..14b122146 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+dgit (10.7+deb12u2) bookworm; urgency=medium
+
+  * Prevent pushing older versions than is in the archive.
+Closes: #1050711.  [Reports from Helmut Grohne and Phil Hands]
+Backported from dgit 11.3.
+
+ -- Ian Jackson   Sun, 03 Sep 2023 00:49:57 
+0100
+
 dgit (10.7+deb12u1) bookworm; urgency=medium
 
   * Use the old /updates security map only for buster.  Fixes fetching from
diff --git a/debian/tests/control b/debian/tests/control
index a22400b17..99ef53414 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -100,7 +100,7 @@ Tests: trustingpolicy-replay
 Tests-Directory: tests/tests
 Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot, 
build-essential, chiark-utils-bin, bc, faketime, liburi-perl, dput-ng
 
-Tests: absurd-gitapply badcommit-rewrite build-modes build-modes-long 
build-modes-source checkout clone-clogsigpipe debpolicy-dbretry 
debpolicy-newreject debpolicy-quilt-gbp debpolicy-taintrm defdistro-rpush 
defdistro-setup distropatches-reject dpkgsourceignores-correct 
drs-push-masterupdate drs-push-rejects dsd-divert fetch-localgitonly 
fetch-somegit-notlast forcesplit-linear forcesplit-overwrite gbp-orig gitconfig 
gitworktree import-dsc import-maintmangle import-native import-nonnative 
import-tarbomb inarchivecopy mismatches-contents mismatches-dscchanges 
multisuite orig-include-exclude orig-include-exclude-chkquery overwrite-chkclog 
overwrite-junk overwrite-splitbrains overwrite-version pbuilder protocol-compat 
push-buildproductsdir push-newpackage push-newrepeat push-nextdgit push-source 
push-source-with-changes quilt quilt-gbp quilt-gbp-build-modes 
quilt-include-binaries quilt-singlepatch quilt-splitbrains quilt-useremail 
rpush rpush-quilt rpush-source sourceonlypolicy tag-updates unrepresentable 
unrepresentable-single-dpkg unrepresentable-single-git version-opt
+Tests: absurd-gitapply badcommit-rewrite build-modes build-modes-long 
build-modes-source checkout clone-clogsigpipe debpolicy-dbretry 
debpolicy-newreject debpolicy-quilt-gbp debpolicy-taintrm defdistro-rpush 
defdistro-setup distropatches-reject dpkgsourceignores-correct 
drs-push-masterupdate drs-push-rejects dsd-divert fetch-localgitonly 
fetch-somegit-notlast forcesplit-linear forcesplit-overwrite gbp-orig gitconfig 
gitworktree import-dsc import-maintmangle import-native import-nonnative 
import-pushold import-tarbomb inarchivecopy mismatches-contents 
mismatches-dscchanges multisuite orig-include-exclude 
orig-include-exclude-chkquery overwrite-chkclog overwrite-junk 
overwrite-splitbrains overwrite-version pbuilder protocol-compat 
push-buildproductsdir push-newpackage push-newrepeat push-nextdgit push-source 
push-source-with-changes quilt quilt-gbp quilt-gbp-build-modes 
quilt-include-binaries quilt-singlepatch quilt-splitbrains quilt-useremail 
rpush rpush-quilt rpush-source sourceonlypolicy tag-updates unrepresentable 
unrepresentable-single-dpkg unrepresentable-single-git version-opt
 Tests-Directory: tests/tests
 Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot, 
build-essential, chiark-utils-bin, bc, faketime, liburi-perl
 
diff --git a/dgit b/dgit
index 541420921..dd2b301a6 100755
--- a/dgit
+++ b/dgit
@@ -103,7 +103,7 @@ our $chase_dsc_distro=1;
 our %forceopts = map { $_=>0 }
 qw(unrepresentable unsupported-source-format
dsc-changes-mismatch changes-origs-exactly
-   uploading-binaries uploading-source-only
+   uploading-binaries uploading-old-version uploading-source-only
reusing-version
push-tainted
import-gitapply-absurd
@@ -4680,6 +4680,7 @@ END
git_fetch_us();
 }
 my $archive_

Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory

2023-09-27 Thread Ian Jackson
Mark Hindley writes ("Bug#1052942: insserv: FTBFS: insserv: Could not read 
script nolsbheader: No such file or directory"):
> Thanks for this. However, I am currently unable to repoduce this
> failure in my customary pbuilder setup. And it doesn't appear at
> reproducible builds either[1]

I just tried this myself with my usual sbuild setup and it succeeded
there too[1].  Lucas, I think something from your rebuild environment
(a chroot of some kind I presume) must be triggering this failure.  Is
there some way we can reproduce it more precisely (eg, a buildinfo
file?)

I looked at the build log
 http://qa-logs.debian.net/2023/09/25/insserv_1.24.0-1_unstable.log
and compared it to the one from my sbuild, using diff.  There are a
lot of changes to the "furniture" but also there are noise changes to
the output of the insserv test suite, including ordring changes of
passing tests.  This seemed surprising to me.

Mark, is the insserv test suite supposed to produce deterministic
output ?

Ian.

[1] just-updated sid chroot, "dgit sbuild -wgf build -c build".



Bug#908274: debvm for autopkgtests with multiple host?

2023-09-23 Thread Ian Jackson
Hi Helmut and others.

Some time ago we had a conversation on debian-devel about how to make
autopkgtests that spawn multiple nodes and communicate between them,
eg for testing network protocols[1].

To summarise that discussion: at that time the best available solution
that worked in ci.d.n seemed to be to write an ad-hoc script to run
the tests in qemu; three packes had done that, each separately, with
complex scripts with many moving parts.

I saw debvm, and wondered if it was suitable for this purpose.
But, then I looked at its debian/test/control and I see that the tests
are marked as flaky.[2]  So maybe it isn't reliable enough :-/.
I have other questions too, particularly to do with the way I would
need autopkgtest to be able to influence package selection in the
nested testbeds.

Everyone else: has there been any other progress on the multi-node
autopkgtest problem ?

Thanks,
Ian.

[1]
  https://lists.debian.org/debian-devel/2023/01/msg00059.html
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908274

[2]
  https://salsa.debian.org/helmutg/debvm/-/blob/main/debian/tests/control

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1051137: bookworm-pu: package dgit/10.7+deb12u2

2023-09-03 Thread Ian Jackson
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dgit

[ Reason ]

Two users separately disscovered a misssing safety catch in dgit:

dgit push won't notice if the changelog for your upload states a
version which is lower or the same as exists in the archive (unless
the currently-being-pushed version wasn't itself previously uploaded
with dgit).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050711

[ Impact ]

Users using dgit from stable might make broken uploads.  Typically,
this happens when they're unintentionally uploading some modifications
which were erroneously based on an out-of-date version of the package.

Such an upload is then rejected by the ftpmaster archive.  But
misleading git tags have been made and published.  Additionally, the
broken upload remains in the dgit history, and mighht end up as noise
in maintainer git histories.

None of this is a violation of the constraints of the dgit data model,
but:

  - It can be very confusing to humans.

  - Some maintainers really hate this kind of git noise,
so this malfunction can generate social friction.

  - If the uploader doesn't notice, their intended changes will
not actually end up in the target Debian suite.

[ Tests ]

I have added a test for this situation to the test suite.  That test
fails before the fix, and passes afterwards.  The test is part of the
autopkgtests.

When backporting the relevant commits to the bookworm branch, I chose
to include the new test.  I have done a formal local run of the
autopkgtests for 10.7+deb12u2.  The test runs and passes as expected.

Additionally, I built and installed 10.7+deb12u2 locally, and ran an
ad-hoc manual test with dgit-test-dummy (which I deliberately put into
this anomalous state for testing this bug).

[ Risks ]

The logic of the check might be wrong.  There's a boolean condition,
and a version number inequality comparison.  However, I think the code
is right because of the new test case. and also because adding this
check only broke two of the existing tests, which, on inspection, did
indeed play fast and loose with versions.

Some downstreams might have workflows that trip the new check.
There is a a --force option for it, but no configuration setting.
This could affect downstreams who are running Debian stable to manage
some other set of packages; but it would only affect downstreams who
are working with source packages *and* routinely reuse (or rewind) source
package versions.  I doubt other tooling, besides dgit, would work
well if you did that; for example, apt's handling of the resulting
debs would be poor.

The new test case is brand new and might be wrong.  Also, I had to
resolve a conflict in d/tests/control (which I did by regenerating
it).  So perhaps the autopkgtests might be broken.  However, I have
run them with bookworm's autopkgtest(1), and the overall impact of any
such breakage seems like ti would be low.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

 * Add the new check to dgit's "dopush" function
 * Provide a way to override the check
 * Add the override to two test cases that play fast and loose
 * Add a new test case for this specific situation

Some more information is available in the commit messages,
which can be found here:
  https://salsa.debian.org/dgit-team/dgit/-/commits/bookworm/

[ Other info ]

Two users experienced lossage due this missing check in the same week:
See #1050711 and #1050924.  I don't know why this is, but perhaps
we are seeing more parttial adoption of dgit within some teams.

Both of these users found this dgit behaviour disturbing, and were
significantly inconvenienced; in particular, both were doing
authorised team uploads, and were concerned that the malfunction might
upset the principal maintainers of the respective packages.
diff --git a/debian/changelog b/debian/changelog
index bf03d2744..55aca1076 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+dgit (10.7+deb12u2) unstable; urgency=medium
+
+  * Prevent pushing older versions than is in the archive.
+Closes: #1050711.  [Reports from Helmut Grohne and Phil Hands]
+Backported from dgit 11.3.
+
+ -- Ian Jackson   Sun, 03 Sep 2023 00:49:57 
+0100
+
 dgit (10.7+deb12u1) bookworm; urgency=medium
 
   * Use the old /updates security map only for buster.  Fixes fetching from
diff --git a/debian/tests/control b/debian/tests/control
index a22400b17..99ef53414 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -100,7 +100,7 @@ Tests: trustingpolicy-replay
 Tests-Directory: tests/tests
 Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot, 
build-essential, chiark-utils-bin, bc, fak

Bug#1050713: --overwrite and mixed team workflows, and split brain

2023-09-02 Thread Ian Jackson
For now I'm at least adding a cross-reference from --overwrite
(in dgit(1)) to --split-view=always.

I still think we may want more guidance in this area, but it's
complicated.  A lot of it depends on individual foibles and opinions
of the co-maintainers, so an opinionated workflow guide isn't the
right answer.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050709: tar-ignore debian/source/options

2023-09-02 Thread Ian Jackson
Control: clone -1 -2
Control: reassign -2 debhelper
Control: retitle -2 Please adjust debian/source/options

Hi.

FTR, I didn't intend to draw this bug to your attention as the
debhelper maintainer.  #1050709 was addressed to dgit maintainers
about about how to deal with this situation in dgit.

I suggested in dgit that we might do one or more of the following
(numbering addded):

| 1. File a bug or MR against debhelper
| 2. Somehow ask that dpkg-source do something about this, but what ?
| 3. Have dgit detect this situation and at least explain it to the user
| 4. Have dgit generate a non-roundtrippable source package
|(probably very hard and also undesirable)

I am working on (3).  (4) seems wrong.  As for (2), that's already
#908742 and #908747.

Since you've engaged, let me do (1) now, and clone this bug
and address you as debhelper maintainer:

The fundamental principle of operation of dgit is that the git tree[1]
is *identical*[2] to result of dpkg-source -x.

Niels Thykier writes ("Bug#1050709: tar-ignore debian/source/options"):
> So this is a common pattern in my packages although it sometimes appears 
> in d/s/local-options rather than d/s/options.

dgit refuses to work with d/s/local-options, because they cannot be
included in the source package.  In debhelper it seems that someone
moved the ignores to d/s/options, probably for this reason.

> Basically, the issue is when you have something you want to have 
> locally, not in git and also not in the archive.

That's fine.  The correct approach is to make dpkg-source and git
agree with each other.  The problem with plain tar-ignore is that it
ignores .gitignore, which *is* in your git tree and is not ignored by
git.

See https://bugs.debian.org/908747

> Here the "local" directory is listed both in .gitignore and in 
> "tar-ignore", because I do not want it in git nor in the archive when I 
> do an upload.

Yes, that makes sense.

> To solve this, I add `tar-ignore=...` (for native packages) to 
> debian/source/(local-)options.  However, if you add that option, you end 
> up with the entire *.git* directory in the tarball.  To avoid that, I 
> add the `tar-ignore` on its own to get the sane defaults back.

Please change this to --tar-ignore=.git.  I.e., I think,
`tar-ignore=.git` in d/s/options.

I think that will cause dpkg-source to do the right things.  I tested
this locally and it seems to fix the problem.

Patch attached.

> PS: Not sure if this problem is specific to native packages, which I 
> happen to maintain a lot of (relative to other maintainers).

It's somewhat worse with non-native packages because things are more
complicated and there's all the different git workflows, but the basic
issue is the same.

Thanks,
Ian.

[1] The git tree uploaded to the dgit git server and seen via "dgit
clone".  There are split view modes for handling some, but not all,
deviations from this principle, notably patches-unapplied git trees.

[2] Except that there is no .pc directory in the git tree.

>From a1d7a8a5ef09938b372d3ae28b954552f6dd9e8e Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Sat, 2 Sep 2023 12:40:40 +0100
Subject: [PATCH] Update d/s/options to use less broad tarignore syntax

---
 debian/source/options | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/source/options b/debian/source/options
index edbbfb5b..2ac64523 100644
--- a/debian/source/options
+++ b/debian/source/options
@@ -1,2 +1,2 @@
-tar-ignore
+tar-ignore=.git
 tar-ignore=debhelper/.idea
-- 
2.20.1


-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.


Bug#1050711: dgit: allowed a push-source for a version that already exists in the archive

2023-09-02 Thread Ian Jackson
Control: forecemerge 1050711 1050924

#1050924 does indeed seem to be the same as #1050711.
I'm adding a version number check.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050711: dgit erroneously allowed an upload reusing a version number

2023-08-31 Thread Ian Jackson
Control: severity 1050711 important
Control: retitle 1050713 mixed team workflows incl. --overwrite, split brain

I think #1050711 and #1050924 are *probably* the same bug, but I asked
Phil to submit a new one anyway.  There are some difference between
them, notably whether the wrong-version is the same as, or older than,
the current archive version, and also maybe the state on the dgit git
server was different.

That two users experienced this in such a short space of time is an
odd coincidence.  dgit hasn't changed; maybe there's something in the
air.

An underlying cause seems to be that we now have people doing
"team uploads" with dgit when some other team members *don't* use
dgit, and maybe object to certain aspects of dgit's outputs.  Our
defaults, and documentation, don't support this use case very well.
Let's think about that as part of #1050713

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050001: Unwinding directory aliasing [and 3 more messages] [and 1 more messages]

2023-08-30 Thread Ian Jackson
On the burden of proof and the correctness of software:

I'm afraid I see a pattern, where blanket statements are made which
are only "mostly" or "roughly" or "generally" true.  But the
discrepancies and details matter.  When we make computer systems, it's
not good enough to if they're only "mostly" right.

Every program is an unproven conjecture whose truth we end up relying
on.  We need simple axioms, and rigorously correct reasoning.

Aliased usrmerge, when deployed, was a conjecture that was disputed:
"usrmerge via directory aliasing functions correctly".

In the time since the TC dismissed the objections and ruled in favour
of believing in the truth of this conjecture, has been disproven.
It is false in such important wsys that even in Debian, where we have
every possible advantage, we have been significantly inconvenienced.
Now we have a long list of counterexamples demonstrating the
invalidity of the original thesis.

Nevertheless, in mathematical terms, we are trying to patch up
the conjecture with many qualifications - the mitigations.
Also, we are apparently trying to impose on 3rd parties qualifications
about when it is OK to refer to files by the "wrong" name, which
cannot even be stated clearly, let along succinctly.

Despite all this, apparently when we argue for continued reliance on
this disproven assertion we go back to imprecise statements.

Helmut Grohne writes ("Bug#1050001: Unwinding directory aliasing [and 3 more 
messages]"):
> In order to prefer Debian over something else, we want it to be similar
> enough to make switching feasible while making it differ from others
> enough to make switching worthwhile. Not having aliasing symlinks hardly
> seems like an aspect that makes Debian more suitable to people. I guess
> that you disagree with this and that is fine.

Debian has historically been simply much more reliable.  That
reliability doesn't come from one particular decision.  It comes from
an aggregate of, on the whole, making better decisions.  That
reliability is very valuable to our users and downstreams.  It's
one of our our most compelling advantages.

>  My impression has always been that the disagreement on the end
> state was involving a minority.

Well, if you disagree with aliased usrmerge and say you don't want it,
you get abuse.  Even here, many abusive messages have been posted with
impunity by persons with considerable status.

usrmerge is a facet of Debian's culture wars.  (Debian's culture wars
are mostly orthogonal to the wider world's, but it would be foolish to
ignore the huge social factors at play.)  If one is on the
currently-losing side one is not optimistic about the value of making
one's views widely known.  Most of my friends agree with me on
substance but think it's a lost cause.

Of course, I could try to "solve" this invisibility by making a blog
post drawing attention and asking random people across the internet to
"contribute" to this discussion (or even just ask them to "me too").
That might even be effective, since currently I'm rather alone here.

I'm not doing that because Debian is quite toxic enough.  (And also
because as an apparent minority, seen as a reactionary outgroup, we
would get blamed for the behaviour of extremists.)

> > This argument is basically drawing together the common factor in the
> > DEP-17 problem list.
> 
> And that's precisely why I don't understand your argument. All of the
> DEP-17 problems are supposed to go away. So it appears as if you cite a
> list of problems that I expect to not be problems for much longer as a
> reason for changing the end goal.

DEP-17's list of *problems* forms a category: directory-aliasing-
induced malfunctions.  But the DEP-17 *solutions* are ad-hoc, and many
are only applicable to to malfunctions that occur during migration.
There is nothing inherently migration-specific about aliasing-induced
malfunction; migration is in this context mostly just a lot of Things
happening, each of which has a chance to go wrong.

The result of the current plan is that all directory-aliasing-induced
malfunctions must be averted, individually, forever.  By us, but also
by everyone who has to modify any Debian-derived system.

> > Affected tooling includes not just our .debs, but also remote
> > configuration management systems like Ansible, image construction
> > (Dockerfiles), and 3rd-party software installation progrmas (including
> > both 3rd-party .debs and 3rd-party script-based installation systems).
> 
> I don't follow the reasoning. [...]

Sam has posted a helpful set of examples of things that one might do,
whose consequences with aliased directories are unclear.

These are of course only examples.

> > I would be much more convinced that all of this isn't a problem, if
> > there existed, and had been formally adopted (eg by existing in some
> > manual somewhere) a short and clear set of rules about what is and
> > isn't allowed - not just rules for us within Debian, but rules for
> > everyone, 

Bug#1050711: Acknowledgement (dgit erroneously allowed an upload reusing a version number)

2023-08-28 Thread Ian Jackson
Control: tags -1 + confirmed

$ dgit push-source --damp-run experimental
canonical suite name for experimental is rc-buggy
dpkg-source: warning: short option not allowed in work/debian/source/options, 
line 1
dpkg-source: warning: no source format specified in debian/source/format, see 
dpkg-source(1)
dpkg-source: warning: --include-removal is not a valid option for 
Dpkg::Source::Package::V1
dpkg-source: warning: --no-preparation is not a valid option for 
Dpkg::Source::Package::V1
dpkg-source: info: using source format '1.0'
dpkg-source: warning: source directory 'work' is not 
- 'dgit-test-dummy-1.37'
dpkg-source: info: building dgit-test-dummy in dgit-test-dummy_1.37.tar.gz
dpkg-source: info: building dgit-test-dummy in dgit-test-dummy_1.37.dsc
changelog will contain changes since 1.37
dpkg-genchanges: warning: 'since' option specifies most recent version '1.37', 
ignoring
dpkg-genchanges: info: including full source code in upload
Not updating refs/tags/archive/debian/1.21 from 
a030b5fc0980550014ea0b70c9b89f5892a145f9 to 
29e6a48f4a4cb9bd150c7992746ee22291ab340d.
Not updating refs/tags/debian/1.21 from 
f4849a972e08dd21d585ba643f407f01fa792529 to 
767c2780988df452820b47d52237f7d2d9176f00.
Not updating refs/tags/debian/1.23 from 
1d0ca2f8bccf54c5a4e7e86e3597d4b793524cf1 to 
35ec850491e5f892bbced8d230b664cae514ddd5.
Not updating refs/tags/debian/1.24 from 
4ad4a4cfe21da30ac6ecd6ea5ddbc5a3c7b990ea to 
ea2c675fe61a6739de8ddfdff02bf102f41f664a.
Not updating refs/tags/debian/1.25 from 
bec2b929d3f07a212412e57493fb73a3100a57bd to 
fc1e169c33fcac379317abd39b3d8ba4be9e361b.
last upload to archive: NO git hash
using existing dgit-test-dummy_1.37.tar.gz
dpkg-source: info: extracting dgit-test-dummy in dgit-test-dummy-1.37
dpkg-source: info: unpacking dgit-test-dummy_1.37.tar.gz
synthesised git commit from .dsc 1.37
checking that dgit-test-dummy_1.37.dsc corresponds to HEAD
dpkg-source: warning: extracting unsigned source package 
(/home/ian/things/Dgit/dgit-test-dummy/../bpd/dgit-test-dummy_1.37.dsc)
dpkg-source: info: extracting dgit-test-dummy in dgit-test-dummy-1.37
dpkg-source: info: unpacking dgit-test-dummy_1.37.tar.gz
../bpd/dgit-test-dummy_1.37_source.changes already has appropriate .orig(s) (if 
any)
# gpg --detach-sign --armor -u 559AE46C2D6B6D3265E7CBA1E3E3392348B50D39 
/home/ian/things/Dgit/dgit-test-dummy/.git/dgit/tag.tmp
# gpg --detach-sign --armor -u 559AE46C2D6B6D3265E7CBA1E3E3392348B50D39 
/home/ian/things/Dgit/dgit-test-dummy/.git/dgit/tag-dgit.tmp
# git verify-tag cbf7afc338be0a0b0b58618492ff09749ddf9b86
# git verify-tag 05f1ef19beb590150ee0f7d87f4c67f70f4f0ab0
# git -c push.followTags=false push 
'git+ssh://d...@push.dgit.debian.org/dgit/debian/repos/dgit-test-dummy.git' 
de18c7def52e4a0fc67c0714b7385291a5728838:refs/dgit/rc-buggy 
refs/tags/archive/debian/1.37 refs/tags/debian/1.37
# git update-ref -m 'dgit push' refs/remotes/dgit/dgit/rc-buggy 
de18c7def52e4a0fc67c0714b7385291a5728838
# debsign -k559AE46C2D6B6D3265E7CBA1E3E3392348B50D39 
../bpd/dgit-test-dummy_1.37_source.changes
# dput ftp-master ../bpd/dgit-test-dummy_1.37_source.changes
would be ok: pushed and uploaded 1.37 (but dry run only)
$

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050713: --overwrite and mixed team workflows, and split brain

2023-08-28 Thread Ian Jackson
Package: dgit
Version: 11.3

The troubles with --overwrite's name and docs are raising their head
again.  This time, we had a user who really wanted, probably,
  --overwrite --split-view=always

The context was the debhelper package, which is team maintained.  Not
all the team members use dgit and there was a desire to avoid
merging the dgit history (again) into the salsa branch.

The user had a mental model that included dgit always separating the
dgit git history from the maintainer git history.  This is probably a
not uncommon mental model.  It will be consistent with the experience
of doing an NMU, and the experiences of uploading from quilt unapplied
histories.

It is wrong only when the package is native (or dgitishly applied) *and*
the developer is not making a NMU.  But that situation can arise
easily in teams where only some team members use dgit.

We should do something better about this situation.  I'm not sure
precisely what.  Maybe make the docs for --overwrite even longer by
adding a cross reference to --split-view ?

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050711: dgit erroneously allowed an upload reusing a version number

2023-08-28 Thread Ian Jackson
Package: dgit
Version: 11.2
Sevrity: important

Helmut reports that dgit made an upload of debhelper 13.11.5 even
though that version was already in the archive (and had been for some
time).  This does seem to be the case, since on the dgit git server we
see:
  archive/debian/13.11.5 debian/13.11.5
pointing to
  f957e45d9f76317bb58b6163ddb27bd874baa916
which is a manual merge of the salsa branch with a dgit history
  259ab8a0d17d9846ae80a157b6636e9d22be131a
which is a dgit-generated psuedomerge of its dsc import of 13.11.5.

We don't have a transcript of this, nor do we know for sure which
options were supplied, but I think the before-trouble situation looked
like this:

 * The previous upload, 13.11.5, was not done with dgit
 * We're on a commit which is ff from the dgit git server branch
 * The debian/changelog says 13.11.5

In this situation, dgit ought to have prevented the upload.

I am trying to reproduce the problem with dgit-test-dummy.  I have
done a non-dgit upload of 1.37.  I am waiting for this to be available
on mirrors, and when it is I will see what happens when I try to do a
re-upload of a different-history version of 1.37.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050709: tar-ignore debian/source/options

2023-08-28 Thread Ian Jackson
Package: dgit
Version: 11.3

debhelper (at least in sid) has a debian/source/options with;

  tar-ignore
  tar-ignore=debhelper/.idea

And it has a .gitignore.  This has the following effects:

 1. It defeats dgit's passing of a -I and -i options to dpkg-source,
so the dgit-generated source package does not contain .gitignore

 2. If one were to somehow manage to make a proper source package
that corresponds to the git tree, it wouldn't round trip
through dpkg-source.

So IMO there is no way to make a DFSG-compliant source package of
Debian's current debhelper package.

I was just assisting another DD contributor with this and other
problems; I was going to try to help sort out a mess by doing what
amounted to a sponsored upload.  However, this turned out to be
impossible.

I have done a non-dgit-based non-DFSG-compliant upload instead.

What should we do about this ?  Options (not mutually exclusive) could
include:

 * File a bug or MR against debhelper
 * Somehow ask that dpkg-source do something about this, but what ?
 * Have dgit detect this situation and at least explain it to the user
 * Have dgit generate a non-roundtrippable source package
   (probably very hard and also undesirable)

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050001: Unwinding directory aliasing [and 3 more messages]

2023-08-26 Thread Ian Jackson
Helmut Grohne writes ("Bug#1050001: Unwinding directory aliasing"):
> On Wed, Aug 23, 2023 at 05:04:36PM +0100, Ian Jackson wrote:
> > And, the approach being taken very seriously privileges Debian itself,
> > and those well-staffed derivatives able to do the necessary transition
> > auditing (albeit, indeed, with tooling from Debian).  I am
> > firmly ideologically opposed to such a tradeoff.
> 
> I have difficulties disagreeing with that. Getting this done is more
> important to me though.

I have hoisted this to the start of the mail.  I think it is a hugely
important point.

Debian is not simply a technical project trying to thread its way in a
complicated world.  Debian is an ideological project.  At its best,
Debian is the infrastructrure that enables vast swathes of people to
massively enhance their own technological autonomy.  Many of our most
controversial decisions served this goal, and stood the test of time.

That's why *I'm* involved in Debian.  Our technical choices should
serve those goals, always.

(To an extent, this divergence in goals may explain why at times our
comments have been talking slightly past each other.)

If you want to think about it on more practical (or even, selfish)
level, we want Debian to continue to be the preferred choice, when
someone is choosing an upstream.  We didn't get where we are today by
following bad technical decisions made by others.

>  * Basically every other distro uses aliasing now. I expect that
>a few upstreams have stopped paying attention to systems in your end
>state. Therefore, they may not only hard code paths in /usr/bin, but
>also the other way round assume that everything is to be found in /.

This is indeed a plausible practical reason to do it the aliased way.
>From my point of view, it amounts to saying "everyone else has made
this mistake, so to be compatible, we must too".

But I think that seriously underestimates our influence.  Debian
derivatives make up well over half of all Linux installations.
They're the default basis for most CI images.  If we decide this was a
failed experiment, then indeed there will be some pain for a while,
but fairly soon people will stop making this assumption.

>  * A key motivation cited for doing the merged-/usr work is called
>"hermetic /usr". [...] Setting up the aliasing symlinks is easier and
>less prone to change over time than setting up the symlink farm that
>you are proposing.

I don't like the phrase "symlink farm" because it suggests that all,
most, or even a substantial minority, of files have these symlinks.
True, at the start, there will be at least a symlink allotment
but I'm hoping that in the end it'll be a symlink flowerbed.

>  And then we have a large body of people who simply
> want this to be over and not having to thing about /usr-merge
> consequences anymore.

Well, of course it is very tempting to declare the matter as settled
and hope that it will go away.  I too want an end state where we will
eventually be able to forget about all of this.

But pushing ahead won't lead to such a state.  As I say, I think
people will keep introducing new references to files by their
non-physical names, and we'll keep getting lossage, essentially
forever.  (Adopting Simon's terminology.)

Or to put it another way, the delays to completion of this project
have not been due to the political opposition,.  They have been
because the project encountered technical problems.  Problems whose
existence was predicted by subject matter experts but dismissed at the
time as FUD.  Problems which were apparently not regarded as real by the
non-expert decisionmakers on the TC.  Problems which still remain in
large part unresolved, albeit in some caes "mitigated".

> > Aliasing is EBW, and "Only use canonical names" is not good enough
> > ==
> > 
> > There is basically one underlying technical reason for preferring the
> > un-aliased usrmerge approach: aliasing directories in this way leads
> > to great complication in file management, especially in package
> > management software and in individual packages.
> 
> I'm not sure I follow this argument precisely.

This argument is basically drawing together the common factor in the
DEP-17 problem list.

>   these complications mostly affect ourselves and
> our package management while end users are mostly unaffected.

I think "package management" is the wrong term here.  It's not just
our tools and packages that are affected.  All forms of operating
system management are affected: anything that changes the software,
and not just its configuration.

Affected tooling includes not just our .debs, but also remote
configuration management systems like Ansible, image construction
(Dockerfile

Bug#1050001: Unwinding directory aliasing

2023-08-23 Thread Ian Jackson
Also, one other thing I noticed:

tl;dr: *no* version of usrmerge relieves us of the obligation of
naming files correctly, via the proper name in /usr rather than /.

Ian Jackson writes ("Bug#1050001: Unwinding directory aliasing"):
> The current plan, as I understand it, is that we will fix these
> problems by arranging to *always* name files by their canonical paths,
> ie the ones in /usr.
> 
> Naming files by their canonical names will have to be done everywhere.
> This is because any time a file is named by a non-canonical path, a
> program that tries to manipulate that file might malfunction.
> (Whether it malfunctions in practice depends on the precise details
> and gets very complicated.)
...

But Simon writes:
> > This does some but not all of what merged-/usr does: calling /usr/bin/sh
> > would become a non-bug, but calling /bin/env would still be an error,
> > /bin would still represent non-trivial on-disk and/or in-dpkg-database
> > state,

This suggests that a goal of the project is to "make it not be a bug
to refer to a file in /usr/bin by its name in /bin".

However, in the aliased-usrmerge such an incorrect reference *remains*
a bug (unless it can be demonstrated that the reference is only
read-only and no-one will take that path and use it in a non-read-only
context).

It's just that the consequences of the bug are different.


Without usrmerge, or with un-aliased-usrmerge for a file where there
is no compat symlink, the reseult is a "file not found" error.  No
references via that path can work.  (Except maybe transitionally,
while the file is moving.)  Such a bug is not likely to survive long.

With un-aliased usrmerge for files which still have compat symlinks
(eventually, a handful of files considered quite special), using the
reference for mutation might result in breaking the symbolic link; or
it might result in errors from filename lookups in package management
databasesa, where the filename would be not recorded in / or not
recorded as a file.  Broken symlinks could be detected post-hoc on the
affected system, and it could be detected simply and automatically by
QA tooling.  But, this is a good reason to try to reduce the number of
compat symlinks to a very small number.

With aliased usrmerge, for all files forever, using the path in /
might result in confusing behaviour by package management and system
administration tooling.  Reasoning about the consequences is
difficult, but in the worst case it might render the affected
subsystem totally broken.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050001: Unwinding directory aliasing

2023-08-23 Thread Ian Jackson
ks
like - systems that are in practice just not quite unreliable enough
to be worth fixing.  And we have much better things to spend our time
and effort (and tolerance for bugs) on.

As I understand it the focus of the current technical work is to try
to figure out how we can get to only-canonical-paths from here, while
working aorund all of the (potential) bugs which arise during the
transition period, when necessarily we will be naming files sometimes
by their names in / and sometimes by their names in /usr.

This technical work seems really quite difficult.  It's certainly
clear that without funding from Freexian we wouldn't be in a position
to undertake it.  Nevertheless I think it is entirely possible that
this technical work will succeed on its own tersm, in the sense that
the upgrades for systems running Debian itself will go reasonably
smoothly with only a tolerable failure rate.

But as I say I don't think the end state being worked towards here, is
far from the best end state.

If I'm ever entitled to play the "I wrote dpkg" card, I think it's
now.  As the author of dpkg, which I intended to be highly reliable
software (and, I like to think, I succeeded), I think this ia very
poor system design.

And, the approach being taken very seriously privileges Debian itself,
and those well-staffed derivatives able to do the necessary transition
auditing (albeit, indeed, with tooling from Debian).  I am
firmly ideologically opposed to such a tradeoff.

The non-aliased approach


Simon comments, on the non-aliases approach.

> This does some but not all of what merged-/usr does: calling /usr/bin/sh
> would become a non-bug, but calling /bin/env would still be an error,
> /bin would still represent non-trivial on-disk and/or in-dpkg-database
> state,

I think that in the long term, /bin *will* become trivial enough.

One of the advantages of the non-aliases approach is that we can
continually improve it to get closer to the desired ideal.

> and we would still potentially have other issues triggered by
> the directories being distinct from one another (like the one discussed
> by the tech committee in #911225, which was exactly a regression caused
> by having moved a library in the traditional Debian way).

>From my conversation with Helmut, it seems that we are envisaging, as
part of the aliased-usrmerge approach, that there will be tools to
detect violations of the "refer only by canonical path" rule.

But detecting violations of "these directories only ought to contain
compat symlinks into /usr" rule is a *lot* simpler.  It can be done,
quite reliably, on end-user systems.

If we had done usrmerge the non-aliased way, then such a checking
program would be able to detect a /-vs-/usr bug analogous to #911225.
So I think a non-directory-aliases variant of this bug is more
tractable than a directory-aliases variant.

> If I remember correctly, openSUSE tried to get from unmerged /usr to
> merged /usr by essentially the route you propose, successfully reached
> the symlink-farm state, but then got stuck without a way to get from the
> symlink farm to the single symbolic link. Do you have a plan for how that
> would be achieved without breaking upgrades or going behind dpkg's back?

As I say above, I don't think we should ever go to the state with a
single symbolic link.  The end state ought to be /lib and /bin with
about six symlinks in.

I hope this helps clarify my thinking.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050179: dgit: unable to clone -security suites (?since bullseye)

2023-08-21 Thread Ian Jackson
Thanks for the report and the investigation!

Matthew Vernon writes ("Bug#1050179: dgit: unable to clone -security suites 
(?since bullseye)"):
> The difficulty is that there is AFAICT no version-knowledge in these
> map/rmap entries - one would prefer to apply the map for suites <
> bullseye and not for >=bullseye

The usual approach is to list *all* old codenames (at least, any that
still have any existence anywhere) and assume that unknown codenames
are newer.

> IMO, this would be worth a backport to at least stable when fixed -
> it's a bit sad that this functionality is broken since it's quite
> useful for end-users of dgit and helps make sure they get security
> updates.

I agree.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050143: dgit: support uploading to security-master

2023-08-20 Thread Ian Jackson
Control: block -1 by 862105

Sean Whitton writes ("Bug#1050143: dgit: support uploading to security-master"):
> I recently joined the LTS Security Team and found that I had to relearn
> how to build source packages with dpkg-buildpackage in order to upload.

Isn't it annoying ?  Unfortunately because security uploads can be
embargoed, this isn't something we can just do here.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050001: Unwinding the directory aliasing mistake

2023-08-18 Thread Ian Jackson
Thanks for your considered reply.

Helmut Grohne writes ("Bug#1050001: Unwinding the directory aliasing mistake"):
> It feels rather strange to submit this as a bug report when you do not
> want feedback. A mail to the list is easier to not respond to, but a bug
> needs a closure one way or another eventually.

I need to clarify this, evidently.  I didn't mean I'm not going to be
reading replies, and I didn't mean I don't want feedback here.  I will
participate here.

It's just that I will deal with it in batches, with a significant lag,
and given the way these discussions tend to go that means that others
will have to carry much of the more interactive load.

I'll write more about the more technical / practical aspects of your
mail at a later point.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1050001: Unwinding the directory aliasing mistake

2023-08-18 Thread Ian Jackson
Package: tech-ctte


Background and current status

In 2019 the TC decided[1] that Debian would achieve the largely-agreed
goal of having only one place to put most files, /usr, by using
symlinks to alias from /bin etc. to e.g. /usr/bin.

At the time, concerns were raised that package management systems and
other software would malfunction but the set of malfunctions was not
enumerated; proponents of the aliasing approach characterised them as
FUD.  In the absence of the results of the research work which has now
been done, that characterisation seems to have been implicitly
accepted as true by the then TC.

Thanks to work funded by Freexian we now have a list of many of these
malfunctions[2] (although new ones keep popping up (eg [3]).

The most serious malfunction is the disappearing files bug, which has
prompted a seriously inconvenient file move moratoriam which has now
been in place for many years.  After 4 years, we still don't have a
clear path forward to resolving that and other problems [4].

It should now be clear to most observers that the decision to go down
this path was a mistake.[5]


Fixing the mistake

I think we can probably fix it by backing out this change, and then
doing usrmerge the traditional Debian way by making changes to
debhelper, so that we move the files package by package, in the .debs.

But given the atmosphere, such a proposal would need clear political
backing from the TC.  It wouldn't be worth anyone's time or emotional
energy to attempt to make a concrete and detailed plan if the TC is
not minded to consider it.

So I would like to pose the following questions for the TC:

 * Given the information that the Committee has now, that it didn't
   have in 2019, does the Commitee agree that the decision in 2019
   was questionable ?

 * Is the Committee open to the idea of a plan being developed which
   reverses the mistake, rather than merely "mitigating" the problems ?
   Would such a plan be considered on its merits ?

I appreciate that I'm asking the TC to revisit a previous and
controversial decision.  That this isn't a step we should take
lightly, but I think in this case it's clearly warranted.


Timeline for a fix

Any plan to solve this would probably take a few releases (ie, many
more years) to sort out, sadly.  We would probably need to wait with
shipping packages that move files in a conventional-for-Debian way,
until we have our userbase's systems restored to a non-aliased state.
So I think we would need trixie to undo the aliasing, and in trixie+1
we could move the files.

This delay is unfortunate, but - unlike pressing forward - it has
relatively low levels of risk, most of which is front-loaded.  I think
we can develop tools which will reliably de-alias a system; and, once
users' systems have been de-aliased, the actual file movement is
routine work that Debian knows how to do.

I can see that there could possibly be ways of going straight to the
desired state (un-aliased systems but with nothing much in /), but I
haven't given them much thought them through because they seem risky
to me and involve some grievous hacks.


Protecting my mental health

I will try to avoid regularly reading this thread.  I hope that now
that I have made the suggestion, others will be able to carry the
conversation.  I will be configuring my mail client to disregard my
personal copies of messages sent to this bug; when I want to read
the thread I will look at the mailing list.

Also, if you disagree with my decision to raise this now, please don't
email me.  If you feel I have overstepped a boundary, please contact
the Community Team or DAM.

If the Comittee gives a positive indication, I will be happy to
re-engage at the level of technical work to try to make it happen.


Thanks,
Ian.

[1] https://lists.debian.org/debian-devel-announce/2019/03/msg1.html
[2] https://subdivi.de/~helmut/dep17.html
[3] https://lists.debian.org/debian-devel/2023/05/msg00311.html
[4] https://lists.debian.org/debian-devel/2023/06/msg00353.html

[5]
  Perhaps merged-usr via directory aliasing worked well in some other
  distros with less sophisticated package management systems.

  But we obtained almost all the practical benefits of abolishing the
  distinction between / and /usr very early, by deciding that the
  initramfs would mount /usr too.  We have inflicted all this pain and
  confusion on ourselves simply to do some tidying up.  The result has
  been the opposite.

  If we had just moved the files rather than trying to rush things
  with the directory alias symlinks, we would have been finished by
  now.



Bug#1042889: vm: autopkgtest fails against Emacs 29.1

2023-08-14 Thread Ian Jackson
Sean Whitton writes ("Bug#1042889: vm: autopkgtest fails against Emacs 29.1"):
> vm's autopkgtest fails with Emacs 29.1, which latter is now in sid.
> 
> https://ci.debian.net/packages/v/vm/testing/amd64/

The regression was indeed caused solely by upstream renaming the
variable that disables byte compilation, from
native-comp-deferred-compilation-deny-list
to
native-comp-jit-compilation-deny-list

ISTM that making that change without also honouring the old setting
was an obviously bad idea.  Upstream set us up for this failure.
Anyway, I have fixed this issue in vm, by handling both variables.
I expect the new vm package to migrate quickly.

I see that there are other packages with failing tests, preventing
emacs from migrating.  I haven't looked at them, but some of them may
be similarly afflicted.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1042889: vm breakage with Emacs 29

2023-08-13 Thread Ian Jackson
Dirk Eddelbuettel writes ("Bug#1042889: vm breakage with Emacs 29"):
> Yes given the previous bug report and fix ensuring no byte-compilation takes
> place for vm may be best. At least until someone (upstream? another dev?)
> understand why it breaks vm.

FTR, I investigated this a bit and I discovered that the regression is
probably because
  native-comp-deferred-compilation-deny-list
has been renamed to
  native-comp-jit-compilation-deny-list

I think we should ahve a patch that works with both Emacs versions
(since I don't want to complicate backports etc.); currently I have
this:

(eval-after-load "comp"
  '(dolist
 deny-list '('native-comp-deferred-compilation-deny-list
 'native-comp-jit-compilation-deny-list)
 (if (boundp deny-list)
   (add-to-list deny-list "/vm.*\.el"

but it is wrong in some way that my limited lisp-fu wasn't able to
diagnose in the limited time I have right now.

I will look at this again RSN.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1042889: Debian PR #1042889

2023-08-10 Thread Ian Jackson
Hi.

Kurt Hornik writes ("Debian PR #1042889"):
> Have you seen
>   <https://bugs.launchpad.net/vm/+bug/1979048>
> ?

No.

> This points to a branch of VM at
>   <https://code.launchpad.net/~markd-kermodei/vm/vm-emacs-28>
> which apparently at some point in time passed native compilation (I
> never got a chance to try to far).

Interesting!

> I can try to follow up with Uday Reddy and Mark Diekhans to try merging
> the native compilation fixes into the main branch (at least).

That would be great.

> Afaict, part of the problem was Emacs 29 not being out when this was
> reported, and Emacs 28 having native compilation off by default but on
> for the Debian packages.  In any case, Emacs 29 is out now, so I guess
> time to ask again.

Thanks for the info.

With my Debian maintainer hat on, I don't think I ought to be fishing
some random branch out of launchpad and shipping it to Debian's users,
without a fairly thorough review.  (Also, it's in bzr!)

So I think I need to fix #1042889 by disabling byte-compilation,
pending a better resolution (ideally, upstream).

PS: Was there a reason you didn't send your message to the Debian
ticket #1042889 ?  I think it's generally a good idea to do these
things in public.  Unless you tell me not to, I will forward your
message (and this one) to the bug - so please let me know if you
object for any reason.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1043335: dgit-user(7) should note where dgit build is inappropriate (e.g. CI)

2023-08-09 Thread Ian Jackson
Matthew Vernon writes ("Bug#1043335: dgit-user(7) should note where dgit build 
is inappropriate (e.g. CI)"):
> dgit-user(7) should note this prominently.

Also this should probably be mentioned somehow in the `dgit build`
options in dgit(1).

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1042889: vm: autopkgtest fails against Emacs 29.1

2023-08-02 Thread Ian Jackson
Sean Whitton writes ("Bug#1042889: vm: autopkgtest fails against Emacs 29.1"):
> vm's autopkgtest fails with Emacs 29.1, which latter is now in sid.

Hi, Sean, as you see we're looking into this.
I have some questions for you as an Emacs expert:

Is byte-compilation known to be sometimes broken?  Is there a
recommended approach to problems caused by byte-compilation ?

We recently did an update to vm in Debian stable, to work around a
critical problem with Emacs 28 (#1039105).  The autopkgtest which is
now failing is new - I introduced it to detect future bugs, which it
seems to have done.

The previous bug was related to byte-compilation and we "fixed" it by
turning off byte-compilation for at least some of vm's files (in what
I feel was rather an ad-hoc way, albeit an effective one).

Or to put it another way, is it possible that this is a bug in emacs
29.1 and if so what is the best workaround ?

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1042889: vm breakage with Emacs 29

2023-08-02 Thread Ian Jackson
Dirk Eddelbuettel writes ("Re: vm breakage with Emacs 29"):
> On 2 August 2023 at 13:17, Ian Jackson wrote:
> | Hi.  Since you were helpful with #1039105 "Fails to start with Emacs
> | 28" I thought I would draw your attention to #1042889
> | "vm: autopkgtest fails against Emacs 29.1" [0]
> | 
> | I won't have time to look at this until next week, probably.  Any help
> | or background research would be greatly appreciated.  We need to fix
> | this to avoid vm getting autoremoved.
> | 
> | I did have a quick look at the test log [1] and the failure looks
> | genuine.  I suggest we do any further diagnosis in the bug.
> 
> The band-aid I found and submitted for #1039105 (ie per Fedora's tracker,
> "just do not byte compile") seems apt here, no?  I still do not really read
> (or, for that matter, write) elisp but it seems to complain about byte code.
> 
> So I would try two things:
>  - turn off elisp byte compilation as in #1039105

The patch from #1039105 is still in the package.

Do we need to add to a list of files in it, or something, do you
think ?  Maybe it would be best to disable byte compilation
completely.

One thing that would be useful would be for someone to try out emacs
and vm in a sid chroot; that would confirm that this isn't a spurious
test failure (or confirm that it is).

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1040947: perl: readline fails to detect updated file

2023-07-17 Thread Ian Jackson
Hi.  I'm sorry that something I had a hand in is causing you an
inconvenience.

I'm afraid it's not clear to me what "working" and "non-working"
behaviour from your example program is.  I don't feel I can reply
comprehensively, so I will comment on some of the details in your
message.

Eric Wong writes ("Re: Bug#1040947: perl: readline fails to detect updated 
file"):
> Both can be data loss bugs, but checking a log file which is
> being written to by another process is a much more common
> occurence than FS failures[1] (or attempting readline on a
> directory (as given in the #1016369 example))

AFAICT you are saying that the fix to #1016369 broke a program which
was tailing a logfile.  I agree that one should be able to tail a
logfile in perl.  I don't think I have a complete opinion about
precisely what set of calls ought to be used to do that, but I would
expect them to mirror the calls needed in C with stdio.

> Since this is Perl and TIMTOWTDI, I've never used IO::Handle->error;
> instead I always check defined-ness on each critical return value and
> also enable Perl warnings to catch undefined return values.
> I've never used `eof' checks, either; checking `chomp' result
> can ensure proper termination of lines to detect truncated reads.

AFIACT you are saying that you have always treated an undef value
from line-reading operations as EOF, and never checked for error.
I think that is erroneous.

That IO errors are rare doesn't mean they oughtn't to be checked for.
Reliable software must check for IO errors and not assume that undef
means EOF.

I believe perl's autodie gets this wrong, which is very unfortunate.

> [1] yes, my early (by my standards) upgrade to bookworm was triggered
> by an SSD failure, but SSD failures aren't a common occurence
> compared to tailing a log file.

I don't think this is the right tradeoff calculus.

*With* the fix to #1016369 it is *possible* to write a reliable
program, but soee buggy programs lose data more often.

*Without* the fix to #1016369 it is completely impossible to write a
reliable program.

Having said all that, I don't see why the *eof* indicator ought to
have to persist.  It is only the *errors* that mustn't get lost.  So I
think it might be possible for perl to have behaviour that would
make it possible to write reliable programs, which still helping buggy
programs fail less often.

But, even if that's possible, I'm not sure that it's a good idea.
Buggy programs that lose data only in exceptional error conditions are
a menace.  Much better to make such buggy programs malfunction all the
time - then they will be found and fixed.

Thanks for your attention.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1041317: dgit: table too wide in man page, trashes autopkgtests

2023-07-17 Thread Ian Jackson
> of column separation to make the table fit.

This sounds like a very reasonable workaround to me.  I'll take a look
at the generated output and (assuming I'm happy with it) I'll adopt
your suggestion.

> $ diff -u ./dgit.1.orig ./dgit.1
...
> -lb l.
> +lb2 l.

I expect to make an upload within a few days, maybe a week.  I hope
that's satisfactory.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1040816: dgit: gpg signing fail when comment section exist in gpg key

2023-07-11 Thread Ian Jackson
Boyuan Yang writes ("Re: Bug#1040816: dgit: gpg signing fail when comment 
section exist in gpg key"):
> Please check the "DEBSIGN_KEYID" environment variable as described in 
> debsign(1).
> Currently I have it set up in my bashrc. When I was using the plain 
> gbp-buildpackage
> workflow, I also used the -k option whenever possible.

Thanks.

I looked at the code, and I'm not DEBSIGN_KEYID is quite right because
it would override the whole keyid.  dgit tries to find the using the
changelog maintainer.  Sean, what do you think?  (It would be a change
to behaviour for existing users who have set DEBSIGN_KEYID.)

There is an alternative approach: dgit honours various command line
and config settings for this.  There's a `-k` option, but I guess
that's not convenient for routine use.

But there's also the git config options

  dgit.default.keyid
  dgit-distro.DISTRO.keyid

So I think you could say

  git config --global dgit-distro.debian.keyid 

Did you see those in the manual ?

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1040816: dgit: gpg signing fail when comment section exist in gpg key

2023-07-11 Thread Ian Jackson
Boyuan Yang writes ("Bug#1040816: dgit: gpg signing fail when comment section 
exist in gpg key"):
> This looks like a rare corner case, but currently when executing
> "dgit push-source --overwrite" in my dgit-enabled repo, the gpg
> signing will fail. Example:

Oh dear.

> Can we make the invocation to gpg more robust? Or, can we allow using
> some environment variable to provide the gpg key fingerprint used for
> signature? If there is indeed such config option somewhere, please let me
> know. Thanks!

I think we should do something about this, yes.

Do you know if your situation works with debsign ?  What configuration
does debsign accept ?  I think dgit probably ought to honour the same
configuration tfor the same thing.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1038616: bookworm-pu: package network-manager-strongswan/1.6.0-1+deb12u1

2023-06-29 Thread Ian Jackson
Harald Dunkel writes ("Bug#1038616: bookworm-pu: package 
network-manager-strongswan/1.6.0-1+deb12u1"):
> I made a mistake on the pu for network-manager-strongswan: I missed to
> set you on CC. I am very sorry.

No problem, it just meant you had to ping me ...

> AFAICT the upload to Bookworm has been approved. Would you mind to check?

Indeed so.  Now done.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1039105: Fails to start with Emacs 28

2023-06-29 Thread Ian Jackson
Control: severity -1 serious

This bug makes the package very hard to use.  It fails to work, by
default.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1039105: Fails to start with Emacs 28

2023-06-29 Thread Ian Jackson
Dirk Eddelbuettel writes ("Bug#1039105: Fails to start with Emacs 28"):
>   After updating my main machine (and the only one running vm along and
> exim4, dovecot, spamassassin and whatnot) to Ubuntu 23.04 with its Emacs 28.2
> (in an upgrade from 22.10 with Emacs 27.*), I found that vm (which I have
> been using all those years, still with some hooks and key-binding you emailed
> to in the mid-1990s (!!)) would no longer start.

Thanks for the report.  And thanks to the others for the further
information.

I can reproduce the problem and the suppression of byte compilation
does indeed fix it.

It's a bit funky to reproduce, because emacs likes to byte-compile
things when it's idle with the effect that naive "emacs --batch" runes
don't show the problem.

I'll do a stable update.  But first I am going to upload to sid,
as per the stable release policy.  And I'm adding a test, since I did
manage to get a reliable repro.

I confess I don't understand the upstream package very well.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1039407: userv: ships sysv-init script without systemd unit

2023-06-26 Thread Ian Jackson
Control: severity -1 normal

Contribution of a systemd unit and corresponding autopkgtest would be
welcome.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1037351: rust-base64 migration dependency adjustment

2023-06-20 Thread Ian Jackson
Control: tags -1 + trixie-ignore

hippotat 1.1.7 FTBFS with rust-base64 0.21.
hippotat 1.1.9 build-depends on rust-base64 0.21.

So the plan is for these to migrate together, and ISTM from reading
tracker that that is what will happen as soon as the remaining
blockers for rust-bsee64 migration are disposed of.

In principle hippotat's build-dependencies could have been adjusted to
depend on rust-base64 0.13, and then we could have waited for that to
enter testing, and then done the update.  But thst seems otiose, given
that the plan is that trixie should have base64 0.21.

Therefore I am tagging this bug trixie-ignore to avoid getting
autoremoval warnings etc.  I hope I'm not overstepping the mark.

PS, with my upstream hat on: It is a shame that the Rust base64 crate
has such a cavalier approach to API stability.  I am considering my
options in this area for hippotat (eg data-encoding or base64ct), but
without better tests and test vectors I am reluctant to switch right
now.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1020495: Duplicate of #1036607, of closing via forcemerge

2023-06-18 Thread Ian Jackson
Control: reassign -1 network-manager-strongswan
Control: forcemerge 1036607 -1

This bug is a duplicate of #1036607, which has been fixed in
unstable.  We're also preparing an update to stable.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#914260: dgit clone fails with "Out of memory, malloc failed"

2023-06-14 Thread Ian Jackson
Control: tags -1 + moreinfo
Control: retitle -1 "botch" package, server out of memory

I think this should be working now ?  I just tested it.  Sorry for
letting this bug languish.  I do recall at some times asking DSA to
increase the VM's RAM.

Please let me know if it's still broken now.  Otherwise I think we
should close this bug.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1037351: hippotat: ftbfs with rust-base64 0.21

2023-06-12 Thread Ian Jackson
Peter Green writes ("Bug#1037351: hippotat: ftbfs with rust-base64 0.21"):
> hippotat FTBFS with the new version of rust-base64.

Thanks for the report.

> I attach a patch which makes the package build.
> I have not tested it beyond that (and the build said it was
> skipping tests due to lack of unshare).

Unfortunately the automatic tests are not suitable for running in
Debian CI.  Running them via autopkgtest is nontrivial and probably
not possible for people other than me :-/.

I'm hoping trixie will bring some new tooling that will help with
that.

> Also your clean target is horriblly broken, I filtered the
> debdiff to get rid of a huge volume of junk.

I confess I don't often use `make clean`.  I normally use `git clean`.

> I may or may not NMU this later.

I will probably fix this myself fairly soon.

Since AFAICT you haven't written a formal Signed-off-by, would you
mind confirming the statements in DEVELOPER-CERTIFICATE (copy
below) ?  (If you don't want to make that confirmation I will rewrite
the patch myself.)

Thanks,
Ian.

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.



-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1020495: Patch to build network-manager-strongswan against GTK 4, too

2023-06-11 Thread Ian Jackson
Harald Dunkel writes ("Re: Patch to build network-manager-strongswan against 
GTK 4, too"):
> this is intended as a bug fix for both Bookworm and Trixie. N-m-s is
> severely restricted for Gnome desktop without this fix. There is no
> newer upstream version yet.

OK, I will review it for trixie.

Would you check the stable release policy for the update to bookworm ?

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1020495: Patch to build network-manager-strongswan against GTK 4, too

2023-06-11 Thread Ian Jackson
Harald Dunkel writes ("Re: Patch to build network-manager-strongswan against 
GTK 4, too"):
> I have to appologize for not checking my bug reports. There is no
> excuse for that. I am very sorry.
> 
> I have applied Moritz' patch to the source repository on Salsa and
> verified the GUI using Gnome on Bookworm. The error message is
> gone now.
> 
> @Ian, if you have some spare minutes, would you mind to upload the
> fixed version 1.6.0-2, if it looks OK to you? There are no source
> code changes, just a modified configure command line and some
> additional dependencies. Janitor made changes to the debian directory
> on Salsa as well. Included.

FTAOD you intend this for trixie ?

AFAICT from the mails on d-d-a I could upload now and it will be
processed "in due course".

Can you confirm the precise git commit hash you intend to release?

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1037258: curl -I (HEAD request) fails with HTTP/2 against a Debian Apache instance

2023-06-09 Thread Ian Jackson
For the record: this bug caused `dgit clone dgit` to fail.  That
aspect of the problem has been worked around by forcing that host to
use HTTP/1 only.  ([rt.debian.org #9218]).

This also means that the repro in this bug report won't work any more,
I'm afraid.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1035361: sauce: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755

2023-05-30 Thread Ian Jackson
Control: severity -1 normal
Control: tags -1 + patch

Andreas Beckmann writes ("Bug#1035361: sauce: Potentially dangerous mode on 
/etc/logrotate.d/sauce: 0755"):
> While the package works fine after a fresh install in sid or bookworm,
> the issue is still present after an upgrade from bullseye to bookworm.
> File permissions of conffiles do net seem to get updated on upgrades,
> this needs to be fixed manually in the postinst, e.g. (untested)
> 
> if dpkg --compare-versions "$2" lt-nl "0.9.3~"
> then
>   chmod -v -x /etc/logrotate.d/sauce 
> fi

Indeed.

However, I decided not to make that change so late in the freeze.  I
didn't want to add a risk that the maintscript fregemnt would be
wrong (despite the testing I would naturally do).

Cribbing from my commit message:

This is a conffile, so old installs don't get the updated mode.
Ideally we would add something to the postinst to fix them but
that seems too complex at this stage of the Debian release cycle.
Users who are annoyed with the warning can change the mode by
hand.

I will probably do something like you suggest when sid has reopened,
for the benefit of downstreams with a different release cycle, users
skip-upgrading, etc.

I don't intend to prepare a stable update for bookworm myself.  But
if, after I've done this fixup in sid, someone would like to drive
that, I would be happy to review the proposed update and lend my
support.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1035361: SAUCE RC bugs to be fixed for bookworm

2023-05-14 Thread Ian Jackson
I have just pushed 0.9.2.  I will file an unblock request later today.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1035397: pm-utils is abandoned, should be removed from Debian

2023-05-02 Thread Ian Jackson
Control: retitle -1 Consider maintainership transfer to d-i-d team

Mario Limonciello writes ("Bug#1035397: pm-utils is abandoned, should be 
removed from Debian"):
> pm-utils hasn't had any changed in 13 years upstream.  It's been effectively 
> replaced by
> systemd-sleep in all practical ways.
> 
> It should be removed from the archive.

Since I don't use systemd, obviously I don't agree.  If necessary I
will consider myself upstream, but I think there are probably other
people worth collaborating with.  Anyway, I'm not changing this
package for bookworm at this stage unless to fix a very serious bug.

For the next release, I agree that this package could do with some
love.  It might be worth transferring maintainership to the Debian
Init Diversity Team, and in any case the patches ought to be reviewed
and applied.

For the avoidance of doubt: I would of course welcome constructive
NMUs.  Members of the Debian Init Diversity Team are welcome to do
0-day NMUs.  But, not during the freeze.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1035361: sauce: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755

2023-05-02 Thread Ian Jackson
Control: clone -1 -2
Control: retitle -2 ancient chown syntax
Control: severity -2 serious

Andreas Beckmann writes ("Re: Bug#1035361: sauce: Potentially dangerous mode on 
/etc/logrotate.d/sauce: 0755"):
> Setting up sauce (0.9.1) ...
> Checking for SAUCE databases in /var/lib/sauce ...
>   cdb.site-annoy (no existing data)  donechown: warning: '.' should be 
> ':': 'mail.mail'
> chown: warning: '.' should be ':': 'mail.mail'
> chown: warning: '.' should be ':': 'mail.mail'
> chown: warning: '.' should be ':': 'mail.mail'

etc.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1035361: sauce: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755

2023-05-02 Thread Ian Jackson
Andreas Beckmann writes ("Re: Bug#1035361: sauce: Potentially dangerous mode on 
/etc/logrotate.d/sauce: 0755"):
> [trying] it manually by installing logrotate and sauce in a chroot 
> (without removing sauce again):

Ah!

Thanks for investigating.  I think that I ought to fix the
permissions of the logrotate.d and the chown syntax.

I will do some more tests to check about whether that's sufficient or
whether "missingok" is needed too.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1035361: sauce: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755

2023-05-02 Thread Ian Jackson
Andreas Beckmann writes ("Bug#1035361: sauce: Potentially dangerous mode on 
/etc/logrotate.d/sauce: 0755"):
> Package: sauce
> Version: 0.9.1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
...
> during a test with piuparts I noticed your package's logrotate
> configuration causes logrotate to exit with an error after the package
> has been removed (*) or when logrote is run but no logfile exists.

Thanks for the report.  I will fix this ASAP.

> Usually the solution is to specify 'missingok' in the logrotate
> configuration.

I will do some tests but that sounds like a possible approach.

> Setting severity to serious since this does not seem limited to being
> emitted after package removal but always. The current logrotate version
> in sid seems to be more strict.

I looked through the changelog and didn't find anything about missing
logfiles since at least 2015.  Are you sure ?

> >From the attached log (scroll to the bottom...):
> 
> 0m17.0s DEBUG: Starting command: ['chroot', 
> '/srv/piuparts.debian.org/tmp/tmp6h9n6ntx', '/usr/sbin/logrotate', 
> '/etc/logrotate.d/sauce']
> 0m17.0s DUMP: 
>   warning: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755
> 0m17.0s DEBUG: Command ok: ['chroot', 
> '/srv/piuparts.debian.org/tmp/tmp6h9n6ntx', '/usr/sbin/logrotate', 
> '/etc/logrotate.d/sauce']
> 0m17.0s ERROR: FAIL: Logrotate file /etc/logrotate.d/sauce exits with error 
> or has output with package removed

I have one question.  The message here is complaining about the file
permission.  I think that mode is probably wrong, but I don't think it
is *dangerous*.

I don't think I ought to change the mode for bookworm.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1033503: dgit autopkgtests broken by git 2.40 [and 2 more messages]

2023-04-09 Thread Ian Jackson
Recap:

  git's new check in "git hash-object" breaks some tests in src:dgit,
  which deliberately create broken objects eg to detect a regression
  like #849041.  Updating the tests looks nontrivial.

  git 1.2.40-1 doesn't seem like it's going to migrate anyway, given
  that it's a key package which was uploaded during the freeze, and
  the git maintainer hasn't filed an unblock.

My previous message didn't receive any response and we're well into
the hard freeze.  I therefore don't have any plans to update dgit's
test suite for bookworm.

I have taken this work item off my personal todo lists and tracking
machinery, including suppressing the nag emails that I usually get
when my autopkgtests are blocking some other package.

After the bookworm release, the severity of this bug should probably
be raised.  That will put this issue back on my radar.

Thanks,
Ian.



Bug#1032826: Debian RT Incorrect redirection for dgit-repos

2023-04-06 Thread Ian Jackson
Control: close -1

We have fixed this by changing the Apache configuration on the server,
for the vhost git.dgit.debian.org.

Thanks to DSA for their help.  (See [rt.debian.org #9169].)

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1033503: dgit autopkgtests broken by git 2.40

2023-03-26 Thread Ian Jackson
Package: dgit
Version: 10.7
Control: affects -1 git

Some of dgit's tests create strange git objects, to test error
handling.  For example, to avoid a repetition of #849041.

git 2.40, just uploaded to unstable, has this change:

 | * "git hash-object" now checks that the resulting object is well
 |   formed with the same code as "git fsck".
 |   (merge 8e4309038f jk/hash-object-fsck later to maint).

This was probably a good idea.  So, dgit's tests need to be updated.
Normally I would file this bug as RC and make the necessary changes.


However, we are currently in the freeze for bookworm.  Information on
tracker.d.o suggests that git is not going to migrate to bookworm
anyway, without an unblock from the release team.  I don't see an
unblock request in https://bugs.debian.org/release.debian.org .

Release team: do you think we (dgit maintainers) should update the
test suite now, for bookworm ?  The changes would be limited to tests,
but the new checks in git mean we'll need to take a different approach
for some of them, which might be complex or messy.


Unhelpfully, there is also #1032826, which prevents "dgit import-dsc"
working for the current git.dsc in bookworm.  I think this situation
is RC.  I haven't filed a bug against src:git because I think we can
fix this just by changing the infrastructure - I'm talking to DSA
about this - but if that turns out to be impossible, we may need to
upload a no-source-changes src:git :-/.


Thanks for everyone's attention and advice/opinions.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1032826: dgit infrastructure broken for git package.

2023-03-12 Thread Ian Jackson
Thanks for the report.

Peter Michael Green writes ("Bug#1032826: dgit infrastructure broken for git 
package."):
> dgit: failed command: git ls-remote -q --refs 
> https://git.dgit.debian.org/git refs/dgit-rewrite/map
> 
> dgit: error: subprocess failed with error exit status 128
...
> Doing some poking around it appears to me that the repo
> does exist, but access to it with git is blocked by some kind
> of redirection rule.

Indeed.  I observe:

$ curl https://git.dgit.debian.org/git


301 Moved Permanently

Moved Permanently
The document has moved https://browse.dgit.debian.org/;>here.

Apache Server at git.dgit.debian.org Port 443

$ curl https://git.dgit.debian.org/dgit
$

I think this is probably some unhelpful default rule that comes with
the cgit package which is providing the git service on git.dgit.d.o.

I ma currently in a poor network environment where interactive work is
super awkward.  Sean has kindly volunteered to file a DSA ticket.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single

2023-02-22 Thread Ian Jackson
Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying 
--quilt=single"):
> I'm reluctant to introduce something else like this when we already have
> the git-debpush tags thing.  Hmm -- is there some reason why dgit
> couldn't put information in those tags in the same way?

Well, I'm a bit confused right now, but: I think a potential problem
is that if the branch format is converted without making a tag, things
can go wrong.  I'm not sure precisely how we avoided this with
git-debpush; part of the answer might be that git-debpush always works
in split brain mode.

> Right, but the pile of Emacs addons I maintain using dgit-maint-merge(7)
> will never hit any of those behaviours.  So it's a high cost to impose
> on someone in a position such as mine.

Hmmm.  I am very reluctant to recommend a practice which will induce
other tools to corrupt data.  Note that the corruption might be
experienced by downstreams (ie, people outside Debian) who are trying
to use dgit to manipulate packages from Debian.

Whereas inventing a dropping in debian/source/ seems straightforward
and precisely correct.  It's a description of the maintenance/update
practice that generated the tree you're working with, and (by
implication) how updates to it should be made.

Is there anything stopping us inventing an "unofficial"
debian/source/options entry ?
... tested it ...
It causes these messages:
dpkg-source: info: using options from dgit/debian/source/options: --wombat
dpkg-source: warning: --wombat is not a valid option for 
Dpkg::Source::Package::V1
which is probably too annoying.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single

2023-02-22 Thread Ian Jackson
Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying 
--quilt=single"):
> How about having single-debian-patch imply --quilt=single in the absence
> of any other setting or command line argument for the quilt mode?
> Then in the docs we would say that it is a good idea to use only the git
> configuration value, but that this is another option if you prefer it.
> 
> This is still better than the previous situation because dgit will undo
> some problems created by single-debian-patch (right?).

The usual reason for eschewing in-tree directions about quilt format
is that the tree can't (mustn't) tell you if it's patches-applied or
not.  I think it would be OK for the tree to influence *how* patches
are made (ie, choose between --quilt=linear, --quilt=single, etc.)

There is also the fact that it would have an effect on dgit's
behaviour for an NMUer, but I think that's OK for this.

So your idea has merit.

However, do we want to have people put single-debian-patch in the
source tree ?  That has such weird dpkg-source behaviours.

Ideally we would do something that would influence dgit, but not
dpkg-source.  So maybe we could put some *other* dropping in the
source tree?

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#557730: /etc/{protocols,network,services} not schroot's to scribble over

2023-02-14 Thread Ian Jackson
Wookey writes ("Re: Bug#557730: /etc/{protocols,network,services} not schroot's 
to scribble over"):
> On 2023-02-14 16:02 +, Ian Jackson wrote:
> > The fake netbase.deb could be contained within schroot.deb, in
> > /usr/share, so schroot wouldn't need to gain runtime build-deps on
> > dpkg tooling.
> 
> Except that it has to build this package live in order to contain the
> /etc/protocols and /etc/services files from the host
> environment. Having these default files with standard contents in a
> pre-built .deb is pointless, isn't it?

No, I thinko it's fine.  They mostly contain standardised constants.

schroot could build-depend on netbase and copy the files from there,
or just have fixed copies which would be updated manually once a
release or something.

These files, especially services, do change, but it is rare for
low-level basic things (or build systems) to actually depend on the
new entries.

> > > Whilst having the passwd database reflected in the chroot is
> > > incredibly useful it's not clear how often the services and protocols
> > > are needed, but I assume people do find that functionality useful.
> > 
> > I had a package that failed its build-time tests due to lack of
> > /etc/protocols.  The missing build-dep was detected in the buildds,
> > because my own local sid build chroot has netbase installed, precisely
> > because of this bug.
> 
> Right, which gets back to having a proper minimal environment used by
> sbuild to do a clean build. I have that (and it doesn't mount home,
> using the 'sbuild' profile). I use it once things are working
> reasonably well to get at least one clean build before uploading. This
> bug is a problem in the 'less clean, but more useful' 'default' chroot
> environment which is best for diagnostic work and builds of various
> sorts where some file persistence (of user files) is needed.

IME having a somewhat-dirty build environment is both convenient and
not a problem.

For example, my own sid chroot which *does* mount /home and import my
passwd and so on, reproducibily-builds the same .debs as the buildds
even for src:xen, whose build system is hardly straightforward.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#557730: /etc/{protocols,network,services} not schroot's to scribble over

2023-02-14 Thread Ian Jackson
Wookey writes ("Bug#557730: /etc/{protocols,network,services} not schroot's to 
scribble over"):
> 2) netbase could be installed in base chroots then the problem would not 
> arise (or only arise once).
> 
> The problem here is that chroots can be made by many tools, and the
> usual tools (debootstrap and mmdebstrap) do not put netbase in by
> default. It would be very easy to make sbuild-createchroot just add
> --include=netbase to the invocation, and I'm not sure there is any
> real downside to doing that? Documenting the reason for including this
> package so that people using other tools to make chroots know it's a
> good idea would also be easy and helpful.

A downside is that missing build-dependencies on netbase would no
longer be detected.  One alternative would be to declare netbase
build-essential.  TBH I'm not sure why that hasn't been done already.

I have a 4th option:

scroot could create this file by installing and then removing (but not
purging) a fake netbase.deb ("Version: 0~~).  Then, when the new
netbase appears, the usual conffile mechanism would DTRT, since the
file would not have been "locally created" (or indeed "locally
modified").

The fake netbase.deb could be contained within schroot.deb, in
/usr/share, so schroot wouldn't need to gain runtime build-deps on
dpkg tooling.

> Whilst having the passwd database reflected in the chroot is
> incredibly useful it's not clear how often the services and protocols
> are needed, but I assume people do find that functionality useful.

I had a package that failed its build-time tests due to lack of
/etc/protocols.  The missing build-dep was detected in the buildds,
because my own local sid build chroot has netbase installed, precisely
because of this bug.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1030093: dgit: can't import python-coverage.

2023-02-04 Thread Ian Jackson
Ian Jackson writes ("Re: Bug#1030093: dgit: can't import python-coverage."):
> (Also probably gbp pq ought to cope natively, so I will file a bug
> about that.).

This is now
  #1030534: gbp pq import fails with series file containing form feed

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1030093: dgit: can't import python-coverage.

2023-02-04 Thread Ian Jackson
Severity: control -1 serious

Hi, thanks for the report!

Peter Green writes ("Bug#1030093: dgit: can't import python-coverage."):
> dgit: trying slow absurd-git-apply...
> Traceback (most recent call last):
>File "/usr/bin/gbp", line 149, in 
...
> IsADirectoryError: [Errno 21] Is a directory: 
> '/home/plugwash/dgittest/repo/.git/dgit/unpack/python-coverage-6.5.0+dfsg1/debian/patches/'
> gbp pq import failed: subprocess failed with error exit status 1

How sad.

> I noticed as weird character which mcedit shows as "^L" in 
> debian/patches/series, perhaps this is related.

I have investigated.  You are right that this is the root cause.
I think this is a deranged to do but dgit ought to be able to import
everything.

I have what I think is a fix - well, a workaround which makes the
absurd gitapply contraption even more nightmarish - which I will
upload soon.

(Also probably gbp pq ought to cope natively, so I will file a bug
about that.).

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1029682: dgit: [INTL:nl] Dutch translation for the dgit package

2023-01-26 Thread Ian Jackson
Frans Spiesschaert writes ("Bug#1029682: dgit: [INTL:nl] Dutch translation for 
the dgit package"):
> Thank you for checking. I fixed it in my local copy of the nl.po file too.
> So hopefully the next translation update won't have the same error again.

If you prefer, I can update the source to remove "Subject:" from the
untranslated string, and you can then send me a corresponding updated
file ?  IDK how hard that is.  I find this gettext tooling a bit
confusing.

The adh-hoc temporary fix to the Dutch translation is in the master
branch on salsa at the moment.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1029682: dgit: [INTL:nl] Dutch translation for the dgit package

2023-01-26 Thread Ian Jackson
Frans Spiesschaert writes ("Bug#1029682: dgit: [INTL:nl] Dutch translation for 
the dgit package"):
> Please find attached the updated Dutch po file for the dgit package. 
> A draft was posted a few weeks ago to the debian-l10n-dutch mailing list
> asking for review. 
> Please add it to your next package revision. 
> It should be put as "po/nl.po" in your package build tree. 

Thanks.  I have incorporated this and it will be uploaded soon.

I took a look at the .po file and I noticed that there was one place
where "Subject:" was translated to "Onderwerp:".  However, there,
"Subject:" is a protocol element and ought not to be translated.

I have fixed that ad-hoc in the nl.po file.  I think I ought to chnage
the source code to not include the "Subject:" test in the string to be
translated, but I haven't done that because I think that would fuzz
the translation.

I have left a TODO in the code and we may fix this properly later.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1029682: dgit: [INTL:nl] Dutch translation for the dgit package

2023-01-26 Thread Ian Jackson
Frans Spiesschaert writes ("Bug#1029682: dgit: [INTL:nl] Dutch translation for 
the dgit package"):
> Package: dgit 
> Severity: wishlist 
> Tags: l10n patch 
...
> Please find attached the updated Dutch po file for the dgit package. 
> A draft was posted a few weeks ago to the debian-l10n-dutch mailing list
> asking for review. 
> Please add it to your next package revision. 
> It should be put as "po/nl.po" in your package build tree. 

<3 :-)

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1029022: git should honour -c safe.directory

2023-01-16 Thread Ian Jackson
Package: git
Version: 1:2.20.1-2+deb10u6

I have a script which I use for privsep builds of Rust stuff.
Since a recent stable security update, I get this:

 fatal: detected dubious ownership in repository at '/home/ian/Rustup/Arti/arti'
 To add an exception for this directory, call:
git config --global --add safe.directory /home/ian/Rustup/Arti/arti

I understand the reason for this.  However, my tool deliberately
arranges to trust a repository owned by a different user: indeed, it
is about to execute code from that user's directory.  The build user
trusts (must trust) the source code user, so this is fine.

So I would like to pass
   -c safe.directory=*

However

  This config setting is only respected when specified in a system or
  global config, not when it is specified in a repository config or
  via the command line option -c

This is preventing me from disabling this check.  I don't understand
why we wouldn't trust the command line.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



  1   2   3   4   5   6   7   8   9   10   >