Bug#1039889: recommends old ffmpeg libs
On Fri, 16 Feb 2024, Phillip Berndt wrote: > this probably got lost. Could you build & upload the package, please? I'm building eac4ec8f7d20c9525a1a5fa0a25f86cde4b15f88 [what's currently in the debian/sid branch on salsa.debian.org:pberndt-guest/pqiv.git, right? > I double checked, the package still builds without warning (except for > one complaint by groff about the manpage, which I think we can live > with and which I'll fix upstream for the next releast). Sounds good. -- Don Armstrong https://www.donarmstrong.com Fate and Temperament are two words for one and the same concept. -- Novalis [Hermann Hesse _Demian_]
Bug#1061240: bugs.debian.org: ALSA don't recognize Mackie ProFxV3 USB sound cards since 5.10 linux kernel
Control: reassign -1 linux bugs.debian.org is for issues with the bug tracking system, not issues with the linux Kernel. On Sun, 21 Jan 2024, Olivier Delemar wrote: > The Mackie ProFX16 is a mixer with a 2x4 USB interface. When I plug it on my > computer, kern.log reports : [...] > I've tried genuine debian kernel also and notice no differences regarding this > bug compared to the Librazik custom kernel. Please run it with a recent Debian kernel and include the version number (and any other details from lsusb -v), and include those details in the bug. [I don't know enough of the sound subsystem details to be of much more help, sorry.] -- Don Armstrong https://www.donarmstrong.com He no longer wished to be dead. At the same time, it cannot be said that he was glad to be alive. But at least he did not resent it. He was alive, and the stubbornness of this fact had little by little begun to fascinate him -- as if he had managed to outlive himself, as if he were somehow living a posthumous life. -- Paul Auster _City of Glass_
Bug#1058696: bugs.debian.org: Can we change the mail address of the release.debian.org pseudo package?
On Tue, 19 Dec 2023, Cord Beermann wrote: > So I need some examples. :0 * 1^0 ^X-Debian-PR-Package:.*release.debian.org $junkdir/debbugs.$YEARMONTH should be sufficient to get most (if not all of them). -- Don Armstrong https://www.donarmstrong.com Whatever you do will be insignificant, but it is very important that you do it. -- Mohandas Karamchand Gandhi
Bug#1058696: bugs.debian.org: Can we change the mail address of the release.debian.org pseudo package?
On Sat, 16 Dec 2023, Cord Beermann wrote: > However: if we implement this, i'd consider this as a workaround as > mails that should not be distributed, should not be sent out in the > first place. That works for me; there's a missing feature in the BTS currently to turn off e-mails to maintainers, so when that is in place, this workaround can be removed. -- Don Armstrong https://www.donarmstrong.com For a moment, nothing happened. Then, after a second or so, nothing continued to happen. -- Douglas Adams
Bug#1058696: bugs.debian.org: Can we change the mail address of the release.debian.org pseudo package?
On Thu, 14 Dec 2023, Paul Gevers wrote: > Does it make sense to you to use the tracker as the canonical point > where e-mail is send, it's already send there anyways? I'm OK with sending the e-mail wherever y'all would like it. I'm also OK if debian-rele...@lists.debian.org is kept as the "maintainer" but bug email for the release.debian.org pseudopackage is discarded by lists.debian.org. [listmaster can do this with a procmail rule on lists.debian.org.] The advantage of the procmail rule is that someone looking to get in contact with the release team won't accidentally send their e-mail to a mailbox which no one ever will look at. But at the end of the day, it's up to y'all. -- Don Armstrong https://www.donarmstrong.com "She decided what she wished to happen and then assumed that reality would bend to her wishes." [...] "Reality doesn't indulge wishes." -- Terry Goodkind _Phantom_ p133
Bug#1035044: autorandr: libinput-tools still missing in autorandr dependencies list?
On Sat, 09 Dec 2023, Allan Olsen wrote: > Dec 08 22:44:15 Innerpeace systemd[1]: Started autorandr-lid-listener.service > - Runs autorandr whenever the lid state changes. > Dec 08 22:44:15 Innerpeace autorandr[61889]: stdbuf: failed to run command > ‘libinput’: No such file or directory > Dec 08 22:44:15 Innerpeace systemd[1]: autorandr-lid-listener.service: > Deactivated successfully. > Dec 08 22:44:45 Innerpeace systemd[1]: autorandr-lid-listener.service: > Scheduled restart job, restart counter is at 1832. > > seems like for now autorandr only have two dependencies > Depends: x11-xserver-utils, python3 > > After I installed libinput-tools Messages are gone. Heh; thanks for the report. I added the lid-listener.service in 1.14-1, and didn't check for new dependencies. I'll have this fixed up in 1.14-2 once I upload it. -- Don Armstrong https://www.donarmstrong.com I'm wrong to criticize the valor of your brave men. It's important to die for one's country when it means being the subject of a king who wears a ruffled collar or a pleated one. -- Cyrano de Bergerac
Bug#1056966: autorandr: Delegate udev rules install location to udev.pc
On Mon, 27 Nov 2023, Chris Hofstaedtler wrote: > thanks for applying the patches from #1054477. I have now noticed that > autorandr hard-codes the udev rules directory to /lib/udev/rules.d. > I'm attaching a patch which delegates the path decision to udev.pc, > merely by removing the argument to make. > > In the near future udev.pc will change the path to > /usr/lib/udev(/rules.d), and then your package can pick this up in a > binNMU without further changes. Thanks for the patch, I'll apply it shortly and upload it the next time I do an upload (or when the udev rules change happens, whatever is earlier). -- Don Armstrong https://www.donarmstrong.com Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. -- Richard Feynman "What is and What Should be the Role of Scientific Culture in Modern Society"; 1964
Bug#1041491: (no subject)
I'm just reiterating the conversation I had with Santiago for transparency and to explain what happened here: This bug was originally tagged with "sid trixie". This means that the for the purposes of archival, the BTS only needs to care if the bug has been fixed in sid and trixie, and it should ignore whether it should be fixed in bookworm. When the bug was fixed in sid and trixie, the BTS archived it. You rarely want to tag a bug with any of the distribution tags. [The major exception is where a bug is present in a distribution because of the versions of other packages in that distribution, not latently present in the package itself, for example when an interface is deprecated/removed.] -- Don Armstrong https://www.donarmstrong.com This isn't life in the fast lane, it's life in the oncoming traffic -- Terry Pratchett
Bug#1054477: autorandr: install autorandr.service twice once dh_installsystemd installs to /usr
On Fri, 27 Oct 2023, Helmut Grohne wrote: > On Tue, Oct 24, 2023 at 10:08:00AM +0200, Helmut Grohne wrote: > > We want to change dh_installsystemd such that it installs units below > > /usr in order to finalize the /usr-merge transition via DEP17. When > > doing so, autorandr happes to install the upstream unit (via > > dh_auto_install) below /lib and debian/autorand.service (via > > dh_installsystemd) below /usr/lib. Doing so is a policy violation and > > this bug will become release critical once I upload debhelper. I'm > > attaching a patch that disables the installation of the upstream unit. > > Once you go back to the upstream unit, please leave SYSTEMD_UNIT_DIR > > unset, because it'll then pick up the right value from pkgconfig and > > dh_installsystemd now supports generating maintainer scripts from both > > locations. > > Jochen Sprickerhof made me aware that my original patch changes the udev > rules file and breaking it in that way, because systemd is removed from > TARGETS in Makefile. I'm attaching an updated patch to avoid this > unintentional issue. Thanks for the attention to detail. Thanks for all of the patches! My current plan is to add the build-dependencies so the pkg-config bits work correctly and then just remove the manual setting of the systemd configuration line, so when you do the switch, the build will just happen correctly. [The upstream systemd service is now in pretty good shape, so there's no point in keeping the Debian specific version any more.] -- Don Armstrong https://www.donarmstrong.com I cannot find rest Because I am powerless To amend a broken world. -- Guy Gavriel Kay _Under Heaven_ p295
Bug#1053174: Block Ben Tris
On Thu, 28 Sep 2023, Christoph Berg wrote: > we keep seeing non-actionable bug reports from Ben Tris that look like > this: Hi Ben, please don't file bugs like this which aren't actionable. If you find something minor wrong with a package like this, please provide a patch so that maintainers can see what you think is wrong and how they should fix it. It looks like you've closed the non-actionable bugs that you had filed, so I won't immediately be putting in a block for you, but if it happens again, I will. Thanks! -- Don Armstrong https://www.donarmstrong.com Thanks be to God, that he gave me Stubbornness, when I know I am right. -- John Adams (Letter to Edmund Jennings, 27 September 1782)
Bug#1052624: debbugs: forwarded messages break DMARC, DKIM, SPF
Control: reassign -1 bugs.debian.org Cotnrol: forcemerge 830865 754809 -1 On Mon, 25 Sep 2023, Jonathan Kamens wrote: > The most obvious solution to this is straightforward: the From line in > these messages should be modified to contain the email address of the > bug, not the email address of the original sender. The original > sender's address can be put in Reply-To and/or indicated in the header > in a number of other ways. For example, sometimes something like this > is done: The problem with this specific From-rewriting is that it breaks replying to the sender instead of just the bug (though maybe that's not a huge deal). Ideally we'd be able to oversign the messages, but DMARC and DKIM weren't engineered to allow that. I've personally been ignoring it because I've been hoping that the standards would get fixed, but if it's impacting enough Debian contributors to matter, I don't mind accepting a patch. -- Don Armstrong https://www.donarmstrong.com It was said that life was cheap in Ankh-Morpork. This was, of course, completely wrong. Life was often very expensive; you could get death for free. -- Terry Pratchet _Pyramids_ p25
Bug#1050915: truncate unsigned parts of signed mails to d-d-a
severity -1 wishlist thanks On Thu, 31 Aug 2023, Lee Garrett wrote: > currently, when using Thunderbird to send OpenPGP/MIME signed mails to > d-d-a, the mail gets silently blackholed (#1050906). It seems like the > reason is that there is a small piece of text before the actual > MIME-encoded data: > > "This is an OpenPGP/MIME signed message (RFC 4880 and 3156)" > > Would be nice if the tool in question could just truncate the unsigned bits > instead and accept the mail, assuming there's a valid signature. The problem there is that we would break DKIM or oversigning of the mail message if we stripped that out. [It also adds a whole bit of complicated code to the signature verification tool which is likely to be wrong.] The real fix is for thunderbird to stop adding unsigned text before the actual mime encoded data. It doesn't add any value whatsoever. [It's one of the only e-mail clients which does this that I'm aware of.] -- Don Armstrong https://www.donarmstrong.com Thanks be to God, that he gave me Stubbornness, when I know I am right. -- John Adams (Letter to Edmund Jennings, 27 September 1782)
Bug#999953: sslh: depends on obsolete pcre3 library
On Tue, 15 Aug 2023, Bastian Germann wrote: > I am uploading a NMU to fix this. That's not the correct fix; the correct fix is to use pcre2 instead of pcre3. I've already got a patch for it available. but apparently I haven't pushed it to salsa; sorry about that. The reason why I haven't uploaded it yet is because the tests for 1.22c do not succeed. -- Don Armstrong https://www.donarmstrong.com Let the victors, when they come, When the forts of folly fall Find thy body by the wall! -- Matthew Arnold
Bug#1041638: bugs.debian.org: the b.d.o mail sofware doesn't parse the "To:" header correctly, generating incorrect addresses
Control: retitle -1 RFC1522 parsing doesn't re-escape commas Thanks for the report. On Fri, 21 Jul 2023, Vincent Lefevre wrote: > For bug 1041631, I replied to a mail, and the headers were: [...] > To: =?iso-8859-1?Q?Preu=DFe=2C?= Hilmar [...] > To: =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org, > ?= Hilmar It failed the comma and then went through address expansion. For future me: the test for this should be that: From: =?UTF-8?B?UHJldcOfZSwgSGlsbWFy?= gets round tripped to the same (or uses quotation marks to escape the comma). [Use a different address in testing.] -- Don Armstrong https://www.donarmstrong.com "I always tend to assume there's an infinite amount of money out there." "There might as well be, [...] but most of it gets spent on pornography, sugar water, and bombs. There is only so much that can be scraped together for particle accelerators." -- Neal Stephenson _Anathem_ p262
Bug#1039889: recommends old ffmpeg libs
On Sat, 01 Jul 2023, Phillip Berndt wrote: > **Don**, what are the right next steps here? There's also a yet > unreleased, automated standard update change > > https://salsa.debian.org/pberndt-guest/pqiv/-/commit/a34f138c5f516ca2953c8151ca3fb806123ec043 > > I assume I'll have to update UNRELEASED to unstable, and then you > issue a build on 2.12-2? Yep! Once you're happy with the state of the git tree, let me know, and I can build it and do an upload. [We can also request a rebuild of a package, but since there are source changes, we might as well do that.] -- Don Armstrong https://www.donarmstrong.com [On a trip back from collecting grass seeds in tropical bird stomachs and being thought by the customs agents to be transporting Marijuana.] "Anyone so square as to tell you they are transporting grass seeds is bound to be OK" -- Peter K. Klopfer _Seeds of Doubt_ Science 134:177 10 April 2009
Bug#1038415: Source present upstream, but not in .tar.gz
Package: perltidy Version: 20230309-1 Severity: important The source for a number of documentation files is present upstream here: https://github.com/perltidy/perltidy but not distributed in the .tar.gz or in Debian. Running lintian... E: perltidy source: source-is-missing [docs/BugLog.html] E: perltidy source: source-is-missing [docs/Tidy.html] E: perltidy source: source-is-missing [docs/perltidy.html] E: perltidy source: source-is-missing [docs/tutorial.html] This should get fixed upstream. -- Don Armstrong https://www.donarmstrong.com "She decided what she wished to happen and then assumed that reality would bend to her wishes." [...] "Reality doesn't indulge wishes." -- Terry Goodkind _Phantom_ p133
Bug#1036574: Unable to change submitter to addresses with non-7 bit characters
Package: debbugs
Severity: normal
Version: 2.6.0
On Sat, 20 May 2023, José Luis González wrote:
> I'm trying to change the email address of my old reports to my current
> one but control is rejecting. It incorrectly claims my address is not
> valid.
>
> I suspect the problem is there's now an issue with ! either when the
> From is not just an address but in the form Name , or Name has
> non-ascii characters. This used to be perfectly fine.
Yeah, the issue is a bug in debbugs; we don't encode the e-mail address
before we check for its validity.
not Mail::RFC822::Address::valid($param{submitter}) should read
not Mail::RFC822::Address::valid(encode_rfc1522($param{submitter}))
Thanks for the report.
--
Don Armstrong https://www.donarmstrong.com
If I had a letter, sealed it in a locked vault and hid the vault
somewhere in New York. Then told you to read the letter, thats not
security, thats obscurity. If I made a letter, sealed it in a vault,
gave you the blueprints of the vault, the combinations of 1000 other
vaults, access to the best lock smiths in the world, then told you to
read the letter, and you still can't, thats security.
-- Bruce Schneier
Bug#1035044: autorandr: recommend libinput-tools missing
On Fri, 28 Apr 2023, Frank Scherrer wrote: > Change of Displays Configuration > >* Additional Info apart from default questions > > Systemd-Service autorandr-lid-listener failed with error: > In the journal of autorandr-lid-listener I found > > autorandr[51936]: stdbuf: failed to run command ‘libinput’: No such file or > directory We currently aren't distributing (or installing) autorandr-lid-listener in the Debian package. That said, we probably should; so I'll add this as a depends. Thanks for the report. -- Don Armstrong https://www.donarmstrong.com Fate and Temperament are two words for one and the same concept. -- Novalis [Hermann Hesse _Demian_]
Bug#993314: User-level systemd unit for autorandr
Control: tag -1 moreinfo You should be able to enable the system-wide unit for a user by using something like the following: systemctl --user enable /lib/systemd/system/autorandr.service That said, the system-wide one is supposed to work. Can you give some details on why autorandr --batch might not be working for your setup? [It works for mine, though I am using xdm with .xsession instead of startx or whatever you're doing.] Thanks! -- Don Armstrong https://www.donarmstrong.com "The trouble with you, Ibid" he said, "is that you think you're the biggest bloody authority on everything" -- Terry Pratchet _Pyramids_ p146
Bug#1017144: Forcing a rebuild of index.db for these bugs
Control: tag -1 newcomer Control: tag -1 - newcomer I'm tagging and untagging these bugs (using newcomer because it's rarely used) to force a rebuild of index.db. -- Don Armstrong https://www.donarmstrong.com "There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself." -- Bach
Bug#1034564: debbugs: "There is no record of Bug" after getting confirmation e-mail
Control: reassign -1 bugs.debian.org Control: forcemerge 1021304 -1 On Tue, 18 Apr 2023, Askar Safin wrote: > I just reported bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034563 > . > > After some minutes I got confirmation e-mail titled "Bug#1034563: > Acknowledgement (login: "su" doesn't put /sbin and /usr/sbin to PATH)" > > This e-mail contained a link " https://bugs.debian.org/cgi- > bin/bugreport.cgi?bug=1034563 " There's a short delay between a bug being filed and the bug being distributed to the frontends. It's known, it's short, and it only happens on new bugs. -- Don Armstrong https://www.donarmstrong.com I finally developed a computer with feelings. It just doesn't have feelings for me. -- a softer world #633 http://www.asofterworld.com/index.php?id=633
Bug#1033206: Subject: in submit@ mails is /always/ changed before forwarding, but not re-DKIM-signed ‒ please add ARC signatures?
Control: tag -1 wontfix Control: retitle -1 Add ARC signatures to outgoing mail On Sun, 19 Mar 2023, наб wrote: > This is slightly similar to #838601 (but I can't repro that particular > issue, since my MUA encodes in UTF-8) and #804421 (but that's wider). > > Every time I submit a bug, I get at least one forensic report from > strikemail now. This has started to happen on the 28th of February, > so I'm assuming some strikemail user subscribed to the distro list. Thanks for the report; I've unsubscribed the user in question. As far as ARC signing, because it's not widely supported (the RFC is still experimental) it's unlikely to fix this particular issue. [Once it is more widely supported, I wouldn't be against adding support, but I don't think it's worth the effort now.] If we want to support DKIM we're going to have to do from rewriting, and I've been resisting doing that for a while. -- Don Armstrong https://www.donarmstrong.com "You have many years to live--do things you will be proud to remember when you are old." -- Shinka proverb. (John Brunner _Stand On Zanzibar_ p413)
Bug#1031196: spamass-milter: 'Could not retrieve sendmail macro "b"' with postfix: PATCH
Control: tag -1 moreinfo - patch
On Mon, 13 Feb 2023, none wrote:
> In this patch I've included a fix for this problem, which includes a
> new option for the /etc/default config. By default it is commented out
> so that the behaviour doesn't change.
>
> This introduces the -Y command line flag for "postfix compatibility
> mode" which explicitly sets default values for macros which postfix
> doesn't support, or doesn't support in the ENVRCPT context.
It's not clear to me why we'd add this flag. If the macros aren't
supported, the code already falls back to reasonable defaults. The only
change this seems to make is to silence warnings (and breaks the macros
that postfix already supports).
Am I missing something?
> You only see the 'b' macro and never the '{auth_type}' macro failing
> because 'b' is requested first.
That's because warnmacro only warns on the first warning. You're
probably missing the correct configuration in your main.cf:
# spamass-milter configuration
smtpd_milters = unix:/spamass/spamass.sock
# milter macros useful for spamass-milter
milter_connect_macros = j {daemon_name} v {if_name} _
milter_data_macros = j i {auth_type} {daemon_name} v {if_name} _
milter_rcpt_macros = j {auth_type} {daemon_name} v {if_name} _
--
Don Armstrong https://www.donarmstrong.com
Taxes are not levied for the benefit of the taxed.
-- Robert Heinlein _Time Enough For Love_ p250
Bug#1028388: Splitting 1028388 into separate issues
Control: clone 1028388 -1 Control: summary 1028388 rsyslog init script distributed by orphan-sysvinit-scripts doesn't work in some (?) cases. Control: reassign -1 rsyslog Control: retitle -1 Please restore the init script for ad-hocery, tests, etc. Control: tag -1 wontfix Control: severity -1 wishlist Control: summary -1 rsyslog no longer distributes an init script; maintainer declines to reintroduce the init script. Control: close -1 With the owner@ hat on: This looks like two separate issues. 1) rsyslog doesn't provide the init script any more, which is totally up to the maintainer (Michael Biebl) unless overridden by the TC. That bug (-1) can be left wontfix, wishlist, and closed. Please do not reopen it without a TC or RM decision.[1] 2) The init script distributed by orphan-sysvinit-scripts doesn't work in some (?) cases. This should be fixed (or otherwise handled) by the maintainer(s) of orphan-sysv-init scripts. [Further messages sent privately to affected individuals.] 1: Probably didn't need to clone it, but I wanted to be clear for everyone. -- Don Armstrong https://www.donarmstrong.com "Old hypotheses never really die, they're like dormant volcanoes." -- John McPhee _Annals of the Former World_ p313
Bug#1030632: bugs.debian.org: cannot select picture from a local directory to use as desktop background in kde plasma
Control: reassign -1 kde-plasma-desktop My guess is that this has something to do with kde-plasma-desktop, but you're going to need to provide more information about which window manager you're using, what version it is, and what you've most recently installed. [You've assigned this bug to bugs.debian.org, which is for bugs in our bug tracking system, not a general catch-all bug location.] -- Don Armstrong https://www.donarmstrong.com "You know," said Arthur, "it's at times like this, when I'm trapped in a Vogon airlock with a man from Betelgeuse, and about to die from asphyxiation in deep space that I really wish I'd listened to what my mother told me when I was young." "Why, what did she tell you?" "I don't know, I didn't listen." –- Douglas Adams _The Hitchhikers Guide To The Galaxy_
Bug#1029597: Login is broken and URLs do not work
On Wed, 25 Jan 2023, William Desportes wrote: > I suggested a FTP RM that was refused for now: #1028968 Thanks for the report; I agree with the removal. [Note for future, the right approach is to file a bug against the package first before requesting removal.] -- Don Armstrong https://www.donarmstrong.com The smallest quantity of bread that can be sliced and toasted has yet to be experimentally determined. In the quantum limit we must necessarily encounter fundamental toast particles which the author will unflinchingly designate here as "croutons". -- Cser, Jim. Nanotechnology and the Physical Limits of Toastability. AIR 1:3, June, 1995.
Bug#1028968: Remove fetchyahoo; no longer working
Control: retitle -1 RoM: remove fetchyahoo from the archive Control: reopen -1 I'm personally no longer using this code, and since it's not working (and has been abandoned by upstream), lets get it out of Debian. -- Don Armstrong https://www.donarmstrong.com First you take a drink, then the drink takes a drink, then the drink takes you. -- F. Scott Fitzgerald
Bug#1029616: perltidy: please package upstream 20221112 release
Thanks, Phil! Let me look into these and see if I can address them in a new version. -- Don Armstrong https://www.donarmstrong.com No matter how many instances of white swans we may have observed, this does not justify the conclusion that all swans are white. -- Sir Karl Popper _Logic of Scientific Discovery_
Bug#1021304: bugs.debian.org: "There is no record of Bug #..."
Control: retitle -1 delay in mirroring new bugs from buxtehude to bembo Control: severity -1 minor On Wed, 05 Oct 2022, Piotr Engelking wrote: > Please only send acknowledgement mail and display the bug in > pkgreport.cgi after the bug is visible in bugreport.cgi. That's happening because there is a mirror and it takes some time for totally new bugs to be picked up by the mirror script and transferred; that particular part uses polling. Existing bugs transfer relatively quickly as they use inotify. There's some optimization here to speed up poling for new bugs (or maybe automatically triggering new bugs into the mirror script), but it's "working as designed". -- Don Armstrong https://www.donarmstrong.com If you wish to strive for peace of soul, then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche
Bug#568230: bugs.debian.org: "forwarded" tags should gracefully ignore line breaks
On Mon, 19 Sep 2022, fab...@greffrath.com wrote: > On Wed, 3 Feb 2010 11:09:22 -0800 Don Armstrong wrote: > > > On Wed, 03 Feb 2010, Fabian Greffrath wrote: > > > The reason is that my mail client breaks lines if they are longer > > > than 70 characters. > > > > If your mail client is unable to send messages with long lines, your > > mail client is fundamentally broken. > > > > If you don't want to fix your MUA, use the bts command line tools > > instead. > > Could this sentiment probably get reconsidered? The problem is that there is no easy way for the bug tracking system to reliably know whether the next line is part of the previous line or a new line. For example if you wanted to retitle a bug like so: retitle 1234 this bug demonstrates broken forwarded data: forwarded 1235 https://foo should that look like this: retitle 1234 this bug demonstrates broken forwarded data: forwarded 1235 https://foo We probably could support a line continuation escape (like \), but that would require a bit of a change management process to enable. Eventually we'll get around to supporting modifying things using a UI to generate mail, which will fix this problem. [Maybe in another 10 years at this rate?] -- Don Armstrong https://www.donarmstrong.com But if, after all, we are on the wrong track, what then? Only disappointed human hopes, nothing more. And even if we perish, what will it matter in the endless cycles of eternity? -- Fridtjof Nansen _Farthest North_ p152
Bug#1017646: Interest in a Possible Patch
Control: tag -1 patch pending On Mon, 19 Sep 2022, Soren Stoutner wrote: > I recently posted in the debian-kde list about packaging the Qt WebEngine > dictionaries to > see if there was any preference about how they should be named or where the > files should > be located. So far there have not been any comments. > > https://lists.debian.org/debian-kde/2022/09/msg00011.html[1] > > If you would like I could attempt to create a patch to enable the building of > these files. I > am new to Debian packaging, but I have been reading over the documentation > and have > some idea of how to put it together. Since the files in question are small, I think just including them and appropriate symlinks should be sufficient. Here's the patch which does that. -- Don Armstrong https://www.donarmstrong.com If I had a letter, sealed it in a locked vault and hid the vault somewhere in New York. Then told you to read the letter, thats not security, thats obscurity. If I made a letter, sealed it in a vault, gave you the blueprints of the vault, the combinations of 1000 other vaults, access to the best lock smiths in the world, then told you to read the letter, and you still can't, thats security. -- Bruce Schneier diff --git a/debian/changelog b/debian/changelog index 2ed6c73..6da3cfc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +scowl (2020.12.07-3) unstable; urgency=medium + + * Include hunspell .bdic files (for qtwebengine and others). (Closes: +#1017646) Thanks to Soren Stoutner. + + -- Don Armstrong Mon, 19 Sep 2022 16:19:57 -0700 + scowl (2020.12.07-2) unstable; urgency=medium * Separate uniqifying from sort; users (and other plurals with diff --git a/debian/control b/debian/control index 89ad062..58aa8ac 100644 --- a/debian/control +++ b/debian/control @@ -4,7 +4,7 @@ Section: text Priority: standard Standards-Version: 4.1.4 Build-Depends: debhelper (>= 12) -Build-Depends-Indep: dictionaries-common-dev, dos2unix, aspell +Build-Depends-Indep: dictionaries-common-dev, dos2unix, aspell, qtwebengine5-dev-tools, libqt5webengine-data Homepage: http://wordlist.sourceforge.net/ Vcs-Browser: https://git.donarmstrong.com/deb_pkgs/scowl.git Vcs-Git: https://git.donarmstrong.com/deb_pkgs/scowl.git diff --git a/debian/hunspell-en-au.install b/debian/hunspell-en-au.install index 2431636..00d9a6a 100644 --- a/debian/hunspell-en-au.install +++ b/debian/hunspell-en-au.install @@ -1,3 +1,4 @@ ./speller/en_AU.aff usr/share/hunspell ./speller/en_AU.dic usr/share/hunspell +./speller/en_AU.bdic usr/share/hunspell diff --git a/debian/hunspell-en-au.links b/debian/hunspell-en-au.links new file mode 100644 index 000..80f3a6e --- /dev/null +++ b/debian/hunspell-en-au.links @@ -0,0 +1,2 @@ +usr/share/hunspell/en_AU.bdic usr/share/qt5/qtwebengine_dictionaries/en_AU.bdic +usr/share/hunspell/en_AU.bdic usr/share/qt6/qtwebengine_dictionaries/en_AU.bdic diff --git a/debian/hunspell-en-ca.install b/debian/hunspell-en-ca.install index b564b3c..f645db0 100644 --- a/debian/hunspell-en-ca.install +++ b/debian/hunspell-en-ca.install @@ -1,3 +1,4 @@ ./speller/en_CA.aff usr/share/hunspell ./speller/en_CA.dic usr/share/hunspell +./speller/en_CA.bdic usr/share/hunspell diff --git a/debian/hunspell-en-ca.links b/debian/hunspell-en-ca.links new file mode 100644 index 000..be369a0 --- /dev/null +++ b/debian/hunspell-en-ca.links @@ -0,0 +1,2 @@ +usr/share/hunspell/en_CA.bdic usr/share/qt5/qtwebengine_dictionaries/en_CA.bdic +usr/share/hunspell/en_CA.bdic usr/share/qt6/qtwebengine_dictionaries/en_CA.bdic diff --git a/debian/hunspell-en-us.install b/debian/hunspell-en-us.install index 54f004b..b0b0a2c 100644 --- a/debian/hunspell-en-us.install +++ b/debian/hunspell-en-us.install @@ -1,3 +1,4 @@ ./speller/en_US.aff usr/share/hunspell ./speller/en_US.dic usr/share/hunspell +./speller/en_US.bdic usr/share/hunspell diff --git a/debian/hunspell-en-us.links b/debian/hunspell-en-us.links new file mode 100644 index 000..68e537e --- /dev/null +++ b/debian/hunspell-en-us.links @@ -0,0 +1,2 @@ +usr/share/hunspell/en_US.bdic usr/share/qt5/qtwebengine_dictionaries/en_US.bdic +usr/share/hunspell/en_US.bdic usr/share/qt6/qtwebengine_dictionaries/en_US.bdic diff --git a/debian/patches/ignore_bdic b/debian/patches/ignore_bdic new file mode 100644 index 000..10e7da2 --- /dev/null +++ b/debian/patches/ignore_bdic @@ -0,0 +1,7 @@ +--- a/speller/.gitignore b/speller/.gitignore +@@ -19,3 +19,4 @@ + aspell/Copyright + aspell/doc/SCOWL-README + *.txt ++*.bdic diff --git a/debian/patches/series b/debian/patches/series index 6c3365e..7fe8864 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -4,3 +4,4 @@ move_sangs_to_insane deprecate_reprized hunspell_size_70 fix_hunspell_affix +ignore_bdic diff --git a/debian/rules b/debian/rules index a72a41e..a9e36b7 100755 --- a/debian/rules +++ b/debian/rules @@ -59,6 +59,10 @@
Bug#1019651: "Control: fixed ..." not working
On Sat, 17 Sep 2022, Paul Wise wrote: > On Fri, 16 Sep 2022 17:07:55 -0700 Don Armstrong wrote: > > Yes, that's correct; the processing for nnn-done@ doesn't do Control: > > processing. > > People often think that it does, don't notice that it doesn't and then > bugs don't get updated properly. I have seen this a number of times. > > Personally I think it happens often enough that it would be worth > making it work in nnn-done@ messages also, to avoid this problem. The main reason why it's not supported is because of the effort required to handle nnn-done@ in scripts/process rather than a principled objection to it. [My main goal was to support Control: at submit@ time where it's critical; support of nnn@ was an added benefit.] -- Don Armstrong https://www.donarmstrong.com No matter how many instances of white swans we may have observed, this does not justify the conclusion that all swans are white. -- Sir Karl Popper _Logic of Scientific Discovery_
Bug#1017646: scowl: Ship qtwebengine-dictionary binaries
On Thu, 18 Aug 2022, Soren Stoutner wrote: > I thought about creating a separate source package for this, but it > seems to make more sense to me to include this as separate binaries in > the current scowl package. I am willing to submit a patch and assist > with maintining it over time if you would like. Yeah, this should definitely be a patch to produce the additional binary packages [or potentially, the existing binary packages can produce the combined dictionary files, depending on the relative sizes.] Is there a naming convention for these packages already? Thanks! -- Don Armstrong https://www.donarmstrong.com Live and learn or die and teach by example -- a softer world #625 http://www.asofterworld.com/index.php?id=625
Bug#1011467: perltidy: Newer upstream release available
On Mon, 23 May 2022, gregor herrmann wrote: > Could you upgrade the package to 20220217 and/or shall we move it to > the Debian Perl Group? I'm happy with either. It's pretty trivial to package new releases (though I probably won't get to this one until tomorrow). -- Don Armstrong https://www.donarmstrong.com Love is... a complex sequence of neurochemical reactions that makes people behave like idiots. It's similar to intoxication, but the hangover's even worse. -- J. Jacques _Questionable Content_ #1039 http://www.questionablecontent.net/view.php?comic=1039
Bug#1010039: autorandr: python deprecation warnings
Control: tag -1 fixed-upstream Control: forwarded -1 https://github.com/phillipberndt/autorandr/issues/266 On Sat, 23 Apr 2022, gregor herrmann wrote: > Looks like autorandr needs an update for compatibility with future > python versions: > > % autorandr > /usr/bin/autorandr:42: DeprecationWarning: The distutils package is > deprecated and slated for removal in Python 3.12. Use setuptools or check PEP > 632 for potential alternatives > from distutils.version import LooseVersion as Version Thanks for the report! Looks like upstream has fixed this, so I just need to upgrade to the newest version. -- Don Armstrong https://www.donarmstrong.com After the first battle of Sto Lat, I formulated a policy which has stood me in good stead in other battles. It is this: if an enemy has an impregnable stronghold, see he stays there. -- Terry Pratchett _Jingo_ p265
Bug#1009181: File suffix for message mbox links should be .eml
On Fri, 08 Apr 2022, Max Nikulin wrote: > Notice that the default file name to save the message has ".mbox" > suffix while freedesktop mime database entry assumes ".eml" for the > "message/rfc822" mime type: > https://sources.debian.org/src/shared-mime-info/1.10-1/freedesktop.org.xml.in/#L5466 > As a result if "message/rfc822" mime type is associated with > thunderbird.desktop file then the application starts composition of a > new message with the .mbox file as attachment instead of displaying > the downloaded message. > I have not managed to convince thunderbird developers that there > should be a way to tell the application that some file should be > opened namely as a message no matter what is the name and the > extension of the file. They believe that current heuristics is correct > and ".mbox" suffix means collection of messages in "application/mbox" > mail box. Thunderbird does not support opening a mbox file outside of > its mail directories. The only real difference between a single message in an mbox and a complete mbox is From escaping. Debbugs is probably technically incorrect, because we do From escaping even if we're returning just a single message, so we're actually returning an application/mbox instead of a message/rfc822. Frankly, using the extension to determine mime time is bad practice, but it's a common bad practice. I've no objection to changing the default extension; I personally wasn't aware of the eml extension when I wrote that part of the code. We should also not do From escaping when we're just returning a single message. -- Don Armstrong https://www.donarmstrong.com The terrorist's job is to terrorize the people, to interfere with freedom in such a way that disrupts ordinary life and commerce. With due respect, it is clear that the above referenced governmental agencies are aiding the terrorists' objective. -- Gary Fielder in Gary Fielder vs Janet Napolitano et al.
Bug#927012: Redesign of libravatar.cgi and testing
On Fri, 08 Apr 2022, Oliver Falk wrote: > When I checked it yesterday, the script was still called with the mail > address !? The script is, but libravatar and gravatar are no longer called with the mail address; they're all using the md5 of the e-mail address now. [The script caches responses from libravatar and gravatar and serves them directly, so there's limited leakage of information on who is visiting a specific page.] > Let me know if I can help you in some way, I'm happy to do so if I > know what exactly is required. Thanks! To be honest, I haven't looked at the issue recently, so I'll have to dig in to see what was failing. [It's probably time to just have it use mod_perl directly instead of the CGI-based mod_perl.] -- Don Armstrong https://www.donarmstrong.com If you wish to strive for peace of soul, then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche
Bug#927012: Redesign of libravatar.cgi and testing
The basic code is working, but we were having performance issues which is why it was disabled on bugs.debian.org. I haven't had a chance to dig into exactly why it was failing, though now that everything is using md5sum of the e-mail addresses, I think the privacy concerns that were mentioned previously have been addressed. It's not super high on my priority list to fix, but I'll try to get to it when I have some time. -- Don Armstrong https://www.donarmstrong.com "You know," said Arthur, "it's at times like this, when I'm trapped in a Vogon airlock with a man from Betelgeuse, and about to die from asphyxiation in deep space that I really wish I'd listened to what my mother told me when I was young." "Why, what did she tell you?" "I don't know, I didn't listen." –- Douglas Adams _The Hitchhikers Guide To The Galaxy_
Bug#1007106: reportbug: please make the meaning of the a11y tag clearer
On Sat, 19 Mar 2022, Nis Martensen wrote: > On 14.03.2022 22.06, Don Armstrong wrote: > > On Mon, 14 Mar 2022, Simon McVittie wrote: > >> Please could the BTS owners provide or approve a clearer wording for > >> this, if they are the "owners" of the tag definition? > > > > I'd like if it includes "accessibility" in the language (so someone can > > figure out why it's called a11y), but I'm happy with any language that > > are acceptable to advocates and the community affected by these issues. > > Something like this? > > "This bug affects accessibility to users with disabilities. It > particularly impacts usability by people who rely on assistive (or other > adaptive) technology to use the system/package." That works for me! [Feel free to modify the appropriate pages and packages; I don't believe that requires any one from owner@ to do that.] - Don Armstrong https://www.donarmstrong.com We must realize that today's Establishment is the New George III. Whether it will continue to adhere to his tactics, we do not know. If it does, the redress, honored in tradition, is also revolution. -- William O. Douglas _Points of Rebellion_
Bug#1007106: reportbug: please make the meaning of the a11y tag clearer
On Mon, 14 Mar 2022, Simon McVittie wrote: > Please could the BTS owners provide or approve a clearer wording for > this, if they are the "owners" of the tag definition? [...] I'm open to any inclusive language which you all agree on. The point of the tag was to help highlight bugs which impacted the usability of an application by someone who was using assistive (or other adaptive) technology to use an application/package/system. [So things like screen readers, dyslexia fonts, braille ttys, predictive input devices, etc. (definitely not an exclusive list of categories, of course).] I'd like if it includes "accessibility" in the language (so someone can figure out why it's called a11y), but I'm happy with any language that are acceptable to advocates and the community affected by these issues. -- Don Armstrong https://www.donarmstrong.com A Bill of Rights that means what the majority wants it to mean is worthless. -- U.S. Supreme Court Justice Antonin Scalia
Bug#1003653: Revision of removal of rename.ul from package util-linux
On Sat, 22 Jan 2022, Chris Hofstaedtler wrote: > * Russ Allbery [220121 18:11]: > > Chris Hofstaedtler writes: > > > > > If the util-linux rename should be made easier to use, then it should > > > become the one and only provider of /usr/bin/rename, and it should not > > > be in an essential package. > > > > The two programs are very, very different, and I suspect the util-linux > > version would not be suitable for what /usr/bin/rename is currently used > > for inside Debian. > > I understand the perl group maintainer scripts switched to using the > /usr/bin/file-rename name. We could investigate rdeps of rename and > see what they use, and/or change them. This problem goes beyond reverse dependencies; there are also a not-insignificant number of user scripts which on Debian expect /usr/bin/rename to be the perl version (and probably a similar number on other distributions which expect the opposite). Not impossible to change, of course, but an ideal transition would avoid breaking currently working scripts and installs. -- Don Armstrong https://www.donarmstrong.com After the first battle of Sto Lat, I formulated a policy which has stood me in good stead in other battles. It is this: if an enemy has an impregnable stronghold, see he stays there. -- Terry Pratchett _Jingo_ p265
Bug#1003704: bugs.debian.org: error compiling kernel 5.16
Control: severity -1 important Control: reassign -1 binutils Control: found -1 binutils/2.35.2-2 Control: tag -1 moreinfo On Thu, 13 Jan 2022, gdaniel1358 wrote: > Package: bugs.debian.org > Severity: grave > Justification: can not compile kernel 5.16 > X-Debbugs-Cc: gdaniel1...@hotmail.com > > Dear Maintainer, > > Hi, tried to compile kernel 5.16.0 from kernel.org. > At linking point I get: > > CHK include/generated/compile.h > LD vmlinux.o > MODPOST vmlinux.symvers > MODINFO modules.builtin.modinfo > GEN modules.builtin > LD .tmp_vmlinux.btf > ld: BFD (GNU Binutils for Debian) 2.35.2 internal error, aborting at > ../../bfd/merge.c:939 in _bfd_merged_section_offset > > ld: Please report this bug. This looks like a bug in ld (part of binutils), not a bug in bugs.debian.org. I'm guessing that this is binutils 2.35.2-2. Please confirm the version and the architecture that you are seeing this bug in. -- Don Armstrong https://www.donarmstrong.com The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of the Conservatives is to prevent the mistakes from being corrected. -- G. K. Chesterton "Illustrated London News (1924-04-19)"
Bug#712979: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"
On Sun, 02 Jan 2022, Bastian Venthur wrote: > On 01.01.22 22:05, Don Armstrong wrote: > > I'm currently working on it, but my available time is so minimal, > > that additional help would be welcome. > > Awesome news! Is there some repository to check out? I'd love to help if I > can. Not publicly yet; I need to get more of the architecture in place before it can be reasonably collaborated on. But I hope to have it in a place that others can collaborate with me in the next 6 months or so. -- Don Armstrong https://www.donarmstrong.com Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rükert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_]
Bug#712979: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"
On Sat, 01 Jan 2022, Nis Martensen wrote: > On 31.12.2021 Don Armstrong wrote in #1002595: > > [Really, it's past time for us to support a REST interface and > > abandon the SOAP interface.] > Just wondering: Don, how much effort would you estimate is this? Do you > have plans for working on this? Could this be a suitable project for a > summer of code contribution? I'm currently working on it, but my available time is so minimal, that additional help would be welcome. My current plan is to reimplement the log and database reading pieces in python (SQLAlchemy + FastAPI) so that the number of people who can contribute to the web frontend parts is significantly larger. [I've started in on this, but it's slow going.] -- Don Armstrong https://www.donarmstrong.com No matter how many instances of white swans we may have observed, this does not justify the conclusion that all swans are white. -- Sir Karl Popper _Logic of Scientific Discovery_
Bug#1002595: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"
On Fri, 31 Dec 2021, Mike Frysinger wrote: > i get that the server is misbehaving now so clients don't have much > choice but to workaround them, but the server response should be fixed > nevertheless. Happy to accept patches to fix the XML serialization in SOAP. The way that Debbugs is doing it is clearly not correct, but fixing it isn't high on my priority list. [Really, it's past time for us to support a REST interface and abandon the SOAP interface.] -- Don Armstrong https://www.donarmstrong.com Grimble left his mother in the food store and went to the launderette and watched the clothes go round. It was a bit like color television only with less plot. -- Clement Freud _Grimble_
Bug#1002834: bugs.debian.org: radeon /dri3/composer vsync/ no browser works/ menu software quits
uot; > # Option "DRI""3" > Option "ShadowPrimary""True" > Option "TearFree" "False" > Option "DeleteUnusedDP12Displays" "True" > Option "VariableRefresh" "True" > EndSection > > Section "Device" > ### Available Driver options are:- > ### Values: : integer, : float, : "True"/"False", > ### : "String", : " Hz/kHz/MHz", > ### : "%" > ### [arg]: arg optional > > Identifier "RadeonSec" > Driver "radeon" > BusID "PCI:1:0:1" > #Screen1 > > Option "Accel" "True" > Option "NoAccel""False" > Option "HWcursor" "True" > Option "BusType""AGP" > Option "DisplayPriority""HIGH" > Option "EnablePageFlip" "False" > Option "AGPMode" "8" > Option "FastWrite" "True" > Option "DepthBits" "24" > Option "DMAForXv" "True" > Option "AccelDFS" "True" > Option "ColorTiling" "True" > Option "ColorTiling2D" "True" > Option "ShadowFB" "True" > Option "SubPixelOrder" "NONE" > #Option "ZaphodHeads" "VGA0,DVI0" > Option "AccelMethod" "glamor" > #Option "AccelMethod" "XAA" stable vintage > Option "DRI3" "True" > Option "DRI" "3" > Option "ShadowPrimary""True" > Option "TearFree" "False" > Option "DeleteUnusedDP12Displays" "True" > Option "VariableRefresh" "True" > > > EndSection > > Section "DRI" mode 0666 EndSection > > #Section "DRI2" mode 0666 EndSection > > #Section "DRI3" mode 0666 EndSection > > Section "Screen" > Identifier "Screen0" > Device "Radeon" > Monitor"Monitor0" > DefaultDepth 16 > # PreferredMode "1024x768@75" > Option "NoMTRR" "False" > Option "Accel" > > SubSection "Display" > Viewport 0 0 > Depth 1 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 4 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 8 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 15 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 16 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 24 > EndSubSection > EndSection > > #Section "Screen" > # Identifier "Screen1" > # Device "RadeonSec" > # Monitor"Monitor1" > # SubSection "Display" > # Viewport 0 0 > # Depth 1 > # EndSubSection > # SubSection "Display" > # Viewport 0 0 > # Depth 4 > # EndSubSection > # SubSection "Display" > # Viewport 0 0 > # Depth 8 > # EndSubSection > # SubSection "Display" > # Viewport 0 0 > # Depth 15 > # EndSubSection > # SubSection "Display" > # Viewport 0 0 > # Depth 16 > # EndSubSection > # SubSection "Display" > # Viewport 0 0 > # Depth 24 > # EndSubSection > #EndSection > -- Don Armstrong https://www.donarmstrong.com "What, now?" "Soon equates to good, later to worse, Uagen Zlepe, scholar. Therefore, immediacy." -- Iain M. Banks _Look to Windward_ p 213
Bug#999041: libimage-base-bundle-perl: diff for NMU version 1.0.7-3.3
On Mon, 13 Dec 2021, gregor herrmann wrote: > I've prepared an NMU for libimage-base-bundle-perl (versioned as 1.0.7-3.3) > and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. Feel free to upload right away; thanks for fixing it. [I'm also happy if the perl team takes over that package too.] -- Don Armstrong https://www.donarmstrong.com
Bug#1001274: scowl source has (probably outdated?) problematic license conditions
On Tue, 07 Dec 2021, Gernot Hillier wrote: > The Debian copyright however cites from r/pos/README that "The MWords > package was explicitly placed in the public domain". To me at least, > it's unclear whether the both READMEs were considered and if yes, it > would really help to add some clarifying statements in copyright why > the licensing terms in the (old?) README files don't apply (any > more?). mwords and pos are both part of the Moby Words project, which Grady Ward dedicated to the public domain (and also provided an equivalent license) on June 1, 1996. See https://web.archive.org/web/20170930060409/http://icon.shef.ac.uk/Moby/ for more details (and the original source files). They're present in the source, because that's how they are distributed upstream, but the copyright file lists the actual licensing. [Maybe a case to be made to clarify this in the upstream source, but I don't think a Debian specific patch is warranted here.] -- Don Armstrong https://www.donarmstrong.com
Bug#992463: shite appears in wbritish
Control: fixed -1 2020.12.07-1 Control: found -1 2019.10.06-1 On Fri, 22 Oct 2021, mooff wrote: > Not that I can see: Ah; it's in the version I haven't uploaded yet. I'll get that rolled out shortly. -- Don Armstrong https://www.donarmstrong.com I've had so much good luck recently I was getting sated with it. It's like sugar, good luck. At first it's very sweet, but after a while you start to think: any more of this and I shall be sick. -- Adam Roberts _Yellow Blue Tibia_ p301
Bug#996969: drop 'close' command --- deprecated since at least February 2002
Control: tag -1 wontfix On Thu, 21 Oct 2021, Adrian Bunk wrote: > On Thu, Oct 21, 2021 at 12:17:25PM -0400, Ryan Kavanagh wrote: > > Package: bugs.debian.org > > Severity: wishlist > > X-Debbugs-Cc: r...@debian.org > > > > The 'close' command has been deprecated since at least February 2002 [0], > > and its use is strongly discouraged by §5.8.2 of the developers > > reference: > > > > You should never close bugs via the bug server close command sent to > > cont...@bugs.debian.org. If you do so, the original submitter will > > not receive any information about why the bug was closed. [1] > > > > After almost 20 years of deprecation, maybe it's time to finally drop > > it? > >... > > If this gets implemented, how are housekeeping actions like [1] supposed > to be done? > > How do you suggest to close bugs like #993125 on submission? Heh; this is actually the first real use for close I've seen. I'm personally not planning on removing it, but it should continue to be deprecated in favor of -done for any use when you actually know the bug number. [I know people have use the fact that the submitter isn't notified on close as a "feature"...] -- Don Armstrong https://www.donarmstrong.com Live and learn or die and teach by example -- a softer world #625 http://www.asofterworld.com/index.php?id=625
Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye
Control: reassign -1 linux-signed-arm64 Control: found -1 5.10.46+4, 5.10.46+4~bpo10+1 Control: tag -1 moreinfo Control: severity -1 important On Fri, 03 Sep 2021, Luca Di Stefano wrote: > A few days ago I tried to upgrade one of the six Socionext SynQuacers > that we have to the latest Debian release. > > It was running fine on Buster using the 4.19 kernel and had no previous > issues. [...] > The next boot sequence would start and get to the point where it would > look for the rootfs without finding it and going into initramfs > > I've then proceeded to reinstall buster on that machine and it just > worked fine, then also tried installing the kernel from backports > linux- image-5.10.0-0.bpo.8-arm64 and after reboot it caused the same > problem not finding the rootfs and going into initramfs. I'm not familiar with the hardware of this particular device, but I suspect that some necessary driver was (likely inadvertently) excluded from the configuration of the 5.10 kernel, but included in 4.19. Looking at the output from the boot of both kernels should give you an idea of what module/device is broken, and providing that to this bug will give one of the maintainers of the arm64 kernel a chance of helping fix the issue. -- Don Armstrong https://www.donarmstrong.com If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money it values more, it will lose that, too. -- W. Somerset Maugham
Bug#685264: merge bugs 685264, 705155 and 746206?
forcemerge 685264 705155 746206 thanks On Fri, 27 Aug 2021, Vincent Lefevre wrote: > Shouldn't these bugs be merged? > > 685264: debbugs: obey “Control” field in pseudoheader of messages to > ‘nnn-d...@bugs.debian.org’ > 705155: allow Control: commands at -done and -forwarded > 746206: Control: pseudoheaders do not work for -done bugs; finish() called > too early Yep. Merging them. -- Don Armstrong https://www.donarmstrong.com I've had so much good luck recently I was getting sated with it. It's like sugar, good luck. At first it's very sweet, but after a while you start to think: any more of this and I shall be sick. -- Adam Roberts _Yellow Blue Tibia_ p301
Bug#992755: closed by Don Armstrong (reply to ow...@bugs.debian.org) (Re: Bug#992755: marked as done ([BTS] Bcc'ed close mails not archived in bug log ?))
On Thu, 26 Aug 2021, Vincent Lefevre wrote:
> On 2021-08-26 03:51:03 +, Debian Bug Tracking System wrote:
> > As a counterexample, this bug is only being closed via Bcc, but it
> > should show up both in the log and in what the bugreport.cgi
> > displays.
>
> This is not the case. The "close" does not appear and actually
> corresponds to
>
> Reply sent to ow...@bugs.debian.org:
> You have taken responsibility. (Thu, 26 Aug 2021 03:51:03 GMT) (full text,
> mbox, link).
Yes, that's what happens when you send a mail to -done. There's an
argument to be made that we should change that to something more
obvious, but that's what a close message has looked like for the past 20
years or so.
[...]
> the main page of the bug report should also display when some metadata
> (close status, tags, etc.) is changed.
Mail to -done is handled differently than a control message, and doesn't
cause a separate html message to be added to the log indicating that the
bug status has been changed.
> Actually, "the first mail message to be received is shown" does not
> seem to be how bugreport.cgi behaves in general. For instance, see
> Message #30. It is displayed on the main page, but this main page
> *also* shows 3 copies:
> * Message #32 ("Bug reopened")
> * Message #34 ("Changed Bug title to ...")
> * Message #36 ("Severity set to 'minor' from 'wishlist'")
Those are just the html that corresponds to the control commands which
were processed from message #30.
> I expect the same thing for "Bug closed", which is currently not the
> case.
It's reasonable to argue that it would be less surprising for the BTS to
handle -done like a control@ message, but that's a separate bug from
this bug.
--
Don Armstrong https://www.donarmstrong.com
We cast this message into the cosmos. [...] We are trying to survive
our time so we may live into yours. We hope some day, having solved
the problems we face, to join a community of Galactic Civilizations.
This record represents our hope and our determination and our goodwill
in a vast and awesome universe.
-- Jimmy Carter on the Voyager Golden Record
Bug#990832: Updates
Thanks for all of the work and the patching. The debug output that you're showing looks a lot like some of the necessary macros aren't enabled in the postfix config; can you compare what you have to what is listed in README.Debian? I'll try to take another look at the code that you have which is working and see what is going on there. -- Don Armstrong https://www.donarmstrong.com I learned really early the difference between knowing the name of something and knowing something -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969
Bug#990832: spamass-milter: Postfix has increased unparseable relay failures leading to SPF_FAIL
On Thu, 08 Jul 2021, William Haller wrote: > I didn't test this message, but I did test some others that failed by > running them directly through spamc and they gave a correct report > with no unparseable relay errors. spamass-milter has to build up a Received: header because one doesn't exist at the moment it has to send the header to spamassassin. I'm suspecting that a configuration issue (or a bug) is causing the Received: header to not be parsable (or doesn't match localnet in spamassassin). Try running spamass-milter with -d spamc; to have it output the received header it is sending to spamc (and compare with the actual received header that gets generated). -- Don Armstrong https://www.donarmstrong.com Live and learn or die and teach by example -- a softer world #625 http://www.asofterworld.com/index.php?id=625
Bug#989799: Bug#990557: bugs.debian.org: Not automatically close Bug#989799 for buster-backports
tag 989799 - bullseye-ignore severity 989799 serious fixed 989799 4.10.0-1 thanks On Fri, 02 Jul 2021, Hideki Yamane wrote: > As > https://tracker.debian.org/news/1243791/accepted-manpages-l10n-4100-1bpo101-source-into-buster-backports-backports-policy-buster-backports/ > Bug#989799 was noted as "Closes" but not done automatically. > > We expect that is closed, is it BTS system side issue or not? 989799 was closed in 4.10.0-1~bpo10+1 but not in 4.10.0-1 (in testing/unstable) which 4.10.0-1 and the bpo version are based on. I'm assuming that it was also fixed in 4.10.0-1 (or maybe it was never broken in that version?) so I'm marking it as fixed there too. See this version graph for details on what was going on: https://bugs.debian.org/cgi-bin/version.cgi?absolute=0;collapse=1;fixed=4.10.0-1~bpo10%2B1;format=png;found=4.9.3-4~bpo10%2B1;height=;info=1;package=manpages-l10n;width=;ignore_boring=0 -- Don Armstrong https://www.donarmstrong.com There is no more concentrated form of evil than apathy.
Bug#985675: plover 4.0.0~dev8~66~g685bd33-2 is missing Conflicts/Replaces plover-common 3.0.0-1
On March 21, 2021 1:06:29 PM PDT, Harlan Lieberman-Berg wrote: >tag 985675 +moreinfo >thanks > >On Sun, Mar 21, 2021 at 3:39 PM Don Armstrong wrote: >> plover-common 3.0.0-1 and plover 4.0.0~dev8~66~g685bd33-2 both ship >> /usr/share/plover/assets/american_english_words.txt, but the latter >is >> missing the appropriate Conflicts/Replaces. > >Hi Don, > >Where have you installed plover-common from? That's not a package I >recognize in the archive. Hrm. It was maintained by you, but there's a non-zero chance I installed it directly from source. If it's never been uploaded, that's probably what happened. I can do more research later if that's helpful. -- This is not a signature.
Bug#985675: plover 4.0.0~dev8~66~g685bd33-2 is missing Conflicts/Replaces plover-common 3.0.0-1
Package: plover Severity: serious Version: 4.0.0~dev8~66~g685bd33-2 Preparing to unpack .../2-plover_4.0.0~dev8~66~g685bd33-2_all.deb ... Unpacking plover (4.0.0~dev8~66~g685bd33-2) over (3.0.0-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-P6rk1s/2-plover_4.0.0~dev8~66~g685bd33-2_all.deb (--unpack): trying to overwrite '/usr/share/plover/assets/american_english_words.txt', which is also in package plover-common 3.0.0-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) plover-common 3.0.0-1 and plover 4.0.0~dev8~66~g685bd33-2 both ship /usr/share/plover/assets/american_english_words.txt, but the latter is missing the appropriate Conflicts/Replaces. -- Don Armstrong https://www.donarmstrong.com [T]he question of whether Machines Can Think, [...] is about as relevant as the question of whether Submarines Can Swim. -- Edsger W. Dijkstra "The threats to computing science"
Bug#984831: bugs.debian.org: should not emit semicolon as query param separator
Control: retitle -1 switch from semicolon ';' to ampersand '&' for query parameter separation On Mon, 08 Mar 2021, Phil Morrell wrote: > As reported on #debian-til, python can no longer parse bugs.d.o URLs > correctly out of the box. The change was backported as a security update > to 3.6+ so also affects buster. > > https://bugs.python.org/issue42967 This looks like an issue in python's urllib. ';' are perfectly valid query parameter separators for URIs and anything consuming debbugs URIs should pass appropriate options to support them. That said, we probably should switch away from semicolons as they are no longer recommended. > From what I can tell, the search form and msg= use semicolon and I > actually can't find any with ampersand. Everything uses semicolon, but we can probably just make Debbugs::URI call query_form instead of query_param. -- Don Armstrong https://www.donarmstrong.com I would like to be the air that inhabits you for a moment only. I would like to be that unnoticed & that necessary. -- Margaret Atwood "Poetry in Motion" p140
Bug#982900: RM: libhtml-calendarmonth-perl -- ROM; RC buggy, upstream unresponsive
Package: ftp.debian.org Severity: normal Please remove libhtml-calendarmonth-perl; it is RC buggy, has a pretty finiky build system (which is why it fails to build), has an unresponsive upstream, and is largely unused in the archive. Thanks! -- Don Armstrong https://www.donarmstrong.com "Old hypotheses never really die, they're like dormant volcanoes." -- John McPhee _Annals of the Former World_ p313
Bug#970210: forcemerge vs. pkgreport.cgi
retitle 970210 repeatmerged=no can't be configured to show a bug other than the lowest numbered bug severity 970210 wishlist tag 970210 wontfix thanks On Sun, 10 Jan 2021, Robert Luberda wrote: > I agree with Dan. I've just forcemerged 979575 979549 979565, and then > marked 979575 as affecting a few packages, for example ifrench. > When I was doing this, I expected 979575 to be the "master" bug, that > will be displayed in bug pages for both ispell and affected packages. forcemerge doesn't do anything but adjust all of the settings that are required to be equal and then merge the bugs. The documentation is pretty clear: "Forcibly merges two or more bug reports. The settings of the first bug listed which must be equal in a normal merge are assigned to the bugs listed next. To avoid typos erroneously merging bugs, bugs must be in the same package. " It doesn't cause a bug to be listed when repeatmerged=no, change the title, or anything like that. Hope that clarifies things a bit. -- Don Armstrong https://www.donarmstrong.com Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. -- Richard Feynman "What is and What Should be the Role of Scientific Culture in Modern Society"; 1964
Bug#977726: debbugs: Decode non-ascii "Done:" field in HTML output
reassign 977726 dak retitle 977726 Done: psuedoheader should not be mime encoded tag 977726 patch thanks On Sat, 19 Dec 2020, Rafael Laboissière wrote: > The header "Done:" in the web pages for the individual bugs are > wrongly displayed when the name of the person who closed the bug > contains non-ASCII characters. This is the case of my name, as we can > see in Bug#976382 [1]: This is because my fix for #950132 in dak was wrong, and used the mime-encoded Maintainer field instead of the unencoded maintainer field. The attached patch addresses this issue. -- Don Armstrong https://www.donarmstrong.com I really wanted to talk to her. I just couldn't find an algorithm that fit. -- Peter Watts _Blindsight_ p294 From ae4b846e8ac95f0bf51c4aa300de40336ef9f657 Mon Sep 17 00:00:00 2001 From: Don Armstrong Date: Sun, 20 Dec 2020 08:04:59 -0800 Subject: [PATCH] The Done: field in the bug-close e-mails should not be mime-encoded This alters commit 53b2e48a05cf to use __MAINTAINER__ which is not mime-encoded instead of __MAINTAINER_FROM__. Closes #977726 --- templates/process-unchecked.bug-close | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/templates/process-unchecked.bug-close b/templates/process-unchecked.bug-close index 58a024ea..ceea21ab 100644 --- a/templates/process-unchecked.bug-close +++ b/templates/process-unchecked.bug-close @@ -11,7 +11,7 @@ Subject: Bug#__BUG_NUMBER__: fixed in __SOURCE__ __VERSION__ Source: __SOURCE__ Source-Version: __VERSION__ -Done: __MAINTAINER_FROM__ +Done: __MAINTAINER__ We believe that the bug you reported is fixed in the latest version of __SOURCE__, which is due to be installed in the __DISTRO__ FTP archive. -- 2.29.2
Bug#962066: bugs.debian.org: Done information badly mistreats names with non-ASCII characters
On Tue, 02 Jun 2020, Adrian Bunk wrote: > Example: #961302 > Done: =?utf-8?q?J=C3=B6rg_Frings-F=C3=BCrst?= This is a problem with the patch I submitted to dak. Pseudoheaders shouldn't have header encodings. -- Don Armstrong https://www.donarmstrong.com "That is why I am still tyrant of [Ankh-Morpork]. The way to retain power, I have always thought, is to ensure the absolute unthinkability of oneself not being there." -- Terry Pratchett _Unseen Academicals_ p391
Bug#954444: Updated neomutt to 20200501 in salsa
I've update the packaging of neomutt to 20200501 to fix some annoying maildir sync issues I've been facing. Feel free to merge directly from https://salsa.debian.org/don/neomutt if you'd like. [I'd create a merge request, but not sure if anyone is following along with that.] [I had to disable some of the tests which require a separate git repo; not sure exactly how you all want to handle that.] -- Don Armstrong https://www.donarmstrong.com "That is why I am still tyrant of [Ankh-Morpork]. The way to retain power, I have always thought, is to ensure the absolute unthinkability of oneself not being there." -- Terry Pratchett _Unseen Academicals_ p391
Bug#923438: NMU to fix SSL issue in tinc experimental
I've just made an upload to delay-3 to address the SSL issue. Debdiff
attached. Let me know if I should delete the upload.
--
Don Armstrong https://www.donarmstrong.com
"You know," said Arthur, "it's at times like this, when I'm trapped in
a Vogon airlock with a man from Betelgeuse, and about to die from
asphyxiation in deep space that I really wish I'd listened to what my
mother told me when I was young."
"Why, what did she tell you?"
"I don't know, I didn't listen."
–- Douglas Adams _The Hitchhikers Guide To The Galaxy_
diff -Nru tinc-1.1~pre17/debian/changelog tinc-1.1~pre17/debian/changelog
--- tinc-1.1~pre17/debian/changelog 2018-10-09 19:58:42.0 -0700
+++ tinc-1.1~pre17/debian/changelog 2020-05-31 15:11:34.0 -0700
@@ -1,3 +1,10 @@
+tinc (1.1~pre17-1.2) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patch to fix EVP_DecryptUpdate issue. Closes: #923438
+
+ -- Don Armstrong Sun, 31 May 2020 15:11:34 -0700
+
tinc (1.1~pre17-1.1) experimental; urgency=medium
* Non-maintainer upload.
diff -Nru tinc-1.1~pre17/debian/patches/fix_use_of_decrypt tinc-1.1~pre17/debian/patches/fix_use_of_decrypt
--- tinc-1.1~pre17/debian/patches/fix_use_of_decrypt 1969-12-31 16:00:00.0 -0800
+++ tinc-1.1~pre17/debian/patches/fix_use_of_decrypt 2020-05-31 15:11:00.0 -0700
@@ -0,0 +1,16 @@
+Description: Fix EVP_EncryptUpdate use (use EVP_DecryptUpdate)
+Author: Don Armstrong
+Origin: https://www.tinc-vpn.org/pipermail/tinc-devel/2019-February/000941.html
+Last-Update: 2020-05-31
+
+--- tinc-1.1~pre17.orig/src/openssl/cipher.c
tinc-1.1~pre17/src/openssl/cipher.c
+@@ -189,7 +189,7 @@ bool cipher_decrypt(cipher_t *cipher, co
+ } else {
+ int len;
+
+- if(EVP_EncryptUpdate(cipher->ctx, outdata, , indata, inlen)) {
++ if(EVP_DecryptUpdate(cipher->ctx, outdata, , indata, inlen)) {
+ if(outlen) {
+ *outlen = len;
+ }
diff -Nru tinc-1.1~pre17/debian/patches/series tinc-1.1~pre17/debian/patches/series
--- tinc-1.1~pre17/debian/patches/series 2017-09-05 12:02:21.0 -0700
+++ tinc-1.1~pre17/debian/patches/series 2019-03-28 18:23:53.0 -0700
@@ -1 +1,2 @@
fix-version-number
+fix_use_of_decrypt
Bug#954790: bugs.debian.org: bugs are no longer sorted by modification time
Control: severity -1 wishlist Control: retitle -1 Allow bugs to be sorted by modification time On Mon, 23 Mar 2020, Piotr Engelking wrote: > Bugs used to be sorted by the modification time, which made it easier > to track recent bug changes. They are now, apparently, sorted by the > bug number, which is not particularly useful. Bugs have always been ordered by bug number, and never by last modified time. It's a reasonable feature request, but just not something we've implemented. > Please sort the bugs by modification time again, or make the behavior > configurable. > -- Don Armstrong https://www.donarmstrong.com For a moment, nothing happened. Then, after a second or so, nothing continued to happen. -- Douglas Adams
Bug#952429: spamass-milter: doesn't work with the -s flag to spamc
On Tue, 25 Feb 2020, Russell Coker wrote: > It seems that any command-line parameter that doesn't start with '-' > will be passed as a parameter to spamc. I don't think this is > something many people will expect or desire. Yeah; that's basically how the code is currently written. > Maybe a good option would be to log what the spamc parameters will be > at daemon start time so the user doesn't have to strace it to find out > what it's doing. If you use -d misc you should get that logged to syslog. -- Don Armstrong https://www.donarmstrong.com [M]en and nations do behave wisely once they have exhausted all other alternatives. -- Abba Ebban
Bug#952429: spamass-milter: doesn't work with the -s flag to spamc
Control: tag -1 moreinfo
On Mon, 24 Feb 2020, Russell Coker wrote:
> spamc -u russ...@coker.com.au --max-size=10485760 127.0.0.1 < spam.mbox
>
> The above command will correctly scan a file that's more than 500K in size.
>
> spamc -u russ...@coker.com.au 127.0.0.1 --max-size=10485760 < spam.mbox
>
> The above command (differing only in the order of 2 parameters)
> doesn't work, spamc logs "skipped message, greater than max message
> size (512000 bytes)" to syslog. The man page for spamc doesn't
> document this, it may be a bug in spamc.
>
> execve("/usr/bin/spamc", ["/usr/bin/spamc", "-u", "russ...@coker.com.au",
> "127.0.0.1", "-s", "10485760"], 0x7ffef748a960 /* 15 vars */) = 0
>
> The above is from stracing spamass-milter, it does what spamc doesn't like and
> there seems to be no way to stop it.
That's really strange; I would have expected the call to spamc to be:
/usr/bin/spamc -u rus...@cocker.com.au -d 127.0.0.1 -s 10485760
That's what the codebase does, and there's no (documented) way to
specify the host without using -d.
Have you modified the init script? Or is there something else
interesting happening here?
--
Don Armstrong https://www.donarmstrong.com
Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
-- Antoine de Saint-Exupe'ry, Terres des Hommes
Bug#951801: User setting of LILYPOND_DATADIR is not honoured
On Fri, 21 Feb 2020, Simon Tatham wrote: > However, the override doesn't actually work! [...] > In order to work around this, I tried to 'exec' the Lilypond binary > with an argv[0] that does not appear on PATH at all, which inhibits > the initial 'relocate' operation and causes the input value of > LILYPOND_DATADIR not to be overwritten. Hrm; that's really surprising. I have to admit that I haven't ever tested LILYPOND_DATADIR. Could you try changing /usr/bin/lilypond to be this instead: #!/bin/sh export LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu/lilypond/2.18.2/guile" exec "lilypond.real" "$@" and see if that works better? -- Don Armstrong https://www.donarmstrong.com Vimes hated and despised the privileges of rank, but they had this to be said for them: At least they meant that you could hate and despise them in comfort. -- Terry Pratchett _The Fifth Elephant_ p111
Bug#950132: Fixed bugs are now always "Done: Debian FTP Masters "
On Thu, 30 Jan 2020, Ansgar wrote: > There are a surprising number of consumbers of these mails, including > AFAIK buildds or the BTS bot on IRC (which interestingly wasn't > confused by this change). Probably because it never paid any attention to From: anyway. > It is also unclear what other services might consume the mails > (directly or indirectly), and I don't really have an idea how to find > out (besides debian-services-admin@). The direct consumers of the mail are listed in the dak codebase: https://salsa.debian.org/ftp-team/dak/blob/master/daklib/announce.py#L141 https://salsa.debian.org/ftp-team/dak/blob/master/config/debian/dak.conf#L13 -- Don Armstrong https://www.donarmstrong.com When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. -- Edmund Burke "Thoughts on the Cause of Present Discontents"
Bug#950132: Fixed bugs are now always "Done: Debian FTP Masters "
On Wed, 29 Jan 2020, Ansgar wrote:
> Adrian Bunk writes:
> > https://salsa.debian.org/ftp-team/dak/commit/8485697a9e11496ff0aed1a5ad32e512a672635d
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936844
> > Found in version libbde/20190102-1
> > Fixed in version libbde/20190102-1.1
> > Done: Debian FTP Masters
>
> I think that is mostly a cosmetic issue. I don't think bugs.d.o
> currently provides a way to specify what entity should be shown in the
> "Done: ${name}" field though, so cloning to bugs.d.o.
That's correct; we don't have a method for doing that yet.
In the future, it would have been nice to coordinate this change a bit
and add such a feature before the change, as the BTS is the primary
consumer of these mails.
I think either a psuedoheader or an X header (well, I'll implement it as
both) is probably the correct approach.
I won't be able to get around to fixing this until this weekend and the
earliest, however.
--
Don Armstrong https://www.donarmstrong.com
One day I put instant coffee in my microwave oven and almost went back
in time.
-- Steven Wright
Bug#949370: Acknowledgement (spamass-milter: synthesized received header sometimes use the sendmail start time instead of current time)
On Tue, 21 Jan 2020, Bjørn Mork wrote: > The issue could probably be fixed in sendmail by moving the initsys(e) > call in front of milter_envrcpt(). But reading the milter docs, I am > not convinced this is the "most correct" fix. I believe the bug really > is in spamass-milter assuming that the "$b" macro value is valid at this > stage. Thanks for the great analysis of this issue; I think the easy fix is to just synthesize the current RFC 5322 format time and provide it instead of relying on a roundtrip to the $b macro in spamass-milter. I'm happy to apply a patch which does this; it might take me a while to get around to do it myself. -- Don Armstrong https://www.donarmstrong.com Rule 30: "A little trust goes a long way. The less you use, the further you'll go." -- Howard Tayler _Schlock Mercenary_ March 8th, 2003 http://www.schlockmercenary.com/d/20030308.html
Bug#945373: ITP: cf -- cf colorizes piped filenames w/Truecolor sRGB
On Sat, 23 Nov 2019, Adam Danischewski wrote: > cf can be used in with find/ls commands in pipelines. > > If you get used to using cf you will likely find it very difficult to > imagine not using cf!! cf is already in use by cloud foundry. Granted, it's not packaged in Debian, but large numbers of people use it. -- Don Armstrong https://www.donarmstrong.com This isn't life in the fast lane, it's life in the oncoming traffic -- Terry Pratchett
Bug#941705: sslh: inconsistent usage of sslh account
On Thu, 03 Oct 2019, Aaron M. Ucko wrote: > sslh fails to start on my system, on which I merged the new stock > "--user sslh" option into /etc/default/sslh: > > Oct 3 20:23:01 his-pc sslh-select[11576]: /var/run/sslh/sslh.pid: > Permission denied > > As the message shows, I'm using sslh-select rather than regular sslh, > as specified in the attached systemd override.conf (whose Requires > setting should apparently become a .requires symlink, but that's > another matter). [...] > -- Configuration Files: > /etc/default/sslh changed: > DAEMON=/usr/sbin/sslh > DAEMON_OPTS="--user sslh --transparent --listen 192.168.1.2:443 --ssh > 192.168.1.2:22 --ssl 192.168.1.2:443 --pidfile /var/run/sslh/sslh.pid" > > /etc/logcheck/ignore.d.server/sslh [Errno 13] Permission denied: > '/etc/logcheck/ignore.d.server/sslh' > > -- debconf information: > * sslh/inetd_or_standalone: standalone > [Service] > > # Replace the start command and make it use sslh-select > ExecStart= > ExecStart=/usr/sbin/sslh-select --foreground $DAEMON_OPTS > > # Run sslh as an user and use capabilities to bind ports > User=sslh > AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_ADMIN So I think this is the issue; you're running it as sslh, not root, so it can't actually drop privileges or write to its pidfile. The default is for it to run as root, open sockets, write its pidfile, and then drop permissions: if (pid_file) write_pid_file(pid_file); /* Open syslog connection before we drop privs/chroot */ setup_syslog(argv[0]); if (user_name || chroot_path) drop_privileges(user_name, chroot_path); if (verbose) printcaps(); main_loop(listen_sockets, num_addr_listen); -- Don Armstrong https://www.donarmstrong.com That's the wonderful thing about crayons. They can take you to more places than a starship. -- Guinan "Star Trek: The Next Generation: Rascals (#6.7)"
Bug#939428: O: sslh -- Applicative protocol multiplexer
Control: retitle -1 ITA: sslh -- Applicative protocol multiplexer Control: owner -1 ! On Wed, 04 Sep 2019, g...@iroqwa.org wrote: > I intend to orphan the sslh package. Unless someone else wants to maintain this package, I will adopt it, as I use it. -- Don Armstrong https://www.donarmstrong.com [T]he question of whether Machines Can Think, [...] is about as relevant as the question of whether Submarines Can Swim. -- Edsger W. Dijkstra "The threats to computing science"
Bug#923510: Temporarily worked around via redirect
Control: severity -1 important I've fixed this issue in the devel branch, but that required a ton of other changes, so it is waiting for a new release of Debbugs. In the meantime, I've put in a rewrite proxy rule to switch this particular request to the devel branch so it should "work" seamlessly. I've downgraded the severity because of the workaround, but the underlying issue will still be present until I release the new version of Debbugs. -- Don Armstrong https://www.donarmstrong.com 2: There is no out. There is only in. -- "The Prisoner (2009 Miniseries)"
Bug#938943: bugs.debian.org: Bad bug log for Bug 936371. Unable to read records: state kill-init at end
On Fri, 30 Aug 2019, Simon McVittie wrote: > dbus-python has a bug listed in > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=dbus-python > where the original bug report is not accessible via the web. > > When I first accessed > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936371 > I got this: > > > An error occurred. Error was: Bad bug log for Bug 936371. Unable to read > > records: state kill-init at end at /usr/local/lib/site_perl/Debbugs/Log.pm > > line 320. > > and when I tried > > $ bts show --mbox 936371 > > I initially got a 500 internal server error. > > Now that I've marked the bug as blocking another bug (which I was able to > do from its subject line), the only thing in the mbox or bug record is the > information that I did so - the actual bug report seems to have been lost. > > Please could someone check what has happened on the server? For a mass-bug > this isn't particularly bad, because I can extrapolate what the bug must > have said from its hundreds of friends, but for a unique bug this would > have been problematic. Hrm; it appears that the original bug report itself wasn't saved properly either. I have a collection of these failures from that mass bug filing (though apparently I'm missing the failure from tap.py) I have the suspicion that this was partially caused by buxtehude being restarted/upgraded around then. I'll try to clean up this mess as I have a chance. -- Don Armstrong https://www.donarmstrong.com A Bill of Rights that means what the majority wants it to mean is worthless. -- U.S. Supreme Court Justice Antonin Scalia
Bug#936043: ITP: gitbatch -- Manage git repositories in one place
On Thu, 29 Aug 2019, Dawid Dziurla wrote: > * Package name: gitbatch > Version : 0.5.0-1 > Upstream Author : Ibrahim Serdar Acikgoz > * URL : https://github.com/isacikgoz/gitbatch > * License : Expat > Programming Lang: Go > Description : Manage git repositories in one place > > Managing multiple git repositories is easier than ever. Often one would end > up working on many directories and manually pulling updates etc. To make > this routine faster, gitbatch was created, a simple tool to handle this job. > Although the focus is batch jobs, one can still do de facto micro management > of > git repositories (e.g add/reset, stash, commit etc.) It would be interesting to know how gitbatch compares to myrepos, as they seem to be operating in the same or similar spaces. -- Don Armstrong https://www.donarmstrong.com It was said that life was cheap in Ankh-Morpork. This was, of course, completely wrong. Life was often very expensive; you could get death for free. -- Terry Pratchet _Pyramids_ p25
Bug#933544: hunspell-en-us: Regression: ~13k words less in Buster compared to Stretch
On Wed, 31 Jul 2019, Philipp Hahn wrote: > This results hunspell no longer accepting valid words like > amongst > cryptographic > dereferenced > scalability > scalable > > Checking scowl/final/ I find most of them in > english-words.?? > but not in > american-words.?? > > I'm not a native English speaker, but the words listed above are > common enough and should be included in the American dictionary. Or > did I miss something? To be fair, amongst isn't super common in American english; among is more common. But amongst should still be present in hunspell as it's not *that* uncommon. The rest of the words should really be there too. I confirm the underlying issue here; the variants don't seem to be being included in the hunspell dictionary and a few other dictionaries are not included. I believe this is likely an upstream issue in its source, but I'll try to dig into this some more when I get a chance. Thanks for the report! -- Don Armstrong https://www.donarmstrong.com All bad precedents began as justifiable measures. -- Gaius Julius Caesar in "The Conspiracy of Catiline" by Sallust
Bug#932795: Ethics of FTBFS bug reporting
I think this discussion is great and good to have; thanks for starting it! As a point of order, the TC isn't responsible for deciding whether bugs are RC or not. That responsibility belongs with the Release Managers. [I don't think that should stop the TC from facilitating the decision and the baseline being enshrined in policy so the RMs can rely on it to decide whether it is RC or not.] -- Don Armstrong https://www.donarmstrong.com Those who begin coercive elimination of dissent soon find themselves exterminating dissenters. Compulsory unification of opinion achieves only the unanimity of the graveyard. -- Justice Roberts in 319 U.S. 624 (1943)
Bug#932482: bugs.debian.org: Xorg problems with Intel graphics after upgrading to Debian buster
Control: reassign -1 xserver-xorg-video-intel On Sat, 20 Jul 2019, Frank Mulder wrote: > Since upgrading to Debian buster, I have problems with the graphical > interface. > My PC is a Zotac ZBOX CI549 Nano and I am using the built-in Intel graphics > (Intel HD Graphics 620), with one monitor connected to the HDMI port (a DELL > U2410). This sounds like an issue with EDID not being passed correctly or interpreted correctly. I'm not really an expert on that, but hopefully someone else can help. [Maybe try debian-u...@lists.debian.org?] For the record, the right place to file these bugs is xserver-xorg-video-intel, not bugs.debian.org, so I have reassigned it there. -- Don Armstrong https://www.donarmstrong.com I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered. My life is my own. I resign. -- Patrick McGoohan as Number 6 in "The Prisoner"
Bug#930433: bugs.debian.org: source for libasan5 is gcc-8, not gcc-9
On Thu, 13 Jun 2019, Vincent Lefevre wrote: > The "src:gcc-9" is incorrect, as the source for libasan5 is gcc-8 > (at least for the reported version), not gcc-9. The bug should > appear on > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gcc-8 > > not on > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gcc-9 The source for libasan5 is gcc-8 and gcc-9. In reality, it should show up on both, but we currently do source mapping using the information in unstable, not the information in testing or stable. [And ideally, it should tell you that the bug is found in gcc-8, but in some other branch for gcc-9.] In my current development branch I have addressed this, but this is significantly more complicated to get right in all of the edge cases, which is why it won't be fixed before I roll out all of those other changes. -- Don Armstrong https://www.donarmstrong.com This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_
Bug#916653: perltidy -- NMU?
On Sat, 08 Jun 2019, Philip Hands wrote: > If you want to deal with uploading that, that's great, otherwise I'm > happy to do an NMU. Thanks for doing the work! I can upload it if that's OK with you. [Working on building/testing it right now.] -- Don Armstrong https://www.donarmstrong.com He was wrong. Nature abhors dimensional abnormalities, and seals them neatly away so that they don't upset people. Nature, in fact, abhors a lot of things, including vacuums, ships called the Marie Celeste, and the chuck keys for electric drills. -- Terry Pratchet _Pyramids_ p166
Bug#926740: bugs.debian.org: Subscription confirmation reply-to address length exceeds RFC-5321 limit
On Tue, 09 Apr 2019, Nazar Zhuk wrote: > I subscribed to a bug (924787) and received a confirmation email asking > me to confirm the subscription by emailing to > 924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f3696...@bugs.debian.org > > My smpt server (mailfence) rejects an email to this address with a > message: > > --- > The recipient address > <924787-subyes-06ddd608dd383c6372c630f8f9be3ea9-04aefdbc1c6c3b3698f22818f3696...@bugs.debian.org> > is not a valid RFC-5321 address.. Hrm; yep, that looks like a bug. Thanks for the report! -- Don Armstrong https://www.donarmstrong.com What I can't stand is the feeling that my brain is leaving me for someone more interesting.
Bug#754809: bugs.debian.org still broken regarding DKIM
On Mon, 11 Mar 2019, Marco d'Itri wrote: > On Mar 11, Matija Nalis wrote: > > > Has this issue ever has been dealt with for bugs.debian.org (as it > > seems to have been solved for lists.debian.org in forked #752084) ? > No: it is obvious that the messages relayed by the BTS are still > modified. Right; the only way forward for this is to completely stop rewriting the subject of messages sent to submit@ or nnn@ or implement resending. > > I can provide whole forensic report if required, or do tests. > The problem is quite clear, but the is no commitment from the BTS > maintainers to choose a solution and maybe implement it. I don't have time to implement either in the near term. My current longer term plan is to switch to resending messages and rewriting From. -- Don Armstrong https://www.donarmstrong.com The game of science is, in principle, without end. He who decides one day that scientific statements do not call for any further test, and that they can be regarded as finally verified, retires from the game. -- Sir Karl Popper _The Logic of Scientific Discovery_ §11
Bug#922715: debbugs: b.d.o/release-critical/britney/testing-nr wrongly reports RC bugs when reported against two packages
On Tue, 19 Feb 2019, Paul Gevers wrote: > Britney is using RC bugs to determine if package may migrate from > unstable to testing. If an RC bug is only in unstable and not in > testing, the package is not allowed to migrate. However, in the above > case simplejson is listed in both > https://bugs.debian.org/release-critical/britney/testing-nr > and > https://bugs.debian.org/release-critical/britney/unstable-nr > > Can you please have a look at it? I wanted to mark the failure as > skiptest, because I expect the bug to be assigned to > json-schema-validator in 10 days from now, and was counting on the RC > bug to block simplejson from migrating. So this is a case where we're using the status of the bug (present in testing) and then reversing it to apply to all of the packages to which the bug is assigned. We don't really have a good way to state that a bug assigned to multiple packages should apply to the intersection of all of the versions/packages listed (which is what you're looking for) rather than the OR of all the versions/packages listed (which is what the BTS does by default). Hopefully that clears things up; I don't expect that I'll get around to adding the AND/OR feature to versions any time soon, so in the meantime I'd just file a separate bug if you want to be sure that a package doesn't transition if one of the set already has. -- Don Armstrong https://www.donarmstrong.com Do not handicap your children by making their lives easy. -- Robert Heinlein _Time Enough For Love_ p251
Bug#919316: bugs.debian.org: DoS with libravatar.cgi and version.cgi
On Tue, 15 Jan 2019, Julien Cristau wrote: > On Mon, Jan 14, 2019 at 21:27:31 -0800, Don Armstrong wrote: > > Is there any reason why we're using RLimitNPROC instead of setting > > MaxClients? > > > MaxRequestWorkers (new name for MaxClients) is set to 150 currently. We > could try lowering that or bumping the RLimitNPROC value a bit? That sounds reasonable to me; I think at the most, there should be twice as many processes as maxclients, so probably setting it to something like 450 should be more than sufficient, and still stop things from completely blowing up if I do something really stupid. -- Don Armstrong https://www.donarmstrong.com As nightfall does not come at once, neither does oppression. In both instances, there is a twilight when everything remains seemingly unchanged. And it is in such twilight that we all must be most aware of change in the air -- however slight -- lest we become unwitting victims of the darkness. -- William O. Douglas
Bug#919316: bugs.debian.org: DoS with libravatar.cgi and version.cgi
On Mon, 14 Jan 2019, Julien Cristau wrote: > the last few days our two bugs web hosts have been struggling. We've > got apache set up with RLimitNPROC 256, which means once www-data has > that many processes fork() dies with EAGAIN. > > In the case of version.cgi that means perl forking to run dot, for > libravatar.cgi it looks like it's either cp or convert. Either way, the > failure mode of fork returning EAGAIN is that perl does sleep(5) and > tries again. Over and over. Which means by the time something happens > the client has long gone, but we're still holding up one of the 256 > nproc slots not doing anything useful for quite a bunch of time. Is there any reason why we're using RLimitNPROC instead of setting MaxClients? There's not much on bugs.debian.org which isn't served by a cgi script, so there's limited difference between the two for it, and as you can see, returning EAGAIN isn't particularly useful. [Those two CGI scripts actually just die() when system() returns non-zero, so it's probably perl internal system() bits which are sleep() and retrying.] -- Don Armstrong https://www.donarmstrong.com Those who begin coercive elimination of dissent soon find themselves exterminating dissenters. Compulsory unification of opinion achieves only the unanimity of the graveyard. -- Justice Roberts in 319 U.S. 624 (1943)
Bug#917389: bugs.debian.org: please close down the debian-maintainers pseudo-package
On Sun, 30 Dec 2018, Mattia Rizzolo wrote: > On Sat, Dec 29, 2018 at 09:32:06AM -0800, Don Armstrong wrote: > > Sure! [I should have it marked as deprecated later today.] > > BTW, can I have more details on what "marking as deprecated" entails in > this context? Are incoming bugs rejected or something? No, it just means that the description is changed for that psuedopackage; we don't reject bugs even if they are filed against an invalid package. -- Don Armstrong https://www.donarmstrong.com "You have many years to live--do things you will be proud to remember when you are old." -- Shinka proverb. (John Brunner _Stand On Zanzibar_ p413)
Bug#917632: bugs.debian.org: During kernel boot the nvme module is not loaded, make the kernel not finding the rootfs
Control: reassign -1 linux-signed-amd64 Control: found -1 4.17.0-3 Just a note, bugs.debian.org is the package for reporting issues with the bug tracking system itself, not general issues in packages (or the kernel.) I've reassigned this bug for you. On Sat, 29 Dec 2018, Patrick Boettcher wrote: > I did an apt upgrade this morning, I'm running testing/unstable. This updated > my kernels to 4.17.0-3-amd64 and 4.19.0-1-amd64. I think the first since a few > months (6 or more, but less then one year). >* What exactly did you do (or not do) that was effective (or > ineffective)? > > sudo apt update; sudo apt dist-upgrade > >* What was the outcome of this action? > > After rebooting to the new kernel booting stuck with some messages about mdadm > looking for a RAID I don't have. > > Ultimately the initramfs-shell came up and I found out that there are no > block- > devices loaded. /dev/sda* and /dev/nvme* did not exists. > > I manually modprobe'd nvme. Followed by CTRL-D and the boot continued. > > > > -- System Information: > Debian Release: buster/sid > APT prefers unstable > APT policy: (602, 'unstable'), (601, 'testing'), (600, 'stable'), (598, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.17.0-3-amd64 (SMP w/12 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_ALL > to default locale: No such file or directory > UTF-8), LANGUAGE=en_US:en (charmap=locale: Cannot set LC_ALL to default > locale: No such file or directory > UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > -- Don Armstrong https://www.donarmstrong.com When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. -- Edmund Burke "Thoughts on the Cause of Present Discontents"
Bug#917389: bugs.debian.org: please close down the debian-maintainers pseudo-package
On Fri, 28 Dec 2018, Mattia Rizzolo wrote: > On Fri, 28 Dec 2018, 8:36 a.m. Don Armstrong > On Thu, 27 Dec 2018, Mattia Rizzolo wrote: > > > While chasing down unused things, like the debian-maintainers@nm.d.o > > > alias, I noticed the debian-maintainers pseudo-package is still > > > available. > > > > > > Would it be possible to close or remove the pseudo-package? > > > What are the required steps? > > > > We can mark it deprecated; it should probably stay around so that no one > > can accidentally create a package called debian-maintainer. > > Can we remove the mail alias after doing so? Sure! [I should have it marked as deprecated later today.] -- Don Armstrong https://www.donarmstrong.com Every gun that is made, every warship launched, every rocket fired signifies [...] a theft from those who hunger and are not fed, those who are cold and are not clothed. This world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children. [...] This is not a way of life at all in any true sense. Under the cloud of threatening war, it is humanity hanging from a cross of iron. [...] [I]s there no other way the world may live? -- President Dwight D. Eisenhower, April 16, 1953
Bug#917389: bugs.debian.org: please close down the debian-maintainers pseudo-package
On Thu, 27 Dec 2018, Mattia Rizzolo wrote: > While chasing down unused things, like the debian-maintainers@nm.d.o > alias, I noticed the debian-maintainers pseudo-package is still > available. > > Would it be possible to close or remove the pseudo-package? > What are the required steps? We can mark it deprecated; it should probably stay around so that no one can accidentally create a package called debian-maintainer. -- Don Armstrong https://www.donarmstrong.com It's brief and bright, dear children; bright and brief. Delight's the lightning; the long thunder's grief. -- John Frederick Nims "Poetry in Motion" p31
Bug#775797: bugs.debian.org: BTS doesn't know about BPO versions; breaks apt-listbugs
On Wed, 28 Nov 2018, Colin Watson wrote: > On Tue, Jan 20, 2015 at 12:17:33AM -0500, Samuel Bronson wrote: > > It would be nice if you could process those changelogs, even if only > > for apt-listbugs' benefit. > > I heard a second-hand report today that this was deliberately not being > done on the grounds that some package maintainers don't want bugs > against backports to be filed in the BTS. I found the link to version > tracking in particular to be surprising, and I want to check that there > isn't a degree of "telephone game" happening here. From my perspective, I think we should be tracking the versioning of backport packages in the BTS; the only real reason I haven't done so is because I've lacked the time to drive the coordination required to move copy the .debinfo and .versions files from the backports archive, and make sure all of that is working. So if you do have the time to do so, that would be great. -- Don Armstrong https://www.donarmstrong.com Nearly all men can stand adversity, but if you really want to test his character, give him power. -- Abraham Lincoln
Bug#912223: auto-wrapping in the web interface Bad
On Wed, 31 Oct 2018, Peter Palfrader wrote: > On Tue, 30 Oct 2018, Don Armstrong wrote: > > On Mon, 29 Oct 2018, Peter Palfrader wrote: > > Heh; that one shouldn't be wrapped. We need something to do wrapping > > because people send messages which aren't wrapped either, so I'm > > going to try to tweak this to not fire on messages which look > > rectangular and still follow the 80 column wide convention. > > How many of those messages do not have > | Content-Type: []; format="flowed" A disturbing percentage, unfortunately. [We actually handle them with a separate CSS class.] -- Don Armstrong https://www.donarmstrong.com With one simple pill we cured unhappiness and art -- a softer world #437 http://www.asofterworld.com/index.php?id=437
Bug#912223: auto-wrapping in the web interface Bad
reassign 912223 debbugs retitle 912223 make auto-wrap heuristic smarter (see #912215) thanks On Mon, 29 Oct 2018, Peter Palfrader wrote: > debbugs tries to wrap messages such as > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912215#10 > in its web interface. > > This makes the message entirely unreadable. Heh; that one shouldn't be wrapped. We need something to do wrapping because people send messages which aren't wrapped either, so I'm going to try to tweak this to not fire on messages which look rectangular and still follow the 80 column wide convention. -- Don Armstrong https://www.donarmstrong.com Logs drowse in the pond Dreaming of their heroes Alligator and crocodile -- Vern Rutsala "Poetry in Motion" p77
Bug#912033: bugs.debian.org: Control pseudo-header does not support usertag command
severity 912033 wishlist retitle 912033 consider supporting usertag/user in Control: psuedo-header reassign 912033 debbugs user debb...@packages.debian.org usertag 912033 control On Sat, 27 Oct 2018, Dominik George wrote: > the user and usertag command are unknown to the BTS when processed from a > Control pseudo header in regular bug mail: > > > user debian-rele...@lists.debian.org > Unknown command or malformed arguments to command. > > > usertags -1 + bsp-2018-10-de-karlsruhe > Unknown command or malformed arguments to command. > > The exact same commands work when mailed directly to control@, though. That's correct, and is documented: "Allows for any of the commands which must be sent to cont...@bugs.debian.org to work". That said, I probably should require usertags to be sent to control, and change how that is parsed. I haven't yet done so, though. -- Don Armstrong https://www.donarmstrong.com [C]haos is found in greatest abundance wherever order is being sought. It always defeats order, because it is better organized. -- Terry Pratchett _Interesting Times_ p4
Bug#910360: debbugs: get_bug_log SOAP operation truncates message
On Sat, 13 Oct 2018, Michael Albinus wrote:
> > I like this approach better, but I'd suggest that we do something like:
> >
> > attachments => [{attachment_id => 1,
> > content_type => 'text/plain',
> > content_name => 'if defined',
> > # or whatever the right mime headers are; I forget
> > },]
> >
> >
> > and then another SOAP interface which does something like:
> >
> > get_bug_attachment($bug_num,$msg_num,$attachment_id)
>
> OK, I'll go along these lines.
Perfect, thanks!
> > Another option could be for the SOAP call just to return the entire
> > message without doing any MIME parsing; maybe that would be better?
>
> Hmm, isn't this possible already via
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712979;mbox=yes>?
True; though I think I'd like to avoid having the URLs be an API.
> And it has the disadvantage that the whole MIME parsing is left to the
> different SOAP clients.
Right; I think this is the main argument against this option (returning
whole message).
--
Don Armstrong https://www.donarmstrong.com
I finally developed
a computer with feelings.
It just doesn't have
feelings for me.
-- a softer world #633
http://www.asofterworld.com/index.php?id=633
Bug#910360: debbugs: get_bug_log SOAP operation truncates message
On Wed, 10 Oct 2018, Michael Albinus wrote:
> Since it returns just empty 'attachments' as of today, and it isn't
> specified anywhere what shall be in, it makes sense.
>
> > 2) MIME messages are much more complicated than just a list of
> > attachments; there could be additional messages with more attachments
> > within them
>
> Yes, although such nested attachments are rather rare in bug
> communication I guess.
The usual case where they exist is in forwarded messages or in the cases
where the BTS includes the original message as an attachment when the
bug is closed.
> Good idea. Shall I raise a (wishlist) bug report about?
There's a wishlist bug for it right now:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712979
On Thu, 11 Oct 2018, Michael Albinus wrote:
> The most simple way would be to handle any attachment like a message.
> 'header' would be the two lines 'Content-Type' and
> 'Content-Transfer-Encoding'. Every attachment would get a unique
> message number, like the messages themselves. 'get_bug_log' shall
> support the second argument $msg_num (which is still could be
> optional), in order to retrieve the bodies of attachments.
> Alternatively, we could have a structure in the attachments with just
> 'header' and 'msg_num', like
>
> --8<---cut here---start->8---
> [{header => '...',
>body=> '...',
>attachments => [{header => '...',
> msg_num => 11,
>},
> header => '...',
> msg_num => 15,
>},
>{header => '...',
> msg_num => 20,
>},
> ],
>msg_num => 5,
> },
> {header => '...',
>body=> '...',
>attachments => [],
>msg_num => 8,
> },
> ]
> --8<---cut here---end--->8---
I like this approach better, but I'd suggest that we do something like:
attachments => [{attachment_id => 1,
content_type => 'text/plain',
content_name => 'if defined',
# or whatever the right mime headers are; I forget
},]
and then another SOAP interface which does something like:
get_bug_attachment($bug_num,$msg_num,$attachment_id)
Another option could be for the SOAP call just to return the entire
message without doing any MIME parsing; maybe that would be better?
--
Don Armstrong https://www.donarmstrong.com
unbeingdead isn't beingalive
-- e.e. cummings "31" _73 Poems_
Bug#910894: spamass-milter: Socket permissions not set correctly if startup takes more than one second
On Fri, 12 Oct 2018, Will Aoki wrote: > If spamass-milter takes too long to create the socket after daemonizing > itself, the socket file will not exist when the startup script attempts > to change its permissions. MTAs relying on the permission change, such > as Postfix, will then be unable to communicate with the milter. > > This is a very rare condition: I've encountered it only once in years of > operation. It may have involved I/O contention with other VMs. > > The following appeared in the system log. Note that systemd thinks > spamass-milter startup failed, but spamass-milter was actually running. Yeah, you're absolutely right. The correct solution (for systemd) involves having systemd create the sockets with the right permissions, and then pass them on to spamass-milter but that requires significant changes to spamass-milter that I won't have time to create in the near future. I'll certainly accept patches which do that, though. -- Don Armstrong https://www.donarmstrong.com Of course, there are cases where only a rare individual will have the vision to perceive a system which governs many people's lives; a system which had never before even been recognized as a system; then such people often devote their lives to convincing other people that the system really is there and that it aught to be exited from. -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_
Bug#910360: debbugs: get_bug_log SOAP operation truncates message
On Mon, 08 Oct 2018, Michael Albinus wrote: > Well, get_bug_log is already prepared to return the attachments, it > just returns an empty array for the time being. As proof of concept, > I've implemented attachments for this function, see attached patch. > This needs *much* more polishing. On debbugs.gnu.org, we run a very > old version of the debbugs software, so I needed to merge my changes > into the recent version from the debbugs git repository, and I > couldn't test that result. Furthermore, I did only some very short > test runs (with the example which triggered this bug report); I'm > pretty sure the MIME multipart handling needs much more attention. There are two main reasons why I didn't really complete this part of the interface: 1) Returning large attachments in get_mail_log() would be fairly surprising to existing users of that interface; it should really return some kind of record of the MIME structure which could then be retrieved using a second interface 2) MIME messages are much more complicated than just a list of attachments; there could be additional messages with more attachments within them So instead of completing the engineering, I punted, and provided the important part of the interface (access to the main text part of the message), and left the unimportant part for as technical debt. I'd be happy to accept a patch which modified get_mail_log to also include the mime structure in attachments (or something like that), and a second SOAP API which provided a mechanism to retrieve those attachments. [As I think SOAP is a technical dead end, I also think that a REST API should probably do the same thing... but I'm really short on time.] -- Don Armstrong https://www.donarmstrong.com Grimble left his mother in the food store and went to the launderette and watched the clothes go round. It was a bit like color television only with less plot. -- Clement Freud _Grimble_
