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#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#988358: marked as pending in bucardo
Control: tag -1 pending Hello, Bug #988358 in bucardo reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/postgresql/bucardo/-/commit/50a1a28940ec521f5b2c5d26485bee1badd04b80 Merge branch 'master' into 'master' Fix upgrade failure with perl-modules-5.24 from stretch is still installed (Closes: #988358) See merge request postgresql/bucardo!2 (this message was generated automatically) -- Greetings https://bugs.debian.org/988358
Bug#988358: marked as pending in bucardo
Control: tag -1 pending Hello, Bug #988358 in bucardo reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/postgresql/bucardo/-/commit/8a7159e2870231d238d20188cfb920ce3ca032ef Fix upgrade failure with perl-modules-5.24 from stretch is still installed (Closes: #988358) (this message was generated automatically) -- Greetings https://bugs.debian.org/988358
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#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#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#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#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#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#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#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#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#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#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#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#884173: SIGSEGV since 63.0.3239.84-1 w/ non-built-in extensions
I'm seeing the same issue with the latest sid version 64.0.3282.11 and by accident found a way to create the problem repeatably. I had my chromium started but not used at all when I upgraded my wlan router's firmware (from Firefox). During reboot of said router chromium crashed and didn't start again until I ran it once with disabled extensions. After that all was well, until I reboot the router again, which brought the problem up again. I don't see any extension on my system that needs the wlan, except of course for internet access. 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#885622: bsdmainutils FTBFS: missing libncurses5-dev build dependency for using termcap.h
> bsdmainutils fails to build from source, because it tries to use > termcap.h without build-depending on libncurses5-dev. After adding > the > dependency it builds successfully on amd64. I'm attaching a patch for > your convenience. Actually bsdmainutils does not need ncurses but tinfo. However, I missed the strange setup that all tinfo header files are in libncurses- dev instead of libtinfo-dev. Therefore I'll switch the dependency back. 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#851086: [Pkg-citadel-devel] Bug#851086: Bug#859789: RFH: citadel/webcit
> We are one bugfix away from that release. Hoping to get it out over > the > next week or so. > > It will have a new version number :) Great! Thanks Art! I'll do an upload when it's available. 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#851086: RFH: citadel/webcit
Robert, > If not I'm going to have it removed I guess. > > I'd be against that. Me too, but somebody has to be able to put some time into it. :) > I have a Jessie installed system that I can't update to Stretch > because citadel won't run on it yet; and the Citadel install there > is > one of the primary reasons I'm running that system. (And I prefer to > use Debian for my systems, and 'official' packages when possible.) What's the problem? I'm not aware of any grave bug on Stretch, but may have missed it. > There used to be a team maintaining these packages, > > but I'm the only one who worked on it in recent years. > >I've wondered about that... >I'm a DM (as j...@rocasa.us) not a DD, so there are some things I > can't do directly. I am very interested in helping how I can with > the Citadel packages. If you're interested, how about becoming a member of the team? 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#851086: [Pkg-citadel-devel] Bug#859789: RFH: citadel/webcit
> We patched some of the sources in an attempt to make it work on the > latest Debian, but that effort seems to have missed the mark. That > having been said, we've got everything working with both old and new > libical versions now, and it seems to build cleanly on both previous > and > current Debian versions. I was referring to problems with libssl1.1, that, according to a post by you Art (I think) is fixed. However, having the same version number with different code causes more work, for which I don't have the time atm. This is why the email was a request for help (RFH). > A new release is forthcoming so if you want to hold tight for a > little > while longer we should be able to smooth things out. Naturally it is > up > to you as package maintainer whether you want to continue to > volunteer > your time -- I totally respect that. Actually the problem is I run very low on time right now. Let me make two things clear, I really like citadel despite not using it and upstream (all of them, not just Art) is very nice to work with and more than willing to help. My problem is a very simple lack of time. I'm able to do an upload every now and then, but not much else. However, since you said there'll be a release shortly, I won't ask for removal if that release fixes the RCs. 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#859789: RFH: citadel/webcit
> You can change the b-d to libical2-dev to still build with the old > libical > version. afaics it doesn't link with packages now linked with > libical3. Sorry, should have said that I was referring to libssl 1.0 vs 1.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#851086: RFH: citadel/webcit
Anyone interested in citadel/webcit? If not I'm going to have it removed I guess. There used to be a team maintaining these packages, but I'm the only one who worked on it in recent years. Not having used the software myself I don't really intend to spend more time on it and both packages have an RC bug, that upstream may or may not have fixed. To explain the latter, upstream claims to have fixed it and their source is different from ours but the version number is exactly the same! 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#881137: xul-ext-https-everywhere: Please update xul-ext-https-everywhere to version 2017.10.30 by next pu
severity 881137 important thanks > Package: xul-ext-https-everywhere > Version: 5.2.8-1 > Severity: grave > Justification: renders package unusable As long as we have firefox-esr in a pre-57 release I don't see why the package is unusable. Nevertheless it should be upgraded of course. 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#876185: Package is not installable with current evolution
Package: evolution-rss Version: 0.3.95-7 Severity: grave Subject says it all, the package either blocks evolution update or is uninstallable. 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.12.0-1-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) Versions of packages evolution-rss depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.0-2+b1 ii evolution3.24.5-3 ii evolution-data-server3.24.5-6 ii libatk1.0-0 2.26.0-2 ii libc62.24-17 ii libcairo-gobject21.14.10-1 ii libcairo21.14.10-1 ii libcamel-1.2-60 3.24.5-6 ii libebackend-1.2-10 3.24.5-6 ii libebook-1.2-19 3.26.0-1 ii libebook-contacts-1.2-2 3.26.0-1 ii libedata-book-1.2-25 3.24.5-6 ii libedataserver-1.2-223.24.5-6 ii libedataserverui-1.2-1 3.24.5-6 ii libevolution 3.24.5-3 ii libgcc1 1:7.2.0-5 ii libgdk-pixbuf2.0-0 2.36.5-4 ii libglib2.0-0 2.54.0-1 ii libgtk-3-0 3.22.21-1 ii libjavascriptcoregtk-4.0-18 2.18.0-2 ii libnspr4 2:4.16-1 ii libnss3 2:3.32-2 ii libpango-1.0-0 1.40.12-1 ii libpangocairo-1.0-0 1.40.12-1 ii libsecret-1-00.18.5-3.1 ii libsoup-gnome2.4-1 2.60.0-1 ii libsoup2.4-1 2.60.0-1 ii libsqlite3-0 3.20.1-1 ii libstdc++6 7.2.0-5 ii libwebkit2gtk-4.0-37 2.18.0-2 ii libxml2 2.9.4+dfsg1-4 evolution-rss recommends no packages. evolution-rss suggests no packages. -- no debconf information
Bug#862297: Install fails if SMTP server is running on port 25, rendering console unuseable
On Wed, May 10, 2017 at 03:36:21PM -0500, John Goerzen wrote: > > If you don't want citadel to provide these > services, turn them off in WebCit via: "Admin->System Preferences->Network". It appears this is now the only way to make it not listen on port 25, meaning it cannot be done during install. I'm not sure what the best way is to handle this situation. Merging citadel-mta with citadel-server and make it conflict with other mtas? And assume that people who want to run citadel with for instance postfix need to manually change things and know how to handle with 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#862297: [Pkg-citadel-devel] Bug#862297: Install fails if SMTP server is running on port 25, rendering console unuseable
On Wed, May 10, 2017 at 03:36:21PM -0500, John Goerzen wrote: > I attempted to install citadel-server on a system that already had an MTA > installed, > using the same command as I showed in #862296. When doing so, my console -- > and every > ssh session to root -- became nearly unuseable as it was flooded with > continuous complaints > about the port 25 already being in use, at such a rate that I couldn't see > anything I > was typing. I was eventually able to blindly type "killall citserver" to get > rid of > this problem. It seems something changed on the upstream side since I think this used to work. But it definitely is an upstream bug imo because the installation explicitely sets ACT_AS_MTA to no. 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#862296: [Pkg-citadel-devel] Bug#862296: Install hangs in postinst with error about c_Default_cal_zone
On Wed, May 10, 2017 at 02:53:17PM -0500, John Goerzen wrote: > On initial install, this package hangs in postinst, and spews several of > these messages across > the console: I cannot reproduce this either, maybe you could run some more tests for me. > Broadcast message from systemd-journald@sid (Wed 2017-05-10 14:45:52 CDT): > > citserver[12602]: configuration setting c_default_cal_zone is empty, but must > not - check your config! This might come but should certainly not cause a hang. Would you be able to find out where in postinst it hangs? And if it is in /usr/lib/citadel-server/setup where there? 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#862300: [Pkg-citadel-devel] Bug#862300: Crashes during the login process
severity 862300 important thanks > Severity: grave > ... I tried with different setups and different packages, freshly downloaded, newly compiled, etc. but I cannot reproduce this. Could it be that you have some special string testing library installed? Also I noticed: > -- System Information: > APT prefers unstable > Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) This doesn't look like a straight forward unstable installation. What exactly are you testing on? I downgraded the bug until we can figure out whether it affects a clean installation or which incompatibility is behind 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
> Here is an updated version of the patch, targeting upstream. > > Can you try the attached patch with both lua-socket versions? > - 3.0~rc1+git+321c0c9-2 > - 3.0~rc1+git+ac3201d-3 Both seem to work, i.e. I can re-start and login to the server both times. Great work! 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#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
> Sorry, my patch was wrong > > local _, unix = pcall(require, "socket.unix"); > if unix then > socket.unix = unix.stream or unix.tcp; > end > This one seems to work. Great, thank you so much. > Unfortunately I can't really test the patches I propose, so I beg > your > pardon if they are wrong. No worries, I'm more than willing to test. Not speaking lua myself I cannot create a patch. All the more reason to be thankful for your work. > And the patches are really for the upstream of prosody-modules, not > for > Debian. Sure, I'll forward. 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#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
> Sorry, I'm a bit puzzled. The only module with such error is > sasl_dovecot that AFAICT is not part of the debian package. Correct, nobody ever claimed it was. > Anyway, I was wrong saying that the incriminated line is fine in 5.1 > but > not in 5.2. It is wrong in 5.1 too. Could you try the fix I > propose? > I've tried, and the socket.unix module loads fine here. > > Could you please try the fix I propose (in sasl_dovecot)? Just did, but apparently your patch does not work: modulemanager error Error initializing module 'auth_dovecot' on 'localhost': /usr/local/lib/prosody/modules/sasl_dovecot.lib.lua:60: attempt to call field 'unix' (a table value) 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#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
> > The patch does not seem to work. I just installed > > lua-socket_3.0~rc1+git+ac3201d-3_amd64.deb manually, re-started > > prosody and got 'luasocket was not compiled with UNIX sockets > > support' > > again. > > Could you please confirm you are on lua 5.2? No, I'm not because prosody depends on lua5.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#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
On Wed, Jan 25, 2017 at 10:48:43PM +0100, Mathieu Parent wrote: The patch does not seem to work. I just installed lua-socket_3.0~rc1+git+ac3201d-3_amd64.deb manually, re-started prosody and got 'luasocket was not compiled with UNIX sockets support' again. 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#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
> The way you want will make prosody-modules break when someone start > to > use lua-socket from stretch-backports. Well, stretch-backports should not have gotten an API update during freeze either. > The unix socket API is not stable nor documented yet [1], being tied > to an API that we know will change on buster is not very solid > either. Sorry, I don't understand. It's definitely documented enough that people use it. API changes happen fairly frequently, that's part of the reason why we need a freeze. > Will look at a fix inside lua-socket (preserving both That would be the best solution, agreed. > compatibilities), but please relax your rules to help find a fix for > all cases. I'm not making the rules, I'm just here arguing the point because I happened to stumble into 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#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
Control: reassign -1 lua-socket I don't think this is the way to go. There is no grave bug in prosody-modules, it's lua-socket that changed its API during freeze. The way I understand our freeze policy this is a no-go, but feel free to check with the release team. 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#852250: [lua-socket] luasocket was not compiled with UNIX sockets support
> Hopefully somebody is prepared to fix all rdepends. Or better reverts the API change. 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#653959: citadel-server was auto-selected and installed by dist-upgrade for what appears to be no good reason, and apt-get purge citadel-server failed to back out all system changes
severity normal thanks On Sun, Jan 01, 2012 at 02:42:07PM -0800, Joshua wrote: > Source: citadel-server > Version: wheezy > Severity: serious > Tags: security > Justification: Policy 3.5 > > apt-get dist-upgrade decided to install citadel-server (no I didn't know what > it was) for who-knows-what reason. > Install created a new publicly listening service (never a good thing > security-wise) > Install created a new user & group > an immediate apt-get purge citadel-server failed to back out the > user,group,extra directories in /var Sorry for the very late reply, but I did not see this report in my list before earlier this week. Chances are you don't even remember the details anymore, but in case you do, which directory was not deleted? This seems to be the only real bug in here. 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#828267: [Pkg-citadel-devel] Bug#828267: reopen, it is still valid
> > What are you trying to do here? Reopen 828267 and merge with > > itself? > > There is no other bug mentioned. What do I miss? > > Yeah. Not very smart. I intended to merge it with 846543. So there is already 846543 to track this problem. I don't really see the point in reopening 828267 and then merging it, but ok. > > Care to explain? The CFLAG change did make the package compile, > > install > > and run, so why reopen the bug? > > The bug was created and it was mentioned that this package needs > changes in > order to get it compiled against the new openssl ABI which is in > experimental. > Your upload of the "fixed" package was performed on 2016-10-30 and > was built > against openssl 1.0.2. So even if you would have done nothing, your Sure, because there was no 1.1.0 to build against for unstable. > package > would been built successfully *but* against a 1.0.2. The test should > have been > done against the version in experimental. Actually I did, but apparently something went wrong. > On 2016-11-01 openssl 1.1.0 was uploaded to unstable. From this point > in time > your package would have fail to build. So I *think* the change in the > CFLAGS > is a nop. It definitely is, at the very least because it contains a copy error, sigh. > So the bug was created because the package did not compile against > openssl > 1.1.0 and now #846543 was created which mostly a dupe of this one. Thus it would have worked to use that one. > That means you have a valid RC bug which should be solved in order to > get this > package ready for the release and I mentioned two options people are > doing. > Most of what I wrote is from the transition bug #827061. The > libssl1.0-dev is > provided by openssl 1.0.2 and is intended to provide the 1.0.2 API > for package > which can't be fixed in time for release. Sorry, wasn't precise enough it seems. I was wondering why you left out the third possible option, namely the compatibility API in libssl 1.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#828267: [Pkg-citadel-devel] Bug#828267: reopen, it is still valid
> control: reopen -1 > control: merge -1 828267 What are you trying to do here? Reopen 828267 and merge with itself? There is no other bug mentioned. What do I miss? > from the change [0] you use say that a compatible API is used but the > CFLAG change makes no sense. This is probably a miss understanding. Care to explain? The CFLAG change did make the package compile, install and run, so why reopen the bug? > You > have two choices: > ... Says who? Again, without any explanation as to why, I don't see any reason to act. 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#844638: Does not work with lua-sec 0.6
As was just pointed out to me, prosody 0.9.11 works well with lua-sec 0.6. It would have been nice to have this properly documented and the dependency enforced. 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#844638: Does not work with lua-sec 0.6
Package: prosody Version: 0.9.10-1 Severity: grave Prosody needs lua 5.1 it seems, but the latest version of lua-sec does not seem to offer this anymore. Therefore prosody is not able to initialize TLS anymore: ... tls error Unable to initialize TLS: LuaSec (required for encryption) was not found This results in a server that is no longer accessible in a standard encrypted way and thus either makes the service unusable or unsafe. Re-installing lua-sec 0.5 from stable fixes the issue. Michael -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages prosody depends on: ii adduser 3.115 ii libc6 2.24-5 ii libidn111.33-1 ii libssl1.0.2 1.0.2j-1 ii lua-expat [lua5.1-expat]1.3.0-3 ii lua-filesystem [lua5.1-filesystem] 1.6.3-1 ii lua-sec [lua5.1-sec]0.5-1 ii lua-socket [lua5.1-socket] 3.0~rc1+git+321c0c9-1 ii lua5.1 5.1.5-8.1+b2 ii ssl-cert1.0.38 Versions of packages prosody recommends: ii lua-event [lua5.1-event] 0.4.3-2
Bug#817550: Any news?
Any news on this? I don't like seeing my packages removed from testing because of this. Obviously I'd be willing to sponsor (or NMU) if needed. 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#818698: does not convert crontabs correctly
On Sat, Mar 19, 2016 at 09:15:00PM +0100, Michael Meskes wrote: > Also I found that changing a crontab to have something executed in a few > minutes always gives me a timer in 24 hours. To make matters worse, the system just (21:22) decided to remove the timer for 21:44 and replace it with one for 22:14, without executing anything! I have to be making some errors here or this package is not functional at all! 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#818698: does not convert crontabs correctly
Package: systemd-cron Version: 1.5.3-1 Severity: grave I just installed systemd-cron to try it out and found that it only partly translated my crontabs. For instance my crontab says: 26 * * * * foo 14,44 * * * * bar However at 21:10 I got this: michael@feivel:~$ systemctl list-timers |grep michael Sa 2016-03-19 21:44:00 CET 32min left n/a n/a cron-michael-michael-1.timer cron-michael-michael-1.service Sa 2016-03-19 22:26:00 CET 1h 14min left n/a n/a cron-michael-michael-0.timer cron-michael-michael-0.service Obviously the very first execution of each job is missing. Also I found that changing a crontab to have something executed in a few minutes always gives me a timer in 24 hours. Since this could result in data loss, depending on what the job is supposed to do (backup!) I think grave is correct, but your mileage may vary. What do I miss? Michael -- Package-specific info: -- output of systemd-delta -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-rc7-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-cron depends on: ii init-system-helpers 1.29 ii python3 3.5.1-2 ii systemd-sysv 229-2 Versions of packages systemd-cron recommends: ii postfix [mail-transport-agent] 3.0.4-5 systemd-cron suggests no packages. -- no debconf information
Bug#815047: Still not fixed
reopen 815047 thanks Still not fixed. It seems the latest fix didn't make it into the package for some reason. Manually setting shlib_directory=/usr/lib/postfix daemon_directory=/usr/lib/postfix/sbin in main.cf fixes the problem for me, but obviously the upgrade shouldn't need such manual config change. 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#815047: Still there with 3.0.4-1
reopen 815047 thanks The latest uploaded does not seem to fix the problem: dpkg -l postfix Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii postfix3.0.4-1 amd64High-performance mail transport agent systemctl start postfix.service; systemctl status postfix.service ● postfix.service - LSB: Postfix Mail Transport Agent Loaded: loaded (/etc/init.d/postfix; bad; vendor preset: enabled) Drop-In: /run/systemd/generator/postfix.service.d └─50-postfix-$mail-transport-agent.conf Active: active (exited) since Mi 2016-02-24 12:44:34 CET; 1min 39s ago Docs: man:systemd-sysv-generator(8) Process: 24148 ExecStop=/etc/init.d/postfix stop (code=exited, status=0/SUCCESS) Process: 24552 ExecStart=/etc/init.d/postfix start (code=exited, status=0/SUCCESS) Feb 24 12:44:33 feivel systemd[1]: Starting LSB: Postfix Mail Transport Agent... Feb 24 12:44:33 feivel postmulti[24558]: fatal: instance /etc/postfix, shlib_directory=/usr/lib/postfix conflicts with instance /etc/postfix, daemon_directory=/usr/lib/postfix Feb 24 12:44:34 feivel postfix[24552]: Starting Postfix Mail Transport Agent: postfix. Feb 24 12:44:34 feivel systemd[1]: Started LSB: Postfix Mail Transport Agent. Feb 24 12:45:37 feivel systemd[1]: Started LSB: Postfix Mail Transport Agent. Feb 24 12:45:56 feivel systemd[1]: Started LSB: Postfix Mail Transport Agent. Feb 24 12:46:13 feivel systemd[1]: Started LSB: Postfix Mail Transport Agent. It does claim success despite the fatal message. Needless to say the system is down afterwards. 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#797135: gnome-software downloads updates automatically by default
Worth mentioning #797138, which is the cause of the aforementioned checkbox being checked by default rather than unchecked. When this is fixed, gnome-software will only download updates in the background but never apply them without the user actively clicking a button or checking a checkbox to do so. I think critical is overstating a bit. I beg to disagree. Yes, it's rather unlikely a stable system gets destroyed the way a sid one does. However, even sid shouldn't carry this undocumented and unnecessary risk. But, and that's the main reason for making the bug critical, the system will download potential huge amounts of data *without* the user even knowing. Now imagine you're paying by the MB, that can create a lot of unexpected costs. 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.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#797135: gnome-software downloads updates automatically by default
Source: gnome-software Severity: critical Once installed the software downloads updates and makes the system do an uograde automatically without even asking the user for confirmation once. The default should be disabled and nor enabled or, at the very least, there should be a very big warning to tell people, but the package description not even gives a hint. This is a critical bug because a) it may create a lot of costs for people who have to pay by traffic and b) might completely destroy systems. Please refer to the whole thread on -devel for details and in particular to https://lists.debian.org/debian-devel/2015/08/msg00597.html Since we're not exactly sure that this package is the (sole) cause please help investigate and, if needed, move to whichever package is the culprit. Thanks. Michael -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#794627: Downgrading
severity 794627 important thanks I don't think a problem with a package in experimental should have the effect of a testing removal. Therefore I downgrad this ug. Feel free to upgrade again, if problem (which does not seem to be easily reproducible) still persists once the newer gnupg version makes it into unstable/tesing. 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.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#779501: clamsmtp: patch included in 1.10-12 completely breaks the package
On Sun, Mar 01, 2015 at 05:05:59PM +0100, Julien Cristau wrote: Package: clamsmtp Version: 1.10-12 Severity: grave Justification: renders package unusable x-debbugs-cc: Michael Tautschnig m...@debian.org ... Patch doesn't seem to help, see attached. What did I miss? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL dpkg-buildpackage -rfakeroot -D -us -uc -i -I dpkg-buildpackage: source package clamsmtp dpkg-buildpackage: source version 1.10-13 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Michael Meskes mes...@debian.org dpkg-source -i -I --before-build clamsmtp dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean --with quilt,autoreconf dh_testdir dh_auto_clean dh_quilt_unpatch No patch removed dh_autoreconf_clean dh_clean dpkg-source -i -I -b clamsmtp dpkg-source: warning: source directory 'clamsmtp' is not sourcepackage-upstreamversion 'clamsmtp-1.10' dpkg-source: warning: .orig directory name clamsmtp.orig is not package-upstreamversion (wanted clamsmtp-1.10.orig) dpkg-source: info: using source format `1.0' dpkg-source: info: building clamsmtp using existing clamsmtp_1.10.orig.tar.gz dpkg-source: info: building clamsmtp in clamsmtp_1.10-13.diff.gz dpkg-source: warning: ignoring deletion of file depcomp, use --include-removal to override dpkg-source: warning: ignoring deletion of file config.h.in, use --include-removal to override dpkg-source: warning: ignoring deletion of file INSTALL, use --include-removal to override dpkg-source: warning: ignoring deletion of file config.guess, use --include-removal to override dpkg-source: warning: ignoring deletion of file missing, use --include-removal to override dpkg-source: warning: ignoring deletion of file config.sub, use --include-removal to override dpkg-source: warning: ignoring deletion of file aclocal.m4, use --include-removal to override dpkg-source: warning: ignoring deletion of file Makefile.in, use --include-removal to override dpkg-source: warning: ignoring deletion of file configure, use --include-removal to override dpkg-source: warning: ignoring deletion of file install-sh, use --include-removal to override dpkg-source: warning: ignoring deletion of file src/Makefile.in, use --include-removal to override dpkg-source: warning: ignoring deletion of file doc/Makefile.in, use --include-removal to override dpkg-source: info: building clamsmtp in clamsmtp_1.10-13.dsc debian/rules build dh build --with quilt,autoreconf dh_testdir dh_quilt_patch Applying patch 300175-fileperms.patch patching file common/smtppass.c Hunk #1 succeeded at 1371 (offset 101 lines). Applying patch manpage.patch patching file doc/clamsmtpd.8 Applying patch gnu_source.patch patching file common/smtppass.c Applying patch include_order.patch patching file common/usuals.h patching file configure.in Hunk #1 succeeded at 51 with fuzz 2. Now at patch include_order.patch dh_autoreconf aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in' automake: warning: autoconf input should be named 'configure.ac', not 'configure.in' configure.in:40: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see: configure.in:40: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation configure.in:49: installing './compile' configure.in:68: installing './config.guess' configure.in:68: installing './config.sub' configure.in:40: installing './install-sh' configure.in:40: installing './missing' Makefile.am: installing './INSTALL' src/Makefile.am:4: warning: source file '../common/spio.c' is in a subdirectory, src/Makefile.am:4: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. src/Makefile.am:4: warning: source file '../common/smtppass.c' is in a subdirectory, src/Makefile.am:4: but option 'subdir-objects' is disabled src/Makefile.am:4: warning: source file '../common/stringx.c' is in a subdirectory, src/Makefile.am:4: but option 'subdir-objects' is disabled src/Makefile.am:4: warning: source file '../common/sock_any.c
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
I just uploaded 9.43-2 with the patch mentioned in this bug report. However, I lack the hardware to test hdparm. So please test it before I file an unblock request. Also I'm not sure if it's a wise idea to remove the init file at this stage of the release. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717190: Leaves RAID sync speed set to 0
I just uploaded 9.43-2 with the patch mentioned in this bug report. However, I lack the hardware to test hdparm. So please test it before I file an unblock request. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771792: [Pkg-mozext-maintainers] Bug#771792: xul-ext-gcontactsync: gContactSync fails with Please login before trying to sync contacts
severity 771792 important thanks On Tue, Dec 02, 2014 at 06:25:17PM +0530, L. Guruprasad wrote: Severity: grave Justification: renders package unusable ... xul-ext-gnome-keyring: 0.6.11-3 icedove: 31.2.0-1 As you're saying yourself the problem appears only when another add-on is installed, that means the package is not unusable by itself and thus the bug is not grave. And yes, there are people like myself who do not use xul-ext-gnome-keyring together with xul-ext-gcontactsync. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771407: server startup fails
Package: dovecot-imapd Version: 1:2.2.13-7 Severity: grave The latest update comments out cert locations which makes the server fail to restart again: dovecot: imap-login: Fatal: Couldn't parse private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: ANY PRIVATE KEY This means that a running imap service is no longer running after the upgrade and cannot even be manually started until the config file has been fixed by hand again. Michael -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dovecot-imapd depends on: ii dovecot-core 1:2.2.13-7 ii libbz2-1.01.0.6-7+b1 ii libc6 2.19-13 ii liblzma5 5.1.1alpha+20120614-2+b2 ii ucf 3.0030 ii zlib1g1:1.2.8.dfsg-2+b1 dovecot-imapd recommends no packages. dovecot-imapd suggests no packages. Versions of packages dovecot-imapd is related to: ii dovecot-core [dovecot-common] 1:2.2.13-7 pn dovecot-dbgnone pn dovecot-devnone pn dovecot-gssapi none ii dovecot-imapd 1:2.2.13-7 pn dovecot-ldap none pn dovecot-lmtpd none pn dovecot-managesieved none pn dovecot-mysql none pn dovecot-pgsql none pn dovecot-pop3d none pn dovecot-sieve none pn dovecot-sqlite none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763134: acpi-support-base: /usr/share/acpi-support/power-funcs broken from line 24 if consolekit installed and no dbus running
from my original report i would guesstimate from: + d=/tmp/.X11-unix ^^ ... Ah, sorry, I was under the impression (no idea why) that you were seeing the problem in getXconsole. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763134: acpi-support-base: /usr/share/acpi-support/power-funcs broken from line 24 if consolekit installed and no dbus running
On Sun, Oct 05, 2014 at 08:49:46PM +0200, Thijs Kinkhorst wrote: On its own, I would not consider failure to lock the screen in specific situations a high priority issue because of the other consequences of having physical access to a machine. Normally I would suggest to fix the bug through the regular stable update channel. Ok, thanks for the clarification. I absolutely agree, but didn't want to go ahead without asking. However, am I correct that this is a regression in the DSA for acpi-support (0.140-5+deb7u3)? If so, we can fix it through stable security since it's a regression introduced in that channel. Nope, I don't think this is a regression. I'm pretty sure the same problem applies to the original stable version. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763134: acpi-support-base: /usr/share/acpi-support/power-funcs broken from line 24 if consolekit installed and no dbus running
On Sun, Sep 28, 2014 at 05:12:45AM +0200, waijb wrote: just testing if /usr/bin/ck-list-sessions is executable doesn't do the trick. until just now i had consolekit installed (some dependency somewhere), but dbus was (and still is and will be) not running. this leads to an error in line 25, ultimately no $user is set. the pinky check is not executed (but would work just fine). Did you actually try this or only call pinky to see if it displays anything? The reason I'm asking is that the script needs to know the display number and calculates that by asking ck-list-sessions again. If it indeed works for you I'd like to know how it came up with the right display number. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763134: acpi-support-base: /usr/share/acpi-support/power-funcs broken from line 24 if consolekit installed and no dbus running
@security: Is this enough of a security problem to warrant a stable upload?
The fix seems easy enough, just run pinky if $user is still empty.
Michael
On Sun, Sep 28, 2014 at 05:12:45AM +0200, waijb wrote:
getXuser() is broken:
block starting at line 24 in /usr/share/acpi-support/power-funcs:
24 if [ -x /usr/bin/ck-list-sessions ]; then
25 uid=$(ck-list-sessions | awk 'BEGIN { unix_user = ; }
/^Session/ { unix_user = ; } /unix-user =/ { gsub(/'\''/,,$3);
unix_user = $3; } /x11-display = '\'$display\''/ { print unix_user; exit
(0); }')
26
27 if [ $uid ]; then
28 IFS=:
29 set -- $(getent passwd $uid)
30 user=$1
31 unset IFS
32 fi
33 else
just testing if /usr/bin/ck-list-sessions is executable doesn't do the
trick.
until just now i had consolekit installed (some dependency somewhere), but
dbus was (and still is and will be) not running. this leads to an error in
line 25, ultimately no $user is set. the pinky check is not executed (but
would work just fine).
finally XAUTHORITY and XUSER are exported as blanks.
this breaks at least /usr/share/acpi-support/screenblank
debug output:
[04:00:22] root@schleppi ~ # /bin/sh -x /usr/share/acpi-support/screenblank
-- source added by me for testing
+ . /usr/share/acpi-support/power-funcs
--
+ umask 022
+
PATH=/sbin:/usr/sbin:/usr/local/sbin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
+ POWERSTATE=/var/lib/acpi-support/powerstate
+ HDPARM=/sbin/hdparm -q
+ LIDSTATE=/var/lib/acpi-support/lidstate
+ d=/tmp/.X11-unix
+ displaynum=0
+ getXuser
+ local plist display uid user startx pid userhome IFS
+ [ 0 ]
+ display=:0
+ user=
+ [ -x /usr/bin/ck-list-sessions ]
+ ck-list-sessions
+ awk BEGIN { unix_user = ; } /^Session/ { unix_user = ; } /unix-user =/
{ gsub(/'/,,$3); unix_user = $3; } /x11-display =
':0'/ { print unix_user; exit (0); }
** Message: Failed to connect to the D-Bus daemon: Failed to connect to
socket /var/run/dbus/system_bus_socket: No such file or
directory
+ uid=
+ [ ]
+ [ -z ]
+ pgrep -n startx
+ :
+ startx=
+ [ -z ]
+ [ x != x ]
+ export XAUTHORITY=
+ XUSER=
+ export XUSER
+ [ x != x ]
+ [ -x = xtrue ]
result: X not locked as expected after sleep/hibernate. free local and
possible remote (root)shells etc...
regards
waijb
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756485: [Pkg-acpi-devel] Bug#756485: acpid: Unable to upgrade/downgrade
severity 756485 normal thanks On Mon, Aug 04, 2014 at 12:57:20PM +0200, Michael Meskes wrote: Please, pretty please, give us at least some output to see what may be happening on your system. My cystal ball is currently not working. :) ... I have no idea what /etc/sysctl.d has to do with acpid, sorry. Please run stop script with set -x and send the output. This bug report lacks important information and thus does not warrant its release critical status IMO. Therefore I cast it down to normal. Please send the missing information. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758060: [Pkg-acpi-devel] Bug#758060: acpi-fakekey: fails to install
On Wed, Aug 13, 2014 at 09:34:32PM +0100, Keith Lee wrote: I purged acpi-fakekey and acpi-support then reinstalled. Does the same happen if you install other packages that have init scripts? -- Output from dpkg Selecting previously unselected package acpi-fakekey. (Reading database ... 90664 files and directories currently installed.) Unpacking acpi-fakekey (from .../acpi-fakekey_0.140-5+deb7u2_amd64.deb) ... Selecting previously unselected package acpi-support. Unpacking acpi-support (from .../acpi-support_0.140-5+deb7u2_all.deb) ... Processing triggers for man-db ... Setting up acpi-fakekey (0.140-5+deb7u2) ... insserv: warning: script 'K10runmbbservice' missing LSB tags and overrides insserv: warning: script 'runmbbservice' missing LSB tags and overrides insserv: There is a loop at service rc.local if started insserv: There is a loop between service rc.local and mountnfs if started insserv: loop involving service mountnfs at depth 7 insserv: loop involving service nfs-common at depth 6 insserv: Starting runmbbservice depends on rc.local and therefore on system facility `$all' which can not be true! previous line repeated several times .. Frankly I cannot see anything related to acpi-fakekey here, other than it's installation triggering the insserv run. What is runmbbservice? Could it be that you have third party software installed? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756485: [Pkg-acpi-devel] Bug#756485: acpid: Unable to upgrade/downgrade
Upgrade to this version resulted in the inability to stop package Please, pretty please, give us at least some output to see what may be happening on your system. My cystal ball is currently not working. :) 1. AFter first upgrade (previous version to this one) moved /etc/sysctl.d directory, so upgrade would continue. From this version to next (or previous) failes completely as acpid won't stop. (or at least stop script exits with error) I have no idea what /etc/sysctl.d has to do with acpid, sorry. Please run stop script with set -x and send the output. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752762: load-module module-alsa-sink freezes display
If a client tries to repeatedly connect then yes, it could respawn pulseaudio pretty fast. But this seems unlikely, given that the log does not show multiple messages. What happens if you have the wrong line and disable autospawn? Then it works. Honestly I haven't checked since finding my problem, but it may also have to do with a non-existing default sink. Anyway, I shall try again and report back. Please do so, also trying with a disabled autospawn. Bad idea, the misconfigured default-sink was not reason for my problems as just enabling the alsa sink module created the same problem again. My screen stayed black again. At the very same moment I had, like, seven pulseaudio processes running at the same time, albeit no log entry at all this time. However, I did manager to lose all my desktop configuration this time. I guess the next time I try I better use a test user. :) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752762: load-module module-alsa-sink freezes display
When pulseaudio is working, does sound play? IIRC, gnome starts some sounds on startup. Now it does, when the problem occured it didn't. This error is weird, because the module load failure should just cause pulseaudio to exit. Perhaps something caused PA to respawn repeatedly? Does it do that if it's, like, killed at the beginning of a session? Yes. By default, pulseaudio is autospawned whenever a connection is attempted. You can disable this behavior in client.conf. I'm not sure we're talking about the same thing here. Yes, of course it does restart on error and similarily of course I had an error, but I only have one error message in the logs. Besides, can it respawn so fast that it blocks the rest of the system? Did the gdm/xsession/any other log have something useful to say? Currently I'm quite stumped as to where the bug may be. Same here. What happens on your system if you enable that config line without the right parameter? Honestly I haven't checked since finding my problem, but it may also have to do with a non-existing default sink. Anyway, I shall try again and report back. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752762: load-module module-alsa-sink freezes display
Jun 26 12:54:57 feivel pulseaudio[3128]: [pulseaudio] module.c: Failed to load module module-alsa-sink (argument: ): initialization failed. Yes, this is expected, because that module needs the card details to Wouldn't it be better than to have the line look like this? #load-module module-alsa-sink card-details load. Is this message shown only once, or repeatedly? Does the log say afterwards: Only once. [pulseaudio] main.c: Module load failed. [pulseaudio] main.c: Failed to initialize daemon. Yes, it did. What DE/WM are you using? Were there sounds being played at the moment? gnome-shell, everything up-to-date sid, no sounds being displayed. This error is weird, because the module load failure should just cause pulseaudio to exit. Perhaps something caused PA to respawn repeatedly? Does it do that if it's, like, killed at the beginning of a session? I tried using this module in an attempt to figure out why my sound doesn't work correctly, or in other words, not at all when using the defaults. For this, try using pavucontrol. There you can see if your card is actually being picked up. I tried that before to no avail as there appeared to be something wrong with pulseaudio in general. Since then I found the problem, a misconfigured default sink in client.conf. I don't remember editing this file at all, but maybe that was an old config from back when. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752762: load-module module-alsa-sink freezes display
Package: pulseaudio Version: 5.0-2 Severity: grave I simply uncommented the line #load-module module-alsa-sink in /etc/pulse/default.pa and resarted pulseaudio to completely freeze my X. Mouse was still working but I wasn't able to focus on any window, let alone type into one or log out. After a reboot I noticed that with that setting my whole X sessions starts up, but the screen remains blank. According to syslog the module failed to load: Jun 26 12:54:57 feivel pulseaudio[3128]: [pulseaudio] module.c: Failed to load module module-alsa-sink (argument: ): initialization failed. But that IMO hardly qualifies as a reason for the display to disappear. It'd also be interesting to know why the module failed, but there doesn't seem to be anything in the logs. I tried using this module in an attempt to figure out why my sound doesn't work correctly, or in other words, not at all when using the defaults. Finally I'm not sure about the severity, but you can (and I did) lose data because of the loss of the X session. Michael -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pulseaudio depends on: ii adduser 3.113+nmu3 ii libasound21.0.27.2-4 ii libasound2-plugins1.0.27-2.1 ii libc6 2.19-4 ii libcap2 1:2.22-1.2 ii libdbus-1-3 1.8.4-1 ii libfftw3-single3 3.3.4-1 ii libgcc1 1:4.9.0-7 ii libice6 2:1.0.8-2 ii libltdl7 2.4.2-1.7 ii liborc-0.4-0 1:0.4.21-1 ii libpulse0 5.0-2 ii libsamplerate00.1.8-7 ii libsm62:1.2.1-2 ii libsndfile1 1.0.25-9 ii libspeexdsp1 1.2~rc1.1-1 ii libstdc++64.9.0-7 ii libsystemd-login0 204-12 ii libtdb1 1.3.0-1.1 ii libudev1 204-12 ii libwebrtc-audio-processing-0 0.1-2 ii libx11-6 2:1.6.2-2 ii libx11-xcb1 2:1.6.2-2 ii libxcb1 1.10-3 ii libxtst6 2:1.2.2-1 ii lsb-base 4.1+Debian13 ii udev 204-12 Versions of packages pulseaudio recommends: ii pulseaudio-module-x11 5.0-2 ii rtkit 0.11-1 Versions of packages pulseaudio suggests: ii paman 0.9.4-1 ii paprefs 0.9.10-1 ii pavucontrol 2.0-2 ii pavumeter 0.9.3-4 ii pulseaudio-utils 5.0-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751900: closed by Michael Meskes mes...@debian.org (Bug#751900: fixed in quota 4.01-5)
My current suspicion is that the non-executable /usr/share/quota/quotarpc.sh causes systemd to barf when trying to run it. Yes, that cannot work. The reason why I didn't see that is rather simple, too: michael@feivel:~$ (dpkg -c quota_4.01-5_amd64.deb ; dpkg -c quota_4.01-5_i386.deb )|grep quotarpc.sh -rwxr-xr-x root/root 1012 2014-06-18 12:20 ./usr/share/quota/quotarpc.sh -rw-r--r-- root/root 1012 2014-06-18 12:59 ./usr/share/quota/quotarpc.sh New upload on its way. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727758: Bug #727758: cups segfaults in libdbus - Fixed in 1.6.4-2 ?
On Thu, Nov 28, 2013 at 02:32:45PM +0100, Didier 'OdyX' Raboud wrote: It would be nice if you could attempt reproducing this bug with 1.6.4-2 and report back to the bugreport. New version is installed and running. With the server not segfaulting all the time for me I cannot say much yet, it did start correctly though. I will keep you guys posted. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725639: [Pkg-citadel-devel] Bug#725639: citadel: FTBFS on kfreebsd-*: error: 'struct dirent' has no member named 'd_namelen'
On Thu, Nov 07, 2013 at 10:05:06AM +0100, Petr Salinger wrote: Control: found -1 8.22-1 Still the same core problem - d_namlen (not d_namelen). ... Sorry, I thought upstream had said they'd fixed the problem. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722159: doesn't seem to work with perl 5.18
tags 722159 patch
thanks
On Mon, Sep 09, 2013 at 05:39:09PM +0200, gregor herrmann wrote:
Too bad, thanks for checking.
I've added this information to the Github issue now.
I finally found some time debugging and fixing it myself. Here's a patch.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--- spampd 2013-11-04 16:03:52.0 +0100
+++ /usr/sbin/spampd 2013-11-04 16:05:05.0 +0100
@@ -900,6 +900,22 @@
usage(0);
}
+# Untaint some options provided by admin command line.
+$pidfile =~ /^(.*)$/;
+$pidfile = $1;
+
+$relayhost =~ /^(.*)$/;
+$relayhost = $1;
+
+$relayport =~ /^(.*)$/;
+$relayport = $1;
+
+$host =~ /^(.*)$/;
+$host = $1;
+
+$port =~ /^(.*)$/;
+$port = $1;
+
if ( $options{tagall} ) { $tagall = 1; }
if ( $options{'log-rules-hit'} ) { $rh = 1; }
if ( $options{debug} ) { $debug = 1; $nsloglevel = 4; }
Bug#727758: cups segfaults in libdbus
On Sat, Oct 26, 2013 at 11:40:20PM +0100, Simon McVittie wrote: thread apply all bt backtrace from cupsd, please? Sorry, I don't know Will send as soon as I'm on the system again. Why is this RC severity? If cupsd links libdbus, then almost by definition it isn't breaks unrelated software... Well, you're right, kind of. I think this bug makes the package in question unusable. However, the package is cups that you moved the bug to anyway. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727758: cups segfaults in libdbus
Package: libdbus-1-3 Version: 1.6.16-1 Severity: grave Most of the times cups comes up I get this: Oct 25 20:27:57 aragorn kernel: [ 389.581166] cupsd[2937]: segfault at 8 ip 7faeb7c98cd0 sp 7fff18af7148 error 4 in libdbus-1.so.3.7.5[7faeb7c72000+45000] Sometimes actually this only happens when the printer is switched on or a job is send to cups. Today for the first time I got this instead: Oct 26 11:26:22 aragorn kernel: [ 53.133630] traps: cupsd[2992] general protection ip:7f4c61ba5c7e sp:7fff4b69f108 error:0 in libdbus-1.so.3.7.5[7f4c61b88000+45000] I'm not sure who's the culprit, libdbus or cups, so feel free to reassign. However, the effect is that my cups server simply disappears. Interestingly enough more often than not it works after a restart. Any idea? Michael -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727041: kernel 3.11-1 freezes when via velocity interface comes up
Package: src:linux Version: 3.11.5-1 Severity: grave Tags: patch Subject kind of says it all. My system freezes solidly as soon as I ifup the network interface. Please see e.g. http://www.spinics.net/lists/netdev/msg251287.html for more details. Attached patch from mentioned URL fixes the problem for me. I haven't checked if kernel devs used the same patch, though. Michael Description: prevent freeze in velocity based networking Origin: http://www.spinics.net/lists/netdev/msg251312.html --- linux-3.11.5.orig/drivers/net/ethernet/via/via-velocity.c +++ linux-3.11.5/drivers/net/ethernet/via/via-velocity.c @@ -2172,14 +2172,12 @@ static int velocity_poll(struct napi_str unsigned int rx_done; unsigned long flags; - spin_lock_irqsave(vptr-lock, flags); /* * Do rx and tx twice for performance (taken from the VIA * out-of-tree driver). */ - rx_done = velocity_rx_srv(vptr, budget / 2); - velocity_tx_srv(vptr); - rx_done += velocity_rx_srv(vptr, budget - rx_done); + rx_done = velocity_rx_srv(vptr, budget); + spin_lock_irqsave(vptr-lock, flags); velocity_tx_srv(vptr); /* If budget not fully consumed, exit the polling mode */
Bug#722479: Doesn't contain license full text in source package
On Wed, Sep 11, 2013 at 08:13:02PM -0300, Eriberto wrote: Michael, I think you're mistaken. In our last talk you said that the license quoted by upstream site was sufficient and I disagree. So I did nothing yet because I was waiting a position about the theme. As I already stated here, I forgot about that clause in MPL. What else do you want me to do? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722479: [Pkg-mozext-maintainers] Bug#722479: Doesn't contain license full text in source package
On Wed, Sep 11, 2013 at 10:19:53AM -0400, Paul Tagliamonte wrote: There's no upstream license at all in the package. This Yeah, we discussed this already in the team, but ... violates both the GPL and MPL. MPL-1.1 section 3.1: You must include a copy of this License with every copy of the Source Code You distribute. ... I simply forgot about this clause. Eriberto was/is already working on this. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722159: doesn't seem to work with perl 5.18
On Sun, Sep 08, 2013 at 11:55:08PM +0200, gregor herrmann wrote: There's a patch upstream which would need a test and some feedback: https://github.com/mpaperno/spampd/issues/2 https://github.com/mpaperno/spampd/commit/1fe20e4c0f06760eb341b519c32954bfc9ef7a15 Doesn't make a difference. That patch does not fix the problem. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722159: doesn't seem to work with perl 5.18
Package: spampd Version: 2.30-22.1 Severity: grave I'm running an up-to-date testing system on which I had to install a couple packages from unstable to be able to update perl (makes me wonder how it made it into testing, but anyhow). Now this morning spampd was restarted by cron script and didn't make it up again with the following being logged: Sep 8 17:53:05 trantor spampd[3693]: Process Backgrounded Sep 8 17:53:05 trantor spampd[3693]: 2013/09/08-17:53:05 Insecure dependency in open while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 75.#012#012 at line 180 in file /usr/share/perl5/Net/Server.pm Sep 8 17:53:05 trantor spampd[3693]: 2013/09/08-17:53:05 Server closing! Needless to say that removing the -T option in spampd's shebang made it run again, albeit I'm not sure about security. I'm not sure where exactly the problem lies, but it damn sure made my email processing come to a halt. Michael -- System Information: Debian Release: jessie/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.10-2-686-pae (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages spampd depends on: ii adduser 3.113+nmu3 ii dpkg1.16.10 ii libnet-server-perl 2.007-3 ii lsb-base4.1+Debian12 ii perl5.18.1-3 ii spamassassin3.3.2-6 spampd recommends no packages. spampd suggests no packages. -- Configuration Files: /etc/default/spampd changed [not included] /etc/spampd.conf [Errno 13] Keine Berechtigung: u'/etc/spampd.conf' -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
