Bug#1071096: gosa: default ldap setup requires schema whose installation is apparently non-trivial to figure out and broken

[Josip Rodin]

Package: gosa
Version: 2.8~git20230203.10abe45+dfsg-1+deb12u2

Hi,

So I wanted something to replace phpldapadmin, this turned up in apt cache
search web ldap, and so I installed it, opened the /gosa URL on the website,
authorized it with the provided shell command, connected to the pre-existing
slapd, and then /gosa/setup.php said:

  LDAP schema check
  5 / 7
  Schema specific settings
  warning
  Attention
  Schema check failed The following object classes are missing:

  gosaObject
  gosaAccount
  gosaLockEntry
  gosaDepartment
  gosaCacheEntry
  gosaProperties
  gosaConfig

If this is not optional, it needs to be stated somewhere more prominently,
or it needs to be made optional. The package description says "Web Based
LDAP Administration Program", it does not say it only works with its own
LDAP schema.

/usr/share/doc/gosa/README.Debian says at the very bottom:

> * Generic information
> 
> Getting GOsa running itself is not very complicated. Problems normally
> arise when integrating it in various services.

This is apparently untrue. It would be better not to make such sweeping
statements at the start of the documentation.

> To play nice with your LDAP, you need to include the gosa schema files
> into your LDAP configuration.
> 
> For Debian, you should install the gosa-schema package and take a look at
> the sample slapd.conf provided in /usr/share/doc/gosa/contrib/openldap.

Installed the package, it does not ship any such directory:

% dpkg -L gosa-schema | grep /usr/share/doc/gosa/contrib/openldap
%

> The GOsa² schemas are located in /etc/ldap/schema/gosa.
> 
> Add these lines to slapd.conf for loading GOsa² schema files into slapd:
> 
> # These should be present for GOsa.
> include /etc/ldap/schema/gosa/samba3.schema
> include /etc/ldap/schema/gosa/gosystem.schema
> include /etc/ldap/schema/gosa/gofon.schema
> include /etc/ldap/schema/gosa/gofax.schema
> include /etc/ldap/schema/gosa/goto.schema
> include /etc/ldap/schema/gosa/goserver.schema
> include /etc/ldap/schema/gosa/gosa-samba3.schema
> include /etc/ldap/schema/gosa/trust.schema

slapd.conf does not exist on modern OpenLDAP slapd, hasn't for at least a
couple of Debian releases, so this is useless as is?

I noticed the same .schema files are accompanied by .ldif files, which could
be usable. However, trying that produced:

% sudo ldapadd -Y EXTERNAL -H ldapi:/// -f 
/etc/ldap/schema/gosa/gosa-samba3.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
ldapadd: invalid format (line 57) entry: "cn=gosa-samba3,cn=schema,cn=config"

So, yeah, all in all this is a very frustrating onboarding experience.

Please fix it. TIA.

-- 
Josip Rodin

Bug#1068950: http_loadtime multiple target / escapeUri regression

[Josip Rodin]

Package: munin-plugins-core
Version: 2.0.73-1

Hi,

This used to work while there was support for only one target:

[http_loadtime]
env.target http://localhost/?munin_http_loadtime=foo-front-60

The RRD value was just a simple string and it didn't matter what the content
of the target URL was. With the multiple target feature, however, this
returns:

% sudo munin-run http_loadtime
http___localhost_?munin_http_loadtime=foo_front_60.value 0.0946937

Which in turn is broken in Munin - it would create the RRD file for it,
the value would always be critical, and munin-cgi-graph complains like
this:

2024/04/14 05:19:49 [RRD ERROR] Unable to graph 
/var/lib/munin/cgi-tmp/munin-cgi-graph/bar.baz.com/foo-front-1.bar.baz.com/http_loadtime-year.png
 : foo_front_60_warning is not a vname nor a number

It sounds like the non-alphabetic characters that are included in
the query string bother it, as they aren't escaped by:

escapeUri() {
echo "$1" | sed 's/[:/.-]/_/g'
}

Please fix it. TIA.

-- 
Josip Rodin

Bug#996580: Acknowledgement (vmdb2 hangs in the mkpart plugin after a lvcreate because of device mapper paths)

[Josip Rodin]

Hm, actually loop doesn't work well either, because the same piece of code
tries to access /dev/loop01 instead of the actual /dev/loop0p1

Once I fix that, it still later fails with:

Exec: ['blkid', '-c', '/dev/null', '-o', 'value', '-s', 'UUID', '/dev/loop0p1']
Installing GRUB for BIOS
ERROR: Do not understand partition device name /dev/loop0p1
ERROR: Exception('Do not understand partition device name /dev/loop0p1')
Something went wrong, cleaning up!

I found in the code that I could override that in the grub plugin by
specifying:

image-dev: "/dev/mapper/vg0-myvm--root"

However, even this failed with:

2021-10-16 22:09:37 INFO Exec: ['chroot', '/tmp/tmpy9lcantw', 'grub-install', 
'--target=i386-pc', '--no-nvram', '--force-extra-removable', '--no-floppy', 
'--modules=part_msdos part_gpt', '--grub-mkdevicemap=/boot/grub/device.map', 
'/dev/mapper/vg0-myvm--root']
2021-10-16 22:09:37 DEBUG STDOUT:
2021-10-16 22:09:37 DEBUG STDERR: Installing for i386-pc platform.
grub-install: error: diskfilter writes are not supported.

2021-10-16 22:09:37 ERROR Program failed: 1

So, uhh, I'm a bit stuck here. This used to work under vmdebootstrap...

-- 
Josip Rodin

Bug#996580: Acknowledgement (vmdb2 hangs in the mkpart plugin after a lvcreate because of device mapper paths)

[Josip Rodin]

On Sat, Oct 16, 2021 at 10:42:38PM +0200, Josip Rodin wrote:
> Installing GRUB for BIOS
> ERROR: Do not understand partition device name /dev/loop0p1
> ERROR: Exception('Do not understand partition device name /dev/loop0p1')
> Something went wrong, cleaning up!
> 
> I found in the code that I could override that in the grub plugin by
> specifying:
> 
> image-dev: "/dev/mapper/vg0-myvm--root"
> 
> However, even this failed with:
> 
> 2021-10-16 22:09:37 INFO Exec: ['chroot', '/tmp/tmpy9lcantw', 'grub-install', 
> '--target=i386-pc', '--no-nvram', '--force-extra-removable', '--no-floppy', 
> '--modules=part_msdos part_gpt', '--grub-mkdevicemap=/boot/grub/device.map', 
> '/dev/mapper/vg0-myvm--root']
> 2021-10-16 22:09:37 DEBUG STDOUT:
> 2021-10-16 22:09:37 DEBUG STDERR: Installing for i386-pc platform.
> grub-install: error: diskfilter writes are not supported.
> 
> 2021-10-16 22:09:37 ERROR Program failed: 1

As it happens, this actually does work with:

image-dev: "{{ image }}"

The log then simply says:

Exec: ['chroot', '/tmp/tmp65a32lou', 'grub-install', '--target=i386-pc', 
'--no-nvram', '--force-extra-removable', '--no-floppy', '--modules=part_msdos 
part_gpt', '--grub-mkdevicemap=/boot/grub/device.map', '/dev/loop0']

-- 
Josip Rodin

Bug#996580: vmdb2 hangs in the mkpart plugin after a lvcreate because of device mapper paths

[Josip Rodin]

Package: vmdb2
Version: 0.22-1
Severity: important

Hi,

I'm trying to replace vmdebootstrap with vmdb2, but this tool still doesn't
work for me with a pretty basic use case based on the manual:

% head -15 myvm.vmdb2.yml
steps:
  - lvcreate: "vg0"
name: "myvm-root"
size: 4G
  - mklabel: msdos
device: "{{ image }}"
  - mkpart: primary
device: "{{ image }}"
start: 0%
end: 100%
tag: /
  - kpartx: "{{ image }}"
  - mkfs: ext4
partition: /
  - mount: /

% sudo vmdb2 myvm.vmdb2.yml --image /dev/vg0/myvm-root --verbose --log 
myvm.vmdb2.log
Load spec file myvm.vmdb2.yml
Exec: ['dpkg', '--print-architecture']
Exec: ['lvcreate', '--name', 'myvm-root', '--size', '4G', 'vg0']
Exec: ['parted', '-s', '/dev/vg0/myvm-root', 'mklabel', 'msdos']
Exec: ['parted', '-m', '/dev/dm-0', 'print']
Exec: ['parted', '-s', '/dev/dm-0', '--', 'mkpart', 'primary', 'ext2', '0%', 
'100%']
Exec: ['parted', '-m', '/dev/dm-0', 'print']

And then it just sits there. Attaching a strace shows a loop:

% sudo strace -p 77503
strace: Process 77503 attached
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=751734}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)
select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)
select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)
select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)
select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)
select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)

So I looked into the code to find the culprit, and found it in
/usr/lib/python3/dist-packages/vmdb/plugins/mkpart_plugin.py

It passes the device parameter through os.path.realpath() which results in
/dev/dm-0, which in turn is actively bad for the rest of the partitioning
logic as you can't simply tack on the partition numbers onto a device path
like that.

I tried passing in /dev/mapper/vg0-myvm--root as that device parameter, but
realpath() destroys that as well by resolving it into /dev/dm-0 again.

That doesn't happen for parted, though, that one could work:

% sudo parted -m /dev/mapper/vg0-myvm--root print
BYT;
/dev/mapper/vg0-myvm--root:4295MB:dm:512:4096:msdos:Linux device-mapper 
(linear):;
1:1049kB:4295MB:4294MB:::;

>From this output, the diff logic could actually generate
/dev/mapper/vg0-myvm--root1 which would indeed work, but, again, realpath()
is unyielding.

So, maybe detect the use of device mapper paths? If realpath resolves into 
/dev/dm*, abort with an error message saying use /dev/mapper/ as the device?
And then have an exception for /dev/mapper paths so that it doesn't even
try to run realpath on those?

Otherwise I'm going to have to work around this by doing lvcreate and
losetup outside of vmdb2, I guess.

Please fix this. TIA.

-- 
Josip Rodin

Bug#988301: exim :include: not working after jessie

[Josip Rodin]

Package: exim4
Version: 4.89-2+deb9u8

Hi,

After an upgrade to stretch, and likewise buster, the :include:
functionality of the redirect router seems to be broken.

I have include_directory set to /etc/exim4, and a subdirectory with
files containing alias content, an an aliases file containing e.g.:

priprema: :include:/etc/exim4/dynaliases/priprema

This worked perfectly up to jessie, but after the upgrade, deliveries
started choking with messages like:

R=aliases defer (-17): error in redirect data: failed to open
/etc/exim4/dynaliases/priprema (component of included file); could
be symbolic link

strace shows:

openat(AT_FDCWD, "/etc/exim4/dynaliases", O_RDONLY|O_LARGEFILE) = 7
openat(7, "/priprema", O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = -1 ENOENT (No such 
file or directory)

Obviously it's supposed to continue to find the file in that directory,
because the file hasn't been touched...

Am I missing something here?

A diff between 4.84 and 4.89 sources shows that this code was changed
inbetween, with a block of new code using EXIM_HAVE_OPENAT replacing
the old logic...?

Please fix it. TIA.

-- 
Josip Rodin

Bug#976104: openvpn enforces suppress-timestamps in systemd even with log-append inside config

[Josip Rodin]

On Mon, Nov 30, 2020 at 11:11:21PM +0100, Bernhard Schmidt wrote:
> On Sun, Nov 29, 2020 at 08:11:09PM +0100, Josip Rodin wrote:
> 
> Dear Josip,
> 
> > For some reason, the systemd unit config shipped by openvpn in
> > /lib/systemd/system/openvpn-server@.service says --suppress-timestamps, but
> > then a log-append inside the server config file logs no timestamps there,
> > either, which doesn't make much sense.
> > 
> > What would be the reason for this, can it be removed or worked around
> > somehow, please?
> > 
> > I see the same file content is present in 2.4.7-1, too.
> 
> openvpn-server@.service and openvpn-client@.service are maintained by
> upstream, I guess the reason is to have them logged properly by systemd
> instead of log-append. If you want to change this I suggest to talk to
> upstream or override it locally.

OK but that seems like a counter-intuitive thing for a Debian package, to
have to override something in a way that conflicts with packaging... If I
have to change one small part of the ExecStart variable using the systemctl
edit override mechanism, what happens after the next upgrade where something
else may change in the rest of the variable?

In the olden days, you'd have init scripts that took all their configurable
elements of what is today ExecStart from variables overridable in
/etc/default/foo, and then the latter would be a conffile, and the upgrade
process would alert you if you changed something that was subsequently
changed in the package. What would alert users in such a case these days?

> The openvpn@.service unit that Debian has "always" shipped does not set
> this option (yes this duplication is somewhat unfortunate).

I saw that this was the topic of another bug report... I actually started to
like the upstream approach better because for some reason I'd have OpenVPN
confused about server profiles, and trying to make a client connection to
itself, and failing, so I moved my server profiles to the server/
subdirectory and switched to the -server@ unit file.

-- 
Josip Rodin

Bug#974898: new release upstream fixed several problems

[Josip Rodin]

Yes, I make a point of not caring to read through emails that are clearly
inflammatory and tendentious. It's well documented how to contribute to
Debian, including uploads of new packages; start observing some minimal
standards of acceptable behavior or stop wasting everyone's time.


On Thu, Nov 26, 2020 at 08:47:35AM -0400, PICCORO McKAY Lenz wrote:
> seems do you not read the mails, several issues are solved upstream,
> but still are happened cos there's no new release. (not so difficult
> to make it)
> 
> same for courier, several bug reports are not taken in consideration
> (solved of course) and now today make a separate package for maildrop
> is nonsense cos is part of courier-mta suite.. it belongs to that
> suite, but upstream committed some of the requested features
> 
> El jue, 26 de nov. de 2020 a la(s) 07:56, Josip Rodin
> (j...@debbugs.entuzijast.net) escribió:
> >
> >
> > Why are you posting these agitated bug reports? Can I suggest that you first
> > calm down and try to compose your thoughts, and then put that in writing
> > while bearing in mind that an assumption of good faith is the only proper
> > way to operate?
> >
> > On Mon, Nov 16, 2020 at 04:08:21AM -0400, PICCORO McKAY Lenz wrote:
> > > Package: maildrop
> > > Version: 2.9.3-2
> > > Severity: important
> > >
> > > The maildrop package in debian is severely out of sync and outdated:
> > >
> > > First of all stop of "Upstream is not willing to add another feature",
> > > seems people dont understan maildrop are made for courier, and if need
> > > can proposed a fork for that!
> > >
> > > Second: **several problems where aborted upstream**, the most
> > > important ones are:
> > > * libs/maildrop/deliver.C (delivery): Always return 75 upon
> > > delivery failure, for the standalone maildrop build. related to #481223
> > > * libs/maildir/maildirmake.c (main): maildirmake's -q option
> > > will create the maildir if it does not exist. related to #501557
> > > * libs/rfc2045/reformime.c (main2): Fix crash when the -s option is
> > > not valid. related to #71625
> > > * rfc2045/reformime.c (main2): fix crash if -x or -X is specified
> > > without the corresponding -s option. related to #71625
> > >
> > > A new maildrop pack is required and this must either come from the
> > > same courier sources (#867121) or update the one... this last seems
> > > quite stupid as courier is the official sources of maildrop and
> > > although it is offered separately by the author upstream, unifying it
> > > will improve maintenance from a team, and as you guys notice lack of
> > > interest/avaliable time in the courier suite (reading the last
> > > changelog, seems changes are more to complain with debian package
> > > policy that is innecesary respect real issues)
> > >
> > > ... and as far as I can see you are looking for the sources in sf
> > > instead of the right place which is the courier oficial download page,
> > > additional while the courier-mta sources are up to date in
> > > salsa-debian, the maildrop one in salsa-debian are too old respect the
> > > mta suite!
> > >
> > > while I made my own package on OBS vegnuli home for Devuan and Debian,
> > > is you guys need help i'm a often user of the complete suite and not
> > > just parts or toys of, maildrop can be build with two ways:
> > >  * set GID mail without restricted caller (maildrop)
> > >  * set UID root with restricted caller for courier-mta
> > >(maildrop-courier) -- missing and the way i set in my package cos
> > > is the need by the original suite the courier-mta
> > >
> > >
> > > NOTE: Courier maildrop in debian present a very not proper behaviour..
> > > original sources are from courier and any other implementation are
> > > non-related and users can fork the software, cases like #375589 are
> > > not valid cos seems maildrop (as author make it for courier filtering)
> > > is a courier implementation if applies! so any external specific usage
> > > are purely optional
> > >
> > > This are related to #910380 (separate makemime from sources) #204187,
> > > #596057 & #375589#26 (bad usage  cos is not made for), #481223
> > > (changed behaviour cos is not made for, what?), #592585 (dovecot
> > > specific crap) and go and go.. seems people thinks that maildrop are
> > > made for others rather than the courier suite... funny please close
> > > all of those package cos seems many of them are not supported by
> > > upstream and community must make a fork in those several cases!
> > >
> > > Lenz McKAY Gerardo (PICCORO)
> > > http://qgqlochekone.blogspot.com
> >
> > --
> > Josip Rodin

