Bug#1086628: authbind: Support root-less builds
<3. I hope to review this some time in the next week or so. If that doesn't happen, feel free to chase me. 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#1086628: authbind: Support root-less builds
Niels Thykier writes ("Bug#1086628: authbind: Support root-less builds"):
> 1) Migrate the package to use a packaging helper such as debhelper, and
> set `Rules-Requires-Root: no` in debian/control. This would have
> other benefits as well (like providing a -dbgsym package)
I think this is a good option. My only concerns would be:
- The upstream makefiles should still work properly outside the
Debian context. (Hopefully this exercise would involve only
minimal changes to the upstream parts of the package - bugfixes of
course would be fine there.)
- The before-and-after diff of the resulting binary packages should
look good. (This seems like a routine part of such an exercise so
I'm mentioning it for completeness.)
> (Side bar: Please also consider adding a Vcs header to the package if it
> is maintained in a version control system).
The git repository is here:
https://www.chiark.greenend.org.uk/ucgi/~ian/git/authbind.git/
The package was uploaded with dgit, so "dgit clone" gets you the full
git history. The upstream branch contains the necesary Debian
packaging and there is no Debian delta.
There should probably be Vcs-Git headers.
> If desired, I can look into providing a patch for either option.
I would be happy to review patch(es). git-format-patch patchbomb or a
git branch somewhere would be very welcome. Otherwise, realistically,
this isn't likely to get to the top of my todo list soon.
Thanks for your interest!
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#1085371: innduct: Excessive debug log when peer expiring for ages
Package: innduct Version: 2.1~~iwj3 Severity: important Tags: upstream I have had trouble over the past few days with innduct generating unreasonable amounts of debug log. Mostly, the messages look like this: Oct 18 08:40:01 chiark innduct[3270]: nntp.[elided]| debug: filemon inotify: read event with unknown wd=5447913 Oct 18 08:40:01 chiark innduct[3270]: nntp.[elided]| debug: filemon inotify: startfile 0x55de6bf4e6b0 wd=5447914 pf=0x55de6c096840 Oct 18 08:40:01 chiark innduct[3270]: nntp.[elided]| debug: filemon inotify: stopfile 0x55de6bf4e6b0 wd=5447914 pf=0x55de6c096840 Oct 18 08:40:01 chiark innduct[3270]: nntp.[elided]| debug: filemon inotify: read event with unknown wd=5447914 Oct 18 08:40:01 chiark innduct[3270]: nntp.[elided]| debug: filemon inotify: startfile 0x55de6bf4e6b0 wd=5447915 pf=0x55de6bfbfd10 Oct 18 08:40:01 chiark innduct[3270]: nntp.[elided]| debug: filemon inotify: stopfile 0x55de6bf4e6b0 wd=5447915 pf=0x55de6bfbfd10 Oct 18 08:40:01 chiark innduct[3270]: nntp.[elided]| debug: filemon inotify: startfile 0x55de6bf4e6b0 wd=5447916 pf=0x55de6bff38d0 This seems to have been triggered by the peer being in "expiring" state for several days and responding to every article with 431. I think I have diagnosed the problem. If my fix holds up, I will upload it. -- System Information: Debian Release: 11.11 APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/16 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages innduct depends on: ii libc62.31-13+deb11u11 ii liboop4 1.0.1-2.1 Versions of packages innduct recommends: ii perl 5.32.1-4+deb11u3 innduct suggests no packages. -- no debconf information
Bug#1085152: dgit: support lightweight no-change-source-only uploads
Paul Gevers writes ("Bug#1085152: dgit: support lightweight
no-change-source-only uploads"):
> While discussing our Release Team work with Graham, we thought it might
> be a nice feature by the dgit infrastructure if it could support
> lightweight (i.e. no local download of the source) no-change-source-only
> uploads to the archive. Two usecases come up in my mind (but I bet there
> are more):
Hi. Thanks for this suggestion.
I think this could be a function of the tag2upload service.
Do we, in this scenario, mind downloading a git clone of the package?
I think it would be best if we could avoid it.
How does the person doing this indicate their intent ?
They could make an OpenPGP signature which would say something like
"please no-source-upload package X, version A, to suite S,
as version B".
Or, in principle, there could be a web self-service system, but that
has many Implications and fits into the various data models less well.
That OpenPGP signature could be a signed git tag. To make a tag, the
tagger does *not* need a complete copy of the code. They need the
commitid, but that's readily available if the package is on
dgit-repos.
I think this could be a mode of git-debpush, or an allied utility.
Presumably the tag2upload service would retrieve the previous
version's archive/ tag and check that it had the same commitid. It
should also check the ftpmaster API to get the hash of the
corresponding .dsc, and fish out the Dgit: field.
(This approach trusts that we won't find that both dgit-repos and
ftpmaster API are colmpromised. Neither the authoriser, nor the t2u
service, can reliably verify the signature on the previous archive/
tag. Debian has no post-hoc audit capability for upload signatures.)
Also, this only works for packages where the most recent version is on
dgit-repos. Currently that's packages uploaded with dgit, and, soon,
t2u. I'm hoping that t2u adoption will become widespread. At that
point I think it would be a good idea to start importing all uploaded
packages into dgit-repos automatically.
Anyway, I think we should focus on t2u service deployment for "normal"
uploads first - but having this kind of future scenario in mind is a
good think.
After t2u is deployed I think we should probably try to widen the
t2u/dgit team. (And we as t2u service operators should seek a DPL
delegation.) There will be more space to explore this kind of idea.
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#1084265: FTBTS was due to itertools dependency
Control: reassign -1 src:hippotat Control: fixed -1 1.1.12 Control: close -1 1.1.12 Control: forcemerge 1082550 -1 The fix has been uploaded. Let me try some more BTS flail. -- 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#1084265: FTBTS was due to itertools dependency
Control: reasign -1 src:hippotat Control: fixed -1 1.1.12 Control: close -1 1.1.12 Control: forcemerge 1082550 -1 The fix has been uploaded. Let me try some more BTS flail. -- 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#1055918: rust-hyper: please provide newer upstream branch v1.0
Blair Noctis writes ("Re: rust-hyper: please provide newer upstream branch
v1.0"):
> The "http stack" (http*, hyper*, tower*, reqwest, axum, etc.) is quite
> intertwined, so it's planned as a (team level) transition pack, tracked here:
>
> https://salsa.debian.org/rust-team/debcargo-conf/-/issues/78
Yes. Thank you for the references!
> Considering the recent libgit2 transition affecting rustc and the
> base64 (team) transition, this is staged in the http-stack branch to
> avoid increasing fallout radius. I plan to carry it out after
> aforementioned fallout is cleared.
Excellent, tyvm.
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#1055918: rust-hyper: please provide newer upstream branch v1.0
> hyper is stable upstream now, so we should probably prepare a > transition for this eco-system (hyper*, http*, h2, ..). one known (to > me) blocker is reqwest, which hasn't updated upstream yet: > > https://github.com/seanmonstar/reqwest/issues/2039 FTR, that blocker has been resolved upstream. 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#1084265: FTBTS is due to itertools dependency
Control: severity 1082550 serious Control: forcemerge 1082550 -1 Hi. Thanks for the report. I am in the process of fixing this. -- 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#1028254: hippotat build seems to be reproducible now
Control: close -1 This problem seem to have gone away, presumably due to toolchain work. I didn't make any relevant changes to src:hippotat. Closing 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#1084924: The system-log-daemon virtual package
Package: tech-ctte Control: block 1072021 by -1 Hi. Earlier this year I was asked [#1072021] to remove Recommends: ... system-log-daemon from one of my packages. There are some explanations here: [0]: https://lists.debian.org/debian-devel/2024/05/msg00425.html https://lists.debian.org/debian-devel/2024/05/msg00436.html The effect of making this change is that on non-systemd systems, nothing pulls in a syslog daemon and no logging takes place. This seems wrong. Also, I notice that this MBF proposal appears to have had no involvement with the Policy process even though it, effectively, amounts to the abolition of the system-log-daemon virtual package, which is, of course, established by Policy [1]. It seems to me that the semantics of the "system-log-daemon" virtual package must mean "there is a syslog service". Since systemd is capable of being a syslog service, that means that it should Provide that virtual package. Because the syslog daemon is a singleton, implementors of the virtual package should Conflict/Provide. Therefore, to avoid apt trying to deinstall systemd, the parts of the systemd.deb that provide this functionality (or enable it) should be split out into a separate package - ie systemd should own and listen on the standard syslog socket iff that package is installed. That is how multiple mutually-exclusive provisions of of the same facility are done in Debian. This option was rejected by the MBF proposal on the grounds that > splitting journald or its configuration to separate packages is not > an acceptable workaround, as keeping enabled it by default is the > goal [0] This doesn't seem to make sense since packages can be installed by default, so it would be possible to split the package and and retain the intended behaviour in the default install. So it seems to me that there is no reason why systemd's syslog functionality couldn't follow Policy, use the virtual package as intended. It should do so, and all changes made as a result of the MBF should be reverted. Perhaps there are some other reasons, why this is not feasible or desirable. In that case, we should still arrange that systems which do *not* have systemd, still end up with a syslog daemon when required. Simon McVitte had a suggestion how this might be achieved [2] but this was not embodied in the MBF. In any case, Policy should be updated rather than bypassed. Please would the TC reaffirm policy, and give appropriate advice. Alternatively, if policy needs to change please would the TC assist this process, and help ensure that the resulting policy (i) suits the needs of all Debian configurations (ii) is properly documented (iii) is implemented. On a previous occasion when I brought a matter to the TC, I was subjected to a sustained campaign of harassment, on the TC mailing list, which Debian's authorities collectively allowed to continue. THe harassers included full Debian members and one of the proponents of the present MBF. Therefore: please do not email me any further about this subject, until a TC decision is made. When Policy is updated, I will change my packages accordingly. In the meantime, I'll adjust my mail filters to discard messages to this bug. Ian. [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#relationships-between-source-and-binary-packages-build-depends-build-depends-indep-build-depends-arch-build-conflicts-build-conflicts-indep-build-conflicts-arch https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml [2] https://lists.debian.org/debian-devel/2024/05/msg00426.html -- 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#1084848: hippotat: Upcoming env-logger update
Matthias Geiger writes ("Bug#1084848: hippotat: Upcoming env-logger update"):
> I intend to update env-logger in Debian to 0.11. It is currently
> available in experimental for your convenience. I will probably upload
> it to unstable in ~ 1 week and then raise the severity accordingly.
Jolly good, thanks for the heads-up.
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#1084523: hippotat: base64 update
Control: severity -1 serious
Matthias Geiger writes ("Bug#1084523: hippotat: base64 update"):
> we recently updated rust-base64 in Debian to 0.22. Since your package
> depends on this library this needs an updated. For your convenience I
> attached a patch facilitating this.
Thanks.
--
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#1082004: Error message not cut-and-paste-able
Package: xfce4-power-manager Version: 4.18.4-1 I installed trixie yesterday, using the netinst d-i image. I selected task-xfce-desktop in tasksel. At the end of the install I replaced systemd with sysvinit as per the wiki instructions: https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time Now, whenever I close the laptop lid, it tries to start a screen locker. But this doesn't work. It puts up a dialogue box saying that Noen of the screen lock tools ran successfully, the screen will not be locked This bug is *not* about that cause of this message! (That's #1082003.) This bug is about the fact that I don't seem to be able to cut-and-paste the error message. I've tried left-clicking and dragging; I've dried double-clicking. The window offers some standard furniture from the window manager, and a close button. I don't know which program is generating this dialogue. xfce4-power-manager is a guess. I'm about to completely replace my personal desktop configuration with my longstanding dotfiles, and reconfigure everything, after which I expect this bug no longer to affect me. I'm reporting it because I wanted to help other users. 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#1082003: screen lock not installed or doesn't work?
FTR, changing the power management settings for "On lid close" to "Suspend" (in the power management settings from the XFCE tray battery icon in the top right) resulted in successful suspend/resume. So think probably the bug is that the intended screen locker/saver isn't installed, or maybe that it's not wired up properly somehow. 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#1082003: screen lock not installed or doesn't work?
#x27;t connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (wrapper-2.0:3191): dbind-WARNING **: 09:53:11.155: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (wrapper-2.0:3182): dbind-WARNING **: 09:53:11.155: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (wrapper-2.0:3195): dbind-WARNING **: 09:53:11.165: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (light-locker:3197): dbind-WARNING **: 09:53:11.169: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (xfce4-power-manager:3198): dbind-WARNING **: 09:53:11.171: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied ** (light-locker:3197): ERROR **: 09:53:11.172: session_id is not set, is /proc mounted with hidepid>0? Xfce Power Manager: Another power manager is already running (nm-applet:3199): dbind-WARNING **: 09:53:11.178: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (xfsettingsd:3209): dbind-WARNING **: 09:53:11.178: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (xfce4-notifyd:3217): dbind-WARNING **: 09:53:11.179: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (polkit-gnome-authentication-agent-1:3225): dbind-WARNING **: 09:53:11.182: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied Another notification daemon is running, exiting Another notification daemon is running, exiting (wrapper-2.0:3327): dbind-WARNING **: 09:53:11.238: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied (thunar-volman:3408): dbind-WARNING **: 09:54:05.671: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied thunar-volman: Unsupported USB device type "usb". (thunar-volman:3429): dbind-WARNING **: 09:54:05.776: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied thunar-volman: Unsupported USB device type "usb-storage". (thunar-volman:3458): dbind-WARNING **: 09:54:06.862: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/107/at-spi/bus_0: Permission denied thunar-volman: Unknown block device type "disk". -- 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#1081887: dgit: dgit-user(7) could mention backwards compatible debs
Sean Whitton writes ("Bug#1081887: dgit: dgit-user(7) could mention backwards
compatible debs"):
> We put effort into keeping dgit.deb installable on old Debian releases,
> as old as we can manage. I think it would be good to advertise this
> fact. dgit-user(7) seems like the appropriate place.
Also now we have gitlab CI we could test it 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#1078016: git-debpush: want some option to print workflow, if known
me code to do this IIRC but I haven't looked at it in a while and it may not be 100% reliable. I forget the details, but I think Sean knows more. >* The repo uses DEP-14 branch layout > Documentation: `https://dep.debian.net/deps/dep14` This is information about the specific repository. The repo itself is named in Vcs-Git so the information could be in-tree if it's understood as only applying to that specific tree. Obviously a downstream, or even some team member's own fork on salsa, might have a different layout. > Obviously, I do not expect `dgit` to provide said tool nor all the > information here. But the parts under `dgit`'s domain should be machine > readable to enable us to write such a tool. Yes. The quilt mode is machine-readable in the git tags. > Ideally, I want this to be reverse engineer-able or machine discoverable > rather than maintained by hand. That is because hand-maintained policies > tend to get out of date as the team changes policies, while reverse > engineering from the data looks at the current pattern. That said, I > fully appreciate that some things are hard or even impossible to > accurately reverse-engineer the common use-cases. Right. > I hope that explains the context and scope for what I want machine > readable. You are the domain experts for `dgit`, so you are in the best > position to say what can and cannot be reversed engineered vs. what must > be a "manually maintained" policy. This makes sense. I'm afraid this reply may be a bit inchoate (and too long) but I hope this it's helpful. 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#1080011: dgit can be very slow compared to apt source
Simon Tatham writes ("Bug#1080011: dgit can be very slow compared to apt
source"):
> warning:
> dgit: error: gbp-pq import and dpkg-source disagree!
> dgit: gbp-pq import gave commit 588df14f290cd60ff33c416fe71e9e19296dd5b1
> dgit: gbp-pq import gave tree 67f0e0262543d2ea406db80e42ecba5602efa2c9
> dgit: dpkg-source --before-build gave tree
> 47299fdddef7fe7744006ef486ed3a76464aaf2f
> dgit: trying slow absurd-git-apply...
Ahh.
This package contains patches where git and dpkg-source disagree about
the meaning of a patch. The workaround dgit uses is very slow (and I
think probably unavoidably so: the workaround is to actually run
dpkg-source).
One thing we *could* do though is to make a config option that causes
dgit to make less detailed git histories when it is forced to import a
dsc. The resulting histories probably ought not to be uploaded
anywhere but they would be much quicker to produce.
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#1079762: dgit: Supporting generated files (`debian/control` and `debian/tests/control`) not commited to git
Niels Thykier writes ("Bug#1079762: dgit: Supporting generated files
(`debian/control` and `debian/tests/control`) not commited to git"):
> I am looking into supporting features that involves generating or
> enriching certain packaging files automatically.
Thanks. These are intereting ideas. I think I need to digest your
message properly. I certainly think I can provide some helpful input.
I hope you don't mind that it may take a little while for me to get my
thoughts together and write them up. Please LMK if I'm taking too
long.
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#1079434: dgit: Can we avoid Debian specific rules for gitattributes?
Niels Thykier writes ("Bug#1079434: dgit: Can we avoid Debian specific rules
for gitattributes?"):
> When using `dgit` on a Debian package where there is a `.gitattributes`
> file, I get the warning:
>
> """
> dgit: .gitattributes not (fully) defused. Recommended: dgit setup-new-tree.
> """
Did you read the section GITATTRIBUTES in dgit(7) ?
>Concretely, I can have `git` enforce that I do not get Windows
> newlines into my scripts just because the contributor wrote the patch on
> a Windows machine in a less than ideal configured editor[2].
I can see how this is useful. I think a better approach to this kind
of thing might be to use git's hook arrangements.
> In a standard git workflow, I can edit the `.gitattributes` as needed
> and push it. From there on, branches based on that commit will now
> respect the delta. This is a nice property for me as an (upstream)
> developer.
I think maybe you have misunderstood what `dgit setup-new-tree` does.
It does not manipulate the git tree object, or your branch.
It manipulates the per-tree *configuration* (.git/info/attributes) to
arrange that the in-tree .gitattributes don't cause discrepancies
between your working tree and the git history. (Such discrepancies can
cause `dgit push-source` to fail.)
When I developed this aspect of dgit, I was thinking of upstreams
who put all manner of surprising things in .gitattributes. For
example, upstream Xen git has a .gitattributes file which encodes
version information in working tree files.
This isn't compatible with dgit's core invariant, which is that the
git tree object is precisely the same as the content of the source
package. (The alternative invariant would be that source package is
identical to content of the working tree *as transformed by
gitattributes* - but the gitattributes are typically
context-sensitive, lossy, and very complex, so that isn't workable.)
I agree that this whole situation is not optimal. To be honest,
I think the whole gitattributes system in git is a mistake.
(See also git subtrees which are an even more badly broken thing[1]
that dgit doesn't support.)
But the situation is not as bad as I think you imagine.
If your gitattributes don't in fact transform files, in practice,
in a way that makes your source packages different from your git tree
object, then:
* You can safely ignore the warning, since even un-defused,
the attributes won't cause discrepancies that cause dgit to fail.
* You can suppress the warning by providing a defuse line
that affects no files (see `dgit setup-gitattributes` in dgit(1))
(Possibly there could be a nicer way to do this.)
* Users who heed dgit's advice (or use `dgit clone`) will not
experience lossage either. (Assuming they don't also apply
patches with Windows line endings, or something.)
>Nevertheless, I think `dgit` should change its behavior here, since
> we are making a Debian specific git workflow and it makes Debian
> contributors that are also upstream developers a second class citizen.
I'm open to suggestions for how this could all be better. But the
situation is certainly not straightforward.
Ian.
[1] See my blog post "Never use git submodules"
https://diziet.dreamwidth.org/14666.html
--
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#1078765: dgit: warning: could not open directory 'debian/source/': No such file or directory
Control: reassign -1 git
Control: found -1 1:2.45.2-1
Control: fixed -1 1:2.20.1-2+deb10u9
Hi, git maintainers. I'm afraid I have another bug for you.
Steps to reproduce
dgit clone debputy-lsp
cd debputy-lsp
git checkout 9ca98dc71acbde18e6328c90d6b48eb752248af1
git status -uall --ignored --porcelain debian/source/format
debian/source/options debian/source/local-options
debian/source/local-patch-header
Expected behaviour
Successful execution, with no ouptut, as seen in earlier versions of
git, for example 1:2.20.1-2+deb10u9.
Actual behaviour
This message is printed to stderr:
warning: could not open directory 'debian/source/': No such file or
directory
This has been reported by a dgit user. dgit runs that rune and
expects it not to mind about the fact that files may not exist.
Indeed, the files not existing is normal and git status doesn't
complain about nonexistence of individual files, only about the
absence of the containing directory. It's not clear to my why git
thinks this is wrong. (Especially given that git doesn't really even
properly track empty directories!)
Niels Thykier writes ("Bug#1078765: dgit: warning: could not open directory
'debian/source/': No such file or directory"):
> Using `dgit push-source`, I noticed the following warning:
>
> ```
> warning: could not open directory 'debian/source/': No such file or
> directory
> ```
I was able to reproduce this. Passing -D makes dgit print the
commands its running. I saw this (without my key available, so it
definitely wouldn't actually upload):
$ dgit -D -wgfa push-source
| git rev-parse --show-toplevel
=> `/volatile/ian/Dgit/Bugs/1078765/debputy-lsp'
| git config -z --get-regexp --local '.*'
| git config -z --get-regexp --local '.*'
| git config -z --get-regexp --global '.*'
| git config -z --get-regexp --system '.*'
format , quilt mode linear
| git status -uall --ignored --porcelain debian/source/format
debian/source/options debian/source/local-options
debian/source/local-patch-header
warning: could not open directory 'debian/source/': No such file or directory
=> `'
+ git diff --quiet HEAD
[...]
dgit: error: You seem to be trying to push an old version.
dgit: Version current in archive: 0.2.1 (in suite sid)
dgit: Version you are trying to upload: 0.2.1
> I feel that is not a warning I should see as a user.
I agree.
> PS: I am pretty sure it is not from dpkg-source.
...
> (Note that dpkg-source correctly identifies itself and gives a clear
> warning for this purpose. Additionally there is a "canonical suite name
> for unstable is sid" between the first `dpkg-source` line and the
> warning in question, which I also assume is coming from `dgit`).
Unfortunately, git frequently fails to identify itself when it prints
messages.
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#1077348: chroma: FTBFS: unsatisfiable build-dependency: libgslcblas0
Control: close -1 Hi. I'm the sponsor for chroma. Thanks for your QA work. chroma does not have a direct b-d on libgslcblas0 (or anything like it). I looked at the build log and it seems that the problem is that inkscape was uninstallable at the time of the archive rebuild test. I have done a test build in sid myself just now, and it built without trouble. Evidently inkscape is installable again. So I think things are good now. I am closing this bug report with this message. 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#1075452: rplay: ftbfs with GCC-14
Ian Jackson writes ("Re: Bug#1075452: rplay: ftbfs with GCC-14"):
> Right. I'm not sure I can do a proper test since I don't use it
> myself but I can at least check that my package builds against it...
> I'll look out for your upload and let you know.
Thanks for addressing this bug. I can confirm that my package (vtwm)
now builds fine, too. So I have no reason to think all is not well.
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#1078190: chiark-utils:FTBFS:build failure（compile failed）
Control: forcemerge 1075799 -1
Yue Gui writes ("Bug#1078190: chiark-utils:FTBFS:build failure（compile
failed）"):
> My solution to this issue:
> The error is caused by _TIME_BITS=64 is used without also setting
> _FILE_OFFSET_BITS=64.To fix this problem, you need to add _FILE_OFFSET_BITS=64
> definition to the compilation options. We can modify the file debian/rules on
> line20 "CMDLINE_CPPFLAGS="$(shell $(D_BUILDFLAGS) --get CPPFLAGS)
> -D_TIME_BITS=
> 64 -D_FILE_OFFSET_BITS=64" \". Replace that with "CMDLINE_CPPFLAGS="$(shell $
> (D_BUILDFLAGS) --get CPPFLAGS) -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" \".This
> way the issue can be fixed. I have tested that in local, and it works well.
> Please let me know wheather this solution can be accepted.
Thanks. I think you are probably right. I am going to apply 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#1078770: nmudiff for 8-25+nmu1
Package: unclutter
Version: 8-25
Hi. I've just NMU'd this package to fix the FTBFS bug #1075602 that
was threatening autoremoval. I didn't make other changes.
I hope you find this helpful. Here is the diff.
Regards,
Ian.
diff --git a/debian/changelog b/debian/changelog
index 20bffaf..9b18672 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+unclutter (8-25+nmu1) unstable; urgency=medium
+
+ * Fix implicit ints in function declarations.
+Closes: #1075602. [Report from Matthias Klose]
+
+ -- Ian Jackson Thu, 15 Aug 2024 20:12:12
+0100
+
unclutter (8-25) unstable; urgency=low
* Upload to unstable again.
diff --git a/debian/patches/fix-implicit-ints-in-function-declaratio.patch
b/debian/patches/fix-implicit-ints-in-function-declaratio.patch
new file mode 100644
index 000..66fe1b7
--- /dev/null
+++ b/debian/patches/fix-implicit-ints-in-function-declaratio.patch
@@ -0,0 +1,64 @@
+From: Ian Jackson
+Date: Thu, 15 Aug 2024 20:10:04 +0100
+X-Dgit-Generated: 8-25+nmu1 5ec60ce56eb580acffd7b384a0e8b8a59b73b655
+Subject: Fix implicit ints in function declarations
+
+Closes: #1075602
+
+---
+
+diff --git a/unclutter.c b/unclutter.c
+index c016663..de5a971 100644
+--- a/unclutter.c
b/unclutter.c
+@@ -32,10 +32,12 @@
+ #include
+
+ char *progname;
++void
+ pexit(str)char *str;{
+ fprintf(stderr,"%s: %s\n",progname,str);
+ exit(1);
+ }
++void
+ usage(){
+ pexit("usage:\n\
+ -display \n\
+@@ -93,6 +95,7 @@ regex_t *nc_re = 0; /* regex for list of classes/names
to avoid */
+ * return true if window has a wm_name (class) and the start of it matches
+ * one of the given names (classes) to avoid
+ */
++int
+ nameinlist(display,window)
+ Display *display;
+ Window window;
+@@ -131,6 +134,7 @@ Window window;
+ /*
+ * create a small 1x1 curssor with all pixels masked out on the given screen.
+ */
++Cursor
+ createnullcursor(display,root)
+ Display *display;
+ Window root;
+@@ -155,7 +159,8 @@ Window root;
+ return cursor;
+ }
+
+-main(argc,argv)char **argv;{
++int
++main(argc,argv)char **argv; int argc;{
+ Display *display;
+ int screen,oldx = -99,oldy = -99,numscreens;
+ int doroot = 0, jitter = 0, usegrabmethod = 0, waitagain = 0,
+diff --git a/vroot.h b/vroot.h
+index 0f32668..cbe41dc 100644
+--- a/vroot.h
b/vroot.h
+@@ -40,6 +40,7 @@
+ static Window
+ VirtualRootWindow(dpy, screen)
+ Display *dpy;
++int screen;
+ {
+ static Display *save_dpy = (Display *)0;
+ static int save_screen = -1;
diff --git a/debian/patches/series b/debian/patches/series
index f04419b..09c5c78 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
02-pass-flags.patch
03-fix-gtk-blinking.patch
04-man-page-fixes.patch
+fix-implicit-ints-in-function-declaratio.patch
diff --git a/unclutter.c b/unclutter.c
index c016663..de5a971 100644
--- a/unclutter.c
+++ b/unclutter.c
@@ -32,10 +32,12 @@
#include
char *progname;
+void
pexit(str)char *str;{
fprintf(stderr,"%s: %s\n",progname,str);
exit(1);
}
+void
usage(){
pexit("usage:\n\
-display \n\
@@ -93,6 +95,7 @@ regex_t *nc_re = 0; /* regex for list of classes/names to
avoid */
* return true if window has a wm_name (class) and the start of it matches
* one of the given names (classes) to avoid
*/
+int
nameinlist(display,window)
Display *display;
Window window;
@@ -131,6 +134,7 @@ Window window;
/*
* create a small 1x1 curssor with all pixels masked out on the given screen.
*/
+Cursor
createnullcursor(display,root)
Display *display;
Window root;
@@ -155,7 +159,8 @@ Window root;
return cursor;
}
-main(argc,argv)char **argv;{
+int
+main(argc,argv)char **argv; int argc;{
Display *display;
int screen,oldx = -99,oldy = -99,numscreens;
int doroot = 0, jitter = 0, usegrabmethod = 0, waitagain = 0,
diff --git a/vroot.h b/vroot.h
index 0f32668..cbe41dc 100644
--- a/vroot.h
+++ b/vroot.h
@@ -40,6 +40,7 @@
static Window
VirtualRootWindow(dpy, screen)
Display *dpy;
+int screen;
{
static Display *save_dpy = (Display *)0;
static int save_screen = -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#1075602: unclutter: ftbfs with GCC-14
Hi again.
Ian Jackson writes ("Re: unclutter: ftbfs with GCC-14"):
> I've just noticed this bug (my scripting was broken). I'm not in a
> position to fix it before the autoremoval but I iintend to NMU it in a
> week or so.
Here's the patch. I've chosen to try to retain the original style and
not convert any of the functions I touched to ANSI C syntax.
I'll be uploading this shortly and will file a separate bug with the
nmudiff.
Thanks,
Ian.
>From 5ec60ce56eb580acffd7b384a0e8b8a59b73b655 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Thu, 15 Aug 2024 20:10:04 +0100
Subject: [PATCH] Fix implicit ints in function declarations
Closes: #1075602
---
unclutter.c | 7 ++-
vroot.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/unclutter.c b/unclutter.c
index c016663..de5a971 100644
--- a/unclutter.c
+++ b/unclutter.c
@@ -32,10 +32,12 @@
#include
char *progname;
+void
pexit(str)char *str;{
fprintf(stderr,"%s: %s\n",progname,str);
exit(1);
}
+void
usage(){
pexit("usage:\n\
-display \n\
@@ -93,6 +95,7 @@ regex_t *nc_re = 0; /* regex for list of classes/names to
avoid */
* return true if window has a wm_name (class) and the start of it matches
* one of the given names (classes) to avoid
*/
+int
nameinlist(display,window)
Display *display;
Window window;
@@ -131,6 +134,7 @@ Window window;
/*
* create a small 1x1 curssor with all pixels masked out on the given screen.
*/
+Cursor
createnullcursor(display,root)
Display *display;
Window root;
@@ -155,7 +159,8 @@ Window root;
return cursor;
}
-main(argc,argv)char **argv;{
+int
+main(argc,argv)char **argv; int argc;{
Display *display;
int screen,oldx = -99,oldy = -99,numscreens;
int doroot = 0, jitter = 0, usegrabmethod = 0, waitagain = 0,
diff --git a/vroot.h b/vroot.h
index 0f32668..cbe41dc 100644
--- a/vroot.h
+++ b/vroot.h
@@ -40,6 +40,7 @@
static Window
VirtualRootWindow(dpy, screen)
Display *dpy;
+int screen;
{
static Display *save_dpy = (Display *)0;
static int save_screen = -1;
--
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#1078563: git-debrebase(1): mention to use --force for the start of Debian packaging
Osamu Aoki writes ("Bug#1078563: git-debrebase(1): mention to use --force for
the start of Debian packaging"):
> ```
> $ git debrebase new-upstream 2.0
> git-debrebase: snag detected (-fanchor-treated): old anchor is recognized due
> to --anchor, cannot check upstream
This is weird. You didn't pass --anchor, so this behaviour seems
wrong.
> In git-debrebase(1), it only says:
Something is definitely wrong here but I don't think I'm convinced
that the right fix is to advise the user to use --force.
(Using --force as a workaround seems fine.)
I'll look into this at some point (but probably not right away, I'm
afraid).
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#1078016: git-debpush: want some option to print workflow, if known
Sean Whitton writes ("Bug#1078016: git-debpush: want some option to print
workflow, if known"):
> If lots of people are already using git-debpush then we are effectively
> storing git workflow information for a lot of packages in their git
> histories. So it would be good to make that information readily
> accessible. If the last upload was done with --quilt=gbp, then
> 'git debpush --which-workflow' could print 'gbp'.
>
> I know we call these quilt modes, but people would probably find
> something with 'workflow' in it easier to remember.
I agree with this in principle. I think we need to be a little
careful about the distinctions between
1. dgit quilt mode
2. git branch and tree format
3. workflow
These go from least to most specific. The user probably needs to know
2, not 1 or 3. For example, what if the package is maintained in
git-debrebase ?
We lack a good name for 2 but maybe we could fudge it and say
"workflow" when we mean "workflow indistinguishability class under
external examination".
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#1075452: rplay: ftbfs with GCC-14
Thorsten Alteholz writes ("Re: Bug#1075452: rplay: ftbfs with GCC-14"):
> thanks, but I am almost finished with a fix and hope to do an upload
> this weekend.
> Unfortunately the software is rather old and the patch became rather
> big, so testing the package would be great.
Right. I'm not sure I can do a proper test since I don't use it
myself but I can at least check that my package builds against it...
I'll look out for your upload and let you know.
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#1075452: rplay: ftbfs with GCC-14
Hi. I've just noticed this bug (my scripting was broken). It's affecting one of my packages too. I'm not in a position to fix it right now but I iintend to look at it in a week or so. If the fix, is straightforard, I will NMU it. I hope that's OK with you. 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#1075632: vtwm: ftbfs with GCC-14
I've just noticed this bug (my scripting was broken). I'm not in a position to fix it before the autoremoval but I will fix it (and do something about #1075452) ) soon, probably in a week aor so. 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. -- 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#1075602: unclutter: ftbfs with GCC-14
I've just noticed this bug (my scripting was broken). I'm not in a position to fix it before the autoremoval but I iintend to NMU it in a week or so. 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#1076983: dgit: sometimes tries to run QF linkorigs twice
Control: tags -1 + confirmed > I can reproduce it with a lighter-weight package using the same > packaging style: > > dgit clone goo > cd goo > # Formally bump version to avoid possible early sanity checks. > dch -i 'dgit test' > dch -r 'dgit test' > git commit -a -m 'dgit test' > dgit push-source --dry-run --split-view=always Thanks :-). -- 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#1077171: gitlab CI isn't useable
Package: dgit Version: 11.11 In gitlab CI, our jobs: * Typically fail because the default pipeline doesn't cope with unfinalised changelogs. * Take an unreasonable length of time because they run a fully-formal autopkgtest. * Don't test every commit, which they ideally should. 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#1076983: dgit: sometimes tries to run QF linkorigs twice
Aaron M. Ucko writes ("Bug#1076983: dgit: sometimes tries to run QF linkorigs
twice"):
> Package: dgit
> Version: 11.10
> Severity: normal
>
> My attempts to run
>
> dgit push-source --collab-non-dgit
>
> for ncbi-tools6 6.1.20170106+dfsg2-3 a little while ago failed:
>
> dgit: error: (sym)link
> /home/amu/src/ncbi-tools6/ncbi-tools6-git/../ncbi-tools6_6.1.20170106+dfsg2.orig.tar.xz
> ncbi-tools6_6.1.20170106+dfsg2.orig.tar.xz: File exists
>
> Adding -D revealed that the problem to be that dgit was for some
> reason trying to run QF linkorigs twice -- once at startup and again
> for quiltification. I eventually managed to get past that by
> separately confirming that no fixups were needed and proceeding to add
> --quilt=nocheck. (--quilt=nofix was insufficient.)
Hrm. This does sound like a bug.
Do you have something resembling a Steps To Reproduce ? Could you
share the debug log ?
I think the linkorigs step is supposed to be idempotent.
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#1076287: git-debrebase: Add "Gbp-Dch: Ignore" to autogenerated commits
Andrea Pappacoda writes ("Bug#1076287: git-debrebase: Add "Gbp-Dch: Ignore" to
autogenerated commits"):
> Would it be possible to add a "Gbp-Dch: Ignore" pseudo header in commit
> messages generated by git-debrebase, so that I don't have to remove them
> manually when finalizing the changelog?
You're talking about "commit the patch queue" etc., I think?
I think what you suggest might make sense.
I wonder if the same should be true of autogenerated commits made by
the more general dgit quilt-fixup (modes like linear and smash).
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#1076117: dgit: crashes with a remote memory error on clone
Sean Whitton writes ("Bug#1076117: dgit: crashes with a remote memory error on
clone"):
> It was me :) The tree is used for more than one source package, emacs
> and emacs-non-dfsg, so tags made by dgit can't co-exist.
Ah, yes. DEP-14 tags don't have the package name in. I think this
was a mistake but at least it's not *my* mistake :-).
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#1076117: dgit: crashes with a remote memory error on clone
tl;dr: use `dgit --for-push clone` and carry on.
Rob Browning writes ("Re: Bug#1076117: dgit: crashes with a remote memory error
on clone"):
> Ian Jackson writes:
> > But, this repo seems very large. Is there something in it that
> > shouldn't be there?
>
> Hmm, I'm not exactly sure what's there. I was actually trying to clone
> it to understand the situation (I'm very new to dgit), because an
> attempt to push the latest release had failed.
The two seem similar in size. I tried cloning both and they took
comparable lengths of time (2m44 from salsa, 3m18 from push.dgit.d.o).
My laptop spent a long time "Resolving deltas".
So I think this means that the repo contents being not as intended, is
not the cause of the perf problems - it's just a large project with a
large history.
> I've been told that our arrangement is a bit unusual for (current) dgit
> because in addition to hosting multiple Debian distributions in the
> repo, we need to host multiple source packages for the dfsg split, and
> for guile, multiple X.Y versions (until recently, this was also true for
> Emacs).
...
> deb/{emacs,emacs-non-dfsg}/d/{sid,bookworm,...}/{upstream,master}
I think you mean you have these multiple git branches with the
different versions? That seems fine to me.
> For now, I've been advised to just use a temporary clone for dgit
> commands so that it won't introduce incompatible branches/tags/etc. into
> the normal working repo(s).
I don't know who advised you to do this, nor do I known what your git
workflow is, but you should be able to work on everything in one git
tree. Whats important is to keep the *branches* separate, and run the
right command(s) on the right branch.
OTOH there is nothing actually wrong with having multiple trees if you
prefer to work that way, aside from the space wastage.
So I recommend for now you use `dgit clone --for-push`. I'm often
available for more timely consultation via OFTC irc, where I'm Diziet.
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#1076117: dgit: crashes with a remote memory error on clone
Rob Browning writes ("Bug#1076117: dgit: crashes with a remote memory error on
clone"):
> $ dgit clone emacs-non-dfsg
> canonical suite name for unstable is sid
> fetching existing git history
> remote: error: Out of memory, malloc failed (tried to allocate 6880549
> bytes)
> remote: fatal: failed to read object
> 619d4b4412b96fba759869304ffa936b712a55e1: Cannot allocate memory
> remote: aborting due to possible repository corruption on the remote side.
> fatal: protocol error: bad pack header
> dgit: failed command: git fetch -p -n -q
> https://git.dgit.debian.org/emacs-non-dfsg
> '+refs/tags/archive/debian/*:refs/dgit-fetch/debian/tags/archive/debian/*'
> '+refs/tags/debian/*:refs/dgit-fetch/debian/tags/debian/*'
> '+refs/dgit/sid:refs/dgit-fetch/debian/dgit/sid'
>
> (I vaguely wondered if that might be git mmap on a large repository
> and/or a 32-bit host.)
This is an infrastructure problem. You'll see I have filed
[rt.debian.org #9567].
git.dgit.debian.org is the public mirror. As a full Debian Project
Member, you have access to the internal origin server. If you say
dgit --for-push clone ... it will use that instead. Hopefully that
will work for you.
But, this repo seems very large. Is there something in it that
shouldn't be 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#1075821: summer can get size wrong on 32-bit host!
Package: chiark-utils-bin Version: 7.0.1 Severity: serious Seen in a backup confirmation checksum diff -08b4ed2ab7e1723fdf84ca56f055cabb 5656798178 660 0 ... +08b4ed2ab7e1723fdf84ca56f055cabb 1361830882 660 0 ... These two values differ by 2^32. (This is with a locally-built backport binary, not a buildd binary, but I doubt that makes much difference.) -- 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#1075799: chiark-utils: ftbfs with time_t errors
Jeremy Bícha writes ("Bug#1075799: chiark-utils: ftbfs with time_t errors"):
> chiark-utils fails to build on 64-bit architectures with errors like:
>
> /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is
> allowed only with _FILE_OFFSET_BITS=64"
>26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
>
>
> https://buildd.debian.org/status/package.php?p=chiark-utils
Thanks for the report.
I had *intended* to enable 64-bit file offsets too.
Ian.
Bug#1075720: authbind does not honor CFLAGS/LDFLAGS set by the maintainer
Olivier Gayot writes ("Bug#1075720: authbind does not honor CFLAGS/LDFLAGS set
by the maintainer"):
> I just noticed that my quilt patch does not automatically apply because
> authbind does not declare d/source/format.
> As a consequence, the patch is ignored and the build still runs without the
> expected CFLAGS / LDFLAGS.
Oh! (I hadn't looked at it yet.)
> I will rework the patch and update.
Thanks. Please don't change the package source format. Just checking
that the patch works if it is actually applied will be fine.
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#1073844: [RFC] General Resolution to deploy tag2upload
Ian Jackson writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Currently, this is rather manual on the dgit-repos server. It could
> be automated, and probably should be.
I have filed #1073844 for this.
I think we can deploy tag2upload and advertise it for early adopters
with this bug unfixed, but we would probably want to make sure it's
sorted out before advertising it for general use.
Compared to dgit (which is already affected by this problem)
tag2upload has a larger risk of accidental history mingling because it
must make more use of pseudomerges, and it will have a wider userbase
who by design are less familiar with how all this stuff works.[1]
Ian.
[1] FTR, making it possible to upload without having to understand
Debian source packages is one of my goals. The source packages should
be Done Right automatically behind the scenes.
--
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#1073844: dgit-repos suite branches and rm'd packages
Package: dgit-infrastructure Version: 11.10 If a package is *removed* from a suite, the suite branch should probably be renamed on the server side. Otherwise if a different package with the same name is introduced, the histories will intermingle. 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#1073787: tag2upload should not remake the maintainer's DEP-14 tag
Package: dgit-infrastructure Version: 11.10 Observe that https://browse.dgit.debian.org/dgit-test-dummy.git/tag/?h=debian/1.39 is not the same as https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit-test-dummy.git;a=tag;h=c61fc1c5503f4c6b8dd7a486f1704af66098d11d This is not desirable. Nor is it necessary, because the maintainer's DEP-14 tag is supposed to be accepted by dgit-repos. (I don't think this is a blocker for t2u deployment, but we should fix it before we annouce it as generally available.) 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#1073171: dgit fails to build libabigail source
Paul Gevers writes ("Bug#1073171: dgit fails to build libabigail source"):
> I now already get issues while cloning. I wonder if that is because I
> already used `dgit push` manually (to delayed) while not on /tmp
I think your upload has succeeded, but there is an infrastructure
problem. See the RT ticket #9552 which I just filed.
As a workaround,
dgit --for-push clone
etc. will ssh to the primary server, rather than using the public
mirror.
--
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#1073171: dgit fails to build libabigail source
Paul Gevers writes ("Re: Bug#1073171: dgit fails to build libabigail source"):
> On 14-06-2024 1:12 a.m., Ian Jackson wrote:
> > The package seems quite large. I hate to ask but ... are you perhaps
> > out of disk space?
>
> Well, not out of regular disk space, but I run this script on /tmp and
> that's on tmpfs. And yes, that will be full with this package.
>
> Closing this bug as a non bug. Sorry for the noise.
If you reran the dgit rune with -D, we could probably see which
program failed to print the errno value, and reassign the bug to that
package as a request for better error handling.
(I bet it's git.)
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#1073171: dgit fails to build libabigail source
Paul Gevers writes ("Bug#1073171: dgit fails to build libabigail source"):
> I ran the following script (with pkg=libabigail):
> """
> dgit clone %(pkg)s
> dch --nmu "source only upload to enable migration (Closes: #%(bug)s)"
> dch -r ""
> git commit . -m"Prepare d/changelog for upload"
> dgit --quilt=linear build-source
> dgit --quilt=linear -wgf --delayed=15 push
> """
>
> It failed with exit status 255 after `build-source` and a lot of output
> like:
> error: unable to write file
> tests/data/test-alt-dwarf-file/test1-libgromacs-debug-dir/.build-id/7c/85cee9a5a59e7d0a866386b47c1674da5d201f.debug
> error: unable to write file
> tests/data/test-alt-dwarf-file/test1-libgromacs-debug-dir/.dwz/gromacs-5.0.6-4.fc22.x86_64
>
> This is with libabigail version 2.5-1 currently in sid.
Do you have the whole output ? dgit itself doesn't have that "unable
to write file" message in its source code. Whatever printed that
message doesn't seem to have included the errno.
I tried your runes but with
dgit --quilt=linear -wgf --delayed=15 --damp-run push
and it seemed to work for me.
The package seems quite large. I hate to ask but ... are you perhaps
out of disk space?
Does --damp-run work for you? If it fails the same way, then -D
output might be useful. Or an strace.
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#1073157: access control system should have emergency fingerprint blocklist
Package: dgit-infrastructure Version: 11.10 In a thread on d-vote Joerg Jaspert reports that ftpmaster sometimes block a particular PGP fingerprint in a hurry. Currently, the dgit-repos server, and the proposed t2u server, do not have this information. They should have it and honour it. Joerg writes: > we can have something like "ftpmaster pushes a list of fingerprints > via $mechanism" (ssh forced command is widely used for similar > things, for example). This seems like an appropriately lightweight answer. I suggest the following details: * Make the dgit-repos-server program, which interprets the keyrings and dm permissions list, take an additional input file, which is the list of blocked fingerprints. * Update ftpmaster's processes to add a script which rsyncs the blocked fingerprint list. Currently, to a suitable location on push.dgit.debian.org. And, after t2u is deployed, to the t2u server too. Using an rsync restricted command, as proposed. * Arrange to regularly test that this push of a new file can be done, in case the rsync restricted command rots. Joerg, does that sound good to you? Should the file be anything more than a list of fingerprints without whitespace in hex ? 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#1072021: hippotat-server: drop dependency on system-log-daemon
bl...@debian.org writes ("Bug#1072021: hippotat-server: drop dependency on
system-log-daemon"):
> As per https://lists.debian.org/debian-devel/2024/05/msg00425.html we
> want to drop dependencies on system-log-daemon when they are set
> simply because a package writes logs to syslogs, as they are no
> longer necessary, since by default systemd-journald takes care of
> persistent logs storage since Bookworm.
This doesn't seem right on systems without systemd (like mine, for
example).
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#947958: Re #947958: adns FTCBFS: help2man
Hi. In 2020 you wrote: > adns fails to cross build from source, because it uses help2man. In > this case, we can simply rebuild adns for the build architecture to > run help2man. Please consider applying the attached patch or stop > using help2man. I don't think I want to stop using help2man. But, I would love to have considered your patch today (finally!). Unfortunately you seem to have omitted to attach it. 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#1065725: adns: FTBFS on arm{el,hf}: FAILED ./case-1stservbroken - WRONG OUTPUT - lines of syscall remaining 0
Dan Bungert writes ("Bug#1065725: adns: FTBFS on arm{el,hf}: FAILED
./case-1stservbroken - WRONG OUTPUT - lines of syscall remaining 0"):
> I took a look at this bug today.
> I found that the regress testsuite make use of some negative offsets, which
> seem to perplex the reader on 32 bit systems.
>
> Please see the attached patch, which has allowed this to build for Ubuntu.
Thanks. I fixed the problem a little differently, in an upstream
release. (Your patch didn't work for me.)
I have just uploaded to Debian too. You may wish to pick up upstream
1.6.1 via Debian's 1.6.1-1 (or wait for it to build and migrate, maybe).
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#1069569: extra_system_ids setting does not work
Package: lvm2
Version: 2.03.11-2.1
root@recovery:~# lvcreate --config 'local/extra_system_id=["hub"]' -L 1G -n
test -Z y hub-early-b
Configuration setting "local/extra_system_id" unknown.
Cannot access VG hub-early-b with system ID hub with local system ID recovery.
root@recovery:~#
This is almost identical to the example from the lvmsystemid(7)
manpage, under "Overriding system ID". I also tried the
"lvmlocal.conf" setting exhibited there, and that didn't work either.
I was able to work around the problem by setting "system_id_source" in
lvm.conf and setting and the system's hostname with hostname(8):
root@recovery:~# cat /etc/lvm/lvm.conf
global {
system_id_source = "uname"
}
root@recovery:~#
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#1069103: Want better error message for git server infra problem
Package: dgit Version: 8.5 https://git.dgit.debian.org is unreliable. (This isn't dgit's fault.) Currently, users get a message like this: $ dgit clone debvm canonical suite name for unstable is sid fetching existing git history fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. dgit: failed command: git ls-remote -q --refs https://git.dgit.debian.org/debvm 'refs/tags/archive/debian/*' 'refs/tags/debian/*' refs/dgit/sid refs/dgit-rewrite/map dgit: error: subprocess failed with error exit status 128 $ It should maybe print something like this: It appears that the git repository repository https://git.dgit.debian.org/debvm is unreachable or broken. If dgit worked before for this distro (and therefore is properly configured), this probably means that your local network is broken, or the git server is malfunctioning. If you have push access, you may find that specifying --for-push works around the problem by using a different repo access method. To be useful, we'd maybe want to bnackport this change. 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#1069001: dgit: tag2upload: [dgit ...] should include source= and version= fields
Sean Whitton writes ("Bug#1069001: dgit: tag2upload: [dgit ...] should include
source= and version= fields"):
> As discussed elsewhere, we want source= and version= tags in the
> tag2upload metadata to prevent the possibility of a certain form of
> attack by someone who is able to replace git objects on salsa.
It should include the target suite too. Then it specifies everything
except the tree contents.
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
I've looked at this again. Sorry it's been so long.
Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying
--quilt=single"):
> I still regret that this change went into bookworm, and would like to
> simplify things again. I still think that this is a case where the cost
> of correctness-in-all-cases is too high.
I hadn't appreciated that, from your (legitimate) point of view, this
was a regression. I'm sorry.
> I think we can revert the behavioural change and come up with an
> appropriate warning in the workflow manpage. It might be relevant to
> recommend users consider using source format 1.0, even.
But, I'm still not sure which behavioural change you're talking about.
Are we talking about this, in 9.0:
* Reject split brain quilt modes with single-debian-patch.
(Previously this would malfunction; now we reject it.)
? That doesn't seem likely since 9.0 was July 2019 and this bug is
February 2023. But maybe that's the one. If so, the commit is
75b7a4c72614 which says "Right now, this malfunctions in dgit: we do
not do the split brain stuff". So although dgit tries to honour d/s/o
single-debian-patch (by invoking dpkg-source) it doesn't manage to do
it in the quilt modes where you evidently want it.
(Looking at the context, I think maybe this was a side effect of other
changes making this complicated to get right.)
#1018984 is scary reading, but doesn't seem to involve anything but
docs changes except
* With dpkg single-debian-patch, pass --include-removal to dpkg-source -b.
but that doesn't seem like it's what is in your way.
Going back to possible options:
Re somehow discovering this information from git tags: since this is
the same branch format, just a different way of generating patches, it
seems like fishing it out of the last git tag would be possible.
My concern in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031793#25
"if the branch format is converted without making a tag"
seems misplaced. But fishing this out of the tag in dgit still feels
very weird to me. It's not a thing dgit ever does the rest of the
time (git-debpush does, but that's different).
You wrote, as an argument in favour of writing single-debian-patch:
> You might want to allow non-dgit users to use 'dpkg-source --commit',
I agree that this is desirable. But the failure modes I previously
described in #1018984 are terrifying. I'm particularly bothered by
"I was able to make a source package [where] as soon as you try to
edit *an unrelated file* dpkg-source craps out terribly".
I don't think we can have both your goal, of letting people
dpkg-source --commit and fold in their changes into an existing patch,
*and* my goal of not ever getting people into the terrifyingly broken
source package situation (or encouraging things that may lead to that).
You also wrote:
> if you think the bugs aren't going to arise for your package
You can know that for the things *you* do to the package. But, you
don't know what changes downstream users are going to try to make. In
my experience, people further from centres of knowledge do
increasingly strange things.
I very much prefer, as an ideological position, to favour the
interests of downstreams, even arguably deragned downstream users,
over upstreams such as ourselves.
So I agree that something should be done. I still think
debian/source/options single-debian-patch is too bad to recommend.
I'm not opposed to trying to honour it, even so. Currently the
rejection is implemented in `build_maybe_quilt_fixup`, near l.6234.
I don't think we can use `quilt_fixup_git_singlepatch` in this case,
because dpkg-source wants to regenerate the patch each time, so we
must produce *our* patch with dpkg-source, or the source package isn't
a fixed point.
So we *have* to generate the patch with
`quilt_fixup_dpkgsource_singlepatch`. AFAICT from the git history and
the source code, that currently just doesn't work in split brain mode
(presumably for reasons to do with playtree juggling etc.
I still think it would be better to invent our own dropping to control
this, and have it modify the default quilt mode. That could cause the
fixup call to be `quilt_fixup_git_singlepatch` and wouldn't need to
interact with dpkg-source's ideas.
We've ruled out our own option in d/s/options, but we could have
debian/source/dgit-options containing `quilt-single-patch` or maybe
even `single-debian-patch` or something.
What a tangled web we weave. I hope this is of some use.
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#1068307: Bug#1068303: epsffit(1): no %%BoundingBox due comment into the EPS file
Ian Jackson writes ("Bug#1068303: epsffit(1): no %%BoundingBox due comment into
the EPS file"):
> So, this information should either be encoded in a DSC comment (I
> think %%Creator would be right), or moved to some place where the DSC
> spec allows "PostScript code".
So specifically, I think for example that changing
%Produced by poppler pdftops version: 22.12.0 (http://poppler.freedesktop.org)
to
%%Creator: poppler pdftops version: 22.12.0 (http://poppler.freedesktop.org)
would be correct. (Assuming that there isn't already a %%Creator - I
haven't checked.)
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#1068303: epsffit(1): no %%BoundingBox due comment into the EPS file
Control: clone -1 -2
Control: reassign -2 poppler-utils
Control: retitle -2 "Produced by poppler" header comment violates DSC spec
Control: severity -1 wishlist
Control: retitle -1 Compatibility with nonconforming poppler-produced files
Control: clone -1 -3
Control: retitle -3
Control: severity -3 wishlist
Hi, Poppler maintainers. A psutils user reported a problem which,
having read the spec, I think is due to a bug in poppler-utils.
Please see the original bug #1068303 for full context.
Niccolo Rigacci writes ("Bug#1068303: epsffit(1): no %%BoundingBox due comment
into the EPS file"):
> I have some scripts to manipulate heterogeneous PDF files, rotating
> and fitting them to a fixed size. The scripts are something like this:
Thanks for the report.
> pdftops -f 1 -l 1 -eps document.pdf document.eps
> epsffit -m -c 7 4 575 825 document.eps document-fit.eps
...
> The problem turned out to be into the header created by the pdftops
> command:
>
> %!PS-Adobe-3.0 EPSF-3.0
> %Produced by poppler pdftops version: 22.12.0 (http://poppler.freedesktop.org)
> %%LanguageLevel: 2
I think that %-comment is wrong. The relevant specification is the
PostScript Language Document Structuring Conventions. I found a copy
here:
https://web.mit.edu/PostScript/Adobe/Documents/5001.DSC_Spec.pdf
My reading of that specification is that normal PostScript comments
are not permitted there. See the diagram on p19 of that pdf. And in
section 4, 4.1 (page 22), the header section "consists of DSC comments
only".
So, this information should either be encoded in a DSC comment (I
think %%Creator would be right), or moved to some place where the DSC
spec allows "PostScript code".
> I'm not sure if the comment "%Produced by" is compliant to the EPS
> format. If it is not, we shuld blame the pdftops(1) command, provided
> by the poppler-utils package.
Yes.
I have cloned/retitled this bug accordingly. Would you please tell
the BTS the affected version of poppler-utils? (Or tell us, and we'll
set the BTS tags appropriately.)
Howeveer, I think it would be good for psutils to be able handle these
files. I don't have effort to work on a patch myself, but would be
happy to review and (if appropriate) accept a patch to tolerate this
situation, perhaps with a warning.
Thanks, all.
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#1068306: want autopkgtests which process varous programs' output
Package: psutils Severity: wishlist See #1068303, where a whole-system regression went undetected. We should have autopkgtests in psutils, which generate PostScript files with various tools in Debian, and check that psutils is happy with them. If we had had those, this regression would have been detected before the bug entered Debian "testing". 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#1068231: want section 5 manpage documenting signed tag format
Package: dgit The `[please-upload]` instruction, and other metadata, don't appear to be documented in-tree. There should be a tag2upload(5) manpage, probably. I will write one. 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#1067924: dgit: can't clone/fetch dockerfile-mode past few days
Sean Whitton writes ("Bug#1067924: dgit: can't clone/fetch dockerfile-mode past
few days"):
> spwhitton@chiark:~/tmp>dgit clone dockerfile-mode
> canonical suite name for unstable is sid
> fetching existing git history
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> dgit: failed command: git ls-remote -q --refs
> https://git.dgit.debian.org/dockerfile-mode 'refs/tags/archive/debian/*'
> 'refs/tags/debian/*' refs/dgit/sid refs/dgit-rewrite/map
>
> dgit: error: subprocess failed with error exit status 128
> 255 spwhitton@chiark:~/tmp>
>
> I was able to successfully dgit push the package, after doing an
> import-dsc for the purposes I wanted to fetch.
It seems to be working now. I'm afraid going to close this bug
without doing much else.
In the future, a DSA ticket is probably more helpful. I don't think
DSA are aware of the frequency of these problems.
As a workaround, when this happens, "dgit --for-push clone" is
very likely to work, since it goes to the underlying git server via
ssh, rather than the public mirror via the git protocol.
I guess we could change dgit to suggest filing a DSA ticket...
Sorry,
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#933044: dgit: should not require --overwrite when debian/changelog contains the version in unstable
> --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
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
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
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
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
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
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)
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
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.
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.
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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]
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
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
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
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
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
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.
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.
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.
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.
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
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.
