Bug#1070304: util-linux: Please build and provide the cal binary
> The example was to show how people could achieve using ncal to get > cal, if the > ncal package would not ship a cal binary. Sure, but the only reason for the cal binary as it is, is to have the original cal available. All new and extended features are in ncal and are explicitly deactivated when called as cal. > This is *not* about forcing Monday, util-linux cal takes that from > the locale as > well, but when working in mixed locale settings or on a machine with > just > C.UTF-8, it is nice to be able to change it and the obvious "cal -M" > fails for > the ncal version, as does "cal -w". Requiring the use of ncal > (instead of cal) > and an option documented as "Use oldstyle format for ncal output" > seems highly > non-obvious to me. Well, there's also the option "-c" explained as: Completely switch to cal mode. For cal like output only, use -b instead. But anyway, there is a reason behind cal offering only the features it does. If you want all the additional bells and whistles you're free to alias cal to ncal for your system. > - util-linux cal doesn't provide the date of Easter, unlike ncal cal > - util-linux cal supports beginning of week and week number switches > for cal, > which do not work with ncal cal But it is supported in ncal. Again, think of cal as traditional-cal if that makes it easier. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org signature.asc Description: This is a digitally signed message part
Bug#1070304: util-linux: Please build and provide the cal binary
> I think that ship has sailed already, since e.g. -m in the ncal
> version
> specifies the month (a bit superfluously), whereas in the util-linux
> version it
> sets the beginning of the week to Monday.
Not sure why specifying the month is superfluous.
> An alternative I could see would be to drop cal from the ncal package
> and only
> provide cal from util-linux.
>
> Nothing would be lost, since ncal can act as cal with the -C option,
> so users
> wanting that specific cal could use a function
>
> cal() {
> ncal -C $@
> }
>
> and the rest would get a cal that can show week numbers and set the
> beginning of
> the Monday.
Now I'm confused. Is the reason for this proposal to have a cal that
shows week numbers and forces the start of the week to Monday? Well,
ncal does both of this, so why don't you just use something like "ncal
-wMb" as cal? Not that ncal needs "-M", it is able to get this from
your locale.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
signature.asc
Description: This is a digitally signed message part
Bug#1070304: util-linux: Please build and provide the cal binary
> > > Unfortunately the command line switches > > are not compatible and util-linux cal cannot display the date of > > Easter, so it > > is not drop-in compatible. It would nevertheless be great if e.g. > > an > > alternatives selection for util-linux cal could be provided. The question is does it offer all the other features? Or would we be better of switching to something like gcal instead? > I'm somewhat open to shipping util-linux's cal, but not if that > involves update-alternatives. Agreed. > Could you maybe work with upstream, so that util-linux's cal becomes > a drop-in replacement, and can work as both cal and ncal? > > Also, quite obviously is this something we want to do as Debian? > Michael, as the maintainer of the current ncal package, what is your > opinion here? I wouldn't mind getting rid of the old bsd code base. The package is heavily patched, which makes maintaining it a lot of work. I would not like to lose too many features, though. The main reason for keeping cal, however, namely having a version fully output compatible to the original one, might not be that valid anymore. After all it's 2024 already. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#1050091: hostname: VCS repository with all past releases
> > > you can find a DEP-14-compliant git repository with the history > > > of > > > the hostname package at > > > > > > https://salsa.debian.org/gioele/hostname > > > > > > My plan is to move this repo into the debian/ namespace in a few > > > weeks, unless you are against it. > > > > What is this? Are you trying to highjack the package? > > That must had been the most polite hijacking attempt ever. I even > spelled out the instructions to take the repo and make it yours. :) Let's agree to disagree. I find your behavior rather rude. > A search on tracker.d.o and all other metadata services showed no > record > of a VCS (because the VCS URLs are missing from d/control) as well as > a > not-yet-acknowledged NMU that happened in 2022. A new release to just acknowledge an NMU is a waste of time and bandwidth. Best, Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#998206: calendar: cronjob processes all users’ calendars as root, allowing information disclosure
All, > calendar.c forks, so there is no need to regain privileges post > setuid(). I'm kinda with tg in that setres[ug]id() makes the intent > clearer instead of relying on uid==0 behavior. FYI I just uploaded a new version of the package. It turned out setres[ug]id() are not declared in the current build process. I don't like adding the declaration manually and getting unistd.h to declare it would mean defining __USE_GNU which may or may not have side effects. Therefore I figured to play it safe and use set[ug]id() instead. Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#997174: netdiag: FTBFS: statnet.c:471:32: error: format not a string literal and no format arguments [-Werror=format-security]
Hi Reiner, > I've prepared an NMU for netdiag (versioned as 1.2-1.2) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. Please go ahead, I wouldn't mind it being uploaded without delay. Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#1007059: hostname: please consider upgrading to 3.0 source format
On Thu, Mar 10, 2022 at 10:06:58PM +0100, Lucas Nussbaum wrote: > This package is among the few (1.9%) that still use source format 1.0 in > bookworm. Please upgrade it to source format 3.0, as (1) this format has many > advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) > this contributes to standardization of packaging practices. I doubt this makes any sense because hostname is a Debian native package and thus will never receive any patches. Or is there any other reason to migrate a native package? Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#998206: calendar: cronjob processes all users’ calendars as root, allowing information disclosure
> As
> I understand it, this is the POSIX way. Anyway, I'm going to prepare
> a
> patch.
I did some more testing and it seems this simple patch fixes the issue:
--- calendar.c 2021-12-07 17:53:16.044315761 +0100
+++ calendar.c 2021-12-07 08:59:20.293726904 +0100
@@ -190,6 +190,8 @@
case 0: /* child */
(void)setpgid(getpid(), getpid());
(void)setlocale(LC_ALL, "");
+ if (setgid(pw->pw_gid) != 0 ||
setuid(pw->pw_uid) != 0)
+ err(1, "unable to switch to
user %u group %u", pw->pw_uid, pw->pw_gid);
if (acstat) {
if (chdir(pw->pw_dir) ||
stat(calendarFile, )
!= 0 ||
Any comments?
@security team: Do you want me to prepare a fix for stable, too?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Bug#998206: calendar: cronjob processes all users’ calendars as root, allowing information disclosure
> > Could you elaborate why? I cannot see much of a difference in these > > when it comes to the topic at hand. Doesn't set[ug]id set all ids > > to > > the given one? > > No, it only sets one of the three (real, effective and saved) uid/gid > to the given one; setres[ug]id() is the one that sets them all. Actually I think that's only correct if you're running under a non-root uid. If your effective uid is 0 all uids will be set to the given value and thus there is no way back for the application to be root again. As I understand it, this is the POSIX way. Anyway, I'm going to prepare a patch. Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#998206: calendar: cronjob processes all users’ calendars as root, allowing information disclosure
> >Wouldn't using setuid() suffice? > > I doubt that. At least change the gid and reset the auxilliary Sure, make that setuid() and setgid(). > groups vector. But using setres[ug]id() is safer, especially > considering each instance shells out to cpp(1), which would > then otherwise be suid-user. Could you elaborate why? I cannot see much of a difference in these when it comes to the topic at hand. Doesn't set[ug]id set all ids to the given one? Why is that less safe? Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#998206: calendar: cronjob processes all users’ calendars as root, allowing information disclosure
> I did manage to cobble together something that at least switches > to users properly… search for USE_CUSTOM_USERSWITCH or userswitch in > http://www.mirbsd.org/cvs.cgi/src/usr.bin/calendar/calendar.c?rev=HEAD > combined with… > ... Wouldn't using setuid() suffice? Yes, I know setusercontext() does more, but in this case we only need to make sure the right user opens the file. Or what am I missing? Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#998206: calendar: cronjob processes all users’ calendars as root, allowing information disclosure
[Sorry, I have missed this bug report, didn't make it into the correct mailbox locally it seems.] On Mon, Nov 01, 2021 at 12:02:48AM +, Thorsten Glaser wrote: > #define·ssh·Nov·01→ ssh > #include·"/root/.ssh/authorized_keys" Hmm, not sure what I'm doing wrong. Using the same entries in my calendar file I get: michael@feivel:~$ calendar :3:2: fatal error: /root/.ssh/authorized_keys: Permission denied compilation terminated. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye
severity 982758 important thanks > I tried with a stable chroot, then installed all the webext* packages you have > installed and then upgraded webext-browserpass. Works like a charm. By now I've ran more test up to a full system dist-upgrade with all webext* packages installed, not a single failure. > > Good question. My gut feeling at least says that the RC severity is > > justified as quite some people ran into it and it actually causes apt > > to abort in a quite nasty way. > > I see your point, the problem is with this setting nobody is getting the > software because of some of us having issues in the upgrade. I'd love to get > this fixed before the freeze, but no matter what I tried I cannot reproduce. Given that freeze is nearing and nobody's volunteering any additional information and the bug has proven to be not reproducible, at least for me, I downgrade it again. Yes, it can be very severe but removing the package for everyone doesn't seem right either. Maybe by keeping it in we will get more data to find out where the problem lies. I'm more than willing to look into it again and fix it once we identify the reason. Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye
Hi all, > Indeed. Using a clean Sid chroot, installing webext-browserpass from > Buster and then upgrading does not exhibit this issue. I tried with a stable chroot, then installed all the webext* packages you have installed and then upgraded webext-browserpass. Works like a charm. > Good question. My gut feeling at least says that the RC severity is > justified as quite some people ran into it and it actually causes apt > to abort in a quite nasty way. I see your point, the problem is with this setting nobody is getting the software because of some of us having issues in the upgrade. I'd love to get this fixed before the freeze, but no matter what I tried I cannot reproduce. > I currently suspect a relation to respectively overlap with a similar > symlink/directory switch of maybe one of the directories mentioned > above. I thought so, too, but again, cannot identify the culprit. > (It also seems important to not just remove but really purge the > current package in case it was installed befotrehand. But I assume you > either did that or used a fresh install.) Yeah, the latter. > Will soonish upgrade another productive Buster desktop to Bullseye > where webext-browserpass is installed. Will have a close eye on the > moment when upgrading webext-browserpass respectively will upgrade > that package in a separate package upgrade from the remainder. Did you find out anything more? Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye
Hi all,
> Preparing to unpack .../370-webext-browserpass_3.7.2-1+b1_amd64.deb ...
> Unpacking webext-browserpass (3.7.2-1+b1) over (2.0.22-2) ...
> dpkg: error processing archive
> /tmp/apt-dpkg-install-VKYulC/370-webext-browserpass_3.7.2-1+b1_amd64.deb
> (--unpack):
>unable to open
> '/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserp...@maximbaz.com/icon.png.dpkg-new':
> No such file or directory
> Reinstalling
> /etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json that
> was moved away
I'm with Daniel on this one as I cannot reproduce it either:
Preparing to unpack .../webext-browserpass_3.7.2-1+b1_amd64.deb ...
Unpacking webext-browserpass (3.7.2-1+b1) over (2.0.22-2) ...
Setting up webext-browserpass (3.7.2-1+b1) ...
Removing obsolete conffile
/etc/chromium/native-messaging-hosts/com.dannyvankoote
n.browserpass.json ...
Something fishy is going on here. I'm not sure how to find out what though if I
cannot reproduce it. Also I wonder if removing the package from testing is
helpful or even correct in such a case. Anyway, any idea how to find out what's
going on and what is different on your systems? For instance I tried on a sid
system where I install the old browserpass package. Did everyone with the error
see it on a dist-upgrade only? Could you test on sid?
Thanks,
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Bug#968920: avfs: AVFS only shows a subset of the files in dar archives.
Hi Adam, thanks for reporting this bug. > * What led up to the situation? I mounted a dar archive, and > attempted to > enter it. >* What exactly did you do (or not do) that was effective (or > ineffective)? Once in the archive, I ran "ls" and saw that many > files > and directories were missing. I think I may have found the reason and will upload a fixed version to unstable in a few minutes. If this doesn't work, or the next time you report a bug, please include the commands you used making it easier to reproduce the issue. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#957230: Bug#966370: bsdmainutils: 12.1.3 removal of lorder breaks rdeps
> > I'm surprised it is actually used as it was pointed out to me that > > the script > > has been non-functional for quite a while. > > I do recall having an issue with it at one point a few years back and > meaning to submit a patch to bsdmainutils to fix it, but resolved it > one way or another without that, though can't find any evidence of > that > nor can I remember what the problem was. But regardless, it was > working > well enough for the freebsd-* packages to build fine. My guess would be that its functionality is not needed at all. > > Anyway, it cannot easily be "restored" > > because the old bsdmainutils package does not exist anymore. All > > tools except > > ncal and calendar, which are now in their own package, are now > > build out of > > util-linux. Would it be possible to include lorder.sh in one of the > > affected > > freebsd packages? > > Yeah, it's possible, and that's no doubt what I'll end up doing. But > I I'm glad you agree, I will therefore close this bug. > really don't appreciate all the breakage that's come about from > bsdmainutils in the past few months. The util-linux handover was Pas few months is a slight exaggeration but whatever. > poorly-handled causing all kinds of problems across the archives It is well documented that the changes caused more issues than expected, but all packages received the necessary fixes as quickly as possible. Having to go through NEW certainly caused some delay, too, but again stuff like this happens, it's called unstable for a reason. > (release and ports), and this removal of something, and thus > *deliberately breaking* the package's "API", should have been done > more > carefully by checking whether anyone is actually using it (archive- > wide > rebuilds like is done for the new GCC versions is the > easy-but-computationally-expensive way to do it). As it stands, I got Come again please? Is this a joke or are you really suggesting we should rebuild the whole archive to figure out if any package still uses a non-functional tool in its build process? > hit with a surprise set of RC bugs from the first archive-wide > rebuild > after this change landed, and I therefore have to react in a > time-pressured way to fix it lest packages be removed from testing > (though, arguably, testing doesn't matter so much for these given > kfreebsd-* aren't release architectures). This really should have So why do you bring up this point then? > been > found out first, with Severity: important bugs filed a month or more > in > advance of making the change, that can then be upgraded to be > release-critical further down the line. So, please, never do a > transition like this again. Just for the record, I do not consider removing lorder.sh a transition of any kind. Nor do I think removing a faulty tool that apparently had no real functionality anymore warrants the kind of lecture you're giving me. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#930736: solstices and equinoxes are wrongly reported in the Russian calendar
> > So you are saying the caledar file is not correct, right? > > Nope, calendar file is correct! Actually it turned out it wasn't. Some over-eager patching removed the locale information and thus calendar couldn't handle any Russian names. I already fixed it in git, the next upload will close the bug. Thanks for reporting. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#957230: Bug#966370: bsdmainutils: 12.1.3 removal of lorder breaks rdeps
On Mon, Jul 27, 2020 at 03:01:31PM +0100, Jessica Clarke wrote: > Package: bsdmainutils > Version: 12.1.3 > Severity: serious > Control: affects -1 src:freebsd-buildutils src:freebsd-glue src:freebsd-libs > > Hi, > The removal of lorder in 12.1.3 causes various freebsd-* packages to > FTBFS which are now scheduled for autoremoval from testing. Please > restore this shell script; it's not deprecated, it's still widely used > by the BSDs and maintained in at least FreeBSD. I'm surprised it is actually used as it was pointed out to me that the script has been non-functional for quite a while. Anyway, it cannot easily be "restored" because the old bsdmainutils package does not exist anymore. All tools except ncal and calendar, which are now in their own package, are now build out of util-linux. Would it be possible to include lorder.sh in one of the affected freebsd packages? Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#930736: solstices and equinoxes are wrongly reported in the Russian calendar
On Wed, Oct 30, 2019 at 10:12:14PM +0300, sergio wrote: > If you look attentively at the output you'll see quite all equinox and > solstice in the same output: > ... So you are saying the caledar file is not correct, right? Unfortunately I neither read nor write Russian, so there is not much I can do about it, but if you'd provide a patch, I'd be more than willing to incorporate it. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#964566: ncal: please handle /usr/bin/cal + manpage via alternatives
On Thu, Jul 16, 2020 at 03:43:24PM +, Thorsten Glaser wrote: > Michael Meskes dixit: > > >Do you have any documentation about the US system that is kind of > >official? I doubt anyone in the States uses week numbers, but there may > >be an official way nonetheless. > > https://de.wikipedia.org/wiki/Woche#Berechnung_in_den_USA_und_vielen_anderen_L%C3%A4ndern Oh right, the German version knows how it's done in the States but the English one doesn't. Please excuse me if I don't really accept this as fact, particularly as the page itself claims that the information is not verifiable and needs references. > Also as an example: > > $ kwal -mw 1 2005 > January 2005 > Mo Tu We Th Fr Sa Su > 1 2 [53] > 3 4 5 6 7 8 9 [ 1] > 10 11 12 13 14 15 16 [ 2] > 17 18 19 20 21 22 23 [ 3] > 24 25 26 27 28 29 30 [ 4] > 31 [ 5] > $ kwal -w 1 2005 > January 2005 > Su Mo Tu We Th Fr Sa >1 [ 1] > 2 3 4 5 6 7 8 [ 2] > 9 10 11 12 13 14 15 [ 3] > 16 17 18 19 20 21 22 [ 4] > 23 24 25 26 27 28 29 [ 5] > 30 31[ 6] > $ ncal -w 1 2005 > January 2005 > Su 2 9 16 23 30 > Mo 3 10 17 24 31 > Tu 4 11 18 25 > We 5 12 19 26 > Th 6 13 20 27 > Fr 7 14 21 28 > Sa 1 8 15 22 29 >52 1 2 3 4 5 > > The first one is correct for Germany. The second one is correct for USA > according to that documentation above. The third… whatever it is, is what > ncal does. Unfortunately you didn't tell us which locale you ran it under, but anyway, let's have a look: $ export LC_ALL=de_DE.UTF8; ncal -bw 1 2005 Januar 2005 w| Mo Di Mi Do Fr Sa So 53| 1 2 1| 3 4 5 6 7 8 9 2| 10 11 12 13 14 15 16 3| 17 18 19 20 21 22 23 4| 24 25 26 27 28 29 30 5| 31 Except for formatting changes this is exactly your case 1, right? As for the second, see above. Unless proven wrong I stick with what the locale gives me. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
Bug#964566: ncal: please handle /usr/bin/cal + manpage via alternatives
> … but they all look only for _NL_TIME_WEEK_1STWEEK, not for the > mode of how the weeks are calculated. I know at least two, ISO In fact there are three different queries, for _NL_TIME_WEEK_1STWEEK, _NL_TIME_WEEK_1STDAY, and _NL_TIME_FIRST_WEEKDAY. > (first week-of-year has at least 4 days/4ᵗʰ January/1ˢᵗ Thursday) > and USA (both 1ˢᵗ January *and* every Sunday begin a new week, > so short weeks are possible). Do you have any documentation about the US system that is kind of official? I doubt anyone in the States uses week numbers, but there may be an official way nonetheless. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#964566: ncal: please handle /usr/bin/cal + manpage via alternatives
On Wed, 2020-07-15 at 18:50 +, Thorsten Glaser wrote: > Michael Meskes dixit: > > >> b�& nor does ncal use the locale for this, so, no, it does not use > >> appropriate calendar week calculation rules. > > > >This is simply not true since it definitely does. > > I looked before writing that eMail, so it’s true; ncal uses the > locale > to look up a country code, which then is used to determine the date > of > the julian→gregorian calendar switch. That’s it exactly, nothing > more. Huh? I don't think so: $ grep -r nl_langinfo ncal/* ncal/calendar.c:if ((wd = weekday(nd) + 1 - weekstart) >= *nl_langinfo(_NL_TIME_WEEK_1STWEEK)) ncal/ncal.c:u.str = nl_langinfo(_NL_TIME_WEEK_1STDAY); ncal/ncal.c:weekstart = *nl_langinfo(_NL_TIME_FIRST_WEEKDAY) + (ndaysj(_week_d) - ndaysj()) % 7 - 1; Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#964566: ncal: please handle /usr/bin/cal + manpage via alternatives
> >I haven't seen any error in ncal so far, but if you see some it > might > > … nor does ncal use the locale for this, so, no, it does not use > appropriate calendar week calculation rules. This is simply not true since it definitely does. > >be more helpful to report and/or fix those as ncal should not show > > I’m honestly not interested in working on ncal, given I don’t even > use > it and have a perfectly working implementation (I *did*, initially, > plan on patching ncal to support various standards for calendar week > calculation, until I found that OpenBSD’s cal already has them > right). Fair enough, but you could at least report these cases. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#964566: ncal: please handle /usr/bin/cal + manpage via alternatives
> The locale doesn’t contain enough information to calculate calendar > weeks: > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html Well, our locales do I think. > There’s neither a data field for the first day of the week, nor one > for > the various ways to calculate a calendar week. But there are, for instance: michael@feivel:~$ locale -kc week-1stweek LC_TIME week-1stweek=1 > In the end I just need a reliable way to get at German (= ISO) > calendar weeks, for use in business environments, and found that, > rather than having to write code myself, I could use OpenBSD’s cal, > which has an option for specifically this (although only for years > 1753‥, same as ncal). I haven't seen any error in ncal so far, but if you see some it might be more helpful to report and/or fix those as ncal should not show incorrect data. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#964566: ncal: please handle /usr/bin/cal + manpage via alternatives
> >Could you please elaborate what (n)cal miss? "ncal -w" does give you > >week numbers > > But which ones? American? German? ISO? (Turns out the latter two are Depends on the locale you use. > identical.) This is completely underdocumented and doesn’t match > expectations; even the “week begins with sunday/monday” knobs don’t > promise anything as the American and ISO ways of counting weeks are > still distinct. No idea what you are saying, sorry, please elaborate. > It also has a different output format from traditional. As mentioned in my previous email, you can use the -b switch to get back to traditional format. > I understand if you find this too bothersome to do in Debian for > such a (corner?) case, but that is why this is of wishlist severity > ;) Na, the problem is understanding what's missing, or wrong. :) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#964566: ncal: please handle /usr/bin/cal + manpage via alternatives
On Wed, Jul 08, 2020 at 09:13:50PM +0200, Thorsten Glaser wrote: > I’ve packaged (some time ago already) cal(1) from OpenBSD, because > it/its documentation guarantees a flag to get German calendar weeks > (KWs) as “kwal” (specifically for that). Could you please elaborate what (n)cal miss? "ncal -w" does give you week numbersand if you prefer the classical layout you could use "ncal -bw". Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#964415: Please don't depend on calendar
On Mon, Jul 06, 2020 at 02:34:14PM -0700, Josh Triplett wrote: > I appreciate that bsdmainutils is becoming a transitional package; > however, please don't depend on the "calendar" package (which runs a > regular cron job). Several packages still depend on bsdmainutils for > other utilities it shipped, and not for calendar; it'll likely remain > installed for a while during that transition. Please consider moving the > calendar package to "recommends". I tried that, which create a lot of problems with the config file handling. A matter that is still not completely fixed. Instead of having bsdmainutils recommend calendar I'd rather see the build dependencies changed to the correct package. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#964389: bsdmainutils: leftover config files
On Mon, Jul 06, 2020 at 05:40:24PM +0200, Chris Hofstaedtler wrote: > It appears there is some gap in the necessary cleanups in > bsdmainutils. My "unstable" system has these files listed as owned > by bsdmainutils: > ... Gheez, I should have done a hard dependency from the get go. I guess this comes from one update that didn't bring in calendar. Anyway, could you please verify for me that there are no config files in your calendar package? Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#964242: bsdmainutils: depends on non-existing version of bsdextrautils
On Sat, Jul 04, 2020 at 10:52:04AM +0200, Rene Engelhard wrote: > But that bsdextrautils (>= 2.35.2-7) doesn't exist: Yes, as already communicated we had to wait with the next util-linux upload until bsdmainutils made it out of NEW. Now that it has, Chris will upload as soon as he finds the time. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963905: bsdmainutils: conffiles not removed: /etc/default/bsdmainutils /etc/cron.daily/bsdmainutils /etc/calendar/default
On Mon, Jun 29, 2020 at 12:50:51AM +0800, Paul Wise wrote: > Package: bsdmainutils > ... > > The recent upgrade did not deal with obsolete conffiles properly. > Please use the dpkg-maintscript-helper support provided by > dh_installdeb to remove these obsolete conffiles on upgrade. This should be fixed with the upload stuck in NEW. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: PGP signature
Bug#946726: bsdmainutils: [calendar] -a results in loop, sending lots of mail
Hi, On Sat, Dec 14, 2019 at 09:00:23PM +0100, Axel wrote: >* What led up to the situation? > > I created ~/.calendar/calendar and then tried 'sudo calendar -a'. This > causes a loop sending lot's of email. It happens with any calendar > file, e.g. > ... Do you still see the problem? If so, could you try on a fresh installation? I tried quite a bit, but cannot reproduce the problem. Given that this is exactly what the cron job does I would expect more reports if this was a general problem. Doesn't mean we shopuld find out what's going on, though. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> I mentioned this in a previous email: the problem is if the upgrade > breaks and the admin has to consult man pages to work out how to fix > it. > (I did just that less than an hour ago in another situation, so I > don't > think this is a theoretical concern.) Another good point, thanks for clarifying. As mentioned in another email, I'm going to make bsdmainutils a transitional package, making this issue mood. Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963327: [Pkg-zsh-devel] Processed: Merge duplicates
> Build breakage out of the void is not nice, usually maintainers > inform > reverse build dependencies them before making such a breaking change. Yes, correct, and I'm sorry about this. It simply didn't occur to me that the change would create a build breakage. > The majority of users are using the default of treating Recommends > as dependencies, for them it doesn't make any difference whether > Recommends or Depends is used. > > Not installing Recommends is supported, and desirable in many > embedded/server/container scenarios. That's why bsdmainutils Recommends bsdextrautils and always has. The only argument here is whether it should be a hard Depends instead. > Installing bsdmainutils from unstable in buster breaks commands like > man ncal | cat > I would not be surprised if there is somewhere in Debian some package > that would do something like that for whatever good or bad reason in > a postinst or prerm. I didn't find any usage of man in a postinst on my system, but I have not checked all packages. > BTW: The naming of the packages is confusing. Agreed. > "extra" sounds like the more obscure utils, > enhanching the more commonly used "main" tools. > Looking at the tools shipped, the opposite seems to be true. Correct, this has to do with the old naming. The more obscure tools are still build out of the bsdmainutils sources. > One could make the point that bsdmainutils should > be a (transitional?) metapackage depending on all > the tools it previously provided. That's my thinking, too. The remaining tools in bsdmainutils are ncal (which should go into a separate package) and a few tools we could switch to util-linux or remove. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> > Any idea how this scenario could unfold? I cannot imagine how it > > could > > get there. What I will do, though, is add a "Breaks: man-db > > (<<2.9.3- > > 1)" to bsdmainutils. Actually this is already in git. > > Breaks only ensures that new bsdmainutils can't be unpacked until > man-db > is deconfigured. For example, it would still permit this plausible > upgrade ordering, which AFAIK apt would have no particular reason to > avoid: > > 1. deconfigure old man-db > 2. unpack new bsdmainutils > 3. configure new bsdmainutils > 4. (piles of other stuff) > 5. unpack bsdextrautils > 6. unpack new man-db > 7. configure bsdextrautils > 8. configure man-db > > man would be broken between the end of step 1 and the end of step > 5. I > think this is undesirable and unnecessary. Good points. However, I still don't see where this creates problems in the upgrade process unless some postinst calls man. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> However, in order to make buster → bullseye upgrades work properly, I > think it's necessary to have bsdmainutils depend on bsdextrautils for > at > least one release cycle. Otherwise there may be a point during the > upgrade where col isn't installed and so man will be broken; it's > worth > putting some effort into avoiding that because if the upgrade happens > to > break then users may need to consult man pages to work out what to > do. > The only reliable way I can think of to avoid this kind of problem is > to > have a hard dependency for a while as a transitional measure. Any idea how this scenario could unfold? I cannot imagine how it could get there. What I will do, though, is add a "Breaks: man-db (<<2.9.3- 1)" to bsdmainutils. Actually this is already in git. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, 2020-06-22 at 20:57 +0200, Julien Cristau wrote: > On Mon, Jun 22, 2020 at 19:46:21 +0200, Michael Meskes wrote: > > > > Depending on bsdmainutils to get col et al seems entirely right, > > > it's > > > been right forever, there doesn't seem to be a reason to break > > > that > > > both > > > for dependent packages and for end users. Especially not without > > > notice. > > > > There is no point arguing against your "do not change anything" > > attitude. > > > I'm not saying don't change anything, I'm saying don't break stuff > for > users for no reason. You are saying the reason is "it's been right forever". The reason for this move is moving from the old and heavily patched BSD source to the more up-to-date GNU version. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> Depending on bsdmainutils to get col et al seems entirely right, it's > been right forever, there doesn't seem to be a reason to break that > both > for dependent packages and for end users. Especially not without > notice. There is no point arguing against your "do not change anything" attitude. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> I think it's probably best at this point to have bsdmainutils depend > on > bsdextrautils. That gets rid of the breakage in the place where it > originated, and doesn't leave things without a transition path. I beg to disagree, there is a transition plan, namely depending on the right package. Things change, that's what unstable is for. Depending on bsdmainutils to get bsdextrautils does not sound right to me. We have to make the change eventually. And keep in mind that there may be other breakages as we changed sources for col et al. I am not aware of any, and I assume Chris isn't either, but there still may be some incompatibilities. I don't see the point of postponing the switch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> I don't know what Julien had in mind, presumably worried about other > breakage to surface. Note that obvious fix to man-db will all > debhelper > using packages transitively build-depending on bsdextrautils. Instead of bsdmainutils, yes. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, 2020-06-22 at 11:37 -0300, David Bremner wrote: > Michael Meskes writes: > > > > IMO the move of col needs to be rolled back ASAP. And, if it is > > > to > > > > Why? Care to give a reason? > > > > The change broke man-db, as I explained in a previous message. Oh, that I understand and I'm sorry I didn't notice that issue before, but why is rolling back preferable over fixing man-db? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> IMO the move of col needs to be rolled back ASAP. And, if it is to Why? Care to give a reason? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> 'm adding the maintainers of util-linux (bsdextrautils) and > bsdmainutils > to Cc. Which path forward do you see for this issue? A similar issue > seems to affect many packages, such as: > ... It seems to me there are two options here, either we ask all those packages to change the dependency or we force bsdextrautils installation by making bsdmainutils depend on it. When changing the package I decided against a hard dependency because it forces people to install something even if they don't need/want it without a technical reason. And quite frankly I think the build dependency should be to the package that is needed directly and not through another one. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963327: [Pkg-zsh-devel] Processed: Merge duplicates
> I already updated the title of the mass-merged bug to > "bsdmainutils must depend on bsdextrautils". > > This is anyway mandatory for not breaking upgrades from buster. Would you care to elaborate? I didn't find anything that mandates a dependency over a recommendation. Yes, it does break build dependencies but imo they should be changed anyway. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#952731: xkb-data: Italian keyboard layout not working in some apps
> Sorry to hear that, but I wonder if this is actually triggered by > something else.. at least I'm not able to reproduce it with .fi layout > on ubuntu focal.. Even if the package is exactly the same I don't see how a "I cannot reproduce on Ubuntu" is helpful, sorry. There may be any number of packages that make it work there but not here. Anyway, it seems all layouts are not working, for me it's "de". A manual "setxkbmap de" does fix the issue, though. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#946198: Since upgrading to 1.25.13 no remote printer is made available anymore
Hi Till, it's been a while since we last met. I hope you're doing well. > I have done several fixes on cups-filters upstream now, please try a > current GIT > snapshot of cups-filters. Just tried and don't really see a difference: Thu Dec 12 09:50:50 2019 Unable to get PPD file for B...: The printer or class does not exist. Thu Dec 12 09:50:50 2019 Unable to load PPD from local queue B..., queue seems to be raw. Thu Dec 12 09:50:50 2019 Queue has still jobs or CUPS error! Thu Dec 12 09:50:50 2019 ERROR: Failed disabling printer 'B...': The printer or class does not exist. Anything I can try to narrow the issue down? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#946198: Since upgrading to 1.25.13 no remote printer is made available anymore
> Which printers list? An application dialog? Oops, sorry, I was referring to the printers tab on localhost:631. In the add printer dialog on the administration tab they are still listed. All application dialogs do not list the printers anymore either. > The outputs of 'lpstat -a' and 'lpstat -l -e', please. Activating > logging 'lpstat -a' does not list any of the printers, 'lpstat -l -e' lists them all. > in cups-browsed.conf and taking a look at a log wouldn't be a bad > idea. Fri Dec 6 11:00:58 2019 Removing entry B... (ipps://host.local:631/printers/B...) and its CUPS queue. Fri Dec 6 11:00:58 2019 Recording printer options for B... to /var/cache/cups/cups-browsed-options-B... Fri Dec 6 11:00:58 2019 Unable to get PPD file for B...: The printer or class does not exist. Fri Dec 6 11:00:58 2019 Unable to load PPD from local queue B..., queue seems to be raw. Fri Dec 6 11:00:58 2019 ERROR: Failed disabling printer 'B...': The printer or class does not exist. I guess that explains why the printer is no longer active, but what changed from the prior version of cups-browsed? I just verified again, downgrading cups-browsed from 1.25.13-1 to 1.25.12-1 fixes the problem and makes the printers appear again. And, yes, I can print on any of them without an issue. Or in other words, the system does have a PPD for the printer. Any idea? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#946198: Since upgrading to 1.25.13 no remote printer is made available anymore
Package: cups-browsed Version: 1.25.13-1 Severity: serious Since upgrading the package all remote printers are gone from my printers list. Downgrading to the latest version brings them all back. I made this bug serious in case the problem is a general one. If not, feel free to downgrade. Upgrading the package and losing the ability to print in the process is an unpleasant surprise, though. Michael -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_FORCED_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-browsed depends on: ii cups-daemon 2.3.0-7 ii libavahi-client3 0.7-4+b1 ii libavahi-common3 0.7-4+b1 ii libavahi-glib10.7-4+b1 ii libc6 2.29-3 ii libcups2 2.3.0-7 ii libcupsfilters1 1.25.13-1 ii libglib2.0-0 2.62.3-2 ii libldap-2.4-2 2.4.48+dfsg-1+b2 ii lsb-base 11.1.0 Versions of packages cups-browsed recommends: ii avahi-daemon 0.7-4+b1 cups-browsed suggests no packages. -- no debconf information
Bug#942349: buster-pu: package ublock-origin/1.18.4+dfsg-2
> > {+ if dpkg --compare-versions "$2" lt 3.0-1; then+}
> >
> > Why is the compared version there 3.0-1 when the extension is only
> > at
> > 1.22.2?
>
> I don't know. I presume Michael wanted the preinst script to execute
> in
> any circumstances?
To me it looks like a copy error that has gone unnoticed till
now. Sorry, this seems to be my bad, but I do not recall putting that
version number in. It certainly was not done on purpose.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
signature.asc
Description: This is a digitally signed message part
Bug#931855: rpc.rquotad takes 100% CPU
Hi Mark, > I've just hit this bug in buster and tested the patch and it > works. I'd > like to prepare an update for stable (as it's already fixed in 4.05 > in > unstable), would that be ok? Yes, please, I completely ran out of time. Thanks a lot. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Bug#875208: [tora] Future Qt4 removal from Buster
> > It's now the last one, so if I don't hear back soon that someone > > intends to > > upgrade this to Qt5, I'll file for the rm. > > Adding the primary uploader to CC. I'm not using the tool anymore, nor do I have time to take care of it. The only reason why I didn't orphan it, is that somebody inb the group might be willing to, but apparently not. So in short, go ahead. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#931855: rpc.rquotad takes 100% CPU
> It's probably the bug reported below: > https://sourceforge.net/p/linuxquota/feature-requests/16/ Can you try if this patch fixes the problem? That way we could make sure there is not something else at play on your system. If it does, we should see if we can get an update into a point release. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#932786: O: acpi-support -- scripts for handling many ACPI events
Package: wnpp Severity: normal I intend to orphan the acpi-support package. The package description is: This package contains scripts to react to various ACPI events. It only includes scripts for events that can be supported with some level of safety cross platform. . It is able to: * Detect loss and gain of AC power, lid closure, and the press of a number of specific buttons (on Asus, IBM, Lenovo, Panasonic, Sony and Toshiba laptops). * Suspend, hibernate and resume the computer, with workarounds for hardware that needs it. * On some laptops, set screen brightness. . Besides some system tools acpi-support recommends vbetool to be able to power off the screen and some screensavers to be able to lock the screen on lid close. I lack the bandwidth to take care of this package and fortunately my systems don't need it anymore. Michael
Bug#932785: O: acpid -- Advanced Configuration and Power Interface event daemon
Package: wnpp Severity: normal I intend to orphan the acpid package. The package description is: Modern computers support the Advanced Configuration and Power Interface (ACPI) to allow intelligent power management on your system and to query battery and configuration status. . ACPID is a completely flexible, totally extensible daemon for delivering ACPI events. It listens on netlink interface (or on the deprecated file /proc/acpi/event), and when an event occurs, executes programs to handle the event. The programs it executes are configured through a set of configuration files, which can be dropped into place by packages or by the admin. Modern computers support the Advanced Configuration and Power Interface (ACPI) to allow intelligent power management on your system and to query battery and configuration status. . ACPID is a completely flexible, totally extensible daemon for delivering ACPI events. It listens on netlink interface (or on the deprecated file /proc/acpi/event), and when an event occurs, executes programs to handle the event. The programs it executes are configured through a set of configuration files, which can be dropped into place by packages or by the admin. I do not need the package anymore and lack the bandwidth to take care of it. Michael
Bug#931939: O: acpitool -- command line ACPI client
Package: wnpp Severity: normal I intend to orphan the acpitool package. The package description is: AcpiTool is a Linux ACPI client. It's a small command line application, intended to be a replacement for the apm tool. The primary target audience are laptop users, since these people are most interested in things like battery status, thermal status and the ability to suspend (sleep mode). The program simply accesses the /proc/acpi or /sysfs entries to get or set ACPI values. It also supports various extensions for Toshiba, Asus, and IBM Thinkpad laptops. Michael
Bug#931868: O: libcitadel -- Development files for libcitadel4
Package: wnpp Severity: normal I intend to orphan the libcitadel package. The package description is: This library contains the commonly used routines for the citadel suite. . This package provides development files and static libraries. I have not used the package for ages and lack the resources to keep maintaining i t. Michael
Bug#931865: O: citadel-client -- complete and feature-rich groupware server (command line client)
Package: wnpp Severity: normal I intend to orphan the citadel-client package. The package description is: This is package contains the command line client for Citadel, a complete and feature-rich open source groupware platform. . See the 'citadel-server' package for more information. I have not used the package for ages and lack the resources to keep maintaining i t. Michael
Bug#931864: O: webcit
Package: wnpp Severity: normal I have not used the package for ages and lack the resources to keep maintaining i t. Michael
Bug#931862: O: citadel
Package: wnpp Severity: normal I have not used the package for ages and lack the resources to keep maintaining it. Michael
Bug#923871: [Pkg-acpi-devel] Bug#923871: acpid: please provide runscript file
On Fri, 2019-06-21 at 10:17 +, Dmitry Bogatov wrote: > [ You replied in private, I took liberty to put BTS back into CC ] And what or who gave you the right to put my private comments into the public BTS? At the very least this is very rude, especially given that you did it on purpose. > > Feel free to upload directly, or if you want, fully take over the > > package. As it stands the package is essentially orphaned as I have > > neither the time not the usage for it anymore. I was thinking of > > officially orphaning it after the release. > > Thank you for your response. > > If you are positive on orphaning package, probably filing Orphan bug > right now would simplify some things: my upload would additionally > reassign maintenance to QA group. Please read what I wrote. There is a reason why I want to do this *after* the release. > I think it is very important for orphaned packages have QA group as > maintainer, otherwise it could scare away prospective new maintainer. Thanks for the lecture. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#927982: chromium: native messaging issues
On Fri, Apr 26, 2019 at 12:41:34AM +0300, sergio wrote: > with the last chromium update to 74.0.3729.108-1 browserpass-extension > freezes on > native messaging communication with "Loading available logins.." > > related browserpass-extension issue: Using the google provided chrome build of the same version works flawlessly. So this might not be an upstream issue. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#927997: Opening a link from a mail client restarts chromium
Package: chromium Version: 74.0.3729.108-1 Severity: important Whenever I click on a link in evolution or thunderbird it takes a long time until chromium (which is configured as the default browser) comes up with the page. When it comes up, it'll show only the current link and all other tabs are gone, but instead it tells me that it was not shut down correctly and offers me to restore the old tabs. All worked well with any version prior to this one. Michael -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.0.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 74.0.3729.108-1 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatomic1 8.3.0-6 ii libatspi2.0-02.30.0-7 ii libavcodec58 7:4.1.1-1 ii libavformat587:4.1.1-1 ii libavutil56 7:4.1.1-1 ii libc62.28-9 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcups2 2.2.10-6 ii libdbus-1-3 1.12.12-1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.6-1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-1 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.3.1-1 ii libicu63 63.1-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1 ii libopenjp2-7 2.3.0-2 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpci3 1:3.5.2-5 ii libpng16-16 1.6.36-6 ii libpulse012.2-4 ii libre2-5 20190101+dfsg-2 ii libsnappy1v5 1.1.7-1 ii libstdc++6 8.3.0-6 ii libva2 2.4.0-1 ii libvpx5 1.7.0-3 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 74.0.3729.108-1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1 Versions of packages chromium-common recommends: ii chromium-sandbox 74.0.3729.108-1 ii fonts-liberation 1:1.07.4-9 ii gnome-shell [notification-daemon] 3.30.2-8 ii libgl1-mesa-dri18.3.6-1 pn libu2f-udev ii notification-daemon3.20.0-4 ii upower 0.99.10-1 Versions of packages chromium-sandbox depends on: ii libatomic1 8.3.0-6 ii libc6 2.28-9 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 -- no debconf information
Bug#927416: ITP: golang-github-konsorten-go-windows-terminal-sequences -- Enable support for Windows Terminal Colors
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: golang-github-konsorten-go-windows-terminal-sequences Version : 1.0.2-1 Upstream Author : marvin + konsorten * URL : https://github.com/konsorten/go-windows-terminal-sequences * License : MIT Programming Lang: Go Description : Enable support for Windows Terminal Colors Windows Terminal Sequences This library allow for enabling Windows terminal color support for Go. . See Console Virtual Terminal Sequences (https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences) for details. This package is needed as build-dependency for browserpass.
Bug#923378: unblock: spampd/2.53-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package spampd
Yes, I know it is a new upstream version, but all versions of spampd starting
with 2.40 had a breaking bug in LMTP processing for multiple recipients
(re-introducing the bug originally reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395355). When upstream
learned this, he released a new and fixed version.
The only other change in the new upstream version is a fix for a warning
message that we had a very similar patch for. The only change is that upstream
put the initialization in question at a different line of the source file.
Finally I fixed an oversight by myself that upstream pointed out. The standard
way of calling spampd lacked the option "--setsid". I seem to have forgotten
the option when the prior patched-in solution was removed.
debdiff is attached.
Thanks
Michael
unblock spampd/2.53-1
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.20.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru spampd-2.52/changelog.txt spampd-2.53/changelog.txt
--- spampd-2.52/changelog.txt 2018-11-10 10:24:14.0 +0100
+++ spampd-2.53/changelog.txt 2019-02-25 12:49:09.0 +0100
@@ -1,6 +1,11 @@
SpamPD Change Log
-
+2.53 (25-Feb-19)
+
+- Fix LMTP delivery with multiple recipients
(https://github.com/mpaperno/spampd/issues/23 &
https://github.com/mail-in-a-box/mailinabox/issues/1523)
+- Fix Warning for "Use of uninitialized value in string"
(https://github.com/mpaperno/spampd/issues/22)
+
2.52 (10-Nov-18)
- Override Net::Server's HUP handling, just restart children
(https://github.com/mpaperno/spampd/pull/20).
@@ -10,17 +15,11 @@
2.51 (01-May-18)
-- Fix listening to IP address, broken in 2.50 "Unix ports" feature. (#18)
-- Add --setsid option to start server with setsid if running in background
(#18)
- Fix listening to IP address, broken in 2.50 "Unix ports" feature.
(https://github.com/mpaperno/spampd/pull/18)
- Add --setsid option to start server with setsid if running in background
(https://github.com/mpaperno/spampd/pull/18)
2.50 (30-Apr-18)
-- Replace IO::Socket::INET with IO::Socket::IP for IPv6 support (#9).
-- Unix ports (ability to listen on UNIX sockets) (#13).
-- Add X-Envelope-* headers before Received (#14).
-- Add /usr/local/bin and /usr/local/sbin to PATH (#17).
- Replace IO::Socket::INET with IO::Socket::IP for IPv6 support
(https://github.com/mpaperno/spampd/pull/9).
- Unix ports (ability to listen on UNIX sockets)
(https://github.com/mpaperno/spampd/pull/13).
- Add X-Envelope-* headers before Received
(https://github.com/mpaperno/spampd/pull/14).
diff -Nru spampd-2.52/debian/changelog spampd-2.53/debian/changelog
--- spampd-2.52/debian/changelog2018-11-21 12:24:59.0 +0100
+++ spampd-2.53/debian/changelog2019-02-26 12:16:46.0 +0100
@@ -1,3 +1,11 @@
+spampd (2.53-1) unstable; urgency=medium
+
+ * New upstream version 2.53
+ * Use the --setsid argument to make sure the process is correctly detached.
+ * Bumped Standards-Version, no changes needed.
+
+ -- Michael Meskes Tue, 26 Feb 2019 12:16:46 +0100
+
spampd (2.52-1) unstable; urgency=medium
* New upstream version 2.52 (Closes: #849543)
diff -Nru spampd-2.52/debian/control spampd-2.53/debian/control
--- spampd-2.52/debian/control 2018-11-21 12:21:27.0 +0100
+++ spampd-2.53/debian/control 2019-02-26 12:16:46.0 +0100
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Michael Meskes
Build-Depends: debhelper (>= 11), quilt, dh-exec
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
Homepage: https://github.com/mpaperno/spampd
Package: spampd
diff -Nru spampd-2.52/debian/patches/20-proto-warning.patch
spampd-2.53/debian/patches/20-proto-warning.patch
--- spampd-2.52/debian/patches/20-proto-warning.patch 2018-11-21
12:22:45.0 +0100
+++ spampd-2.53/debian/patches/20-proto-warning.patch 1970-01-01
01:00:00.0 +0100
@@ -1,10 +0,0 @@
spampd-2.52/spampd.pl.orig 2018-11-10 10:24:14.0 +0100
-+++ spampd-2.52/spampd.pl 2018-11-12 08:32:59.0 +0100
-@@ -145,6 +145,7 @@
- return 0 unless defined($_ = $self->_getline);
- s/[\r\n]*$//;
- $self->{state} = $_;
-+$self->{proto} = "(unknown)";
- if (s/^(l|h)?he?lo\s+//i) { # mp: find helo|ehlo|lhlo
- # mp: determine protocol
- if (s/^helo\s+//i) {
diff -Nru spampd-2.52/debian/patches/series spampd-2.53/debian/patches/series
--- spampd-2.52/debian/patches/series
Bug#922403: RM: google-tasks-sync -- ROM; unmaintained upstream, no longer usable
Package: ftp.debian.org Severity: normal The software does not work with Thunderbird for quite a while and does not seem to receive upstream changes anymore. Therefore it's best to remove it from the archive I think. Michael
Bug#919694: [Pkg-acpi-devel] Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration
> So I think this aspect of this bug should be reassigned to acpi- > support. I will > try and prepare a patch and then clone the bug. acpi-support > maintainers, are > you OK with that? Sure. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#911285: Current version is incompatible with Thunderbird 60
Please disregard my prior email, because > > > A new upstream version exists, that should be compatible. this is no longer true. The current version of this extension does not work with the current Thunderbird version. Therefore there is no point in upgrading. > > The package wasn't updated for a year, shall we remove it? Yes. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#918693: RM: gcontactsync -- ROM; does not work
Package: ftp.debian.org Severity: normal The latest upstream version is incompatible with our thunderbird version. Michael
Bug#911285: Current version is incompatible with Thunderbird 60
On Thu, Jan 03, 2019 at 11:35:05PM +0100, Moritz Mühlenhoff wrote: > > The version of gcontactsync in unstable is incompatible with the Thunderbird > > version in unstable. > > > > A new upstream version exists, that should be compatible. > > The package wasn't updated for a year, shall we remove it? Actually I was planning to upgrade it, but ran out of time. Let me see if I find some soon-ish. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#911283: bsdmainutils: Commandline option to display monday first does not function properly.
On Thu, Oct 18, 2018 at 10:06:49AM +0300, Marko Eha wrote: > Manual states that for monday first formatting -M should be used, > however it only produces an 'usage' output, not a calendar. It would be nice if you gave me a little bit more to work on, like which tool you are actually using. >From the top of my head, ncal is the only tool with option -M and that seems to work well on my system: michael@feivel:~$ ncal -M December 2018 Mo 3 10 17 24 31 Tu 4 11 18 25 We 5 12 19 26 Th 6 13 20 27 Fr 7 14 21 28 Sa 1 8 15 22 29 Su 2 9 16 23 30 michael@feivel:~$ ncal -S December 2018 Su 2 9 16 23 30 Mo 3 10 17 24 31 Tu 4 11 18 25 We 5 12 19 26 Th 6 13 20 27 Fr 7 14 21 28 Sa 1 8 15 22 29 Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#914334: RM: gnome-shell-extension-taskbar -- ROM; Abandoned upstream
Package: ftp.debian.org Severity: normal Upstream stopped development, i.e. there will not be a version for current GNOME. Michael
Bug#911056: chromium,webext-browserpass: impossible to install chromium and webext-browserpass together
Unless chromium changed the places it looks for some files, I guess this is an oversight in chromium and thus be fixed there. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#908551: apt-listchanges: apt update hangs if no mail system
On Tue, Sep 11, 2018 at 11:11:34PM +0200, Robert Luberda wrote: > reassign 908551 citadel-server 902-4 > ... > like this (BTW. I've just temporaily installed the latest version of > citadel-server, trying to reproduce the bug, but its sendmail command > just fails, not hangs): Sorry, I don't understand this. Why do you reassign to citadel-server when your test shows citadel-server works correctly? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#909399: kacpimon handles not more than 20 connections
On Sun, Sep 23, 2018 at 12:55:20AM +0200, zieg...@uni-freiburg.de wrote: > Package: kacpimon > Version: 1:2.0.28-1+b1 > Severity: grave I doubt this warrants a grave severity as it obviously works with less than 20 connections and thus is not unusable per se. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#909044: quota: Running quotacheck -cmug / fails with buster version but not with stretch version on lxc container
On Mon, Sep 17, 2018 at 10:15:23PM +0200, Adrian Almenar wrote: > Package: quota > Version: 4.04-2 > Severity: grave > Justification: renders package unusable This is not correct imo as the package seems to work nicely on all non-lxc installations. Therefore I downgraded the bug to important. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#908119: RM: flashgot -- ROM; not useful anymore
Package: ftp.debian.org Severity: normal This extension is using the xul interface which is going away. Therefore it is now useless. Please remove. Thanks. Michael
Bug#908115: RM: downthemall -- ROM; not useful anymore
Package: ftp.debian.org Severity: normal With the xul extension going away this package is no longer useful. Please remove. Thanks. Michael
Bug#905816: [Pkg-mozext-maintainers] Bug#905816: xul-ext-form-history-control: rename to webext-form-history-control, set correct dependencies
> It has been redone as a web extension without renaming to webext-*. Ah, ok, thanks for clarifying. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Bug#905816: [Pkg-mozext-maintainers] Bug#905816: xul-ext-form-history-control: rename to webext-form-history-control, set correct dependencies
> Since the package no longer works with Firefox ESR 52 from Debian > unstable and earlier, please rename it to webext-form-history-control > and set the dependencies to prevent installing it with Firefox ESR > 52. I doubt it magically becomes a web extension just because we rename the package. I haven't checked this particular extension, but if it has not been redone as a web extension it cane be removed. If it has, though, it needs to be updated to the latest version. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Bug#877040: Bug 877040: Transition script for xul-ext-ublock-origin->webext-ublock-origin
> I have prepared a new upstream version of ublock-origin which is now > available in our Git repository. Regarding #877040 I have installed > the > ublock_migration.sh script into /usr/share/doc/webext-ublock-origin > and > explained the usage with a NEWS file. I believe it is best to let the Thanks a lot. > user decide whether he or she wants to migrate the XUL data to the > new > webext format. I didn't feel comfortable with operating on data in > $HOME > by a postinst script for example. > > If you agree I can upload the new package at anytime. I agree completely, please go ahead. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Bug#899365: [Pkg-mozext-maintainers] Bug#899365: Same thing
> I have the same problem: the extension does not show up in the > extension > list in Firefox. > > Do you know how to debug? what do you want to debug? The report gives a *reason* for this behavior. However, I've had reports that this bug should only result in a warning but haven't found time to look into it so far. If you mean that, be my guest. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#881135: [Pkg-mozext-maintainers] Bug#881135: marked as done (xul-ext-ublock-origin: Update ublock-origin to version 1.14.16 by next p-u)
> I think it should remain open for the transition script work, which > David has started doing. Oops, yes, sorry David, I simply forgot about it when uploading. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#877040: New upstream version, including transition to webext
On Thu, Mar 08, 2018 at 01:19:29PM -0600, david s wrote: > I'm interested in potentially taking on maintenance of this package. I > am new to Debian but I'd like to start contributing. Great. > To explore this possibility, I've created a proof-of-concept transition > script. Please take a look at the attached script and let me know your > thoughts and suggestions. Excellent. > Regarding the other part of this bug, it appears that some work has been > done on #866997 to support webext. I plan to look into this and see if I > can contribute to that as well. Having done several webext packages already I should be able to help with that part. As a first step I would love to see us migrate to salsa. The current git structure is different from what I usually use, so I have to dig into that. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#894575: ITP: node-tldjs -- JavaScript module that delivers details about domain names
Package: wnpp Severity: wishlist Owner: Michael Meskes <mes...@debian.org> * Package name: node-tldjs Version : 2.3.1 Upstream Author : Thomas Parisot <tho...@oncle-tom.net> * URL : https://github.com/oncletom/tld.js/ * License : MIT Programming Lang: JavaScript Description : JavaScript module that delivers details about domain names `tld.js` is a Node.js module written in JavaScript to work against complex domain names, subdomains and well-known TLDs. . It answers with accuracy to questions like what is host's (sub)domain, or is its TLD a well-known one? Just another new dependency for browserpass.
Bug#894562: ITP: node-fuzzysort -- Fast SublimeText-like fuzzy search for JavaScript
Package: wnpp Severity: wishlist Owner: Michael Meskes <mes...@debian.org> * Package name: node-fuzzysort Version : 1.1.1. Upstream Author : Stephen Kamenar <stephenkame...@gmail.com> * URL : https://github.com/farzher/fuzzysort * License : MIT Programming Lang: JavaScript Description : Fast SublimeText-like fuzzy search for JavaScript An open source JavaScript implementation that gives results similar to SublimeText search feature. This is needed as a new dependency for the browserpass webextension.
Bug#893963: ITP: golang-github-sahilm-fuzzy -- Go library for fuzzy string matching
Package: wnpp Severity: wishlist Owner: Michael Meskes <mes...@debian.org> Package: wnpp Severity: wishlist Owner: Michael Meskes <mes...@debian.org> * Package name: golang-github-sahilm-fuzzy Version : 0.0.3+git20171025.a154b19-1 Upstream Author : Sahil Muthoo * URL : https://github.com/sahilm/fuzzy * License : MIT Programming Lang: Go Description : Go library for fuzzy string matching Go library that provides fuzzy string matching optimized for filenames and code symbols in the style of Sublime Text, VSCode, IntelliJ IDEA et al. This library is external dependency-free. It only depends on the Go standard library. Demo Here is a demo (_example/main.go) of matching various patterns against ~16K files from the Unreal Engine 4 codebase. Package is needed for new versions of webext-browserpass and will be maintained within go-team.
Bug#889279: marked as done (stretch-pu: package quota/4.03-2+b1)
> Nope. p-u bugs get closed once the package is actually in stable, > i.e. > after the point release. Oops, sorry, I thought I had missed it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
> For the records I do not think that this is important since the > whole > purpose of the program is accessing this data, but the other > objections > are significant enough that I do not see much value in having this > packaged. I agree that Steve's last point got me, too. As long as one has to check the created config file manually there is no point in automating the rest of it. > > That is actually a good point. I wonder if using a local copy might > > be > > a good alternative. > > Obviously not, since it would quickly become stale considering the > nature of the data. This I don't understand. The way I understand it these are legit offerings by universities, telcos, etc. Why should they become stale? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
> I'd strongly urge you to reconsider packaging this project, for > three main reasons: > > * It relies upon the external VPNGate.net site/service. If this > goes away in the lifetime of a stable Debian release users will > be screwed. That is actually a good point. I wonder if using a local copy might be a good alternative. > * It allows security attacks against the local system, which other > users on the host could exploit via symlink attacks on > /tmp/openvpnconf True, but this could be handled by using a better system to access a temp file. > * It allows security attacks on against the local system which the > remote service could exploit: > > 1. The tool downloads a remote URL to /tmp/openvpnconf > > 2. The file is then given as an argument to the command: > sudo openvpn /tmp/openvpnconf > > 3. That generated/downloaded openvpn configuration file could >be written to do anything, up to and including `rm -rf /`. Can you actually get openvpn to do this? > Finally the project itself notes: > > "This is completely insecure. Please do not use this for anything > important. Get a real and secure VPN. This is mostly a fun tool > to > get a VPN for a few minutes." I read this not as "insecure for the system it runs on" but "insecure on the connection side". This is certainly not something you should use to open your local network to, or to do something illegal. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
Package: wnpp Severity: wishlist Owner: Michael Meskes <mes...@debian.org> * Package name: autovpn Version : 0.0~git20170129.72dd7f6-1 Upstream Author : Adhityaa C <c.adhit...@gmail.com> * URL : https://github.com/adtac/autovpn * License : GPL V3 Programming Lang: Go Description : Connect to a VPN in a country of your choice autovpn is a tool to automatically connect you to a random VPN in a country of your choice. It uses openvpn to connect you to a server obtained from VPN Gate (http://www.vpngate.net/en/). A small tool that comes handy in particular for people who travel a lot. Will be maintained in the go-team. Michael
Bug#890717: browserpass: Incomplete debian/copyright?
> I just ACCEPTed browserpass from NEW but noticed it specifies > "several others" in its debian/copyright. This is … not ideal :) > > (This is not exhaustive so please check over the entire package > carefully and address these on your next upload.) Thanks for pointing this out. A new version will be uploaded as soon as the build-dependencies made it through new. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#890697: ITP: webext-proxy-switcher -- Modify Proxy Settings for your Browser
Package: wnpp Severity: wishlist Owner: Michael Meskes <mes...@debian.org> * Package name: webext-proxy-switcher Version : Upstream Author : * URL : https://github.com/rNeomy/proxy-switcher * License : Programming Lang: Javascript Description : Modify Proxy Settings for your Browser Proxy Switcher lets you change your browser proxy settings (preferences) from a toolbar panel in a familiar UI. The panel allows you to access all proxy related settings and it also stores your configurations in different profiles for easy access. The extension supports importing and exporting feature in case profiles need to be used in another browser instance or you want to switch to a new clean profile. I've been using this as a replacement for the old xul-ext-* proxy extension for quite a while and it works flawlessly for my needs.
Bug#890690: ITP: node-mithril -- Javascript framework for building Single Page Applications
Package: wnpp Severity: wishlist Owner: Michael Meskes <mes...@debian.org> * Package name: node-mithril Version : 1.1.6 Upstream Author : Leo Horie <leoho...@hotmail.com> and others * URL : https://github.com/MithrilJS/mithril.js * License : MIT Programming Lang: Javascript Description : Javascript framework for building Single Page Applications Mithril is a modern client-side Javascript framework for building Single Page Applications. It's small (< 8kb gzip), fast and provides routing and XHR utilities out of the box. I need this as a build dependency and will thus take care of it, but wouldn't mind seeing it end up in the appropriate javascript group. Michael
Bug#890623: ITP: webext-bulk-media-downloader -- Cross-browser extension to detect and download media resources
Package: wnpp Severity: wishlist Owner: Michael Meskes <mes...@debian.org> * Package name: webext-bulk-media-downloader Version : 0.2.1 Upstream Author : InBasic <inb@gmail.com> * URL : https://addons.mozilla.org/firefox/addon/bulk-media-downloader/ * License : MPL-2.0 Programming Lang: Javascript Description : Cross-browser extension to detect and download media resources Bulk Media Downloader is a browser extension (add-on) to detect all media (video, audio and image) sources by monitoring network activities. In oppose to the other similar extensions, Bulk Media Downloader has zero impact on your browser performance when the grabber window is closed. To grab a media, open the Media Tools window and refresh the browser tab that has the intended resource and wait for the resource to be fetched by browser one more time. You can use filters to declutter resources area and you can bulk download resources by selecting multiple items at once. This will replace some extensions for firefox that no longer work and will be maintained inside the pkg-mozext group. Michael
Bug#819061: [Pkg-clamav-devel] Bug#819061: clamsmtp/proxsmtp does not handle lines with leading dots correctly
On Fri, Feb 16, 2018 at 03:10:18PM +0100, Christoph Pleger wrote: > after this has been undealed with since almost two years, I wrote a patch > myself. Maybe someone finds at least the time to review it. Please take into account that upstream has abandoned this project, at least as far as I can tell. But since you asked so nicely I did look into it and found that your patch does not apply to clamsmtp. Also you made some changes that don't really seem to be related to the problem at hand, or why did you do for instance this: > -while((rc = getline(, _len, file)) != -1) > +while(line = (fgets(buf + 1, buf_len - 1, file))) I may be missing something obvious here, though, but I haven't looked into clamsmtp's source code much. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#890520: ITP: webext-privacy-badger -- Privacy Badger blocks spying ads and invisible trackers
Package: wnpp Severity: wishlist Owner: Michael Meskes <mes...@debian.org> * Package name: webext-privacy-badger Version : 2018.2.5 Upstream Author : Electronic Frontier Foundation and other contributors * URL : https://github.com/EFForg/privacybadger * License : GPL v3+ Programming Lang: JavaScript Description : Privacy Badger blocks spying ads and invisible trackers Privacy Badger is a browser add-on that stops advertisers and other third-party trackers from secretly tracking where you go and what pages you look at on the web. If an advertiser seems to be tracking you across multiple websites without your permission, Privacy Badger automatically blocks that advertiser from loading any more content in your browser. To the advertiser, it's like you suddenly disappeared. Git has already been created for webext-team on salsa. Michael
Bug#890392: please add file in /etc/chromium.d to load extensions
Package: chromium
Version: 64.0.3282.119-2
Severity: wishlist
With more and more extensions being packaged it would be nice to have chromium
load them automatically instead of requiring user action. And the chromium
package seems to be the natural place for this.
It appears to me that it's sufficient to add the attached file to
/etc/chromium.d.
Thanks
Michael
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages chromium depends on:
ii chromium-common 64.0.3282.119-2
ii libasound2 1.1.3-5
ii libatk-bridge2.0-0 2.26.1-1
ii libatk1.0-0 2.26.1-3
ii libavcodec57 10:3.4.2-dmo1
ii libavformat5710:3.4.2-dmo1
ii libavutil55 10:3.4.2-dmo1
ii libc62.26-6
ii libcairo21.15.10-1
ii libcups2 2.2.6-5
ii libdbus-1-3 1.12.4-1
ii libevent-2.1-6 2.1.8-stable-4
ii libexpat12.2.5-3
ii libflac8 1.3.2-1
ii libfontconfig1 2.12.6-0.1
ii libfreetype6 2.8.1-2
ii libgcc1 1:8-20180207-2
ii libgdk-pixbuf2.0-0 2.36.11-1
ii libglib2.0-0 2.54.3-2
ii libgtk-3-0 3.22.26-2
ii libharfbuzz0b1.7.2-1
ii libicu57 57.1-8
ii libjpeg62-turbo 1:1.5.2-2+b1
ii liblcms2-2 2.9-1
ii libminizip1 1.1-8+b1
ii libnspr4 2:4.18-1
ii libnss3 2:3.35-2
ii libopus0 1.2.1-1
ii libpango-1.0-0 1.40.14-1
ii libpangocairo-1.0-0 1.40.14-1
ii libpng16-16 1.6.34-1
ii libpulse011.1-4
ii libre2-3 20170101+dfsg-1
ii libsnappy1v5 1.1.7-1
ii libstdc++6 8-20180207-2
ii libvpx4 1.6.1-3
ii libwebp6 0.6.0-4
ii libwebpdemux20.6.0-4
ii libwebpmux3 0.6.0-4
ii libx11-6 2:1.6.4-3
ii libx11-xcb1 2:1.6.4-3
ii libxcb1 1.12-1
ii libxcomposite1 1:0.4.4-2
ii libxcursor1 1:1.1.15-1
ii libxdamage1 1:1.1.4-3
ii libxext6 2:1.3.3-1+b2
ii libxfixes3 1:5.0.3-1
ii libxi6 2:1.7.9-1
ii libxml2 2.9.4+dfsg1-6.1
ii libxrandr2 2:1.5.1-1
ii libxrender1 1:0.9.10-1
ii libxslt1.1 1.1.29-5
ii libxss1 1:1.2.2-1+b2
ii libxtst6 2:1.2.3-1
ii zlib1g 1:1.2.8.dfsg-5
Versions of packages chromium recommends:
ii fonts-liberation 1:1.07.4-5
Versions of packages chromium suggests:
pn chromium-driver
ii chromium-l10n 64.0.3282.119-2
pn chromium-shell
pn chromium-widevine
-- Configuration Files:
/etc/chromium.d/extensions changed [not included]
-- no debconf information
export CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --load-extension=`ls -dm
/usr/share/chromium/extensions/*|tr -d '\n'`"
Bug#890199: ITP: go-zglob
On Sun, Feb 11, 2018 at 09:27:52PM +0100, Michael Meskes wrote: > Package: wnpp > Severity: wishlist > Owner: Michael Meskes <mes...@debian.org> > > * Package name: go-zglob > Version : 0.0~git20171230.4959821-1 > Upstream Author : Yasuhiro Matsumoto > * URL : https://github.com/mattn/go-zglob > * License : MIT Expat > Programming Lang: Go > Description : glob library that descends into other directories Argh, should hve mentioned that this is needed as dependency for browserpass, a web extension for the pass password manager. It's actually the last one missing afait. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#866997: [Pkg-mozext-maintainers] Bug#866997: Packaging WebExtensions
> > Here's my attempt: > > https://anonscm.debian.org/cgit/pkg-mozext/mozilla-devscripts.git/commit/?h=pu/webext > https://anonscm.debian.org/cgit/pkg-mozext/mozilla-devscripts.git/diff/?id=pu/webext=master > > > > > It can be used like this (only --with, no --buildsystem is needed): > > https://anonscm.debian.org/cgit/pkg-mozext/tree-style-tab.git/commit/?h=pu/webext > https://anonscm.debian.org/cgit/pkg-mozext/tree-style-tab.git/diff/?id=pu/webext=master When can we expect this to come? Sooner rather than later, please. :) While working on browserpass (should be ready as soon as the dependencies are in) I figured to give this layout a try, albeit manually created. Seems to work nicely. If anyone's interested: git.debian.org/git/pkg-mozext/browserpass.git I'd love to convert some more, in particular https-everywhere is bugging me atm. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#890331: ITP: browserpass -- web extension for the password manager pass
Package: wnpp Severity: wishlist Owner: Michael Meskes <mes...@debian.org> * Package name: browserpass Version : 2.0.11 Upstream Author : Maxim Baz * URL : https://github.com/dannyvankooten/browserpass * License : MIT Programming Lang: go, javascript Description : web extension for the password manager pass webext-browserpass is a Firefox/Chromium extension for the password manager pass. It retrieves your decrypted passwords for the current domain and allows you to auto-fill login forms, as well as copy it to clipboard. If you have multiple logins for the current site, the extension shows you a list of usernames to choose from. git is already created for the pkg-mozext team. Michael