-- 
Josip Rodin

Bug#976104: openvpn enforces suppress-timestamps in systemd even with log-append inside config

[Josip Rodin]

Package: openvpn
Version: 2.4.0-6+deb9u3

Hi,

For some reason, the systemd unit config shipped by openvpn in
/lib/systemd/system/openvpn-server@.service says --suppress-timestamps, but
then a log-append inside the server config file logs no timestamps there,
either, which doesn't make much sense.

What would be the reason for this, can it be removed or worked around
somehow, please?

I see the same file content is present in 2.4.7-1, too.

TIA.

-- 
Josip Rodin

Bug#974898: new release upstream fixed several problems

[Josip Rodin]

Why are you posting these agitated bug reports? Can I suggest that you first
calm down and try to compose your thoughts, and then put that in writing
while bearing in mind that an assumption of good faith is the only proper
way to operate?

On Mon, Nov 16, 2020 at 04:08:21AM -0400, PICCORO McKAY Lenz wrote:
> Package: maildrop
> Version: 2.9.3-2
> Severity: important
> 
> The maildrop package in debian is severely out of sync and outdated:
> 
> First of all stop of "Upstream is not willing to add another feature",
> seems people dont understan maildrop are made for courier, and if need
> can proposed a fork for that!
> 
> Second: **several problems where aborted upstream**, the most
> important ones are:
> * libs/maildrop/deliver.C (delivery): Always return 75 upon
> delivery failure, for the standalone maildrop build. related to #481223
> * libs/maildir/maildirmake.c (main): maildirmake's -q option
> will create the maildir if it does not exist. related to #501557
> * libs/rfc2045/reformime.c (main2): Fix crash when the -s option is
> not valid. related to #71625
> * rfc2045/reformime.c (main2): fix crash if -x or -X is specified
> without the corresponding -s option. related to #71625
> 
> A new maildrop pack is required and this must either come from the
> same courier sources (#867121) or update the one... this last seems
> quite stupid as courier is the official sources of maildrop and
> although it is offered separately by the author upstream, unifying it
> will improve maintenance from a team, and as you guys notice lack of
> interest/avaliable time in the courier suite (reading the last
> changelog, seems changes are more to complain with debian package
> policy that is innecesary respect real issues)
> 
> ... and as far as I can see you are looking for the sources in sf
> instead of the right place which is the courier oficial download page,
> additional while the courier-mta sources are up to date in
> salsa-debian, the maildrop one in salsa-debian are too old respect the
> mta suite!
> 
> while I made my own package on OBS vegnuli home for Devuan and Debian,
> is you guys need help i'm a often user of the complete suite and not
> just parts or toys of, maildrop can be build with two ways:
>  * set GID mail without restricted caller (maildrop)
>  * set UID root with restricted caller for courier-mta
>(maildrop-courier) -- missing and the way i set in my package cos
> is the need by the original suite the courier-mta
> 
> 
> NOTE: Courier maildrop in debian present a very not proper behaviour..
> original sources are from courier and any other implementation are
> non-related and users can fork the software, cases like #375589 are
> not valid cos seems maildrop (as author make it for courier filtering)
> is a courier implementation if applies! so any external specific usage
> are purely optional
> 
> This are related to #910380 (separate makemime from sources) #204187,
> #596057 & #375589#26 (bad usage  cos is not made for), #481223
> (changed behaviour cos is not made for, what?), #592585 (dovecot
> specific crap) and go and go.. seems people thinks that maildrop are
> made for others rather than the courier suite... funny please close
> all of those package cos seems many of them are not supported by
> upstream and community must make a fork in those several cases!
> 
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com

-- 
Josip Rodin

Bug#972223: [Pkg-samba-maint] Bug#972223: Acknowledgement (samba: NT4-style domain member doesn't work without winbind, but even with it, doesn't work)

[Josip Rodin]

On Sun, Oct 18, 2020 at 11:12:15AM +0200, Josip Rodin wrote:
> On Sat, Oct 17, 2020 at 01:09:08PM +0200, Josip Rodin wrote:
> > [2020/10/17 10:26:37.521971,  3, pid=16890, effective(0, 0), real(0, 0)] 
> > ../source3/smbd/share_access.c:151(token_contains_name)
> >   token_contains_name: returning false for users
> > [2020/10/17 10:26:37.522069, 10, pid=16890, effective(0, 0), real(0, 0)] 
> > ../source3/smbd/share_access.c:222(user_ok_token)
> >   User joy not in 'valid users'
> > 
> > I'm afraid I haven't had the time yet to figure out why the netgroup code
> > can't resolve the users group (I'll keep at it).
> 
> I added a bit more debugging and found the following pattern:
> 
> [2020/10/18 09:04:55.557863,  3, pid=20645, effective(0, 0), real(0, 0)] 
> ../source3/passdb/lookup_sid.c:432(lookup_name)
>   lookup_name: lookup for Unix Group\users succeeded: name (null), domain 
> (null), sid ^A^B, type ^B
> [2020/10/18 09:04:55.557938,  3, pid=20645, effective(0, 0), real(0, 0)] 
> ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID 
> S-1-5-21-145766654-2861277506-3272706772-1001000 and S-1-22-2-100
> [2020/10/18 09:04:55.558008,  3, pid=20645, effective(0, 0), real(0, 0)] 
> ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-5-21-145766654-2861277506-3272706772-513 
> and S-1-22-2-100
> [2020/10/18 09:04:55.558052,  3, pid=20645, effective(0, 0), real(0, 0)] 
> ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-1-0 and S-1-22-2-100
> [2020/10/18 09:04:55.558094,  3, pid=20645, effective(0, 0), real(0, 0)] 
> ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-5-2 and S-1-22-2-100
> [2020/10/18 09:04:55.558134,  3, pid=20645, effective(0, 0), real(0, 0)] 
> ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-5-11 and S-1-22-2-100
> [2020/10/18 09:04:55.558173,  3, pid=20645, effective(0, 0), real(0, 0)] 
> ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-22-1-1000 and S-1-22-2-100
> [2020/10/18 09:04:55.558213,  3, pid=20645, effective(0, 0), real(0, 0)] 
> ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-22-2-1000 and S-1-22-2-100
> [2020/10/18 09:04:55.558253,  3, pid=20645, effective(0, 0), real(0, 0)] 
> ../source3/smbd/share_access.c:139(token_contains_name)
>   token_contains_name: nt_token_check_sid failed for users, (null)
> [2020/10/18 09:04:55.558321,  3, pid=20645, effective(0, 0), real(0, 0)] 
> ../source3/smbd/share_access.c:155(token_contains_name)
>   token_contains_name: returning false for users
> [2020/10/18 09:04:55.558364, 10, pid=20645, effective(0, 0), real(0, 0)] 
> ../source3/smbd/share_access.c:226(user_ok_token)
>   User joy not in 'valid users'
> 
> This S-1-22-2- base SID seemed indicative, so I googled that, but the best
> explanation I could find was in a question at
> https://stackoverflow.com/questions/31109871/mapping-sambas-s-1-22-12-sid-into-names
> where it says this is something that "Samba uses" for groups.
> 
> Is this the idmap setup that I don't seem to have in my old config?

OK so after some more discussion with the folks in #samba on IRC, I decided
to try the method of not having a domain member server on the file server,
but a classic (NT4-style) backup domain controller instead, with the ldapsam
setup directly on it.

This generally works much better, but I observed users having their SID
lists expanded partially, i.e. the LDAP clearly had them in e.g. 5 groups,
but Samba only saw 3 groups - based on the output of security_token_debug().

This was even after I destroyed all obvious traces of winbind and whatever.

Then I completely uninstalled Samba from the machine, which eliminated the
entire /var/lib/samba directory, and reinstalled the software and re-did the
net(8) and smbpasswd(8) commands needed, and now it miraculously all works
just fine.

So it looks like something is definitely wrong with how Winbind/idmap
stuff functions with this particular LDAP directory, yet it's completely
obfuscated why.

This also makes me even more afraid to move from NT4-style to AD-style,
because who know what else might fail there, too...

-- 
Josip Rodin

Bug#972223: [Pkg-samba-maint] Bug#972223: Acknowledgement (samba: NT4-style domain member doesn't work without winbind, but even with it, doesn't work)

[Josip Rodin]

On Sat, Oct 17, 2020 at 01:09:08PM +0200, Josip Rodin wrote:
> [2020/10/17 10:26:37.521971,  3, pid=16890, effective(0, 0), real(0, 0)] 
> ../source3/smbd/share_access.c:151(token_contains_name)
>   token_contains_name: returning false for users
> [2020/10/17 10:26:37.522069, 10, pid=16890, effective(0, 0), real(0, 0)] 
> ../source3/smbd/share_access.c:222(user_ok_token)
>   User joy not in 'valid users'
> 
> I'm afraid I haven't had the time yet to figure out why the netgroup code
> can't resolve the users group (I'll keep at it).

I added a bit more debugging and found the following pattern:

[2020/10/18 09:04:55.557863,  3, pid=20645, effective(0, 0), real(0, 0)] 
../source3/passdb/lookup_sid.c:432(lookup_name)
  lookup_name: lookup for Unix Group\users succeeded: name (null), domain 
(null), sid ^A^B, type ^B
[2020/10/18 09:04:55.557938,  3, pid=20645, effective(0, 0), real(0, 0)] 
../libcli/security/dom_sid.c:85(dom_sid_equal)
  dom_sid_equal: Comparing SID S-1-5-21-145766654-2861277506-3272706772-1001000 
and S-1-22-2-100
[2020/10/18 09:04:55.558008,  3, pid=20645, effective(0, 0), real(0, 0)] 
../libcli/security/dom_sid.c:85(dom_sid_equal)
  dom_sid_equal: Comparing SID S-1-5-21-145766654-2861277506-3272706772-513 and 
S-1-22-2-100
[2020/10/18 09:04:55.558052,  3, pid=20645, effective(0, 0), real(0, 0)] 
../libcli/security/dom_sid.c:85(dom_sid_equal)
  dom_sid_equal: Comparing SID S-1-1-0 and S-1-22-2-100
[2020/10/18 09:04:55.558094,  3, pid=20645, effective(0, 0), real(0, 0)] 
../libcli/security/dom_sid.c:85(dom_sid_equal)
  dom_sid_equal: Comparing SID S-1-5-2 and S-1-22-2-100
[2020/10/18 09:04:55.558134,  3, pid=20645, effective(0, 0), real(0, 0)] 
../libcli/security/dom_sid.c:85(dom_sid_equal)
  dom_sid_equal: Comparing SID S-1-5-11 and S-1-22-2-100
[2020/10/18 09:04:55.558173,  3, pid=20645, effective(0, 0), real(0, 0)] 
../libcli/security/dom_sid.c:85(dom_sid_equal)
  dom_sid_equal: Comparing SID S-1-22-1-1000 and S-1-22-2-100
[2020/10/18 09:04:55.558213,  3, pid=20645, effective(0, 0), real(0, 0)] 
../libcli/security/dom_sid.c:85(dom_sid_equal)
  dom_sid_equal: Comparing SID S-1-22-2-1000 and S-1-22-2-100
[2020/10/18 09:04:55.558253,  3, pid=20645, effective(0, 0), real(0, 0)] 
../source3/smbd/share_access.c:139(token_contains_name)
  token_contains_name: nt_token_check_sid failed for users, (null)
[2020/10/18 09:04:55.558321,  3, pid=20645, effective(0, 0), real(0, 0)] 
../source3/smbd/share_access.c:155(token_contains_name)
  token_contains_name: returning false for users
[2020/10/18 09:04:55.558364, 10, pid=20645, effective(0, 0), real(0, 0)] 
../source3/smbd/share_access.c:226(user_ok_token)
  User joy not in 'valid users'

This S-1-22-2- base SID seemed indicative, so I googled that, but the best
explanation I could find was in a question at
https://stackoverflow.com/questions/31109871/mapping-sambas-s-1-22-12-sid-into-names
where it says this is something that "Samba uses" for groups.

Is this the idmap setup that I don't seem to have in my old config?

-- 
Josip Rodin

Bug#972223: [Pkg-samba-maint] Bug#972223: Acknowledgement (samba: NT4-style domain member doesn't work without winbind, but even with it, doesn't work)

[Josip Rodin]

On Sat, Oct 17, 2020 at 06:40:39AM +1300, Andrew Bartlett wrote:
> On Thu, 2020-10-15 at 15:37 +0200, Josip Rodin wrote:
> > On Thu, Oct 15, 2020 at 10:06:12AM +0200, Josip Rodin wrote:
> > > Further down the line, I also enabled more debugging, and observed
> > > messages like these:
> > > 
> > > [2020/10/15 08:00:57.669098,  3, pid=29639, effective(0, 0),
> > > real(0, 0)] ../libcli/security/dom_sid.c:210(dom_sid_parse_endp)
> > >   string_to_sid: SID root is not in a valid format
> > > 
> > > [2020/10/15 08:00:57.669313,  3, pid=29639, effective(0, 0),
> > > real(0, 0)] ../libcli/security/dom_sid.c:210(dom_sid_parse_endp)
> > >   string_to_sid: SID @users is not in a valid format
> > > 
> > > I guess I'm gonna have to UTSL to figure that one out
> > 
> > Err, I must be missing something, but I've been trying to add a few
> > changes
> > to libcli/security/dom_sid.c in the unpacked source, and then build
> > and
> > install that, and restart all daemons, but nothing changes in the
> > logs.
> > 
> > How do I debug this?
> 
> I wouldn't automatically assume this is catastrophic, it could just as
> easily be code that wants to parse something as a SID if it is a SID
> (avoiding a remote name lookup for a SID).

Yeah, in the meantime I figured out my mistake, I wasn't installing the
rebuilt samba-libs package (d'oh). You're right, those two SID resolutions
aren't fatal there, instead it can't seem to look up the users group
correctly.

That behavior looks like this at log level 10 (I added a few messages extra):

[2020/10/17 10:26:37.516221,  3, pid=16890, effective(0, 0), real(0, 0)] 
../source3/smbd/share_access.c:98(token_contains_name)
  token_contains_name: string_to_sid failed for @users
[2020/10/17 10:26:37.516338,  5, pid=16890, effective(0, 0), real(0, 0)] 
../source3/auth/user_util.c:160(user_in_netgroup)
  Unable to get default yp domain, let's try without specifying it
[2020/10/17 10:26:37.516370,  5, pid=16890, effective(0, 0), real(0, 0)] 
../source3/auth/user_util.c:164(user_in_netgroup)
  looking for user joy of domain (ANY) in netgroup users
[2020/10/17 10:26:37.516850,  3, pid=16890, effective(0, 0), real(0, 0)] 
../source3/passdb/lookup_sid.c:476(lookup_name_smbconf)
  lookup_name_smbconf: trying with winbind default domain name for users
[2020/10/17 10:26:37.516889, 10, pid=16890, effective(0, 0), real(0, 0)] 
../source3/passdb/lookup_sid.c:113(lookup_name)
  lookup_name: IMAGO\users => domain=[IMAGO], name=[users]
[2020/10/17 10:26:37.516909, 10, pid=16890, effective(0, 0), real(0, 0)] 
../source3/passdb/lookup_sid.c:114(lookup_name)
  lookup_name: flags = 0x077
[2020/10/17 10:26:37.521971,  3, pid=16890, effective(0, 0), real(0, 0)] 
../source3/smbd/share_access.c:151(token_contains_name)
  token_contains_name: returning false for users
[2020/10/17 10:26:37.522069, 10, pid=16890, effective(0, 0), real(0, 0)] 
../source3/smbd/share_access.c:222(user_ok_token)
  User joy not in 'valid users'

I'm afraid I haven't had the time yet to figure out why the netgroup code
can't resolve the users group (I'll keep at it). Yet this is particularly
surprising given that:

% sudo wbinfo -g | grep ^users$
users

...does seem to basically work... Unlike:

% sudo wbinfo -i root
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user root

...which in turn logs the following:

[2020/10/17 10:58:00.352810,  6, pid=638, effective(0, 0), real(0, 0), 
class=winbind] ../source3/winbindd/winbindd.c:912(new_connectio
  accepted socket 21
[2020/10/17 10:58:00.353036, 10, pid=638, effective(0, 0), real(0, 0), 
class=winbind] ../source3/winbindd/winbindd.c:763(process_reque
  process_request_send: process_request: request fn INTERFACE_VERSION
[2020/10/17 10:58:00.353141,  3, pid=638, effective(0, 0), real(0, 0), 
class=winbind] ../source3/winbindd/winbindd_misc.c:419(winbindd
  [ 4727]: request interface version (version = 30)
[2020/10/17 10:58:00.353287, 10, pid=638, effective(0, 0), real(0, 0), 
class=winbind] ../source3/winbindd/winbindd.c:846(process_reque
  process_request_written: [4727:unknown request]: delivered response to client
[2020/10/17 10:58:00.353501, 10, pid=638, effective(0, 0), real(0, 0), 
class=winbind] ../source3/winbindd/winbindd.c:739(process_reque
  process_request: Handling async request 4727:GETPWNAM
[2020/10/17 10:58:00.353554,  3, pid=638, effective(0, 0), real(0, 0), 
class=winbind] ../source3/winbindd/winbindd_getpwnam.c:58(winbi
  getpwnam root
[2020/10/17 10:58:00.353633,  1, pid=638, effective(0, 0), real(0, 0), 
class=rpc_parse] ../librpc/ndr/ndr.c:471(ndr_print_function_deb
   wbint_LookupName: struct wbint_LookupName
  in: struct wbint_LookupName
  domain   : *
  domain   : 'IMAGO'
  na

Bug#972223: Acknowledgement (samba: NT4-style domain member doesn't work without winbind, but even with it, doesn't work)

[Josip Rodin]

On Thu, Oct 15, 2020 at 10:06:12AM +0200, Josip Rodin wrote:
> Further down the line, I also enabled more debugging, and observed
> messages like these:
> 
> [2020/10/15 08:00:57.669098,  3, pid=29639, effective(0, 0), real(0, 0)] 
> ../libcli/security/dom_sid.c:210(dom_sid_parse_endp)
>   string_to_sid: SID root is not in a valid format
> 
> [2020/10/15 08:00:57.669313,  3, pid=29639, effective(0, 0), real(0, 0)] 
> ../libcli/security/dom_sid.c:210(dom_sid_parse_endp)
>   string_to_sid: SID @users is not in a valid format
> 
> I guess I'm gonna have to UTSL to figure that one out

Err, I must be missing something, but I've been trying to add a few changes
to libcli/security/dom_sid.c in the unpacked source, and then build and
install that, and restart all daemons, but nothing changes in the logs.

How do I debug this?

-- 
Josip Rodin

Bug#972223: Acknowledgement (samba: NT4-style domain member doesn't work without winbind, but even with it, doesn't work)

[Josip Rodin]

Hi,

I tried to analyze the samba* attributes in that LDAP directory, and found
some glaring inconsistencies - namely there were 4 pairs of accounts with
duplicate sambaSID attributes. Some time after fixing that, and some service
restarts, I realized that wbinfo -u started to work on the buster Samba
domain member server.

However, the authentication was still broken, based on the users group whose
gitNumber was the default for all users. I checked LDAP and saw its cn=users
entry wasn't a sambaGroup*, so I made it one because that seemed
inconsistent. Sadly, that still didn't help.

When I try to look up a user, it says:

% sudo wbinfo -i joy
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user joy

The log says:

[2020/10/15 06:07:13.320974,  3] 
../source3/winbindd/winbindd_misc.c:419(winbindd_interface_version)
  [24581]: request interface version (version = 30)
[2020/10/15 06:07:13.321216,  3] 
../source3/winbindd/winbindd_getpwnam.c:58(winbindd_getpwnam_send)
  getpwnam joy
[2020/10/15 06:07:13.321898,  5] 
../source3/winbindd/winbindd_getpwnam.c:137(winbindd_getpwnam_recv)
  Could not convert sid S-1-22-1-1000: NT_STATUS_INVALID_PARAMETER

Looks like it wants a domain SID S-1-22-1, which I don't actually recognize
from my LDAP...

Further down the line, I also enabled more debugging, and observed
messages like these:

[2020/10/15 08:00:57.669098,  3, pid=29639, effective(0, 0), real(0, 0)] 
../libcli/security/dom_sid.c:210(dom_sid_parse_endp)
  string_to_sid: SID root is not in a valid format

[2020/10/15 08:00:57.669313,  3, pid=29639, effective(0, 0), real(0, 0)] 
../libcli/security/dom_sid.c:210(dom_sid_parse_endp)
  string_to_sid: SID @users is not in a valid format

I guess I'm gonna have to UTSL to figure that one out

-- 
Josip Rodin

Bug#972223: samba: NT4-style domain member doesn't work without winbind, but even with it, doesn't work

[Josip Rodin]

t makes the package in question
unusable), but I'll try not to harp on that...

Please help. TIA.

-- 
Josip Rodin

Bug#777403: leave: please make the build reproducible

[Josip Rodin]

On Sat, Jul 11, 2020 at 07:32:22AM -0400, Boyuan Yang wrote:
> It has been another 3 years since last reply; is there any possibility
> to push this forward?

Oh, sure, I just forgot about it.

-- 
Josip Rodin

Bug#963785: gman: Search and viewing are inconsistant

[Josip Rodin]

On Fri, Jun 26, 2020 at 01:36:26PM -1000, Howard Johnson wrote:
> Also I'm seeing error messages in monitor I started it in.  I would think that
> I should not be seeing these.  (Example is below)

> $ gman
> P
> sh: $'0k\317G\265\177whatis': command not found

Hmm, if you just run whatis from console, does it work?

-- 
Josip Rodin

Bug#617898: cron.d snippets have different default PATH from crontab/cron.{daily,...}

[Josip Rodin]

severity 617898 normal
thanks

Hi,

Recently I added a logrotate setup that was very similar to apache2's, but
I ran it from a cron.d file, and it obviously failed because the normal
logrotate runs from /etc/crontab, which has a different PATH set.

I think this is not a wishlist item to change this, rather it is a genuine
bug, because I don't see the actual rationale for the behavior of
/etc/crontab and cron(8) to differ in such a fundamental way, and it's
clearly causing a number of users to have to amend their cron.d files
in a way that is redundant and error-prone (having to redefine PATH
everywhere reminds me of the dark days of 1990s Unix systems, and it is
NOT something we want to replicate ever again).

I certainly don't see a downside with adding the sbin variants, because
on Debian systems they're expected to be as reliable as bin variants,
and there should be no confusing overlaps.

For local, an argument could be made that it exposes a possibility of
problems with random local binaries getting in the way, but it would
still probably be better to do this kind of a transition to get everything
consistent. Random complexity just leads to more trouble.

Please fix this. TIA.

-- 
Josip Rodin

Bug#961963: grub serial console forces gfxterm which can break virsh console

[Josip Rodin]

Package: vmdebootstrap
Version: 1.11-2

Hi,

For some reason, vmdebootstrap has started enforcing "gfxterm" for GRUB
console, which seems to break virsh console on a bunch of buster
libvirt-daemon-system setups I tried; only VNC console works that way.

GRUB_TERMINAL="serial console" makes virsh console work again.
/usr/lib/python2.7/dist-packages/vmdebootstrap/grub.py seems to do it
without the option to configure anything.

This seems to be a regression from jessie.

Please fix it. TIA.

-- 
Josip Rodin

Bug#703617: ditto

[Josip Rodin]

Hi,

Looks like people have been noticing this for a while now, e.g.:

https://serverfault.com/questions/320767/apaches-htcacheclean-doesnt-scale-how-to-tame-a-huge-apache-disk-cache

Even when normal find(1) can stroll through the directory within minutes,
htcacheclean just can't seem to keep up.

My current workaround seems to be:

% cat /etc/cron.d/local-htcacheclean
0 0 * * * www-data logger -t /etc/cron.d/local-htcacheclean $(find 
/var/cache/apache2/mod_cache_disk -mtime +30 -type f -print -delete | wc -l)
0 1 * * * www-data logger -t /etc/cron.d/local-htcacheclean $(find 
/var/cache/apache2/mod_cache_disk -mtime +30 -type d -print -delete 2>/dev/null 
| wc -l)

Clearly far from perfect, but at least the inode count doesn't risk causing
write errors to the partition.

Please fix it. TIA.

-- 
Josip Rodin

Bug#954980: hibernate: scriptlet documentation problems

[Josip Rodin]

Package: hibernate
Version: 2.0+15+g88d54a8-1

Hi,

It's not clear from hibernate(8) or hibernate.conf(5) whether the files in
/usr/share/hibernate/scriptlets.d are actually run by default or not.
Should they be symlinked to /etc/hibernate/scriptlets.d/ ? This should be
documented.

/usr/share/doc/hibernate/SCRIPTLET-API.gz mentions:
  Running "bash admin/list-hooks.sh scriptlets.d/" will produce a list of
  all the hook functions in order of execution if you need to look closely.

But this list-hooks.sh script doesn't seem to be provided in the hibernate
package.

The skeleton example in SCRIPTLET-API includes an if for $SKELETON_HOOKED,
but it's not explained anywhere whether this is actually required or not.

Please fix this. TIA.

-- 
Josip Rodin

Bug#945584: vmdb2: lvcreate fails, as if noudevsync is in play

[Josip Rodin]

Package: vmdb2
Version: 0.13.2+git20190215-1

Hi,

I'm switching from vmdebootstrap, and I always used to lvcreate beforehand,
so I was pleasantly surprised to see this facility in vmdb2. Unfortunately,
it seems not to work at all on the fresh Debian 10 system where I tried it
like this:

The first step in foo-bar-1.vmdb.yml was:

  - lvcreate: vg0
name: "{{ image }}"
size: 4G

The invocation was:

% sudo vmdb2 foo-bar-1.vmdb.yml --image /dev/vg0/foo-bar-1-root --verbose 
--log=foo-bar-1.vmd.log

The log said:

2019-11-27 11:19:02 DEBUG Python version: 3.7.3 (default, Apr  3 2019, 
05:39:12) 
[GCC 8.3.0]
2019-11-27 11:19:02 INFO Load spec file foo-bar-1.vmdb.yml
2019-11-27 11:19:02 INFO Running step: {'lvcreate': 'vg0', 'name': 
'/dev/vg0/foo-bar-1-root', 'size': '4G'}
2019-11-27 11:19:02 INFO Calling >
2019-11-27 11:19:02 INFO Exec: ['lvcreate', '--name', 
'/dev/vg0/foo-bar-1-root', '--size', '4G', 'vg0']
2019-11-27 11:19:02 DEBUG run external command: [['lvcreate', '--name', 
'/dev/vg0/foo-bar-1-root', '--size', '4G', 'vg0']]
2019-11-27 11:19:02 DEBUG STDOUT: b'  Logical volume "foo-bar-1-root" 
created.\n'
2019-11-27 11:19:02 ERROR 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/vmdb/app.py", line 107, in 
run_steps_helper
method(step, self.settings, state)
  File "/usr/lib/python3/dist-packages/vmdb/plugins/lvm2_plugin.py", line 74, 
in run
assert os.path.exists(lvdev)
AssertionError
2019-11-27 11:19:02 INFO Something went wrong, cleaning up!
2019-11-27 11:19:02 INFO Running teardown: {'lvcreate': 'vg0', 'name': 
'/dev/vg0/foo-bar-1-root', 'size': '4G'}
2019-11-27 11:19:02 INFO Calling >
2019-11-27 11:19:02 ERROR An error occurred, exiting with non-zero exit code

It's as if it ran lvcreate with --noudevsync or something, but that
shouldn't be...

Please fix it. TIA.

-- 
Josip Rodin

Bug#945581: vmdb2: grub fails on an LV image

[Josip Rodin]

Package: vmdb2
Version: 0.13.2+git20190215-1

Hi,

I pre-created my LV using the same lvcreate syntax that doesn't work from
within vmdb2 (see previous bug filed), and used with the invocation:

% sudo vmdb2 foo-bar-1.vmdb.yml --image /dev/vg0/foo-bar-1-root --verbose 
--log=foo-bar-1.vmd.log

The boot loader step in foo-bar-1.vmdb.yml was the default one from the
manual:

  - grub: bios
tag: root
console: serial

But the log said:

2019-11-27 11:38:31 INFO Installing GRUB for BIOS
2019-11-27 11:38:31 ERROR Do not understand partition device name 
/dev/mapper/vg0-foo--bar--1--root1
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/vmdb/app.py", line 107, in 
run_steps_helper
method(step, self.settings, state)
  File "/usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py", line 98, 
in run
self.install_bios(step, settings, state)
  File "/usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py", line 115, 
in install_bios
self.install_grub(step, settings, state, grub_package, grub_target)
  File "/usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py", line 128, 
in install_grub
image_dev = self.get_image_loop_device(root_dev)
  File "/usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py", line 204, 
in get_image_loop_device
partition_device))
Exception: Do not understand partition device name 
/dev/mapper/vg0-foo--bar--1--root1
2019-11-27 11:38:31 INFO Something went wrong, cleaning up!

I remembered I used to be able to work around these kinds of problems in
similar situations by doing sudo losetup /dev/loop0 /dev/$vg/$host-root
and then operating on /dev/loop0. (That's what worked with vmdebootstrap.)
However, with vmdb2, that doesn't work either, the log says:

2019-11-27 11:41:09 INFO Running step: {'mklabel': 'gpt', 'device': 
'/dev/loop0'}
2019-11-27 11:41:09 INFO Calling >
2019-11-27 11:41:09 INFO Exec: ['parted', '-s', '/dev/loop0', 'mklabel', 'gpt']
2019-11-27 11:41:09 DEBUG run external command: [['parted', '-s', '/dev/loop0', 
'mklabel', 'gpt']]
2019-11-27 11:41:09 INFO Calling >
2019-11-27 11:41:09 INFO Running step: {'mkpart': 'primary', 'device': 
'/dev/loop0', 'start': '0%', 'end': '100%', 'tag': 'root'}
2019-11-27 11:41:09 INFO Calling >
2019-11-27 11:41:09 INFO Exec: ['parted', '-m', '/dev/loop0', 'print']
2019-11-27 11:41:09 DEBUG run external command: [['parted', '-m', '/dev/loop0', 
'print']]
2019-11-27 11:41:09 DEBUG STDOUT: 
b'BYT;\n/dev/loop0:4295MB:loopback:512:512:gpt:Loopback device:;\n'
2019-11-27 11:41:09 INFO Exec: ['parted', '-s', '/dev/loop0', 'mkpart', 
'primary', 'ext2', '0%', '100%']
2019-11-27 11:41:09 DEBUG run external command: [['parted', '-s', '/dev/loop0', 
'mkpart', 'primary', 'ext2', '0%', '100%']]
2019-11-27 11:41:10 INFO Exec: ['parted', '-m', '/dev/loop0', 'print']
2019-11-27 11:41:10 DEBUG run external command: [['parted', '-m', '/dev/loop0', 
'print']]
2019-11-27 11:41:10 DEBUG STDOUT: 
b'BYT;\n/dev/loop0:4295MB:loopback:512:512:gpt:Loopback 
device:;\n1:1049kB:4294MB:4293MB:ext4:primary:;\n'
2019-11-27 11:41:10 INFO remembering partition /dev/loop01 as root
2019-11-27 11:41:10 INFO Calling >
2019-11-27 11:41:10 INFO Running step: {'kpartx': '/dev/loop0'}
2019-11-27 11:41:10 INFO Calling >
2019-11-27 11:41:10 INFO Exec: ['kpartx', '-asv', '/dev/loop0']
2019-11-27 11:41:10 DEBUG run external command: [['kpartx', '-asv', 
'/dev/loop0']]
2019-11-27 11:41:10 DEBUG STDOUT: b'add map loop0p1 (253:3): 0 8384512 linear 
7:0 2048\n'
2019-11-27 11:41:10 INFO remembering /dev/mapper/loop0p1 as root
2019-11-27 11:41:10 ERROR Already has device: root
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/vmdb/app.py", line 107, in 
run_steps_helper
method(step, self.settings, state)
  File "/usr/lib/python3/dist-packages/vmdb/plugins/partition_plugin.py", line 
109, in run
state.tags.set_dev(tag, dev)
  File "/usr/lib/python3/dist-packages/vmdb/tags.py", line 61, in set_dev
raise AlreadyHasDev(tag)
vmdb.tags.AlreadyHasDev: Already has device: root
2019-11-27 11:41:10 INFO Something went wrong, cleaning up!

This latter part is clearly a failure to recognize that the partition number
suffixes cannot be concatenated onto a base device name that ends in a
number. Note how kpartx adds the letter 'p' inbetween.

Please fix it. TIA.

-- 
Josip Rodin

Bug#925698: gman: ftbfs with GCC-9

[Josip Rodin]

On Wed, Mar 27, 2019 at 07:45:20PM +, Matthias Klose wrote:
> GCC 9 also passes the linker option --as-needed by default; typical
> build issues are passing libraries before object files to the linker,
> 
> [...]
> /usr/bin/ld: menu.c:(.text+0x17bb): undefined reference to 
> `gtk_clist_set_column_width'
> [...]

gman: $(objectfiles)
$(CC) -lpthread $(GTK_LIBS) -rdynamic $(objectfiles) -o gman

That sounds like libraries before object files passed to the linker...
So, we just need to swap the order, to:

$(CC) -rdynamic $(objectfiles) -lpthread $(GTK_LIBS) -o gman

?

-- 
 2. That which causes joy or happiness.

Bug#908514: [rt.cpan.org #127094] possible duplicate, doubts about the patch and the original code

[Josip Rodin]

On Fri, Dec 28, 2018 at 10:12:15PM +0100, joy wrote:
>  * https://forum.mikrotik.com/viewtopic.php?t=91863 from 2014
> 
> Even if all those devices have not been RFC-compliant

JFTR I had approached MikroTik about their issue, provided a test case and
tested a beta, and now with RouterOS 6.44 (released 2019-02-25) Net::SNMP
no longer croaks.

-- 
 2. That which causes joy or happiness.

Bug#865141: more info

[Josip Rodin]

Not only does it not work, it errors out with:

% sudo update-grub
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/oldvgname-lvroot'.

Which is to say:

% sudo sh -ex /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg
+ set -e
+ prefix=/usr
+ exec_prefix=/usr
+ datarootdir=/usr/share
+ prefix=/usr
+ exec_prefix=/usr
+ sbindir=/usr/sbin
+ bindir=/usr/bin
+ sysconfdir=/etc
+ PACKAGE_NAME=GRUB
+ PACKAGE_VERSION=2.02~beta3-5+deb9u1
+ host_os=linux-gnu
+ datadir=/usr/share
+ [ x = x ]
+ pkgdatadir=/usr/share/grub
+ export pkgdatadir
+ grub_cfg=
+ grub_mkconfig_dir=/etc/grub.d
+ basename /usr/sbin/grub-mkconfig
+ self=grub-mkconfig
+ grub_probe=/usr/sbin/grub-probe
+ grub_file=/usr/bin/grub-file
+ grub_editenv=/usr/bin/grub-editenv
+ grub_script_check=/usr/bin/grub-script-check
+ export TEXTDOMAIN=grub
+ export TEXTDOMAINDIR=/usr/share/locale
+ . /usr/share/grub/grub-mkconfig_lib
+ prefix=/usr
+ exec_prefix=/usr
+ datarootdir=/usr/share
+ datadir=/usr/share
+ bindir=/usr/bin
+ sbindir=/usr/sbin
+ [ x/usr/share/grub = x ]
+ test x/usr/sbin/grub-probe = x
+ test x/usr/bin/grub-file = x
+ test x = x
+ grub_mkrelpath=/usr/bin/grub-mkrelpath
+ which gettext
+ :
+ grub_tab=
+ test 2 -gt 0
+ option=-o
+ shift
+ argument -o /boot/grub/grub.cfg
+ opt=-o
+ shift
+ test 1 -eq 0
+ echo /boot/grub/grub.cfg
+ grub_cfg=/boot/grub/grub.cfg
+ shift
+ test 0 -gt 0
+ fgrep -qs ${GRUB_PREFIX}/video.lst /etc/grub.d/00_header
+ [ x = x ]
+ id -u
+ EUID=0
+ [ 0 != 0 ]
+ set /usr/sbin/grub-probe dummy
+ test -f /usr/sbin/grub-probe
+ :
+ /usr/sbin/grub-probe --target=device /
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/oldvgname-lvroot'.
+ GRUB_DEVICE=

Which is to say:

% sudo strace grub-probe --target=device / 2>&1 | grep -E 
'(mapper|vg|lv|dev|mount)'
execve("/usr/sbin/grub-probe", ["grub-probe", "--target=device", "/"], [/* 17 
vars */]) = 0
open("/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libudev.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tr"..., 1024) = 311
open("/boot/grub/device.map", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/proc/self/mountinfo", O_RDONLY)  = 3
read(3, "kio rw,nosuid,nodev,noexec,relat"..., 1024) = 717
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3440, ...}) = 0
lstat("/dev/mapper", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
lstat("/dev/mapper/oldvgname-lvroot", 0x7ffc7a97ad80) = -1 ENOENT (No such file 
or directory)
write(2, "failed to get canonical path of "..., 63failed to get canonical path 
of `/dev/mapper/oldvgname-lvroot') = 63

So the problem is the info exposed by the running kernel:

% grep oldvgname "/proc/self/mountinfo"
21 0 253:0 / / rw,relatime shared:1 - ext4 /dev/mapper/oldvgname-lvroot 
rw,errors=remount-ro,data=ordered

Once upon a time, one could mess with /etc/mtab in these cases, but that
file is no longer used, it's a symlink into /proc/mounts.

Not sure if this should be reassigned elsewhere then... maybe lvm2 should
try harder to communicate volume group changes to the running kernel?
The device mapper seems to have done its job in updating /dev/mapper,
but it didn't seem to percolate into mountinfo.

btw xref 
https://askubuntu.com/questions/765058/how-do-you-rename-the-volume-group-that-contains-the-root-volume-in-lvm

-- 
 2. That which causes joy or happiness.

Bug#865141: more info

[Josip Rodin]

And in turn this makes subsequent kernel upgrades croak:

% sudo dpkg --configure -a
Setting up linux-image-4.9.0-8-amd64 (4.9.144-3.1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-8-amd64
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/oldvgname-lvroot'.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
dpkg: error processing package linux-image-4.9.0-8-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 linux-image-4.9.0-8-amd64

-- 
 2. That which causes joy or happiness.

Bug#900761: please separate passwd manipulation from the library package, together with expect et al

[Josip Rodin]

On Mon, Feb 04, 2019 at 02:39:16PM +0100, Markus Wanner wrote:
> On 2/3/19 10:51 PM, Josip Rodin wrote:
> > If it's an upstream issue that can't be fixed with packaging, then
> > tag it upstream and forward it, as the fine manual teaches you to.
> 
> Well, I think of it as a feature, not a bug, so I see no reason to
> forward anything.  Think of authlib as a general abstraction layer over
> several different ways to manage user accounts.  This certainly includes
> the ability to change a users password.

I can't say I agree with this approach, since the scope seems arbitrarily
drawn -- the name of the library says authentication, and that is widely
understood to be the ability to verify a user's identity (read-only), which
is typically distinct from the ability to manipulate the authentication
credentials (read-write).

But what actually led me here was the practical aspect. Compare:

% sudo apt install courier-authlib --no-install-recommends
[...]
The following NEW packages will be installed:
  courier-authlib libltdl7
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 472 kB of archives.
After this operation, 733 kB of additional disk space will be used.

% sudo apt install courier-authlib
[...]
The following NEW packages will be installed:
  courier-authlib expect libdrm-amdgpu1 libdrm-intel1 libdrm-nouveau2 
libdrm-radeon1 libdrm2 libfontenc1 libgl1-mesa-dri
  libgl1-mesa-glx libglapi-mesa libice6 libllvm3.9 libltdl7 libpciaccess0 
libsensors4 libsm6 libtcl8.6 libtk8.6 libtxc-dxtn-s2tc
  libutempter0 libx11-xcb1 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 
libxcb-present0 libxcb-shape0 libxcb-sync1 libxcomposite1
  libxdamage1 libxext6 libxfixes3 libxft2 libxi6 libxinerama1 libxmu6 libxmuu1 
libxrandr2 libxrender1 libxshmfence1 libxss1 libxt6
  libxtst6 libxv1 libxxf86dga1 libxxf86vm1 tcl-expect tcl8.6 tk8.6 x11-common 
x11-utils xbitmaps xterm
0 upgraded, 54 newly installed, 0 to remove and 0 not upgraded.
Need to get 22.1 MB of archives.
After this operation, 179 MB of additional disk space will be used.

Why a security-related library would ever lead to this kind of a thing,
that just seems like something somewhere went horribly wrong.

> > (I'm not sure why people are so anxious to close bug reports these days...)
> 
> The former courier maintainer was blamed to have closed issues too
> quickly without really taking care.  I'm trying to avoid that.
> 
> Can I take that question as an okay to close the issue, then?

I have no idea how you could interpret the above sentence like that.

-- 
 2. That which causes joy or happiness.

Bug#900761: please separate passwd manipulation from the library package, together with expect et al

[Josip Rodin]

On Sat, Feb 02, 2019 at 09:39:25PM +0100, Markus Wanner wrote:
> I fear that's not possible, as it would mean splitting the library
> itself.  Please speak up if you have ideas or wishes on what the
> packaging could do to improve your use case.  Otherwise, I'll close this
> issue.

If it's an upstream issue that can't be fixed with packaging, then
tag it upstream and forward it, as the fine manual teaches you to.

(I'm not sure why people are so anxious to close bug reports these days...)

-- 
 2. That which causes joy or happiness.

Bug#874542: reopen, the wildcard seems to have gotten lost somewhere

[Josip Rodin]

reopen 874542
severity 874542 normal
found 874542 2.9.1-2
found 874542 2.9.2-1~bpo9+1
thanks

Hi there,

Apparently, if the user doesn't honor Recommends, which is no longer the
default but is nevertheless perfectly legitimate, this package fails to
install on stretch with or without backports:

% sudo apt install libapache2-mod-security2
[...]
Setting up libapache2-mod-security2 (2.9.1-2) ...
apache2_invoke: Enable module security2
apache2_reload: Your configuration is broken. Not restarting Apache 2
apache2_reload: apache2: Syntax error on line 147 of /etc/apache2/apache2.conf: 
Syntax error on line 12 of /etc/apache2/mods-enabled/security2.conf: Could not 
open configuration file /usr/share/modsecurity-crs/owasp-crs.load: No such file 
or directory

% sudo apt install libapache2-mod-security2 -t stretch-backports
[...]
Setting up libapache2-mod-security2 (2.9.2-1~bpo9+1) ...
Installing new version of config file 
/etc/modsecurity/modsecurity.conf-recommended ...
apache2_invoke security2: already enabled
apache2_reload: Your configuration is broken. Not restarting Apache 2
apache2_reload: apache2: Syntax error on line 147 of /etc/apache2/apache2.conf: 
Syntax error on line 12 of /etc/apache2/mods-enabled/security2.conf: Could not 
open configuration file /usr/share/modsecurity-crs/owasp-crs.load: No such file 
or directory

The changelog entry says "Change CRS IncludeOptional to wildcard to
get the desired behaviour (not failing when CRS not present)." but this
appears to not be the case in the package itself:

% grep IncludeOptional /etc/apache2/mods-enabled/security2.conf
IncludeOptional /etc/modsecurity/*.conf
IncludeOptional /usr/share/modsecurity-crs/owasp-crs.load

There's no wildcard in the latter statement, did it get lost somewhere?

JFTR, in stretch, apache2 itself is 2.4.25-*, but
https://httpd.apache.org/docs/2.4/mod/core.html#includeoptional says "Not
existent file paths without wildcards do not cause SyntaxError after 2.4.30"

Because of the Recommends relationship, this probably won't be seen by a lot
of users, and it can be trivially worked around by commenting that line out,
so I've downgraded the severity to normal. And in buster, apache2 js already
2.4.37-1. Still, this situation is noticable because it happens on stable,
can't be avoided with stable backports, and failing to install normally
trips up basic exit status checks.

-- 
 2. That which causes joy or happiness.

Bug#918169: munin-node-configure --help is useless

[Josip Rodin]

Package: munin-node
Version: 2.0.25-1+deb8u3, 2.0.33-1

Hi,

For some reason this program is unable to show a half-decent help output:

  % sudo munin-node-configure --help
  Usage:
munin-node-configure [options]

So users have to read its source to see its GetOptions syntax... which isn't
so bad, but still.

Please fix it. TIA.

-- 
 2. That which causes joy or happiness.

Bug#918168: http_loadtime autoconf checks for time(1) incorrectly

[Josip Rodin]

Package: munin-plugins-core
Version: 2.0.25-1+deb8u3, 2.0.33-1

Hi,

The http_loadtime plugin does:

time_bin=`which time`

command -v $time_bin 2>&1 >/dev/null || result=1

But if you don't have the time package installed, $time_bin is nothing, and
command -v with no argument returns 0.

It has to be quoted for command -v to return 1.

Obviously some sort of a package dependency on the time package would be
appreciated, too.

Without this, it is enabled and it crashes with a syntax error.

Please fix it. TIA.

-- 
 2. That which causes joy or happiness.

Bug#908514: [rt.cpan.org #127094] possible duplicate, doubts about the patch and the original code

[Josip Rodin]

On Tue, Jan 01, 2019 at 01:42:23PM +0100, Roland Rosenfeld wrote:
> On Fr, 28 Dez 2018, Josip Rodin wrote:
> > Even if all those devices have not been RFC-compliant, I would still
> > say it's doubtful that the Net::SNMP approach of croaking with a
> > single opaque sentence -- and a code warning on top -- is the right
> > thing to do.
> 
> So what's your suggestion as a DD to handle this in Debian?
> Should I simply add Manuels patch from
> https://rt.cpan.org/Public/Bug/Display.html?id=75191#txn-1040627 to
> the Debian package and change the behavior of Debian Net::SNMP in a
> way that doesn't follow the upstream maintainer but will solve the
> problem of many people using non RFC compliant systems?
> 
> I personally tend to do it that way, but I do not really like the idea
> to ignore upstreams intention here...

I definitely wouldn't do that in the package right now. All those people we
know kludged it that way may have had their use case start working, yet they
probably didn't distribute their kludge to hundreds of thousands of other
places. If you do it, it will lead to having to support various other edge
cases that may well crop up.

Instead, I'd first have upstream speak up - is there a technical reason
why they didn't come up with any solution since 2012?

Note also my subsequent message in
https://rt.cpan.org/Public/Bug/Display.html?id=75191#txn-1826575 - I could
not reproduce the rationale for that original patch, so IMHO it's all on
pretty shaky ground.

-- 
 2. That which causes joy or happiness.

Bug#908514: [rt.cpan.org #127094] possible duplicate, doubts about the patch and the original code

[Josip Rodin]

Hi,

If the logic is changed in line 2620 to assume empty _error to be a sign of
success, it would contradict the comment above that says "If another error
is returned, we assume that the synchronization has failed."

This might actually be a duplicate of 
https://rt.cpan.org/Public/Bug/Display.html?id=75191

Speaking of duplicate reports, I came across this by trying to use a Munin
plugin for access MikroTik's SNMP interface, which seems to work fine using
SNMP v3 from snmpwalk, but croaks in Net::SNMP with v3.
As it turns out, it's been many years now since this code path has been
confusing people, judging by mentions of it in numerous online forums,
like:
 * 
https://forum.centreon.com/forum/centreon-use/centreon-project/6646-centreon-and-snmp-v3/page2
   from 2008
 * http://www.perl-community.de/bat/poard/thread/13628 from 2009
 * https://www.sugarbug.fr/blog/files/supervision_switch_3com_snmpv3.html
   from 2011
 * https://forum.mikrotik.com/viewtopic.php?t=91863 from 2014
 * http://gojooz.blogspot.com/2013/10/snmpv3-error-perl-netsnmp-time.html
   from 2013
 * 
https://sourceforge.net/p/net-snmp/mailman/net-snmp-users/thread/alpine.BSF.2.20.1606121624280.60771%40freesbee.wheel.dk/
   from 2016
 * https://lists.oetiker.ch/pipermail/mrtg/2016-July/037451.html from 2016
 * 
https://community.opmantek.com/display/NMIS/Perl+Net%3A%3ASNMP+Error%3A+Time+synchronization+failed+during+discovery
   from 2018

Even if all those devices have not been RFC-compliant, I would still say
it's doubtful that the Net::SNMP approach of croaking with a single opaque
sentence -- and a code warning on top -- is the right thing to do.

-- 
 2. That which causes joy or happiness.

Bug#875621: ditto

[Josip Rodin]

Hi,

Without this kernel module shipped, users of X1 gen6 are forced to compile,
which is significantly more taxing than just having to unblacklist the
module.

Can't it be shipped, yet added to the default blacklist, until the Yoga X11e
issue is resolved?

(It goes without saying that it's already most annoying to have to fiddle
with anything at all to get basic mouse support on this machine, it's like
it's 1998 all over again and I'm too old for this...)

TIA.

-- 
 2. That which causes joy or happiness.

Bug#476193: closed by Bernhard Schmidt (Closing old bugs against unsupported releases)

[Josip Rodin]

On Mon, Sep 03, 2018 at 10:48:27PM +, Debian Bug Tracking System wrote:
> Subject: ntpdc times out when the server monlist has over 600 clients
> 
> Apparently the people at support.ntp.org have it documented:
> 
> http://support.ntp.org/bin/view/Support/MonitoringAndControllingNTP#Who_is_using_my_NTP_server
> 
> |  Please note that a maximum of 600 entries is supported with current
> |  versions of ntpdc. The protocol (or better: the contents of the return
> |  packets) used by ntpdc is not standardized, therefore it is recommended
> |  to only use ntpdc with a matching ntpd, i.e. both should have the same
> |  version number.
> |
> |  To get by this 600 entry limitation, many server operators run client
> |  statistics scripts [...]
> 
> I went to look at the code, and it looks like ntpdc/ntpdc.c is printing the
> contents of the haveseq array, whose size is MAXSEQ+1, which would be 128,
> so that doesn't sound like. At the other end,
> ntpd/ntp_request.c:mon_getlist_0() is sending over all of the mon_data
> structures found in mon_mru_list, and after looking at that, I see the
> culprit in ntpd/ntp_monitor.c:
> 
> /*
>  * Limits on the number of structures allocated.  This limit is picked  
>  * with the illicit knowlege that we can only return somewhat less
>  * than 8K bytes in a mode 7 response packet, and that each structure
>  * will require about 20 bytes of space in the response.
>  *
>  * ... I don't believe the above is true anymore ... jdg
>  */
> #ifndef MAXMONMEM 
> #define MAXMONMEM   600 /* we allocate up to 600 structures */
> #endif
> [...]
> int
> ntp_monitor(
> [...]
> if (mon_free == NULL && mon_total_mem >= MAXMONMEM) {
> [...]
> 
> I can't help but think that there are better ways to handle this in
> both ntpd and ntpdc. :)

I looked this up after getting the closure message, and it looks like it
might have been addressed upstream with:

commit 9407fc0ef596404e620317a0acf39d63ed27c550
Author:  
Date:   Sat Feb 27 08:47:04 2010 +

[...]
Many files:
  add MRU sizing knobs:
mru mindepth 600 maxage 64 maxdepth 1024 maxmem 4096
  entries beyond 600 which are older than 64s are reclaimed,
with a hard upper limit on the size of maxdepth (indirectly
set by maxmem).
[...]

-- 
 2. That which causes joy or happiness.

Bug#532856: [Pkg-samba-maint] Bug#532856: Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")

[Josip Rodin]

On Mon, Jul 02, 2018 at 01:39:34PM +1200, Andrew Bartlett wrote:
> We simply don't have the resources to manage the tasks you suggest

I'm saying one shouldn't send a message to n-close@bugs.d.o and instead
just keep an existing bug open. That change alone actually conserves
resources. Sending a message to the control bot to tag it upstream and
perhaps mark it wontfix or a custom tag called triaged or something like
that - doesn't sound particularly more taxing compared to closing.

> Upstream (non-packaging) bugs filed here at best have to be copied into
> Samba's bugzilla before any progress can be made and the lossy nature
> of that just makes work for everyone. 

This is literally what every other maintainer is taught to do - weed through
the chaff and forward upstream stuff upstream.

> Finally, debates, even meta debates, about unsupported and ancient
> Samba and MacOS versions are simply not productive.  

Yet, this isn't one, as I've long given up on expecting that upgrade path to
be fixed - I've reverted to arguing simply that if there's a piece of
functionality (Unix extensions) in the software, the documentation for the
software should mention its basic characteristics, esp. those that have been
known to cause annoying behavior in practice.

It would be akin to having the Apache documentation describe its HTTPS
support with two sentences in a manual, and have nothing else whatsoever
(yet it ships e.g. /etc/apache2/mods-available/ssl.conf with a fair bit
of info, and there's other docs too).

-- 
 2. That which causes joy or happiness.

Bug#532856: [Pkg-samba-maint] Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")

[Josip Rodin]

On Mon, Jul 02, 2018 at 09:41:39AM +1200, Andrew Bartlett wrote:
> > How does that make sense? If the option is called "do X", and fails to
> > do X in some opaque circumstances, how is that not a bug? At the very
> > very least, it needs to be explained somewhere. Last I checked, there
> > was nothing in the smb.conf manual to indicate that any of this would
> > happen. The existence of a chmod extension isn't even mentioned. (As I
> > said before.)
> > 
> > On a more general note, I would recommend triaging user bug reports when you
> > are available to actually try to understand what users are saying. Ignoring
> > information provided and repeating the same question all over again is
> > unhelpful at best.
> 
> Honestly, this really isn't the place.
> 
> While this goes against general Debian practice, these bug reports are
> really not a good place to discuss general issues with Samba.  

It's unreasonable to have a Debian package that doesn't respect the
universally common practices of the Debian bug tracking system.

The Debian social contract doesn't go into that much detail, to explicitly
require keeping bugs open because they exist in practice -- but common sense
and decades of precedent do.

Or is this some new thing that we're now doing, am I that much out of
the loop?

-- 
 2. That which causes joy or happiness.

Bug#532856: [Pkg-samba-maint] Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")

[Josip Rodin]

On Fri, Jun 29, 2018 at 11:04:27AM +0200, Mathieu Parent wrote:
> The "create mask" doesn't impact the chmod UNIX extension.

Exactly, and likewise for "force create mode". How does that make sense? If
the option is called "do X", and fails to do X in some opaque circumstances,
how is that not a bug? At the very very least, it needs to be explained
somewhere. Last I checked, there was nothing in the smb.conf manual to
indicate that any of this would happen. The existence of a chmod extension
isn't even mentioned. (As I said before.)

On a more general note, I would recommend triaging user bug reports when you
are available to actually try to understand what users are saying. Ignoring
information provided and repeating the same question all over again is
unhelpful at best.

-- 
 2. That which causes joy or happiness.

Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")

[Josip Rodin]

On Mon, Jun 18, 2018 at 09:51:03PM +, Debian Bug Tracking System wrote:
> Closing as this is not a bug but a configuration tuning.

Sorry, what? I don't see such an explanation in the bug log.

Two people said "unix extensions = no" would work around the issue.
Nobody provided an actual solution to the issue.
Nobody responded to the part where I said:

> I had specified all documented options that describe native Linux permission
> masks to be applied on files on Samba shares. The daemon ignored this
> because of another implicit option being in effect, one which contradicted
> those other, explicit settings. That just doesn't make sense from a user
> standpoint, regardless of the rationale. A proper bug fix would be to change
> the behaviour of that new option to take into account the requirements set
> by old options (better), or to fully document the impact of the new option
> and make it explicit (worse, but still satisfactory).

Can you?

-- 
 2. That which causes joy or happiness.

Bug#900761: please separate passwd manipulation from the library package, together with expect et al

[Josip Rodin]

Package: courier-authlib

Hi,

For some reason there exists an expect script in
/usr/lib/courier/courier-authlib/authsystem.passwd
which seems to be calling passwd(1),
which causes courier-authlib to depend on expect(1),
which in turn has a bunch of other dependencies,
which in turn gets installed on all systems where users want packages
that happen to depend on courier-authlib (regardless of whether those
users actually use the authlib's facilities)

In my case, the latter is maildrop, which honestly I have no idea whatsoever
how it could ever come into a situation where it would want the
authentication subsystem to invoke a user password change.

In fact I'm pretty sure someone would slap us with a critical security bug
if it ever came to pass that a mail filtering utility was even attempting
to manipulate the password of a user for whom it was filtering mail.

And they would not be wrong, because that scenario sounds like an
abomination. I sincerely hope it is not practically possible.

Please separate this functionality from the library package into a separate
package, which can then depend on and invoke whatever it needs.

TIA.

-- 
 2. That which causes joy or happiness.

Bug#675906: ditto

[Josip Rodin]

FWIW I can't remember a dist-upgrade of a samba server in my life where
smb.conf changes weren't a very annoying distraction...

It seems that whenever you have anything within the global section of
smb.conf, like domain membership or log level or any number of assorted
similar settings, it lists that in the diff as something to be removed.

It also doesn't seem to like shares commented out, saw a lot of that in the
diffs slated for removal, too.

And just executing the 3-way merge seems to inevitably lead to the removal
of all local settings en masse, and then there's no backup file for them.
(This might be a generic ucf thing, which is probably why that option is
marked experimental?)

Using a .d subdirectory to farm out settings into more manageable hunks
isn't really a hack these days, it's SOP to avoid having sysadmins go
berserk when doing upgrades.

-- 
 2. That which causes joy or happiness.

Bug#884163: ditto

[Josip Rodin]

Hi,

I had a post-upgrade reboot surprise me like this:

% grep ^ENABLED /etc/default/spamassassin
ENABLED=1
% ls -l /etc/default/spamassassin
-rw-r--r-- 1 root root 908 Vel 21  2008 /etc/default/spamassassin
% sudo systemctl status spamassassin -l
* spamassassin.service - Perl-based spam filter using text analysis
   Loaded: loaded (/lib/systemd/system/spamassassin.service; disabled)
   Active: inactive (dead)

The package really needs to have followed up on the earlier enable flag,
there was nothing ambiguous about this situation.

The updated package introduced a /lib/systemd/system/spamassassin.service
file that didn't seem to follow up on the earlier configuration, so it
is clearly at fault; even if we say that spamd should be in a separate
package, for as long as it is not, the existing users need to be
supported...

Please fix this. TIA.

-- 
 2. That which causes joy or happiness.

Bug#81077: clarify

[Josip Rodin]

retitle 81077 links: Cyrillic transliteration not aware of varieties
thanks

My original bug report was insufficiently informed - there are a variety
of transliteration methods, and the default one picked is in fact the
most common one for the Russian language and character sets.

It would, however, be nice if it was able to detect other languages and
character set combinations. I checked Serbian and it doesn't use the
most relevant transliteration there.

There's an informative list of various options at the Firefox addon site
http://www.benya.com/transliterator

TIA

-- 
 2. That which causes joy or happiness.

Bug#781961: ditto

[Josip Rodin]

On Tue, Feb 20, 2018 at 03:06:36PM -0800, Jamie Zawinski wrote:
> It is not my responsibility to secure Debian's laptop power management system.
> 
> It is not my responsibility to integrate xscreensaver with Debian's laptop 
> power management system.
> 
> It is my responsibility to make *xscreensaver* as secure as it can be.
> 
> It is my judgement that linking with additional massive, 
> someone's-learning-experience libraries like dbus does exactly the opposite 
> of that.
> 
> Again, you have my sympathies that the operating system you choose to use 
> treats security as an afterthought.

That's all fine, but it seems like the line is drawn arbitrarily.
libx11 alone has had numerous vulnerabilities over the last few years.
Ctrl+Alt+Backspace and similar are still not completely eradicated.
I'm not sure we should be bashing a < 1 MB library and daemon
when many larger and much more critical dependencies are guilty
of the exact same issues. Am I missing something specific to dbus?

-- 
 2. That which causes joy or happiness.

Bug#781961: ditto

[Josip Rodin]

On Tue, Feb 20, 2018 at 12:00:20PM -0800, Jamie Zawinski wrote:
> There is absolutely no chance in hell that the xscreensaver daemon will
> ever, ever link with dbus. Over my dead body. For all of these reasons:
> https://www.jwz.org/xscreensaver/toolkits.html

With so many users forced to manually apply workarounds to this security
issue, goodness knows how many different other security issues are being
created. A single, minimal, audited solution would seem preferable to this
hodgepodge.

FWIW the overall security record of all those 15 libraries that are already
linked doesn't necessarily inspire a whole lot of confidence. It seems like
a tradeoff either way.

-- 
 2. That which causes joy or happiness.

Bug#781961: ditto

[Josip Rodin]

On Sun, Feb 18, 2018 at 02:13:41PM -0800, Jamie Zawinski wrote:
> I absolutely agree with you that there should be documentation on how to
> solve this problem.
> 
> If you come up with a set of simple steps that solve it, please let me
> know and I will happily add it to the xscreensaver FAQ. The reason it's
> not there already is that I have no idea -- because, as you have
> discovered in your googling, the whole thing is a gigantic clusterfuck of
> competing and incompatible non-solutions.

The dbus method sounds like it's here to stay, as it seems fairly
lightweight... Would it be possible for you to link to that library,
and engage that delay lock if it exists (hopefully it doesn't croak
if logind isn't there)? It seems that the other libraries xscreensaver
already depends on pull libdbus in anyway, so there's no extra overhead
in that regard.

-- 
 2. That which causes joy or happiness.

Bug#781961: ditto

[Josip Rodin]

On Sun, Feb 18, 2018 at 10:39:10PM +0100, Josip Rodin wrote:
> On Sun, Feb 18, 2018 at 07:21:52PM +0100, Josip Rodin wrote:
> > The xscreensaver package should probably document some of these options,
> > provide examples, and add some package relationships to indicate what should
> > be done... laptops suspending isn't really a niche use case these days.
> 
> Fun fact: the latter method I found is already obsolete... the systemd way
> is to put something in /lib/systemd/system-sleep/, yet the systemd-sleep
> manual page says:
> 
>Note that scripts or binaries dropped in /lib/systemd/system-sleep/ are
>intended for local use only and should be considered hacks. If
>applications want to be notified of system suspend/hibernation and
>resume, there are much nicer interfaces available.
> 
> It proceeds not to actually mention any one of those nicer interfaces.

Found it after some more googling, at
https://wiki.freedesktop.org/www/Software/systemd/inhibit/

A screen lock tool wants to bring up the screen lock right before
suspend, and delay the suspend until that's complete. Applications which
want to make use of the inhibition logic shall take an inhibitor lock
via the logind D-Bus API.

-- 
 2. That which causes joy or happiness.

Bug#781961: ditto

[Josip Rodin]

On Sun, Feb 18, 2018 at 07:21:52PM +0100, Josip Rodin wrote:
> Apparently there's a whole little cottage industry of ways people have been
> trying to use to get this working, e.g.:
> 
>  * a xss-lock package that subscribes to Linux power events more
>natively
>  * a pm-utils package which provides a hooking mechanism in
>/usr/lib/pm-utils/sleep.d/
> 
> The xscreensaver package should probably document some of these options,
> provide examples, and add some package relationships to indicate what should
> be done... laptops suspending isn't really a niche use case these days.

Fun fact: the latter method I found is already obsolete... the systemd way
is to put something in /lib/systemd/system-sleep/, yet the systemd-sleep
manual page says:

   Note that scripts or binaries dropped in /lib/systemd/system-sleep/ are
   intended for local use only and should be considered hacks. If
   applications want to be notified of system suspend/hibernation and
   resume, there are much nicer interfaces available.

It proceeds not to actually mention any one of those nicer interfaces.

-- 
 2. That which causes joy or happiness.

Bug#781961: ditto

[Josip Rodin]

Hi,

After reproducing this information leak for a while, it occurred to me to go
report it, and I see I'm not alone :)

Apparently there's a whole little cottage industry of ways people have been
trying to use to get this working, e.g.:

 * a xss-lock package that subscribes to Linux power events more
   natively
 * a pm-utils package which provides a hooking mechanism in
   /usr/lib/pm-utils/sleep.d/

The xscreensaver package should probably document some of these options,
provide examples, and add some package relationships to indicate what should
be done... laptops suspending isn't really a niche use case these days.

-- 
 2. That which causes joy or happiness.

Bug#890753: rxvt processes get stuck after the shell exits

[Josip Rodin]

Here's a backtrace with rxvt-dbgsym installed:

(gdb) bt
#0  0xb76dbcf9 in __kernel_vsyscall ()
#1  0xb7350d61 in __lll_lock_wait_private ()
at ../sysdeps/unix/sysv/linux/i386/lowlevellock.S:97
#2  0xb7347ad7 in __nptl_setxid (cmdp=0xbf8a6ee8) at allocatestack.c:1085
#3  0xb74a2336 in __GI_seteuid (uid=1000)
at ../sysdeps/unix/sysv/linux/i386/seteuid.c:31
#4  0x0048394e in rxvt_privileges (mode=114, r=0x2319008) at main.c:288
#5  rxvt_privileged_utmp (action=114 'r', r=0x2319008) at main.c:322
#6  rxvt_clean_exit () at main.c:196
#7  0xb73f079b in __run_exit_handlers (status=0, 
listp=0xb75763dc <__exit_funcs>, run_list_atexit=true, run_dtors=true)
at exit.c:83
#8  0xb73f0801 in __GI_exit (status=0) at exit.c:105
#9  0x004835a5 in rxvt_Child_signal (sig=17) at main.c:141
#10 
#11 0xb76dbcf9 in __kernel_vsyscall ()
#12 0xb7347d67 in __nptl_setxid (cmdp=) at allocatestack.c:1172
#13 0xb74a2336 in __GI_seteuid (uid=1000)
at ../sysdeps/unix/sysv/linux/i386/seteuid.c:31
#14 0x0048394e in rxvt_privileges (mode=114, r=0x2319008) at main.c:288
#15 rxvt_privileged_utmp (action=114 'r', r=0x2319008) at main.c:322
#16 rxvt_clean_exit () at main.c:196
#17 0x00482369 in rxvt_cmd_getc (r=0x2319008) at command.c:754
#18 0x004833e9 in rxvt_main_loop (r=0x2319008) at command.c:3031
#19 0x0047f64c in main (argc=1, argv=0xbf8a7934) at rxvt.c:13

-- 
 2. That which causes joy or happiness.

Bug#890753: rxvt processes get stuck after the shell exits

[Josip Rodin]

Package: rxvt
Version: 1:2.7.10-7+b1
Severity: important

Hi,

After upgrading from jessie to stretch, when I start rxvt from xfce, and
then simply run exit in the shell, the process sometimes gets stuck.
I see a blank rxvt window that I can't terminate with the window manager's
X button.

In the process list, they look fairly normal:

joy797  0.0  0.0   4856  3496 ?S12:53   0:00  \_ rxvt
joy943  0.0  0.0   4724  3516 ?S12:57   0:00  \_ rxvt
joy974  0.0  0.0   4724  3516 ?S13:03   0:00  \_ rxvt
joy   1000  0.3  0.0   4724  3568 ?S13:04   0:00  \_ rxvt

But tracing some of them reveals:

strace: Process 943 attached
futex(0xb735e1b0, FUTEX_WAIT_PRIVATE, 2, NULL

(gdb) bt
#0  0xb76dbcf9 in __kernel_vsyscall ()
#1  0xb7350d61 in __lll_lock_wait_private ()
at ../sysdeps/unix/sysv/linux/i386/lowlevellock.S:97
#2  0xb7347ad7 in __nptl_setxid (cmdp=0xbf8a6ee8) at allocatestack.c:1085
#3  0xb74a2336 in __GI_seteuid (uid=1000)
at ../sysdeps/unix/sysv/linux/i386/seteuid.c:31
#4  0x0048394e in rxvt_clean_exit ()
#5  0xb73f079b in __run_exit_handlers (status=0, 
listp=0xb75763dc <__exit_funcs>, run_list_atexit=true, run_dtors=true)
at exit.c:83
#6  0xb73f0801 in __GI_exit (status=0) at exit.c:105
#7  0x004835a5 in rxvt_Child_signal ()
#8  
#9  0xb76dbcf9 in __kernel_vsyscall ()
#10 0xb7347d67 in __nptl_setxid (cmdp=) at allocatestack.c:1172
#11 0xb74a2336 in __GI_seteuid (uid=1000)
at ../sysdeps/unix/sysv/linux/i386/seteuid.c:31
#12 0x0048394e in rxvt_clean_exit ()
#13 0x00482369 in ?? ()
#14 0x004833e9 in ?? ()
#15 0x0047f64c in main ()

And if I don't kill them manually before reboot, they impede that,
systemd waits a very long time after trying to kill them (don't know
how much, I got bored and killed the laptop physically after a while).

Please fix it. TIA.

-- 
 2. That which causes joy or happiness.

Bug#833182: Info received (ditto, but different resolution)

[Josip Rodin]

It should be noted that the general issue involving needing to use
libpam-systemd or xserver-xorg-legacy but the errors being vague already
has a separate bug report at #890749.

The aspects of this bug regarding the Intel video driver remain relevant,
though.

-- 
 2. That which causes joy or happiness.

Bug#801401: splitting off distinct issues

[Josip Rodin]

retitle 801401 with systemd, cannot start X from the console command line using 
xinit, only startx
clone 801401 -1
severity 801401 normal
retitle -1 using startx requires either libpam-systemd or xserver-xorg-legacy
submitter -1 James Richardson 
thanks

I just happened to find this bug report after researching #833182... it
looks like it had a very generic title, and all sorts of issues got tacked
on - but Giuseppe Bilotta's original issue came down to startx vs. xinit, so
that should be the title there.

The complaints about needing to either use libpam-systemd or
xserver-xorg-legacy should be split to a separate bug report.
These were first articulated by James Richardson, so I'm resetting
submitter.

-- 
 2. That which causes joy or happiness.

Bug#887098: joe orphans buffers for no reason

[Josip Rodin]

On Sat, Jan 13, 2018 at 02:33:35PM -0500, Wolfgang Tichy wrote:
> When I start joe with just one C-file and then press Esc-C to compile, joe
> orphans my C-file into a buffer. Instead I am left with 2 windows. One
> contains the new file "Unnamed" , the other contains "* Build Log *". If I
> use Ctrl-K N, I cannot get back to my C-file, because it's in an orphaned
> buffer. The only way to get it back is with Esc-U to put the buffer back
> into a window. This seems a little counterintuitive.

I can confirm that Ctrl+K+N doesn't seem to work, but then, Esc+V does.
Or when you do Ctrl+C to close both of those, the original file reappears
as before.

I guess the most confusing part here for me is the upper window Unnamed.
What would that be for? That sounds like a mistake, like it should have
been the place for the original file to be shown...?

-- 
 2. That which causes joy or happiness.

Bug#833182: ditto, but different resolution

[Josip Rodin]

Hi,

I observed something very similar this after a jessie -> stretch
dist-upgrade. My whole failing logfile is attached, and the gist of the
problem was in these errors:

[...]
[  5115.028] (EE) systemd-logind: failed to get session: PID 4398 does not 
belong to any known session
[...]
[  5116.097] (EE) modeset(0): drmSetMaster failed: Permission denied
[  5116.097] (EE) 
[  5116.097] (EE) AddScreen/ScreenInit failed for driver 0
[...]

The first error appeared to be the root cause - it was caused by not reading
through
https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#x-no-longer-requires-root
where it said that the new way needs libpam-systemd

Nothing had installed that package in my dist-upgrade, probably because
I didn't choose to observe Recommends.

After installing that and rebooting, everything was fine and Xorg runs as
my own user, yay.

I'll also note here that my first searches for the latter error message
had produced a workaround - installing xserver-xorg-legacy and setting
needs_root_rights=yes in Xwrapper.config. But that result is obviously
inferior.

It would be much better if the Xorg modesetting error messages were somewhat
clearer as to what actually went wrong.

It looks like the defaults excluded the intel driver as such:

[  5115.616] (==) Matched nouveau as autoconfigured driver 0
[  5115.616] (==) Matched nv as autoconfigured driver 1
[  5115.616] (==) Matched modesetting as autoconfigured driver 2
[  5115.616] (==) Matched fbdev as autoconfigured driver 3
[  5115.616] (==) Matched vesa as autoconfigured driver 4

When it worked, driver 2 actually seems to have reported:

[20.775] (II) modeset(0): [DRI2] Setup complete
[20.775] (II) modeset(0): [DRI2]   DRI driver: i965
[20.775] (II) modeset(0): [DRI2]   VDPAU driver: i965

This is counterintuitive given that I have xserver-xorg-video-intel
installed. If the intel driver is installed, that should provide
at least some sort of a hint to the Xorg server on runtime.

Maybe to include it in the list of defaults? I don't have several of the
above drivers installed and these particular wrong defaults merely lead to
more redundant error output...

If not that, then perhaps the modesetting driver should tell the user
that it tried to take command over these drivers, but that perhaps its
failure should not be completely fatal?

Arguably the situation is made complex by the fact that these laptops
have two GPUs, the Intel and the Nvidia one, and so both the users and
the software are more likely to be confused by default.

-- 
 2. That which causes joy or happiness.


Xorg.0.log.old
Description: application/trash

Bug#877664: joe: display corruption on many Unicode characters

[Josip Rodin]

On Sat, Feb 17, 2018 at 09:22:34PM +0100, Adam Borowski wrote:
> > https://sourceforge.net/p/joe-editor/bugs/380/
> 
> That site uses some broken Javascript that keeps breaking even when writing
> a reply.  That's on par with how SourceForge has been working since 2003 or
> so, only the kind of breakage changes...
> 
> As I've been unable to post the reply (the web bug tracker drops the partial
> text at a random moment; can't even paste in), commenting here.  I guess
> using some particular version of Internet Explorer^W^WChrome might succeed.

It seems to be working in my ordinary Firefox 52 from stretch.
I've relayed your comment.

-- 
 2. That which causes joy or happiness.

Bug#856351: ditto from screen

[Josip Rodin]

Hi,

I saw this error message when I accidentally ran startx on tty1 from a
screen(1) session.

For some reason, there's a root-owned /dev/tty0 on the machine.
Should there be one? I certainly don't seem to see it - I have
six VTs set up, and e.g. /dev/tty1 where I'm running that startx
is owned by my user.

The only non-comment content of Xwrapper.config is "allowed_users=console"

man Xwrapper.config fails to run, oddly enough

-- 
 2. That which causes joy or happiness.

Bug#877664: joe: display corruption on many Unicode characters

[Josip Rodin]

On Wed, Oct 04, 2017 at 01:06:58AM +0200, Adam Borowski wrote:
> Package: joe
> Version: 4.4-1
> Severity: normal
> 
> If you try to edit for example the following file:
> .
> ???
> ???
> ???
> 
> 
> 
> 
> ???
> ???
> 
> 
> 
> `
> joe displays wrong not just everything to the right of a character, but even
> most subsequent lines; redraw doesn't help.  This happens on all terminals
> that know about double-width characters.

Did you happen to see what upstream folks wrote in

https://sourceforge.net/p/joe-editor/bugs/380/

? 

-- 
 2. That which causes joy or happiness.

Bug#887953: lxc-download drops stderr from external commands whose failure can be fatal

[Josip Rodin]

Package: lxc
Version: 1:2.0.7-2+deb9u1

Hi,

I tried following the https://wiki.debian.org/LXC#Unprivileged_container
guide on a new machine, but got stuck on:

% sudo lxc-create -o lxc-create.log -l DEBUG --name test1 -t download
Setting up the GPG keyring
ERROR: Unable to fetch GPG key from keyserver.
lxc-create: lxccontainer.c: create_run_template: 1297 container creation 
template for test1 failed
lxc-create: tools/lxc_create.c: main: 318 Error creating container test1

So something went wrong, but what? Even with the most detailed level of
logging, it doesn't say:

 lxc-create 20170121234841.963 INFO lxc_confile - 
confile.c:config_idmap:1531 - read uid map: type u nsid 0 hostid 10 range 
65536
 lxc-create 20170121234841.963 INFO lxc_confile - 
confile.c:config_idmap:1531 - read uid map: type g nsid 0 hostid 10 range 
65536
 lxc-create 20170121234841.964 INFO lxc_confile - 
confile.c:config_idmap:1531 - read uid map: type u nsid 0 hostid 10 range 
65536
 lxc-create 20170121234841.964 INFO lxc_confile - 
confile.c:config_idmap:1531 - read uid map: type g nsid 0 hostid 10 range 
65536
 lxc-create 20170121234842.593 ERRORlxc_container - 
lxccontainer.c:create_run_template:1297 - container creation template for test1 
failed
 lxc-create 20170121234842.596 INFO lxc_container - 
lxccontainer.c:container_destroy:2398 - Destroyed rootfs for test1
 lxc-create 20170121234842.598 INFO lxc_container - 
lxccontainer.c:container_destroy:2414 - Destroyed directory for test1
 lxc-create 20170121234842.598 ERRORlxc_create_ui - 
tools/lxc_create.c:main:318 - Error creating container test1

(Why is the timestamp in 2017? date(1) on the machine says 2018.)
 
A peek into the source revealed the culprit - actual effort appears to have
been put into making the relevant fetch command never log any errors.
And then some:

% grep 'null 2>&1' /usr/share/lxc/templates/lxc-download
if ! wget_wrapper -T 30 -q https://${DOWNLOAD_SERVER}/$1 -O $2 >/dev/null 
2>&1; then
if ! wget_wrapper -T 30 -q http://${DOWNLOAD_SERVER}/$1 -O $2 
>/dev/null 2>&1; then
--recv-keys ${DOWNLOAD_KEYID} >/dev/null 2>&1; then
if ! type $bin >/dev/null 2>&1; then
if ! type gpg >/dev/null 2>&1; then
if ! type mktemp >/dev/null 2>&1; then
chown -R $LXC_MAPPED_UID $LXC_CACHE_BASE >/dev/null 2>&1 || true
chgrp -R $LXC_MAPPED_GID $LXC_CACHE_BASE >/dev/null 2>&1 || true
chown $LXC_MAPPED_UID $LXC_PATH/config $LXC_PATH/fstab >/dev/null 2>&1 || 
true
chgrp $LXC_MAPPED_GID $LXC_PATH/config $LXC_PATH/fstab >/dev/null 2>&1 || 
true

Once I removed that from the gpg invocation, I got the answer:

gpg: keybox '/tmp/tmp.sxyjecGTyC/gpg/pubring.kbx' created
gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory
gpg: connecting dirmngr at '/tmp/tmp.sxyjecGTyC/gpg/S.dirmngr' failed: No such 
file or directory
gpg: keyserver receive failed: No dirmngr
gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory
gpg: connecting dirmngr at '/tmp/tmp.sxyjecGTyC/gpg/S.dirmngr' failed: No such 
file or directory
gpg: keyserver receive failed: No dirmngr
gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory
gpg: connecting dirmngr at '/tmp/tmp.sxyjecGTyC/gpg/S.dirmngr' failed: No such 
file or directory
gpg: keyserver receive failed: No dirmngr

Adding a check for the existence of dirmngr prior to executing
gpg --keyserver would be superfluous if all this stderr wasn't
explicitly hidden.

I see what might have prompted it - if it's shown by default, in case
where everything works, one still gets the following line printed:

gpg: keybox '/tmp/tmp./gpg/pubring.kbx' created

But if that needs to be captured, then that is what should be done -
which is quite possible without discarding all of stderr.

Please fix it. TIA.

-- 
 2. That which causes joy or happiness.

Bug#818377: improve courier-maildrop compatibility

[Josip Rodin]

On Sun, Dec 31, 2017 at 10:09:22AM +0900, Osamu Aoki wrote:
> | AC_DEFINE_UNQUOTED(HAVE_COURIER,1,
> | [ Whether this version of maildrop is part of Courier ])

All of those changes related to HAVE_COURIER sound like something that
should be possible to figure out on runtime. For example, it could detect
some Courier-specific config file somewhere in /etc/, and then make those
few subtle changes in behavior.

> But in the courier MTA use case, the upstream apparently had need to keep
> this program setUID root and added some extra codes to take advantage
> (code before the quoted section seems to be for such purpose) of it and to
> limit it privilege as quoted in the above.

I still don't see a rationale for that. The existence of those measly few
lines about the HAVE_COURIER define, that we then have to interpret and
reverse-engineer and whatnot - simply don't constitute a valid rationale
for adding back a binary with suid root by default.

I think we need to ask Sam to document this properly, and only then proceed
with any further considerations.

-- 
 2. That which causes joy or happiness.

Bug#818377: improve courier-maildrop compatibility

[Josip Rodin]

On Sun, Dec 24, 2017 at 09:17:28AM +0900, Osamu Aoki wrote:
> Another option is create another wrapper code such as maildrop-suid-root
> which is a SUID on root program and let it calls maildrop in upstream.
> And make courier call this new code.  This needs upstream cooperation.  
> 
> I don't want to maintain any SUID root program.  Too much
> responsibility.  If you are willing to take over this package
> maintenance, I can help 2 binary package script.

It doesn't make sense to add a new setuid root binary in the maildrop
package. Whatever problem there is to solve, more setuid root by default
is simply not a legitimate solution without a big fat obvious rationale
about how it's unavoidable. Let's not jump to any such conclusions
beforehand.

-- 
 2. That which causes joy or happiness.

Bug#709104: [pkg-gnupg-maint] Bug#709104: libgpgme11 dependency suckage

[Josip Rodin]

On Sun, Sep 10, 2017 at 08:07:46PM -0400, Daniel Kahn Gillmor wrote:
> you don't want to be bothered to install pinentry-curses before upgrading

The point isn't that I personally happen not to want to be bothered to do
a specific thing; the point is that these kinds of issues get noticed years
after the fact. It was prefaced with JFTR, which, while abbreviated, was
nevertheless critical in explaining my intent. I'm sorry that you found it
to be too inflammatory or felt that I somehow addressed you in particular;
I didn't intend that to happen, rather, I wanted to note for posterity what
happened in hope that anyone interested enough to read would learn from this
history.

-- 
 2. That which causes joy or happiness.

Bug#875370: dependency on PSL pulls in ICU, which dwarfs wget in size

[Josip Rodin]

Package: wget
Severity: minor

Hi,

Resolving #766780 seems to have pulled in a pair of disproportionally large
libraries:

  [...]
  The following NEW packages will be installed:
libicu52 libpsl0
  The following packages will be upgraded:
wget
  [...]
  After this operation, 28,4 MB of additional disk space will be used.

Can this new dependency be made more optional, please? There's oh so many
situations where wget is used to download something where cookies are not
used at all, and having this amount of cruft lying around on the off chance
you enable cookies and then talk to a malicious server makes very littlek
sense.

See also https://lists.debian.org/debian-boot/2014/11/msg00595.html

TIA.

-- 
 2. That which causes joy or happiness.

Bug#709104: libgpgme11 dependency suckage

[Josip Rodin]

JFTR the pinentry gtk ridiculosity, addressed in bug #753163, was never
fixed in jessie, so upgrading headless servers that e.g. have mutt installed
to read a few files in /var/mail/, has caused tons of these completely
pointless dependencies to be installed via libgpgme11; or, rather, for
libgpgme11 (and programs depending on it) to be removed and remembered as
a pariah...

-- 
 2. That which causes joy or happiness.

Bug#422347: [pkg-ntp-maintainers] Packaging ntpq seperately

[Josip Rodin]

On Fri, Jul 07, 2017 at 09:01:35AM +0200, Bernhard Schmidt wrote:
> > Yes, it's common to set up a network service in a way that only localhost
> > will access it. No, that doesn't conflict with the idea that server software
> > goes into server software packages and client software goes into client
> > software packages.
> 
> Well, patches accepted, but ntpq is not really the client for ntp (or
> the ntp protocol). It can be compared to a control program, which is
> often inside the server package (i.e. unbound-control in unbound).

I thought of responding to this by saying I could be persuaded to this
argument in the case of ntpdc, which resembles unbound-control, or rndc,
in that it actually exerts control over ntpd, yet ntpq was just a query
program that monitors ntpds rather than controls them...

But then I noticed that ntpq included commands like saveconfig,
config-from-file, ... And, conversely, ntpdc includes numerous *stats and
*info commands. It's hard to argue any matter of principle when
the underpinnings of the matter appear devoid of it.

Since nobody remembers the etch upgrade that had broken this, I guess the
only remaining argument would be practicality mentioned by the submitter of
#582128 - they want to run ntpq and ntpdc from a machine that has chrony
installed. That's severity wishlist rather than normal, though, because of
the lack of precedent with the aforementioned rndc and unbound-control.

-- 
 2. That which causes joy or happiness.

Bug#464035: closed by Mathieu Parent <math.par...@gmail.com> (Re: Bug#464035: 464035 [Pkg-samba-maint] Bug#464035: samba: Cannot connect user)

[Josip Rodin]

It should be noted for anyone looking at the bug report that this didn't
seem to make any sense with regard to the original submission.

Right now things look like this at one of my Samba servers:

% sudo find /var/log/samba/ -type f -mtime -5 -print0 | xargs -0 grep -h -A1 
getpeername | grep -v '^--$' | sort | uniq -c
   1938   getpeername failed. Error was Transport endpoint is not connected
   1477   read_fd_with_timeout: client 0.0.0.0 read error = Connection reset by 
peer.
 14   read_fd_with_timeout: client 0.0.0.0 read error = Connection timed 
out.
 81   read_fd_with_timeout: client 0.0.0.0 read error = No route to host.
366   write_data: write failure in writing to client 0.0.0.0. Error Broken 
pipe

These subsequent lines make it more obvious that there seems to be a problem
with the remote end rather than with the Samba server, which seems like
a decent enough resolution to the original bug submission.

On Tue, Jun 27, 2017 at 01:45:06PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the samba package:
> 
> #464035: samba "getpeername failed." error message
> 
> It has been closed by Mathieu Parent <math.par...@gmail.com>.
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Mathieu Parent 
> <math.par...@gmail.com> by
> replying to this email.
> 
> 
> -- 
> 464035: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464035
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Tue, 27 Jun 2017 15:44:06 +0200
> From: Mathieu Parent <math.par...@gmail.com>
> To: "L.P.H. van Belle" <be...@bazuin.nl>, 464035-d...@bugs.debian.org
> Subject: Re: Bug#464035: 464035 [Pkg-samba-maint] Bug#464035: samba: Cannot
>  connect user
> 
> Hi,
> 
> I'm closing this bug then.
> 
> 2017-06-27 15:12 GMT+02:00 L.P.H. van Belle <be...@bazuin.nl>:
> > Hai,
> >
> > I agree with Steve, this is not a bug but fix below ( for windows )
> > even that the pdbedit -L fixed this for Peter, im adding this for historical
> > lookups.
> >
> > You see this mainly with windows XP.
> >
> > When attempting to join a domain, you receive the following error message:
> > "Computer Name Changes: The following error occurred attempting to join the
> > domain MYDOMAIN: The specified network password is not correct".
> >
> > Additionally, your Samba logfile (at debug level 1) reveals:
> > "smbd/service.c:make_connection(): Can't become connected user!".
> >
> > This is usually caused by improper registry settings in the client.
> >
> > Use Window's Group Policy Editor (gpedit.msc) to make the following changes
> > in the :
> >  "Local Computer Policy\Computer Configuration\Windows Settings\Security
> > Settings\Local Policies\Security Options"
> >
> > Disable: Domain member: Digitally encrypt or sign secure channel data
> > Disable: Domain member: Digitally sign secure channel data (when possible)
> > Please, close bug.
> >
> >
> > Greetz,
> >
> > Louis
> 
> 
> 
> -- 
> Mathieu

> Date: Mon, 4 Feb 2008 21:33:09 +0100
> From: Josip Rodin <j...@debbugs.entuzijast.net>
> To: sub...@bugs.debian.org
> Subject: samba "getpeername failed." error message
> 
> Package: samba
> Version: 3.0.24-6etch9
> 
> Hi,
> 
> source/lib/util_sock.c's get_peer_addr() function does:
> 
>   if (getpeername(fd, , ) < 0) {
>   DEBUG(0,("getpeername failed. Error was %s\n", strerror(errno) 
> ));
>   return addr_buf;
>   }
> 
> This is littering my log.smbd file, like this:
> 
>   getpeername failed. Error was Transport endpoint is not connected
> 
> This apparent ENOTCONN is happening a couple of times every hour on one set
> of my machines.
> 
> At first I thought it was harmless, just logged at the level 0 (always),
> but looking more into the source, this should be getting generated after
> the following sequence of call in source/smbd/server.c:
> 
> if (allowable_number_of_smbd_processes() && 
> smbd_server_fd() != -1 && sys_fork()==0) {
> /* Child code ... */
> 
> /* close the listening socket(s) */
> for(i = 0; i < num_sockets; i++)
> 

Bug#422347: closed by Bernhard Schmidt <be...@debian.org> (Re: can't get ntpq without ntpd)

[Josip Rodin]

reopen 422347
thanks

I've read the discussion that happened after the message to -done and I'm at
a loss for words - this kind of a decision would go against the BCP of some
twenty years of Debian packaging.

Yes, it's common to set up a network service in a way that only localhost
will access it. No, that doesn't conflict with the idea that server software
goes into server software packages and client software goes into client
software packages.

Honestly it's really hard to comment further in a way that wouldn't be
considered toxic... does nobody remember the old netbase package?
Why do we have to do argue this all over again in 2017?

-- 
 2. That which causes joy or happiness.

Bug#824010: ssh-keyscan: hash does not include the port - duplicate?

[Josip Rodin]

Hi,

Isn't https://bugs.debian.org/857736 the same as https://bugs.debian.org/824010 
?

-- 
 2. That which causes joy or happiness.

Bug#744751: ditto

[Josip Rodin]

Hi,

I just wanted to chime in to say this behavior where

perl -p '...' arg1 arg2 arg3 ...

...fails to reflect the basic failure to process arg* in the return code -
is essentially a bug. Just because the manual page explains how it is wrong
that doesn't make it less wrong. By that logic, any other arbitrary issue
with command line parameter parsing would be dismissable with documentation.

-- 
 2. That which causes joy or happiness.

Bug#777403: leave: please make the build reproducible

[Josip Rodin]

On Sun, Feb 05, 2017 at 10:00:35AM +1300, Chris Lamb wrote:
> > Would you consider applying this patch and uploading?
> 
> Friendly ping on this :)

Sure. But, on this note, was this issue by any chance resolved by that
recent patch to dpkg-dev, where it resets timestamps itself?

-- 
 2. That which causes joy or happiness.

Bug#495526: closed by Michael Gilbert <mgilb...@debian.org> (re: automatic fetching of domain-name-servers from resolv.conf)

[Josip Rodin]

reopen 495526
thanks

On Sat, Jan 14, 2017 at 10:51:04PM +, Debian Bug Tracking System wrote:
> From: Michael Gilbert 
> To: 495526-cl...@bugs.debian.org
> Subject: re: automatic fetching of domain-name-servers from resolv.conf
> 
> DDNS can be used to achieve your goal.

Sorry, I don't understand, what does that mean? How does Dynamic DNS factor
into this at all? Or is DDNS some new acronym for something else?

The issue was that one had to hardcode specific IP addresses of
recursive DNS servers given out to DHCP clients in the DHCP server's
domain-name-servers setting. What I was suggesting is to have a way of
telling the DHCP server to not require that, but that it relays whatever
the system resolver is currently set with.

-- 
 2. That which causes joy or happiness.

Bug#777726: joe: please make the build reproducible

[Josip Rodin]

On Mon, Jan 16, 2017 at 06:11:03AM +, Chris Lamb wrote:
> > Would you consider applying this patch and uploading?
> 
> Friendly ping on this :)

Oh I'm so sorry for apparently ignoring you with this, I just didn't get
around to it in the last upload, but I have every intention to add it in
the next one. The patch seems straightforward enough, if you wanted to
upload it yourself, there'd be absolutely no objection from me.

-- 
 2. That which causes joy or happiness.

Bug#844289: joe FTCBFS: uses build architecture toolchain

[Josip Rodin]

On Mon, Nov 14, 2016 at 06:53:01AM +0100, Helmut Grohne wrote:
> Source: joe
> Version: 4.3-1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> joe fails to cross build from source, because it configures the build
> for the build architecture (by failure of passing --host) and uses the
> build architecture strip. The attached patch addresses both issues and
> makes joe cross build. Alternatively, moving to dh_auto_configure and
> dh_strip also fixes the cross build as both tools are well aware of
> cross building. Please consider applying the attached patch or moving to
> debhelper.

Surely this is a wishlist report? Why are you cross-building the package?

-- 
 2. That which causes joy or happiness.

Bug#822074: patch

[Josip Rodin]

forwarded 822074 https://sourceforge.net/p/joe-editor/bugs/359/
thanks

Adam, thanks for the bug report as well as the patch.

I encourage you to use the upstream bug tracking system for these generic
issues in the future, so other people see it faster.

On Sun, Apr 24, 2016 at 10:41:38PM +0200, Adam Borowski wrote:
> Control: tags -1 +patch
> 
> Hi!
> Here's a minimal patch that fixes iswprint(PUA):
> 
> --- joe-4.1.orig/joe/unicode.c
> +++ joe-4.1/joe/unicode.c
> @@ -321,6 +321,7 @@ void joe_iswinit()
> cclass_union(cclass_print, unicode("N"));
> cclass_union(cclass_print, unicode("P"));
> cclass_union(cclass_print, unicode("Zs"));
> +   cclass_union(cclass_print, unicode("Co"));
> cclass_opt(cclass_print);
>  
> /* Graphical characters (no spaces) */
> 
> > Classification returned by glibc:
> > width 1 punct graph print
> 
> I wonder about iswpunct() -- glibc somehow returns true for PUA characters,
> so it might be a good idea to be consistent with it (even if I don't see why
> it's set).  As for iswgraph(), joe defines this function but never uses it.
> Joe's wcwidth() assumes 1 for all not explicitely listed characters, so
> that's same as glibc.
> 
> -- 
> A tit a day keeps the vet away.

-- 
 2. That which causes joy or happiness.

Bug#818537: RC bug on maildrop [was Re: freeradius]

[Josip Rodin]

On Sat, Oct 22, 2016 at 03:41:46PM +0200, Tobias Frost wrote:
> However may I ask you to take a look at the RC bugs in your DDPO? [2]
> ;-)

Intriguing, I completely missed that maildrop bug, I think my spam filters
somehow ate it. I'll try to figure out both issues, thanks for the hint.

-- 
 2. That which causes joy or happiness.

Bug#838404: freeradius

[Josip Rodin]

On Tue, Sep 20, 2016 at 11:13:17PM +0200, Tobias Frost wrote:
> On Mon, Sep 19, 2016 at 09:14:50PM +0200, Josip Rodin wrote:
> > On Sat, Sep 17, 2016 at 02:34:12PM +0200, Tobias Frost wrote:
> > > there was some disussion in respect to freeradius lately on debian-
> > > devel. I'm wondering if you are still maintaining this package and if
> > > you know about the co-maintainers whereabout?
> > 
> > See the discussion in bug #806617
> 
> Thanks for the answer.
> So, I guess the anwer is "no longer"... Would you mind to file a
> a bug then to document that, something like I filed on behalf of sgran? 
> (#838404)
> (Of course I can do that too for you, if you want)

Not sure what this would have to do with MIA since I'm not MIA :)
but sure.

-- 
 2. That which causes joy or happiness.

Bug#806617: freeradius: FTBFS when built with dpkg-buildpackage -A (dh_install: freeradius-common missing files)

[Josip Rodin]

On Tue, Aug 30, 2016 at 11:20:50AM +0200, Raphael Hertzog wrote:
> Josip, do you really still care about this package?

I'm pretty sure I told Sam to take it over a few years back...?

If you want to fix that, by all means, just work on it.

-- 
 2. That which causes joy or happiness.

Bug#833928: xtail crash on a large directory

[Josip Rodin]

Package: xtail
Version: 2.1-5
Severity: important

Hi,

I seem to have hit a wall here:

% xtail /opt/build-web/build-web/storage/logs/josip/
zsh: segmentation fault (core dumped)  xtail 
/opt/build-web/build-web/storage/logs/josip/

Kernel logs at the time things like:

[99470.526562] traps: xtail[15506] general protection ip:4021ed sp:7fff9162b1f0 
error:0 in xtail[40+4000]

A DEB_BUILD_OPTIONS=debug build says:

% echo bt | gdb /tmp/xtail-2.1/xtail core
Reading symbols from /tmp/xtail-2.1/xtail...done.
[New LWP 15506]
Core was generated by `/tmp/xtail-2.1/xtail 
/opt/build-web/build-web/storage/logs/josip/'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x004021ed in scan_directory (dirname=) at 
miscfuncs.c:90
90  for (i = List_file->num_entries, elist=List_file->list ; i > 0 
; --i, ++elist) {
(gdb) bt
#0  0x004021ed in scan_directory (dirname=) at 
miscfuncs.c:90
#1  0x0040180c in main (argc=, argv=0x7fff9162b4f8) at 
xtail.c:72

It actually doesn't crash with an expanded wildcard on the same directory,

% xtail /opt/build-web/build-web/storage/logs/josip/*

In there, Ctrl+C says:

currently watching:  408 files  0 dirs  0 unknown entries

But I wanted it specifically for the advertized functionality of not having
to have a fixed list of files to monitor, so this bug makes the program
useless to me.

The machine it's running on is an Ubuntu 14.04 LTS VM (512 MB RAM) ane
the directory is on an ext4 filesystem.

Let me know if there's anything else I can do to help.

Please fix this. TIA.

-- 
 2. That which causes joy or happiness.

Bug#470671: not actually forwarded

[Josip Rodin]

notforwarded 470671
thanks

The link 
http://studio.imagemagick.org/pipermail/magick-developers/2009-October/003188.html
is dead now.

I'm guessing that's:
https://www.mail-archive.com/magick-developers@imagemagick.org/msg00745.html

But that's not necessarily the same thing. So I'm removing the forwarded tag.

-- 
 2. That which causes joy or happiness.

Bug#470671: ditto

[Josip Rodin]

Hi,

This idea is still legitimate on headless servers. There's many machines
that will run convert(1), but will never run display(1), and pulling in
hicolor-icon-theme and whatever else that entails is just wasteful and may
well lead to harder upgrades in the future.

Please implement separate packages. TIA.

-- 
 2. That which causes joy or happiness.

Bug#827480: make a leaner package for ssconvert and other command-line utilities

[Josip Rodin]

Package: gnumeric
Severity: wishlist

Hi,

Would it be possible to get the command-line utilities without all the
various GUI dependencies?

TIA.

-- 
 2. That which causes joy or happiness.

Bug#824010: ssh-keyscan doesn't record port specified with -p in its output

[Josip Rodin]

Package: openssh-client
Version: 1:6.0p1-4+deb7u4

Hi,

When you connect to an SSH server at an alternate port using ssh-keyscan,
its known_hosts output doesn't contain the port number.

However, the ssh client does expect the port in the known_hosts entries,
it skips them otherwise.

Please fix ssh-keyscan. TIA.

-- 
 2. That which causes joy or happiness.

Bug#819198: Missing libapache2-mod-auth-radius on Debian 8.3 mirrors.

[Josip Rodin]

reassign 819198 www.debian.org
thanks

On Thu, Mar 24, 2016 at 03:49:28PM -0300, Js wrote:
> Package: libapache2-mod-auth-radius
> Version: 1.5
> Severity: serious
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> 
> The package libapache2-mod-auth-radius is not on Debian mirrors. I did not
> find why this package was excluded from mirrors.

It is on the mirrors, you can check the
pool/main/liba/libapache-mod-auth-radius/ directory I guess?

The package just got back into testing a couple of months ago, putting it on
track to be released with Debian 9.x, and now this bug report removed it
again :)

I do find it strange that the website search brings up nothing:
https://packages.debian.org/search?keywords=libapache2-mod-auth-radius

It's supposed to show the one in unstable at least...

https://packages.qa.debian.org/liba/libapache-mod-auth-radius.html

https://buildd.debian.org/status/package.php?p=libapache-mod-auth-radius=unstable

-- 
 2. That which causes joy or happiness.

Bug#820992: joe: "Ins" stopped working again

[Josip Rodin]

On Thu, Apr 14, 2016 at 01:58:25PM +0200, Adam Borowski wrote:
> Package: joe
> Version: 4.1-2
> Severity: normal
> 
> Hi!
> It looks like #508797 ("Ins" not working) is back -- you apparently lost the
> patch somewhere.
> 
> Changing "overtype" to "overwrite" in one's config file solves this, as
> before.

Which config file exactly? Because the patch is still shipped, I actually
formatted it nicely the last time around:

% cat joe-4.1/debian/patches/001_jstarrc_overtype.patch
Description: fix jstarrc overtype error to make the Ins key work in jstar
 Fix the Ins key for jstar users by replacing the obsolete marker
 "overtype" with "overwrite" in rc/jstarrc.in
Author: Adam Borowski
Bug-Debian: http://bugs.debian.org/508797
Last-Update: 2010-11-13

Index: joe-4.1/rc/jstarrc.in
===
--- joe-4.1.orig/rc/jstarrc.in  2015-09-04 22:15:55.0 +0200
+++ joe-4.1/rc/jstarrc.in   2016-01-31 18:01:34.0 +0100
@@ -977,8 +977,8 @@
 insf   ^K r
 macros ^[ dDump macros
 macros ^[ ^D
-mode,"overtype",rtn^V  Insert/Overtype
-mode,"overtype",rtn.kI
+mode,"overwrite",rtn   ^V  Insert/Overtype
+mode,"overwrite",rtn   .kI
 lindent^K ,Indent to left
 line   ^Q IGoto line no.
 line   ^Q ^I

-- 
 2. That which causes joy or happiness.

Bug#718816: +1

[Josip Rodin]

On Tue, Feb 23, 2016 at 08:42:17PM +0100, Nicolas Schier wrote:
> I have already made some patches at home that do prepare separation of 
> parallel from moreutils (as described previously); but these changes do 
> only make sense iff the GNU parallel package is also going to be 
> adjusted (since GNU parallel 'conflicts' with moreutils).  I haven't 
> heard anything yet that the proposed solution has a chance to be 
> implemented in the GNU parallel package...

Once you split out moreutils parallel to its own package, then there can
hardly be any dispute about removing that Conflicts line, it becomes more of
a technicality.

-- 
 2. That which causes joy or happiness.

Bug#718816: +1

[Josip Rodin]

Hi,

Please proceed with the split in whichever form, it really doesn't make
sense to have parallel + 5 other programs in one package and then
slightly different parallel + 7 other programs in another package.

TIA.

-- 
 2. That which causes joy or happiness.

Bug#786997: clarification

[Josip Rodin]

Hi,

In my original message I mentioned several other timeouts, which may have
misled other readers into thinking that it's safe to actually change them
all - it isn't.

I've had best results when I only changed the ProcessManager.pm's
worker_timeout to 10+ seconds less than global timeout. That had the effect
such as this in the logs:

2016/02/06 10:53:42 [FATAL] Socket read timed out to server.  Terminating 
process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 254.
2016/02/06 10:53:42 [ERROR] Munin::Master::UpdateWorker died with 
'[FATAL] Socket read timed out to server.  Terminating process. at 
/usr/share/perl5/Munin/Master/UpdateWorker.pm line 254.
'
2016/02/06 10:53:50 [INFO] Remaining workers: badnode
2016/02/06 10:53:50 [INFO] Reaping Munin::Master::UpdateWorker.  Exit 
value/signal: 18/0
2016/02/06 10:53:51 [INFO]: Munin-update finished (49.94 sec)

When I messed with other variables, it had nasty side-effects such as
thousands of repeated lines in the logs in case of downtimes, effectively
causing log disk DoS. So just don't do that.(TM)

-- 
 2. That which causes joy or happiness.

Bug#813349: joe: jstar crashes on startup if old config is present

[Josip Rodin]

forwarded 813349 https://sourceforge.net/p/joe-editor/bugs/341/
thanks

On Mon, Feb 01, 2016 at 12:47:38AM +0100, Adam Borowski wrote:
> Package: joe
> Version: 4.1-2
> Severity: important
> 
> If a ~/.jstarrc from a previous version exists, jstar will segfault on 
> startup.
> This happens even for unmodified configs (ie, a straight copy of
> /etc/joe/jstarrc into ~/.jstarrc).
> 
> Prior versions complained in the presence of an outdated config, but you
> just removed that check (#560182).  But in any case, response to even
> complete garbage should be an error message rather than a segfault.

Thanks for reporting this Adam, I filed it upstream.

-- 
 2. That which causes joy or happiness.

Bug#813350: joe: :include ignores other commands in the file

[Josip Rodin]

On Mon, Feb 01, 2016 at 01:53:24AM +0100, Adam Borowski wrote:
> /usr/share/doc/joe/README.Debian claims you can ":include /etc/joe/jstarrc"
> to avoid having to copy the entire file and to make it work over upgrades.
> However, doing so seems to ignore the entirety of ~/.jstarrc
> 
> Let's say we want to replace
> -rmsg  %S Row %4r Col %3c %t  Ctrl-J for help
> with
> -rmsg  %S Row %4r Col %3c %A
> 
> The following ~/.jstarrc
> =
> :include /etc/joe/jstarrc
> -rmsg  %S Row %4r Col %3c %A
> =
> makes "Ctrl-J for help" show up instead of the Unicode code.
> 
> so does
> =
> -rmsg  %S Row %4r Col %3c %A
> :include /etc/joe/jstarrc
> =
> so it's not a matter of "first setting stays".

Could this be some sort of a special screwup with regard to jstar, like the
previous bug? Because, I still have the latter config with .joerc and it's
working.

-- 
 2. That which causes joy or happiness.

Bug#660787: joe: hardlocks running in mrxvt; had to kill -9 it and then ctrl-c the console tab

[Josip Rodin]

tag 660787 unreproducible
thanks

On Wed, Feb 22, 2012 at 09:28:28AM +0100, Josip Rodin wrote:
> On Tue, Feb 21, 2012 at 04:00:00PM -0500, cvev...@users.sourceforge.net wrote:
> > Package: joe
> > Version: 3.7-2
> > Severity: important
> > 
> > started in mrxvt tab. 
> > after showing  the help, typed a line then attempted to exit.
> > locked solid, kill would not kill w/o -9
> 
> Can you attach a strace -p to the joe PID at some point in the process?
> Is there anything peculiar in your mrxvt configuration? What is $TERM?

Lacking any debug info whatsoever, I'm afraid I'm going to have to mark this
unreproducible. Can you try with the latest joe 4.1?

-- 
 2. That which causes joy or happiness.

Bug#748944: [Pkg-xfce-devel] Processed: Re: Processed (with 1 errors): on how lightdm does not like it when /etc/X11/Xsession is not executable

[Josip Rodin]

reopen 748944
thanks

On Fri, Jul 24, 2015 at 10:55:12PM +0200, Julien Cristau wrote:
 On Thu, Jul 23, 2015 at 10:06:42 +0200, Josip Rodin wrote:
 
  reassign 748944 x11-common
  retitle 748944 lightdm relies on the executability of /etc/X11/Xsession, 
  please enforce it
  thanks
  
 x11-common installs /etc/X11/Xsession executable.  Anything beyond that
 is not its responsibility.

I'm sure all of our users who hit this bug will be thrilled to see this
kind of behavior.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748944: [Pkg-xfce-devel] Processed: Re: Processed (with 1 errors): on how lightdm does not like it when /etc/X11/Xsession is not executable

[Josip Rodin]

reassign 748944 x11-common
retitle 748944 lightdm relies on the executability of /etc/X11/Xsession, please 
enforce it
thanks

On Wed, Jul 22, 2015 at 08:52:14PM +0200, Yves-Alexis Perez wrote:
 On mer., 2015-07-22 at 20:43 +0200, Josip Rodin wrote:
  On Tue, Jul 21, 2015 at 09:48:35PM +0200, Yves-Alexis Perez wrote:
   On mar., 2015-07-21 at 15:20 +0200, Josip Rodin wrote:
No, startx has also worked on my machine without the executable bit on 
that
file. It's lightdm that seems to be depending on something others don't.
   
   I had the impression that startx (without argument) would use Xsession.
   At least the Xsession file header gives that impression.
  
  On related note, this system executes the ~/.xsession file as a shell
  script, but it isn't executable :)
 
 No, see 50x11-common_determine-startup, if it's not executable it'll
 treat it as a shell script and run it through $SHELL (or sh).

That's what I meant, it's effectively the same.

If this is an actual requirement of some standard, please reassign the 
bug
to the owner of the file (x11-common) and have them enforce the 
standard.
   
   It's already done. x11-common ships Xsession with executable bit.
  
  Well, then it shouldn't ship it as a conffile, because that implies they
  can't maintain the enforcement, as the user is allowed to do all sorts of
  things to conffiles (and usually expected to).
 
 Sure, if you remove the executable bit, it won't execute. Isn't what
 you wanted, then?

I have no recollection of actually removing that executable bit for any
actual purpose, and I don't generally go around chmod -x'ing arbitrary files
on my system. I'm thinking it happened through some change of functionality
on an upgrade.

 Anyway, end of discussion for me. It might be entertaining for you, but
 it's time consuming for me.

I assure you that bugs like this aren't entertaining to users - being unable
to access your working environment is usually quite stressful. That I've
made a lighthearted comment should indicate to you that I'm on your side,
probably unlike N unknown lurkers who may have seen the same bug, got pissed
off at what they saw as a useless piece of software, but then never bothered
to tell us.

I've moved it to x11-common.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748944: [Pkg-xfce-devel] Processed: Re: Processed (with 1 errors): on how lightdm does not like it when /etc/X11/Xsession is not executable

[Josip Rodin]

On Tue, Jul 21, 2015 at 09:48:35PM +0200, Yves-Alexis Perez wrote:
 On mar., 2015-07-21 at 15:20 +0200, Josip Rodin wrote:
  No, startx has also worked on my machine without the executable bit on that
  file. It's lightdm that seems to be depending on something others don't.
 
 I had the impression that startx (without argument) would use Xsession.
 At least the Xsession file header gives that impression.

On related note, this system executes the ~/.xsession file as a shell
script, but it isn't executable :)

  If this is an actual requirement of some standard, please reassign the bug
  to the owner of the file (x11-common) and have them enforce the standard.
 
 It's already done. x11-common ships Xsession with executable bit.

Well, then it shouldn't ship it as a conffile, because that implies they
can't maintain the enforcement, as the user is allowed to do all sorts of
things to conffiles (and usually expected to).

(Executable configuration file - doesn't that just sound wrong?)

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748944: [Pkg-xfce-devel] Processed: Re: Processed (with 1 errors): on how lightdm does not like it when /etc/X11/Xsession is not executable

[Josip Rodin]

On Mon, Jul 20, 2015 at 04:57:53PM +0200, Yves-Alexis Perez wrote:
 On lun., 2015-07-20 at 12:51 +, Debian Bug Tracking System wrote:
  Processing commands for cont...@bugs.debian.org:
  
   unarchive 748944
  Bug #748944 {Done: James Lynn ja...@biometry.me.uk} [lightdm] 
  lightdm: Attempt to login fails to get past greeter
  Unarchived Bug 748944
   submitter 748944 !
  Bug #748944 {Done: James Lynn ja...@biometry.me.uk} [lightdm] 
  lightdm: Attempt to login fails to get past greeter
  Changed Bug submitter to 'Josip Rodin j...@debbugs.entuzijast.net' 
  from 'James Lynn ja...@biometry.me.uk'
   thanks
  Stopping processing here.
 
 Please don't hijack bugs. Also, that won't change anything. Sure we
 rely on the fact that /etc/X11/Xsession is executable, like startx and
 any display manager which does not specifically chose something else.
 We have to rely on a minimal system, we can't really check (or worse,
 fix) each and every bit of the system.

No, startx has also worked on my machine without the executable bit on that
file. It's lightdm that seems to be depending on something others don't.

If this is an actual requirement of some standard, please reassign the bug
to the owner of the file (x11-common) and have them enforce the standard.

If it isn't a standard, please handle the legitimate discrepancy.

Neither of these options really seems onerous.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735251: my two cents

[Josip Rodin]

On Sun, Jul 19, 2015 at 02:09:29PM +0200, Josip Rodin wrote:
 Hi,
 
 I think I hit this bug too: I don't have anything (uncommented) in
 /etc/default/locale, but after installing lightdm I ended up with a ~/.dmrc
 that says:
 
 [Desktop]
 Language=de_DE.utf8
 Session=lightdm-xsession
 
 Oddly enough, I didn't actually notice this because lightdm was in English.
 
 Once I logged in, I clicked on XFCE's menus and found them to be in German,
 which I never actually wanted.
 
 The cause seems to be:
 
 % grep '^[^#]' /etc/locale.gen
 de_DE ISO-8859-1  
 de_DE.UTF-8 UTF-8
 de_DE@euro ISO-8859-15
 en_US ISO-8859-1
 en_US.UTF-8 UTF-8
 fr_FR ISO-8859-1
 fr_FR.UTF-8 UTF-8
 hr_HR ISO-8859-2
 hr_HR.UTF-8 UTF-8
 nb_NO ISO-8859-1
 nb_NO.UTF-8 UTF-8
 
 I don't think the order of this file - which seems to be alphabetically
 sorted by default - should override the standard implicit default of POSIX,
 that is, English.
 
 In fact if the program itself is running with POSIX, and there's no other
 indicator, it should make the user default POSIX as well.
 
 This kind of guesswork doesn't seem to be a safe choice at all.

Oh, but it gets worse. I edited the file to replace de_DE with en_US, and
retried login, but it was still in German. So I edited the file to put in
hr_HR.UTF-8, and did a sudo service lighdm restart for good measure, and now
after login XFCE menus are in Croatian. Well, at least some progress.

Yet I then opened the file again and now I see:

% cat .dmrc
[Desktop]
Language=de_DE.utf8
Session=lightdm-xsession

So, um, what the hell? What program is rewriting the config file in my
user home directory?

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735251: my two cents

[Josip Rodin]

Hi,

I think I hit this bug too: I don't have anything (uncommented) in
/etc/default/locale, but after installing lightdm I ended up with a ~/.dmrc
that says:

[Desktop]
Language=de_DE.utf8
Session=lightdm-xsession

Oddly enough, I didn't actually notice this because lightdm was in English.

Once I logged in, I clicked on XFCE's menus and found them to be in German,
which I never actually wanted.

The cause seems to be:

% grep '^[^#]' /etc/locale.gen
de_DE ISO-8859-1  
de_DE.UTF-8 UTF-8
de_DE@euro ISO-8859-15
en_US ISO-8859-1
en_US.UTF-8 UTF-8
fr_FR ISO-8859-1
fr_FR.UTF-8 UTF-8
hr_HR ISO-8859-2
hr_HR.UTF-8 UTF-8
nb_NO ISO-8859-1
nb_NO.UTF-8 UTF-8

I don't think the order of this file - which seems to be alphabetically
sorted by default - should override the standard implicit default of POSIX,
that is, English.

In fact if the program itself is running with POSIX, and there's no other
indicator, it should make the user default POSIX as well.

This kind of guesswork doesn't seem to be a safe choice at all.

Thanks,

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756867: transition: gdal

[Josip Rodin]

On Fri, Jun 12, 2015 at 12:17:27PM +0200, Sebastiaan Couwenberg wrote:
 The gdal 1.11.2 package is Ubuntu from some time already, and they
 didn't have these concerns. But that may be inherent to Ubuntu not being
 as strict as Debian about these kind of issues.

 I'd hate having to wait for GDAL 2.0 and the SONAME bump that should
 introduce before getting a newer gdal in unstable.

On Fri, Jun 12, 2015 at 05:12:12PM +0200, Vincent Danjean wrote:
 If the dependency system allows to have gdal 1.11 and old rdeps, then
 they must work.
 If old rdeps and gdal 1.11 does not work together, the dependency system
 must reflect that (for example by adding versionned Breaks in new gdal
 against old rdeps).

It just so happens I was on the receiving end of GDAL's ABI breakages with
an in-house dependent package, I feel I have to post this link here:

http://upstream.rosalinux.ru/versions/gdal.html

This library has apparently been consistently horrible about compatibility,
and it seems that it's high time that its SONAME, and consequently its
package names, started changing in order to avoid harming its users.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786997: munin-update doesn't work reliably with 4 min update intervals because of hardcoded timeouts

[Josip Rodin]

Package: munin
Version: 2.0.25-1

Hi,

This feels like #464880 all over again :) You can easily change the cron
jobs and it generally works. However, as soon as any one of your nodes
croaks, everything basically grinds to a halt way too easily.

...
2015/05/27 14:47:53 [INFO] Remaining workers: backends;foo5n
2015/05/27 14:47:53 [INFO] Reaping Munin::Master::UpdateWorkerbackends;foo5p. 
 Exit value/signal: 0/0
2015/05/27 14:48:01 [FATAL ERROR] Lock already exists: 
/var/run/munin/munin-update.lock. Dying.
2015/05/27 14:48:01  at /usr/share/perl5/Munin/Master/Update.pm line 128.
2015/05/27 14:48:03 [INFO] Remaining workers: backends;foo5n
2015/05/27 14:48:13 [INFO] Remaining workers: backends;foo5n
2015/05/27 14:48:23 [INFO] Remaining workers: backends;foo5n
2015/05/27 14:48:33 [INFO] Remaining workers: backends;foo5n
2015/05/27 14:48:43 [INFO] Remaining workers: backends;foo5n
2015/05/27 14:48:53 [INFO] Remaining workers: backends;foo5n
2015/05/27 14:49:02 [FATAL ERROR] Lock already exists: 
/var/run/munin/munin-update.lock. Dying.
2015/05/27 14:49:02  at /usr/share/perl5/Munin/Master/Update.pm line 128.
2015/05/27 14:49:03 [INFO] Remaining workers: backends;foo5n
2015/05/27 14:49:10 [FATAL] Socket read from foo5n failed.  Terminating 
process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 254.
2015/05/27 14:49:10 [ERROR] Munin::Master::UpdateWorkerbackends;foo5n died 
with '[FATAL] Socket read from foo5n failed.  Terminating process. at 
/usr/share/perl5/Munin/Master/UpdateWorker.pm line 254.
'
2015/05/27 14:49:13 [INFO] Remaining workers: backends;foo5n
2015/05/27 14:49:13 [INFO] Reaping Munin::Master::UpdateWorkerbackends;foo5n. 
 Exit value/signal: 18/0
2015/05/27 14:49:14 [INFO]: Munin-update finished (132.65 sec)
...

The problem is that there are several hardcoded timeout variables,
*independent* of the value you can pass via munin-update --timeout=N

/usr/share/perl5/Munin/Master/Node.pm:io_timeout = 120,
/usr/share/perl5/Munin/Master/ProcessManager.pm:worker_timeout  = 180,
/usr/share/perl5/Munin/Master/ProcessManager.pm:timeout = 240,

So you *think* you set a timeout smaller than a minute, but actually the
socket read function waits for much longer than that.

Please make these configurable just like the other timeout is. TIA.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org