Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Michael Stapelberg]

On Mon, 4 Sept 2023 at 19:54, Simon McVittie  wrote:

> On Mon, 04 Sep 2023 at 18:56:52 +0200, Michael Stapelberg wrote:
> > > i3 isn’t a desktop environment, it’s a window manager only.
> >
> > It's behaving like a (very small) desktop environment to the extent
> that
> > it installs a file in /usr/share/xsessions, which results in it
> appearing
> > in the menu of possible session types in display managers like gdm,
> > lightdm or sddm.
> >
> > Are you saying only desktop environments may install to the xsessions
> > directory?
> >
> > If so, what is the mechanism for window managers to show up in the
> display
> > manager menu?
>
> It depends where you draw the line between window manager and desktop
> environment. Where I would personally draw that line is:
>
> If it makes sense to log in to a thing as a desktop session in its own
> right, which has some way to run programs in order to be independently
> useful, and preferably some way to exit, then it makes sense to register
> it in xsessions, and it's effectively behaving like a tiny desktop
> environment. For instance, openbox and icewm are definitely this: each
> has a menu that can launch apps and exit. You could call this a desktop
> environment, or if you think that term has other connotations which
> don't apply here, you could call it something else, but it's certainly
> something that is useful to list as an option in e.g. lightdm.
>
> If it doesn't make sense to log in to a thing because it isn't useful on
> its own, then I don't think it should be registered in xsessions or show
> up in the display manager menu. For instance, the /usr/bin/mutter in the
> mutter package is a window manager, but it intentionally isn't registered
> as an xsession, because it isn't useful on its own: it will manage the
> windows of any programs you run some other way, but it doesn't have any
> built-in way to start any programs, so you need to add at least a way to
> run programs (some sort of menu or panel or hotkey mechanism, which it
> doesn't have built-in) to make a directly useful user-facing environment.
>
> I don't know which of those i3 wants to be.
>

i3 definitely aims to be useful on its own, but it also specifically does
not supply enough parts to constitute a full desktop environment.

For features that are unequivocally needed, even among niche window
managers,
i3 will have a component or recommendation (i3bar, i3status, i3lock, dmenu),
but you’re free to swap these out, or decide not to use them.


>
> > When we stop patching xdg-desktop-portal to hard-code its GTK backend
> > as a fallback, the default will be to use no portal backends at all,
> > which means the apps I described above will try and fail to make use
> of
> > those desktop features, unless the user has written a portals.conf(5)
> > of their own (which they can always do anyway, and it will overrule
> the
> > desktop environment's choices).
> >
> > Uhm, why would we actively remove the fallback?
> > I don’t understand the logic behind that.
> > It seems like a decision that will leave users worse off, for no benefit?
>
> The -gtk backend was never really intended to be a fallback: it was
> originally GNOME-specific, and only got used in other environments
> as a last resort because of implementation details of how the portal
> backend is selected. The upstream design of x-d-p was always intended
> to be that each GUI environment would provide its own choice of backend
> (either its own, or shared with other GUI environments) that implements
> the various interfaces in a desktop-appropriate way.
>
> I suggested in an upstream issue[1] that maybe x-d-p-gtk should be
> hard-coded as the portal backend of last resort (as I've done downstream
> in Debian for now), but upstream developers didn't think that was
> appropriate, and the user who originally opened the issue thought that
> an unconfigured x-d-p specifically *shouldn't* start any backends,
> so your opinion on this is noted but is not universally shared.
>
> [1] https://github.com/flatpak/xdg-desktop-portal/issues/1077


Ah, thanks for raising the backward compatibility point upstream.


> We have had some quite bad bugs in the past caused by portal backends
> being run outside their intended environment, failing to find the
> desktop-specific services that they need (for example for screen sharing
> and screencasting under Wayland, which are very implementation-specific),
> and causing crashes or arbitrary delays, so it's important to avoid
> x-d-p's old behaviour where it would arbitrarily pick *any* backend
> if there is none that declares that it supports the current desktop
&g

Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Michael Stapelberg]

Thanks for your explanations. Answers inline:

On Sun, 3 Sept 2023 at 22:55, Simon McVittie  wrote:

> On Sun, 03 Sep 2023 at 20:25:52 +0200, Michael Stapelberg wrote:
> > If I'm reading its code correctly, I think i3-wm asks the display
> manager
> > to set XDG_CURRENT_DESKTOP to "i3"?
> >
> > I don’t know what code you’re referring to.
> > I don’t recall i3 asking any display manager anything, but maybe I’m
> missing
> > something?
>
> i3-wm_4.22-2/share/xsessions/i3.desktop contains DesktopNames=i3, which is
> how you ask a display manager to set XDG_CURRENT_DESKTOP=i3 when running
> the command defined in i3.desktop as an X11 session.
>

Ah, understood. Apparently, this line was needed for gdm, at least per the
2016 changelog entry.


>
> > i3 isn’t a desktop environment, it’s a window manager only.
>
> It's behaving like a (very small) desktop environment to the extent that
> it installs a file in /usr/share/xsessions, which results in it appearing
> in the menu of possible session types in display managers like gdm,
> lightdm or sddm.
>

Are you saying only desktop environments may install to the xsessions
directory?

If so, what is the mechanism for window managers to show up in the display
manager menu?


>
> > I’m also not familiar with what these xdg portals are, and I don’t think
> I’m
> > using them (yet)?
>
> I don't expect that i3 uses them, but some of the applications that users
> run within an i3 session are going to be using them.
>
> The most prominent use is that sandboxed Flatpak and Snap apps make D-Bus
> calls to xdg-desktop-portal to get things like File -> Open and File ->
> Save As dialogs, ask to open URLs or files outside the sandbox, pop up
> notifications, take screenshots and other outside-sandbox actions.
> xdg-desktop-portal implements all those things by passing on the request
> to a backend such as xdg-desktop-portal-gtk, which can be desktop-specific.
>
> Non-sandboxed apps are starting to use the same portal mechanism to do
> things that are otherwise hard to do in a desktop-independent way, like
> screenshots, screen-sharing and remote-desktop.
>
> > I don’t want to make the choice of whether gtk or qt should be used for
> parts
> > of a user’s desktop.
> ...
> > I think for the case of i3, the defaults should be fine, so I would
> prefer not
> > to add this config file.
>
> When we stop patching xdg-desktop-portal to hard-code its GTK backend
> as a fallback, the default will be to use no portal backends at all,
> which means the apps I described above will try and fail to make use of
> those desktop features, unless the user has written a portals.conf(5)
> of their own (which they can always do anyway, and it will overrule the
> desktop environment's choices).
>

Uhm, why would we actively remove the fallback?
I don’t understand the logic behind that.
It seems like a decision that will leave users worse off, for no benefit?


>
> I'm aware that i3 is quite an "assemble it yourself" environment, so
> perhaps users of i3 would expect to have to write their own configuration
> to make things like this work? If that's the case then this could be
> closed as "won't fix".


I would interpret the lack of a config file as “just make a reasonable
choice for me”,
so I would say users expect portals to work, in some unspecified way.

I would certainly be surprised if portals just didn’t work,
when they could just fall back to the gtk implementation.

-- 
Best regards,
Michael

Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Michael Stapelberg]

Hey Simon

Answers inline:

On Thu, 31 Aug 2023 at 13:27, Simon McVittie  wrote:

> Source: i3-wm
> Severity: normal
> Tags: trixie sid
> User: xdg-desktop-por...@packages.debian.org
> Usertags: portals.conf
>
> xdg-desktop-portal 1.17.x introduces a new way to select which portals will
> be used for which desktop environments, modelled on mimeapps.list:
>
> - each desktop environment should provide a file like
>   /usr/share/xdg-desktop-portal/i3-portals.conf
>
> - the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
>   environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
>   from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
>
> - sysadmins and users can override this via files named portals.conf or
>   ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
>   and ~/.config/xdg-desktop-portal
>
> Please see portals.conf(5) or its source code
>
> https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
> for full details.
>
> If I'm reading its code correctly, I think i3-wm asks the display manager
> to set XDG_CURRENT_DESKTOP to "i3"?
>

I don’t know what code you’re referring to.
I don’t recall i3 asking any display manager anything, but maybe I’m
missing something?


>
> As a backwards-compatibility mechanism, x-d-p will fall back to trying to
> guess the most appropriate portals from the portals' deprecated UseIn=
> fields, but it will log warnings when it does that, and anyway Debian
> doesn't currently ship any portal backends that are flagged as suitable
> for i3. Please add an i3-portals.conf to tell x-d-p more explicitly
> what backends i3-wm is meant to be using by default.
>
> For example, if the intention is to use the x-d-p-gtk backend,
> the way to write that would be:
>
> [preferred]
> default=gtk;
>
> The desktop environment (either i3-wm or some larger metapackage) should
> probably also have a Recommends, or at least a Suggests, on whatever
> portals would be most appropriate for it.


i3 isn’t a desktop environment, it’s a window manager only.

I don’t want to make the choice of whether gtk or qt should be used for
parts of a user’s desktop.
I’m also not familiar with what these xdg portals are, and I don’t think
I’m using them (yet)?

I think for the case of i3, the defaults should be fine, so I would prefer
not to add this config file.

If you think i3 should provide a portal file, it would probably be best to
discuss upstream:
https://github.com/i3/i3/issues

-- 
Best regards,
Michael

Bug#1029089: mandoc: -Thtml renders .Em as a hyperlink

[Michael Stapelberg]

Can you report this upstream at https://mandoc.bsd.lv/contact.html please?

On Tue, 17 Jan 2023 at 16:18, Colin Watson  wrote:

> Package: mandoc
> Version: 1.14.6-1+b1
> Severity: normal
>
> I was in the process of referring a user to
> https://manpages.debian.org/bullseye/germinate/germinate.1.en.html, and
> I happened to notice that some things are rendered oddly.  This input:
>
>   The contents of the Ubuntu distribution, and others, are managed by
> means of
>   .Em seeds .
>
> ... is rendered as follows by "mandoc -Thtml":
>
>   The contents of the Ubuntu distribution, and others, are
> managed
>   by means of
>id="seeds">seeds.
>
> Perhaps there's some reason for this, but it looks odd - the effect is a
> hyperlink to the same place in the document - and it seems to deviate
> from the documented semantics of .Em.  mdoc(7) says:
>
>  Em word ...
>   Request an italic font.  If the output device does not provide
> that,
>   underline.
>
>   This is most often used for stress emphasis (not to be confused
> with
>   importance, see Sy).  In the rare cases where none of the
> semantic
>   markup macros fit, it can also be used for technical terms and
>   placeholders, except that for syntax elements, Sy and Ar are
>   preferred, respectively.
>
>   Examples:
> Selected lines are those
> .Em not
> matching any of the specified patterns.
> Some of the functions use a
> .Em hold space
> to save the pattern space for subsequent retrieval.
>
>   See also No, Ql, and Sy.
>
> ... while groff_mdoc(7) says:
>
>Emphasis Macro
>  Text may be stressed or emphasized with the ‘.Em’ macro.  The usual
> font
>  for emphasis is italic.
>
>Usage: .Em ⟨argument⟩ ...
>
> .Em does not  does not
> .Em exceed 1024 . exceed 1024.
> .Em vide infra ) ) ,  vide infra)),
>
>  The default width is 10n.
>
> Maybe this is just an accidental consequence of something else and can
> be fixed; I don't see a reason why we need more than italic-font
> emphasis here.  But if it's deliberate, please could there at least be a
> portable way to suppress the spurious hyperlinks?
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.19.0-26-generic (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND,
> TAINT_OOT_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
>
> Versions of packages mandoc depends on:
> ii  libc6   2.36-8
> ii  zlib1g  1:1.2.13.dfsg-1
>
> mandoc recommends no packages.
>
> mandoc suggests no packages.
>
> -- no debconf information
>
> Thanks,
>
> --
> Colin Watson   [cjwat...@debian.org]
>


-- 
Best regards,
Michael

Bug#1025409: libxcb-cursor0: Causes X11 errors for non-existing cursors / please update to a newer upstream release

[Michael Stapelberg]

sur5r, would you be interested in picking this tiny package up?
Otherwise, I’ll file a bug to orphan it.

(I’m no longer active in Debian:
https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/)

On Sun, 4 Dec 2022 at 10:24, Uli Schlachter  wrote:

> Package: libxcb-cursor0
> Version: 0.1.1-4
> Severity: normal
> X-Debbugs-Cc: tobespam...@web.de
>
> Hi,
>
> for $REASONS [0] I tested today what happens when loading a non-existing
> cursor through libxcb-cursor. To my surprise, I got X11 errors instead
> of the existing "cannot load cursor"-message. After some debugging, I
> figured out that this is a bug that was fixed upstream 7 years ago [1].
>
> Please update the package to a version that contains this fix. The first
> such version is version 0.1.2. Thanks!
>
> Cheers,
> Uli
>
> P.S.: Hi Michael. :-)
>
>
> [0]: https://github.com/awesomeWM/awesome/pull/3745
> [1]:
>
> https://gitlab.freedesktop.org/xorg/lib/libxcb-cursor/-/commit/cf26479ece9ab9e04616bc10ba674d88a284e5b0
>
> -- System Information:
> Debian Release: bookworm/sid
>APT prefers testing
>APT policy: (990, 'testing'), (500, 'testing-debug'), (50,
> 'experimental'), (50, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libxcb-cursor0 depends on:
> ii  libc62.36-5
> ii  libxcb-image00.4.0-2
> ii  libxcb-render-util0  0.3.9-1+b1
> ii  libxcb-render0   1.15-1
> ii  libxcb-shm0  1.15-1
> ii  libxcb1  1.15-1
>
> libxcb-cursor0 recommends no packages.
>
> libxcb-cursor0 suggests no packages.
>
> -- no debconf information
>


-- 
Best regards,
Michael

Bug#1014573: sbuild-debian-developer-setup: Add option to use a specific mirror instead of apt-cacher-ng

[Michael Stapelberg]

Thanks for taking care of the other bugs!

Unfortunately I don’t have time to do any development on
sbuild-debian-developer-setup, so I can’t help with this bug.

Maybe Ben can try and send a patch?

On Wed, 14 Sept 2022 at 08:10, Johannes Schauer Marin Rodrigues <
jo...@debian.org> wrote:

> Hi Michael,
>
> On Fri, 08 Jul 2022 02:35:50 -0400 Ben Westover 
> wrote:
> > I was trying to create an Ubuntu schroot for sbuild using the command
> > sbuild-debian-developer-setup --distribution=ubuntu --suite=jammy and
> > debootstrap failed because it tried to use apt-cacher-ng, which doesn't
> work
> > for Ubuntu if you're on Debian, and vice versa. This would be solved
> with an
> > option that can specify the mirror to use in place of apt-cacher-ng.
> > Alternatively, sbuild-debian-developer-setup could do a sanity check on
> > apt-cacher-ng, and if it fails, switch to http://deb.debian.org/debian
> or
> > http://archive.ubuntu.com/ubuntu.
>
> I'm going to take care of the other sbuild-debian-developer-setup related
> bugs
> in the bts (#1014574 and #1006135 -- I am going to comply with both
> requests
> unless you have any objections). In turn, could you take care about this
> bug?
>
> Thanks!
>
> cheers, josch



-- 
Best regards,
Michael

Bug#1015738: xcb-util-xrm fails to parse resources like *.foo

[Michael Stapelberg]

Feel free to just adopt this one. Thanks for taking care of it!

On Wed, 20 Jul 2022 at 09:45, Jakob Haufe  wrote:

> On Wed, 20 Jul 2022 08:28:11 +0200
> Michael Stapelberg  wrote:
>
> > sur5r, is updating libxcb-xrm something you’d be able to help with?
>
> Yes, but I will not be able to have a look for at least another week.
>
> > The alternative is orphaning that package and updating it via the QA
> team,
> > I suppose.
>
> Do you prefer co-/team-maintenance as with i3 or should I adopt it?
>
> Cheers,
> sur5r
>
> --
> ceterum censeo microsoftem esse delendam.
>


-- 
Best regards,
Michael

Bug#1015738: xcb-util-xrm fails to parse resources like *.foo

[Michael Stapelberg]

sur5r, is updating libxcb-xrm something you’d be able to help with?

The alternative is orphaning that package and updating it via the QA team,
I suppose.

Thanks

On Wed, 20 Jul 2022 at 04:33, Antoine Beaupre  wrote:

> Package: libxcb-xrm0
> Version: 1.0-3+b1
> Severity: normal
>
> This is a rather convoluted issue, but bear with me for a minute and
> hopefully things will be a little clearer.
>
> I have recently changed themes to use srcery, which basically means I
> loaded this Xresources file:
>
>
> https://github.com/srcery-colors/srcery-terminal/blob/566eb23e7bbf084bb56587a08ba2df6cb65db5a8/xresources/srcery.xresources
>
> Notice the ... particular pattern:
>
> ! white
> *.color7:   #baa67f
> *.color15:  #fce8c3
>
> Normally, that would be something like:
>
> ! white
> *color7:   #baa67f
> *color15:  #fce8c3
>
> ... which was fixed in:
>
>
> https://github.com/srcery-colors/srcery-terminal/commit/96b21803832d00fd816473fd20517d39f9245741
>
> ... but, actually, *.foo *is* legal according to the X(7)
> specification. The actual quote, if I may, is:
>
> When an application looks for the value of a resource, it specifies
> a complete path in the hierarchy, with both class and instance
> names. However, resource values are usually given with only
> partially specified names and classes, using pattern matching
> constructs. An asterisk (*) is a loose binding and is used to
> represent any number of intervening components, including none. A
> period (.) is a tight binding and is used to separate immediately
> adjacent components. A question mark (?) is used to match any single
> component name or class. A database entry cannot end in a loose
> binding; the final component (which cannot be "?") must be
> specified. The lookup algorithm searches the resource database for
> the entry that most closely matches (is most specific for) the full
> name and class being queried. When more than one database entry
> matches the full name and class, precedence rules are used to select
> just one.
>
> So this *should* work, but doesn't. This affects any package using the
> libxcb-xrm0 which includes, most prominently for me, the i3 window
> manager (but there are problem many others).
>
> This bug has been acknowledged upstream:
>
> https://github.com/Airblader/xcb-util-xrm/issues/79
>
> ... and fixed over 4 years ago, in a release that was shipped as 1.3
> in March 2018:
>
> https://github.com/Airblader/xcb-util-xrm/releases/tag/v1.3
>
> It seems like Debian should probably fix this bug as well, so I'm
> filing this here to make sure we have that particularly hairy issue,
> which sent me spinning over three different GitHub projects (i3,
> xcb-util-frm, and srcery). ;)
>
> More details in:
>
> https://github.com/i3/i3/discussions/5051
> https://github.com/srcery-colors/srcery-terminal/pull/164
>
> Thanks!
>
> -- System Information:
> Debian Release: 11.3
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500,
> 'stable'), (1, 'unstable'), (1, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-15-amd64 (SMP w/4 CPU threads)
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libxcb-xrm0 depends on:
> ii  libc6 2.31-13+deb11u3
> ii  libxcb-util1  0.4.0-1+b1
> ii  libxcb1   1.14-3
>
> libxcb-xrm0 recommends no packages.
>
> libxcb-xrm0 suggests no packages.
>
> -- no debconf information
>


-- 
Best regards,
Michael

Bug#1015080: irssi-plugin-robustirc: FTBFS: robustsession.c:599:25: error: ‘G_INPUT_READ’ undeclared (first use in this function); did you mean ‘I_INPUT_READ’?

[Michael Stapelberg]

I fixed the compilation issue with
https://github.com/robustirc/irssi-robustirc/commit/a89d711914cc852c7135bd8f822bbd0a4e16829a
upstream, but the plugin itself doesn’t actually work, at least not with
irssi 1.4.2.

When I last tried to use this plugin a few months ago by installing it from
Debian, it wouldn’t work either (mismatching ABI between irssi and the
plugin), but there never have been any user bug reports about this.

Given the low user interest and breakage that is not currently planned to
be fixed upstream (
https://github.com/robustirc/irssi-robustirc/commit/6c5a9d01f61dac8698cd993c44b525c5246c4890),
I think it would be best to remove this package from Debian entirely.

On Sat, 16 Jul 2022 at 16:02, Lucas Nussbaum  wrote:

> Source: irssi-plugin-robustirc
> Version: 0.6-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220716 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > cd /<>/obj-x86_64-linux-gnu/src/core && /usr/bin/cc
> -DUOFF_T_LONG -Drobustirc_core_EXPORTS -I/usr/include/yajl
> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/<>/src/core
> -I/<>/src/core/robustsession -I/<>/src/fe-common
> -I/usr/include/irssi -I/usr/include/irssi/src
> -I/usr/include/irssi/src/fe-common/core -I/usr/include/irssi/src/core
> -I/usr/include/irssi/src/irc/core -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra
> -fPIC   -pthread -std=gnu99 -MD -MT
> src/core/CMakeFiles/robustirc_core.dir/robustsession/robustsession.c.o -MF
> CMakeFiles/robustirc_core.dir/robustsession/robustsession.c.o.d -o
> CMakeFiles/robustirc_core.dir/robustsession/robustsession.c.o -c
> /<>/src/core/robustsession/robustsession.c
> > /<>/src/core/robustsession/robustsession.c: In function
> ‘get_messages_timeout’:
> > /<>/src/core/robustsession/robustsession.c:268:17: warning:
> unused variable ‘server’ [-Wunused-variable]
> >   268 | SERVER_REC *server = request->server;
> >   | ^~
> > /<>/src/core/robustsession/robustsession.c: In function
> ‘socket_recv_cb’:
> > /<>/src/core/robustsession/robustsession.c:543:34: warning:
> unused parameter ‘data’ [-Wunused-parameter]
> >   543 | static void socket_recv_cb(void *data, GIOChannel *source, int
> condition) {
> >   |~~^~~~
> > /<>/src/core/robustsession/robustsession.c:543:64: warning:
> unused parameter ‘condition’ [-Wunused-parameter]
> >   543 | static void socket_recv_cb(void *data, GIOChannel *source, int
> condition) {
> >   |
> ^
> > /<>/src/core/robustsession/robustsession.c: In function
> ‘socket_callback’:
> > /<>/src/core/robustsession/robustsession.c:595:26: warning:
> implicit declaration of function ‘g_io_channel_new’; did you mean
> ‘i_io_channel_new’? [-Wimplicit-function-declaration]
> >   595 | GIOChannel *handle = g_io_channel_new(s);
> >   |  ^~~~
> >   |  i_io_channel_new
> > /<>/src/core/robustsession/robustsession.c:595:26: warning:
> initialization of ‘GIOChannel *’ {aka ‘struct _GIOChannel *’} from ‘int’
> makes pointer from integer without a cast [-Wint-conversion]
> > /<>/src/core/robustsession/robustsession.c:599:25: error:
> ‘G_INPUT_READ’ undeclared (first use in this function); did you mean
> ‘I_INPUT_READ’?
> >   599 | condition = G_INPUT_READ;
> >   | ^~~~
> >   | I_INPUT_READ
> > /<>/src/core/robustsession/robustsession.c:599:25: note:
> each undeclared identifier is reported only once for each function it
> appears in
> > /<>/src/core/robustsession/robustsession.c:602:25: error:
> ‘G_INPUT_WRITE’ undeclared (first use in this function); did you mean
> ‘I_INPUT_WRITE’?
> >   602 | condition = G_INPUT_WRITE;
> >   | ^
> >   | I_INPUT_WRITE
> > /<>/src/core/robustsession/robustsession.c:608:11: warning:
> implicit declaration of function ‘g_input_add’; did you mean ‘i_input_add’?
> [-Wimplicit-function-declaration]
> >   608 | *id = g_input_add(handle, condition, socket_recv_cb, NULL);
> >   |   ^~~
> >   |   i_input_add
> > /<>/src/core/robustsession/robustsession.c:575:34: warning:
> unused parameter ‘easy’ [-Wunused-parameter]
> >   575 | static int socket_callback(CURL *easy, curl_socket_t s, int
> what, void *userp, void *socketp) {
> >   |~~^~~~
> > /<>/src/core/robustsession/robustsession.c:575:73: warning:
> unused parameter ‘userp’ [-Wunused-parameter]
> >   575 | static int socket_callback(CURL *easy, curl_socket_t s, int
> what, void *userp, void 

Bug#930557: i3-gaps RFS/ITP

[Michael Stapelberg]

Personally, I don’t want gaps to be built from src:i3-wm.
It’s enough work to maintain one version of i3.

That said, sur5r is doing all of the Debian work since I retired from
Debian,
so it’s ultimately up to him.

I will stress one more time that what we need here is not a one-time
sponsorship offer,
but a multi-year commitment for maintaining the i3-gaps package in Debian.

On Sun, 3 Oct 2021 at 08:57, Vincent Bernat  wrote:

>  ❦  3 October 2021 08:48 +02, Michael Stapelberg:
>
> > I still think it’d be better to spend time on merging gaps rather than
> > packaging gaps,
> > but it seems like nobody has the skill set and/or motivation.
>
> This is a very different skillset from packaging.
>
> > Is there someone who would continuously maintain i3-gaps in Debian?
> > I wouldn’t want that package to diverge from upstream i3 in terms of
> which
> > version is available in Debian.
>
> Alternatively, src:i3-wm could build both i3-wm and i3-gaps. It adds
> extra work on existing maintainers but maybe you and Jakob would be OK
> with that? I can propose a patch for that if it helps.
> --
> Use recursive procedures for recursively-defined data structures.
> - The Elements of Programming Style (Kernighan & Plauger)
>


-- 
Best regards,
Michael

Bug#930557: i3-gaps RFS/ITP

[Michael Stapelberg]

I still think it’d be better to spend time on merging gaps rather than
packaging gaps,
but it seems like nobody has the skill set and/or motivation.

Is there someone who would continuously maintain i3-gaps in Debian?
I wouldn’t want that package to diverge from upstream i3 in terms of which
version is available in Debian.

I’m asking in particular because people might switch from X11+i3 to
Wayland+sway over the next few years.

On Sun, 3 Oct 2021 at 08:35, Vincent Bernat  wrote:

>  ❦ 17 June 2019 18:30 +02, Michael Stapelberg:
>
> > Ingo will outline what needs to be done to get i3-gaps into a mergable
> > state, so that we can eventually bring these features to all i3 users.
> >
> > For the time being, our recommendation is to NOT add i3-gaps to Debian or
> > any other Linux distribution. Instead, if you have time and motivation,
> > please consider helping improve i3-gaps with the goal of a merge.
>
> It seems there is not much progress on this front. The issue on GitHub
> does not show activity either. As other popular desktop distributions
> (Fedora, openSuSE, Arch and Manjaro) are providing a i3-gaps package,
> maybe an i3-gaps package in Debian could be reconsidered?
>
> I would gladly sponsor it if there is no strong opposition from i3
> maintainers.
> --
> Write and test a big program in small pieces.
> - The Elements of Programming Style (Kernighan & Plauger)
>


-- 
Best regards,
Michael

Bug#992512: Debug in i3-wm is enabled by default

[Michael Stapelberg]

This is a mistake in 4.19.1 that we fixed in 4.19.2:
https://i3wm.org/downloads/RELEASE-NOTES-4.19.2.txt

It’s unfortunate that 4.19.2 did not make it into Debian.

On Thu, 19 Aug 2021 at 16:39, arctic noise  wrote:

> Package: i3-wm
> Version: 4.19.1-1
> Severity: minor
>
> According to i3 manual it has debugging disabled by default:
>
>  >--shmlog-size  Limits the size of the i3 SHM log to
>  bytes. Setting this to 0 disables SHM logging entirely. The
> default is 0 bytes.
>
> Also, as I can see, debug and non-debug versions have different xsession
> files:
>
>  >> grep ^Exec /usr/share/xsessions/i3*
>  > /usr/share/xsessions/i3.desktop:Exec=i3
>  > /usr/share/xsessions/i3-with-shmlog.desktop:Exec=i3-with-shmlog
>
> However, i3-with-shmlog is an alias to i3, so both xsession files refers
> to the same executable file with the same parameters:
>
>  >> ls -l $(which i3-with-shmlog)
>  >lrwxrwxrwx 1 root root 2 Feb  7  2021 /usr/bin/i3-with-shmlog -> i3
>
> /dev/shm/i3-logs-${pid} file is present after every launch, so the
> debugging is enabled by default.
>
> I think it is better to disable debugging by default, remote the
> symbolic link and use "--shmlog-size" option in "Exec" field for
> i3-with-shmlog.desktop
>
> I am using debian 11 with all the latest updates, no packages from
> unofficial or testing repositories
>


-- 
Best regards,
Michael

Bug#992002: mandoc: -Thtml: tbl font requests ignored

[Michael Stapelberg]

Can you send your patches to upstream directly please?
See https://mandoc.bsd.lv/contact.html

It’s awkward for Debian maintainers to sit in the middle.
Thanks!

On Sun, 8 Aug 2021 at 14:51, наб  wrote:

> Control: retitle -1 mandoc: -Thtml: tbl font requests ignored
> Control: tags -1 + patch
>
> Easy enough, oddly. Patch attached, applies cleanly on top of 1.22.4-6.
> Please consider it.
>
> Given the following document:
> -- >8 --
> .Dd
> .Dt V 1
> .Os
> .
> \fBtext\fItext\f(BItext\f(CRtext\f(CBtext\f(CItext\fR
> .Pp
> .TS
> lfB lfI lfBI lb li lbi lfCR lfCB lfCI .
> texttexttexttexttexttexttexttexttext
> .TE
> -- >8 --
>
> When rendering to a teletype, the fonts are
>   b, ul, bul;  b, ul, bul;  normal, b, ul
> this is as expected!
>
> -Thtml -Ofragment yields
> -- >8 --
> 
>   
> V(1)
> General Commands Manual
> V(1)
>   
> 
> texttexttext class="Li">texttexttext
> 
> 
>   
> text
> text
> text
> text
> text
> text
> text
> text
> text
>   
> 
> 
> 
>   
> August 8, 2021
> Debian
>   
> 
> -- >8 --
>
> This is, also, as expected, if suboptimal because of the general
> HTML \fC[BI] handling.
>
> Best,
> наб
> --- mdocml-1.14.5.orig/tbl.7
> +++ mdocml-1.14.5/tbl.7
> @@ -178,10 +178,11 @@ of any other column also having the
>  .Cm e
>  modifier.
>  .It Cm f
> -The next character selects the font to use for this cell.
> +The next two characters select the font to use for this cell.
> +One-character font names must be followed by a blank or period.
>  See the
>  .Xr roff 7
> -manual for supported one-character font names.
> +manual for supported font names.
>  .It Cm i
>  Use an italic font for the contents of this cell.
>  .It Cm m
> --- mdocml-1.14.5.orig/tbl.h
> +++ mdocml-1.14.5/tbl.h
> @@ -59,12 +59,13 @@ struct  tbl_cell {
> int   flags;
>  #defineTBL_CELL_BOLD(1 << 0)   /* b, B, fB */
>  #defineTBL_CELL_ITALIC  (1 << 1)   /* i, I, fI */
> -#defineTBL_CELL_TALIGN  (1 << 2)   /* t, T */
> -#defineTBL_CELL_UP  (1 << 3)   /* u, U */
> -#defineTBL_CELL_BALIGN  (1 << 4)   /* d, D */
> -#defineTBL_CELL_WIGN(1 << 5)   /* z, Z */
> -#defineTBL_CELL_EQUAL   (1 << 6)   /* e, E */
> -#defineTBL_CELL_WMAX(1 << 7)   /* x, X */
> +#defineTBL_CELL_FONTCW  (1 << 2)   /* fC[RBI] */
> +#defineTBL_CELL_TALIGN  (1 << 3)   /* t, T */
> +#defineTBL_CELL_UP  (1 << 4)   /* u, U */
> +#defineTBL_CELL_BALIGN  (1 << 5)   /* d, D */
> +#defineTBL_CELL_WIGN(1 << 6)   /* z, Z */
> +#defineTBL_CELL_EQUAL   (1 << 7)   /* e, E */
> +#defineTBL_CELL_WMAX(1 << 8)   /* x, X */
> enum tbl_celltpos;
>  };
>
> --- mdocml-1.14.5.orig/tbl_html.c
> +++ mdocml-1.14.5/tbl_html.c
> @@ -25,6 +25,7 @@
>  #include 
>
>  #include "mandoc.h"
> +#include "mandoc_aux.h"
>  #include "tbl.h"
>  #include "out.h"
>  #include "html.h"
> @@ -218,6 +219,7 @@ print_tbl(struct html *h, const struct t
> else
> valign = NULL;
>
> +   int flags = cp->flags;
> for (i = dp->hspans; i > 0; i--)
> cp = cp->next;
> switch (cp->vert) {
> @@ -239,8 +241,36 @@ print_tbl(struct html *h, const struct t
> "vertical-align", valign,
> "text-align", halign,
> "border-right-style", rborder);
> -   if (dp->string != NULL)
> -   print_text(h, dp->string);
> +   if (dp->string != NULL) {
> +   const char *font = NULL;
> +   switch (flags & (TBL_CELL_BOLD | TBL_CELL_ITALIC |
> TBL_CELL_FONTCW)) {
> +   case TBL_CELL_BOLD:
> +   font = "\\fB";
> +   break;
> +   case TBL_CELL_ITALIC:
> +   font = "\\fI";
> +   break;
> +   case TBL_CELL_BOLD | TBL_CELL_ITALIC:
> +   font = "\\f(BI";
> +   break;
> +   case TBL_CELL_FONTCW:
> +   font = "\\f(CR";
> +   break;
> +   case TBL_CELL_FONTCW | TBL_CELL_BOLD:
> +   font = "\\f(CB";
> +   break;
> +   case TBL_CELL_FONTCW | TBL_CELL_ITALIC:
> +   font = "\\f(CI";
> +   break;
> +   }
> +   if (font) {
> +   char *str;
> +   mandoc_asprintf(, 

Bug#868352: linux: Please enable USB_SERIAL_CONSOLE

[Michael Stapelberg]

Hi Ben,

Ben Hutchings  writes:
> On Fri, 2017-07-14 at 20:34 +0200, Sascha Silbe wrote:
>> Source: linux
>> Version: 4.11.6-1
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> on some amd64 systems no native or PCI(e) serial ports are available
>> resp. possible. USB serial adapters are the only option to get a
>> serial console for debugging boot problems in this case. Unfortunately
>> the Debian amd64 kernels are built with USB_SERIAL_CONSOLE unset
>> (because USB_SERIAL is not built-in) so even that option isn't
>> available. When the BIOS text mode isn't working (e.g. high-res
>> monitor with a BIOS that only supports up to FullHD) one is left
>> without any working console device.
> [...]
>
> I think this case is too unusual to make it worth building in all the
> USB stuff needed to make this work on all x86 systems.

I’d like to respectfully ask you to reconsider this position.

Over the years, more and more mainboards have dropped all support for
any onboard serial ports. Using a USB serial console is nowadays often
the only option for getting boot messages to another computer.

I ran into this issue yesterday using an AsRock B550 Taichi mainboard,
which has no serial headers.

To make the USB console work, I had to build my own Debian kernel with
the following options changed:

CONFIG_USB=y
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y

This is very tedious, partly because a build takes 42 minutes even on my
latest-gen Ryzen CPU, and also because I don’t want to maintain a custom
kernel build indefinitely.

I don’t think this is a niche use case, at least not among users of
serial consoles: other users of Debian and Ubuntu are running into this
issue, too, see for example:

https://unix.stackexchange.com/q/425280/181634
https://askubuntu.com/q/1269623

Notably, both Fedora and Arch Linux (the 2 other distributions I can
quickly check) ship their default kernel with
CONFIG_USB_SERIAL_CONSOLE=y:

--- /tmp/config-debian  2021-07-27 23:29:22.648166910 +0200
+++ /tmp/config-fedora  2021-07-27 23:29:12.734958768 +0200
@@ -1,4 +1,5 @@
-CONFIG_USB_SERIAL=m
+CONFIG_USB_SERIAL=y
+CONFIG_USB_SERIAL_CONSOLE=y
 CONFIG_USB_SERIAL_GENERIC=y
 CONFIG_USB_SERIAL_SIMPLE=m
 CONFIG_USB_SERIAL_AIRCABLE=m
@@ -16,7 +17,7 @@

So Debian seems like the odd one out. Given Debian’s popularity for
server scenarios, I think we should make troubleshooting easier and have
USB serial consoles just work.

Could you please enable CONFIG_USB_SERIAL_CONSOLE=y?

Thank you!

-- 
Best regards,
Michael

Bug#989188: mandoc: missing mandoc.css example CSS file

[Michael Stapelberg]

The installation of mandoc.css happens in the cgi-install target:
https://sources.debian.org/src/mdocml/1.14.5-1/Makefile/#L448
…but the cgi-install target is not called by the package Debian build files.
See e.g. build log
https://buildd.debian.org/status/fetch.php?pkg=mdocml=amd64=1.14.5-1=1613511718=0

On Fri, 28 May 2021 at 04:36, Nick Gasson  wrote:

> Package: mandoc
> Version: 1.14.5-1
> Severity: normal
>
> Dear Maintainer,
>
> The mandoc(1) man page says:
>
>   The file /usr/share/misc/mandoc.css documents style-sheet classes
>   available for customising output.
>
> However this file is not installed on Debian.
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (650, 'testing'), (600, 'unstable'), (500, 'testing-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-6-amd64 (SMP w/12 CPU threads)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages mandoc depends on:
> ii  libc6   2.31-5
> ii  zlib1g  1:1.2.11.dfsg-2
>
> mandoc recommends no packages.
>
> mandoc suggests no packages.
>
> -- no debconf information
>


-- 
Best regards,
Michael

Bug#977367: debsources: search results point to not existing sources?

[Michael Stapelberg]

On Wed, Apr 28, 2021 at 10:36 PM Matthieu Caneill  wrote:

> Hi Michael,
>
> On Sun, Apr 11, 2021 at 10:41:10AM +0200, Michael Stapelberg wrote:
> > We introduced unpacking tarballs in
> https://github.com/Debian/dcs/issues/80
> > (from 2017!),
> > but apparently didn’t think it through far enough regarding sources.d.o
> :)
>
> Thanks for your answer! And I think we can reasonably assume this edge
> case doesn't happen too often. :)
>
> > Would adding support for unpacking tarballs be something you would
> consider
> > in debsources?
> > I know that tarballs *technically are the source*, but humans clearly
> find
> > the contents of these tarballs more interesting.
>
> Yes - clearly. The bug to implement tarballs-in-tarballs unpacking has
> been open forever, so I think it's quite unlikely it's gonna be picked
> up within a reasonable timeframe. I myself won't have time to take
> care of this anytime soon.
>

I can empathize regarding not having enough time, but just want to point
out that the change itself ended up being quite simple in terms of lines of
code and mental complexity:
https://github.com/Debian/dcs/commit/2c94a341f785e2c7552a02500289b95dfe75a83d
— as you can see, we just loop over *.tar.* and call “tar xf”.

I’m not saying this to push you to implement it, just mentioning this for
your information should you eventually get around to it :)


>
> > Otherwise, we could handle these with our own /show handler by checking
> if
> > the source is present in debsources first,
> > but that obviously involves one additional request per /show handler, so
> > it’s not exactly cheap.
>
> That'd work indeed. Doing nothing also sounds like a reasonable
> strategy, given the (assumed) low rate of this failure and the efforts
> involved to implement a work-around.
>
> But I'm glad we know where that comes from. Thanks for your thoughts!
>
> Cheers,
> --
> Matthieu
>


-- 
Best regards,
Michael

Bug#977367: debsources: search results point to not existing sources?

[Michael Stapelberg]

Thanks for looping me in.

We introduced unpacking tarballs in https://github.com/Debian/dcs/issues/80
(from 2017!),
but apparently didn’t think it through far enough regarding sources.d.o :)

Would adding support for unpacking tarballs be something you would consider
in debsources?
I know that tarballs *technically are the source*, but humans clearly find
the contents of these tarballs more interesting.

Otherwise, we could handle these with our own /show handler by checking if
the source is present in debsources first,
but that obviously involves one additional request per /show handler, so
it’s not exactly cheap.

On Mon, Apr 5, 2021 at 8:23 PM Matthieu Caneill  wrote:

> Control: usertag -1 debsources
> Control: merge 761077 -1
>
> Hi Tomas,
>
> On Mon, Dec 14, 2020 at 02:13:49PM +0100, Tomas Pospisek wrote:
> > Go to
> https://codesearch.debian.net/search?q=Client+sent+an+HTTP+request+to+an+HTTPS+server
> > select first link
> https://codesearch.debian.net/show?file=gcc-10_10.2.1-1%2Fgcc-10.2.0%2Flibgo%2Fgo%2Fnet%2Fhttp%2Fserver.go=1798
> > get a 404 with a list of 12 alternative source files of different
> > versions of gcc-XX/XX.Y.Z-W/gcc-XX.V.U/libgo/go/net/http/server.go
> > each returning a 404.
> >
> > I have now clicked through quite a few links to source files, but
> > have yet to find one that won't return a 404...?
> >
> > Maybe the search index would need to be purged of source files that
> > have disappeared (been updated) or something?
>
> Thank you very much for the detailed bug report, and apologies for the
> delay in getting back to you.
>
> After further inspection, it turns out the tarball containing the
> source for gcc-10 contains embedded tarballs. See
> http://deb.debian.org/debian/pool/main/g/gcc-10/gcc-10_10.2.1.orig.tar.xz
> and https://sources.debian.org/src/gcc-10/10.2.0-3/
>
> Debsources unpacked the first tarball, and the embedded ones are
> technically the "source" of gcc-10. The path you obtained from
> codesearch.debian.net points to a file inside the tarball inside the
> tarball; this is unfortunately not supported by sources.d.o.
>
> I didn't know codesearch supported this feature. CCing Michael, in
> case you have an idea on how not to point to sources.d.o for code
> results originating from unpacked archives. :)
>
> Cheers,
> --
> Matthieu
>


-- 
Best regards,
Michael

Bug#983010: mdocml breaks debiman autopkgtest: different output

[Michael Stapelberg]

Agreed, the test seems too brittle. Can we just turn the test off for now?

https://github.com/Debian/debiman/issues/127 tracks updating mdocml on
manpages.d.o,
which I intend to do as time permits.

I wonder whether it makes sense to have debiman packaged in Debian itself,
though.
Personally, I’m not maintaining that package, and I’m not sure if there are
any users of the package.

Anyway, any help welcome to sort this out on the package level.
I don’t have time to help, sorry:
https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

On Tue, Feb 23, 2021 at 12:45 PM Ivo De Decker  wrote:

> Control: reassign -1 debiman 0.0~git20200217.fc82521-1
>
> Hi,
>
> On Thu, Feb 18, 2021 at 07:31:32AM +0100, Paul Gevers wrote:
> > With a recent upload of mdocml the autopkgtest of debiman fails in
> > testing when that autopkgtest is run with the binary packages of mdocml
> > from unstable. It passes when run with only packages from testing. In
> > tabular form:
>
> [...]
>
> > === CONT  TestToHTML/i3lock
> > convert_test.go:92: unexpected conversion result: (diff from want →
> > got):
> > --- /tmp/debiman-8492488252021-02-18 04:13:33.034473409 +
> > +++ /tmp/debiman-3766921622021-02-18 04:13:33.034473409 +
> > @@ -7,67 +7,76 @@
> >
> >  
> >  
> > -
> > -
> > +
> > +
> > +
> [...]
>
> Hard-coding the exact html output of a dependency that generates html, and
> expecting that not to change doesn't seem like a robust way to test it
> functionality, so I think it's clear that the bug is in the autopkgtest of
> debiman. It's perfectly acceptable for mdocml to generate different html
> output to represent the data (whether the upload of the new upstream
> version
> should have happened during the soft freeze is a different matter, but
> that's
> unrelated to this bug).
>
> Testing that the html is valid, and contains certain parts of the input
> might
> be a more useful test.
>
> Cheers,
>
> Ivo
>


-- 
Best regards,
Michael

Bug#969254: i3-save-tree: Can't locate AnyEvent/I3.pm in @INC (you may need to install the AnyEvent::I3 module)

[Michael Stapelberg]

control: severity -1 normal

The i3-wm package recommends libanyevent-i3-perl:
https://packages.debian.org/bullseye/i3-wm

I have verified that in a clean debian:sid Docker container, running
“apt update && apt install i3” results in installing
libanyevent-i3-perl, so I think this situation is specific to your
system somehow.
Maybe you have disabled installation of recommended packages in apt at
some point?

In any case, install the package and things should start working.

On Sun, Aug 30, 2020 at 10:27 AM xiscu  wrote:
>
> Package: i3
> Version: 4.18-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
> I wanted to save/restore the layout used in workspace 1 and tested, following
> as on:
>
> https://i3wm.org/docs/layout-saving.html (and man i3-save-tree)
>
> But I get:
> ~> i3-save-tree --workspace 1 > ~/.i3/ws1.json
> Can't locate AnyEvent/I3.pm in @INC (you may need to install the AnyEvent::I3 
> module)
> (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3
> /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base
> /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 
> /usr/local/lib/site_perl)
> at /usr/bin/i3-save-tree line 19.
> BEGIN failed--compilation aborted at /usr/bin/i3-save-tree line 19.
>
> the file is created but is empty.
>
> Shouldn't the dependencies to run that command be installed?
> otherwise IMHO the command isn't as usefull as it promisses.
> Or what I'm missing or doing wrong?
>
> Let me know if some information is needed.
>
> Thanks in advance!
> xiscu
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (10, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages i3 depends on:
> ii  i3-wm  4.18-1
>
> Versions of packages i3 recommends:
> pn  dunst   
> ii  i3lock  2.11.1-1
> ii  i3status2.13-3
> ii  suckless-tools  45-1
>
> i3 suggests no packages.
>
> -- no debconf information



-- 
Best regards,
Michael

-- 
Best regards,
Michael

Bug#964755: i3: Memory leak consumes all available memory

[Michael Stapelberg]

And can you test with any other window manager (e.g. awesome, dwm,
wmii) to see if the issue really is i3 specific please?

On Thu, Jul 23, 2020 at 3:05 AM Gabriel Krisman Bertazi
 wrote:
>
> Michael Stapelberg  writes:
>
> > Is this fixed with commit
> > https://github.com/i3/i3/commit/025743eaf9c993e57c7fdd20127078b835bcd2c0
> > already (not yet released)? Or are we talking about a separate leak?
>
> Sorry for the delay.
>
> I built the 4.18 package with this patch, and have been running it for
> the past 3 days.  The issue persists:
>
> ❯ ps -o etime= $(pidof Xorg)
>  3-05:34:11
>
> root@dilma:/home/krisman/src/i3-wm-4.18# cat /proc/$(pidof Xorg)/status | 
> grep Vm
> VmPeak:  5488804 kB
> VmSize:  5471796 kB
> VmLck: 0 kB
> VmPin: 0 kB
> VmHWM:   4507732 kB
> VmRSS:   4507732 kB
> VmData:  4516956 kB
> VmStk:   132 kB
> VmExe:  1580 kB
> VmLib:116212 kB
> VmPTE:  9480 kB
> VmSwap:  556 kB
>
> xrestop doesn't seem bad:
>
> xrestop - Display: localhost
>   Monitoring 33 clients. XErrors: 0
>   Pixmaps:  102802K total, Other:  56K total, All:  102858K total
>
> The top entry in xrestop, in particular:
> res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
> 04049   911   43  41256925K 13K  56938K   ?   i3
>
> Pixmaps is not increasing over time, even though the overall xorg memory
> is.
>
> --
> Gabriel Krisman Bertazi



-- 
Best regards,
Michael

Bug#964755: i3: Memory leak consumes all available memory

[Michael Stapelberg]

Is this fixed with commit
https://github.com/i3/i3/commit/025743eaf9c993e57c7fdd20127078b835bcd2c0
already (not yet released)? Or are we talking about a separate leak?

On Fri, Jul 10, 2020 at 3:03 AM Gabriel Krisman Bertazi
 wrote:
>
> Package: i3
> Version: 4.18-1
> Severity: important
>
> Dear Maintainer,
>
> I've seen my xorg grow in memory usage through the course of the day,
> until it consumes all RAM available and starts swapping, even when the
> machine is left idle.  This is 100% reproducible on my system, after
> killing X and restarting it, it starts to eat memory again.
>
> I'm reporting this against i3 instead of xorg, because I found other
> Debian derivative users reporting this issue against i3, and it doesn't
> seem to reproduce on other X based WM.
>
> I reproduced this on a machine after a fresh install of bullseye, with
> the package version below.
>
> In my system, it is taking around 1 day to fill up 10GB of RAM.
>
> I'm happy to apply patches and test packages you provide to help debug
> this.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_CA:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages i3 depends on:
> ii  i3-wm  4.18-1
>
> Versions of packages i3 recommends:
> ii  dunst   1.4.1-1
> ii  i3lock  2.11.1-1
> ii  i3status2.13-3
> ii  suckless-tools  45-1
>
> i3 suggests no packages.
>
> -- no debconf information



-- 
Best regards,
Michael

-- 
Best regards,
Michael

Bug#952469: i3-wm: Moving windows in a specific way causes i3 to crash

[Michael Stapelberg]

Thanks for your report. Please file this issue on GitHub. There are
Debian repositories you can use to get the latest version:
https://i3wm.org/docs/repositories.html

On Mon, Feb 24, 2020 at 10:27 PM nabijaczleweli
 wrote:
>
> Package: i3-wm
> Version: 4.17.1-1
> Severity: normal
> Tags: upstream
>
> Dear Maintainer,
>
>
> I was trying to get myself out of a pickle with a workspace layout when
> i3 crashed to DM. I've managed to reduce this issue down to the
> following keystrokes (all with Mod held down, based on the default
> config -- Enter for terminal, W for tabbed, V for vert-split,
> A for select parent):
>
>   Enter
>   W
>   Enter
>   Left
>   V
>   Right
>   Shift+Down
>   Shift+Up
>   Shift+Up
>   Shift+Up
>   Down
>   A
>   Shift+Right
>
> See the attached screenshot for the layout before the final S+Right.
>
>
> I've attached a log of a crashing session, but in all of the ones I've
> collected (that managed to flush to disk) the following assertion fired:
>
>   i3[-with-shmlog]: ../../i3-wm-4.17.1/src/x.c:103: state_for_frame:
>   Assertion `false' failed.
>
> But the logging wasn't always exceptional and i3 seemed to crash much
> harder with it than without. Crashing backtraces are attached as well.
>
>
> I'm reporting this here rather than upstream because none of
> [next branch, 4.18.1, 4.18] built for me, and the website says
> that only the latest stable is supported, but I'll be happy to move this
> to GitHub.
>
> Regards,
> nabijaczleweli
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)
>
> Kernel: Linux 5.4.0-4-686-pae (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages i3-wm depends on:
> ii  libc6 2.29-10
> ii  libcairo2 1.16.0-4
> ii  libev41:4.31-1
> ii  libglib2.0-0  2.62.4-2
> ii  libpango-1.0-01.42.4-8
> ii  libpangocairo-1.0-0   1.42.4-8
> ii  libpcre3  2:8.39-12+b1
> ii  libstartup-notification0  0.12-6
> ii  libxcb-cursor00.1.1-4
> ii  libxcb-icccm4 0.4.1-1.1
> ii  libxcb-keysyms1   0.4.0-1+b2
> ii  libxcb-randr0 1.13.1-5
> ii  libxcb-shape0 1.13.1-5
> ii  libxcb-util0  0.3.8-3+b2
> ii  libxcb-xinerama0  1.13.1-5
> ii  libxcb-xkb1   1.13.1-5
> ii  libxcb-xrm0   1.0-3
> ii  libxcb1   1.13.1-5
> ii  libxkbcommon-x11-00.10.0-1
> ii  libxkbcommon0 0.10.0-1
> ii  libyajl2  2.1.0-3
> ii  perl  5.30.0-9
>
> Versions of packages i3-wm recommends:
> ii  fonts-dejavu-core   2.37-1
> ii  libanyevent-i3-perl 0.17-1
> ii  libjson-xs-perl 4.020-1+b1
> ii  rxvt-unicode [x-terminal-emulator]  9.22-6+b1
> ii  xfonts-base 1:1.0.5
>
> i3-wm suggests no packages.
>
> -- no debconf information



-- 
Best regards,
Michael

Bug#944056: i3-wm: i3 ignores system keyboard layouts

[Michael Stapelberg]

i3 is not involved in handling keys, only keyboard shortcuts.

Are you saying that keybindings (such as Mod+2 to switch to workspace 2)
you configured in the i3 config file are not working? Or are you referring
to text input to applications, such as entering your name in a web form in
Firefox?

On Sun, Nov 3, 2019 at 3:09 PM Vlastimil Zima 
wrote:

> Package: i3-wm
> Version: 4.17.1-1
> Severity: normal
> Tags: l10n
>
> Dear Maintainer,
>
> I'm trying to setup a i3, but I encountered a problem with keyboard
> layout setup. Multiple layouts set up in /etc/default/keyboard are
> ignored by i3 and only 'us' layout is available. On the other hand,
> keyboard options are respected.
>
> I have in /etc/default/keyboard
>
> XKBLAYOUT="us,cz"
> XKBVARIANT=",qwerty"
> BACKSPACE="guess"
> XKBMODEL="pc105"
> XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll,caps:none"
>
> but after i3 is started, 'setxkbmap -query' returns
>
> rules:  evdev
> model:  pc105
> layout: us
> options:grp:alt_shift_toggle,grp_led:scroll,caps:none
>
> I'd expect the layouts from the keyborad setup would be used as well. I
> wasn't able to find another location which would override the keyboard
> layout.
>
> Regards,
> Vlastimil Zíma
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages i3-wm depends on:
> ii  libc6 2.29-2
> ii  libcairo2 1.16.0-4
> ii  libev41:4.27-1
> ii  libglib2.0-0  2.62.2-1
> ii  libpango-1.0-01.42.4-7
> ii  libpangocairo-1.0-0   1.42.4-7
> ii  libpcre3  2:8.39-12+b1
> ii  libstartup-notification0  0.12-6
> ii  libxcb-cursor00.1.1-4
> ii  libxcb-icccm4 0.4.1-1.1
> ii  libxcb-keysyms1   0.4.0-1+b2
> ii  libxcb-randr0 1.13.1-2
> ii  libxcb-shape0 1.13.1-2
> ii  libxcb-util0  0.3.8-3+b2
> ii  libxcb-xinerama0  1.13.1-2
> ii  libxcb-xkb1   1.13.1-2
> ii  libxcb-xrm0   1.0-3
> ii  libxcb1   1.13.1-2
> ii  libxkbcommon-x11-00.8.4-1
> ii  libxkbcommon0 0.8.4-1
> ii  libyajl2  2.1.0-3
> ii  perl  5.30.0-9
>
> Versions of packages i3-wm recommends:
> ii  fonts-dejavu-core 2.37-1
> ii  gnome-terminal [x-terminal-emulator]  3.34.2-1
> ii  libanyevent-i3-perl   0.17-1
> ii  libjson-xs-perl   4.020-1+b1
> ii  xfonts-base   1:1.0.5
> ii  xterm [x-terminal-emulator]   349-1
>
> i3-wm suggests no packages.
>
> -- no debconf information
>


-- 
Best regards,
Michael

Bug#930557: i3-gaps RFS/ITP

[Michael Stapelberg]

> Certainly, a merge is the superior solution and i am glad its actually
being considered, but my understanding is that code refactoring/cleaning
could take a considerable amount of time, and therefore the package should
actually be available as a temporary solution for all those who want to use
it, as it currently is everywhere else.

I don’t think having it available temporarily is a good idea. It
complicates the situation both for the package maintainers and for end
users.

-- 
Best regards,
Michael

Bug#930557: i3-gaps RFS/ITP

[Michael Stapelberg]

Hey,

thanks everyone for reaching out.

The interest in making i3-gaps available to more people has prompted some
discussion between Ingo (the maintainer of the i3-gaps fork, and an i3 core
maintainer) and me.

The key concern about the i3-gaps fork is code quality: the implementation
cannot easily be merged into i3 as-is. One example is that you cannot
enable gaps and display title bars at the same time. The intention behind
publishing the fork was to make the feature available to people who can
live with the lower code quality and restrictions, not to have a long-term
sustainable fork.

Ingo will outline what needs to be done to get i3-gaps into a mergable
state, so that we can eventually bring these features to all i3 users.

For the time being, our recommendation is to NOT add i3-gaps to Debian or
any other Linux distribution. Instead, if you have time and motivation,
please consider helping improve i3-gaps with the goal of a merge.

Thank you,

-- 
Best regards,
Michael

Bug#930309: O: libtomcrypt

[Michael Stapelberg]

Package: wnpp
Severity: normal


Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

Bug#930310: O: dunst -- dmenu-ish notification-daemon

[Michael Stapelberg]

Package: wnpp
Severity: normal


Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

Bug#930304: O: wiipdf -- present a PDF file using your wiimote

[Michael Stapelberg]

Package: wnpp
Severity: normal


Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

Bug#930307: O: simple-tpm-pk11 -- simple library for using the TPM chip to secure SSH keys

[Michael Stapelberg]

Package: wnpp
Severity: normal


Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

Bug#930306: O: teensy-loader-cli -- load and run programs onto your Teensy micro controller

[Michael Stapelberg]

Package: wnpp
Severity: normal


Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

Bug#930305: O: unworkable -- efficient, simple and secure bittorrent client

[Michael Stapelberg]

Package: wnpp
Severity: normal


Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

Bug#930303: O: wit -- manipulate Wii and GameCube ISO images and WBFS containers

[Michael Stapelberg]

Package: wnpp
Severity: normal


Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

Bug#930308: O: mscompress -- Microsoft "compress.exe/expand.exe" compatible (de)compressor

[Michael Stapelberg]

Package: wnpp
Severity: normal


Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

Bug#927786: wit: wfuse is not included anymore

[Michael Stapelberg]

On Tue, Apr 23, 2019 at 10:09 AM Léo  wrote:

> Package: wit
> Version: 3.01a-2
> Severity: important
>
> Package: wit
> Version: 3.01a-2
>
> Hello, it looks like the latest version of the wit package does not
> include the wfuse binary anymore.
>
> I noticed this after trying to run wfuse and noticing that only
> the documentation was still present...
>
> Is this an intended change?
>

No. Can you send a patch to fix this please?

As per https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/,
I’ll not be working on this package (formal orphaning to follow when I find
the time).


>
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8),
> LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages wit depends on:
> ii  libbz2-1.0  1.0.6-9
> ii  libc6   2.28-8
> ii  libmhash2   0.9.9.9-7+b1
> ii  zlib1g  1:1.2.11.dfsg-1
>
> wit recommends no packages.
>
> wit suggests no packages.
>
> -- no debconf information
>


-- 
Best regards,
Michael

Bug#841385: This is a two year old bug

[Michael Stapelberg]

Your tone is inappropriate. Please find a more constructive way of
expressing your thoughts. Note that you are communicating with an
organization of volunteers.

On Fri, Mar 15, 2019 at 7:03 AM Nye Liu  wrote:

> This is a completely brain damaged bug that is now going on 3 years old
> with no fix in sight.
>
> Meanwhile, golang-1.12-go installs go in /usr/lib/go-1.12/bin, but the
> only way to use it is to add it to the path or overwrite the symlinks.
>
> Insanity.
>


-- 
Best regards,
Michael

Bug#923942: postinst script error: mv: cannot move '/tmp/ca-certificates.crt.tmp.hi8W7j' to a subdirectory of itself, 'ca-certificates.crt'

[Michael Stapelberg]

Please see https://travis-ci.org/stapelberg/i3/jobs/506217228 for a lot
more detailed log (sh -x and strace on the mv command). The issue seems to
be in update-ca-certificates, but it’s not readily apparent to me what
exactly it’s doing wrong—any idea?

Thanks,

On Thu, Mar 7, 2019 at 5:13 PM Michael Shuler 
wrote:

> On 3/7/19 8:13 AM, Michael Stapelberg wrote:
> > Package: ca-certificates
> > Version: 20190110
> > Severity: normal
> >
> > The i3 continuous integration testing on travis-ci.org currently fails:
> >
> > Setting up ca-certificates (20190110) ...
> > Updating certificates in /etc/ssl/certs...
> > mv: cannot move '/tmp/ca-certificates.crt.tmp.hi8W7j' to a subdirectory
> of itself, 'ca-certificates.crt'
> > dpkg: error processing package ca-certificates (--configure):
> >  installed ca-certificates package post-installation script subprocess
> returned error exit status 1
> >
> > See https://travis-ci.org/i3/i3/jobs/503115864 for the full log.
> >
> > Have not dug any deeper, but perhaps this rings a bell, or is obvious
> from the
> > error message. Let me know if you need more details.
>
> Thank you. I have not seen this error before, but will dig around!
>
> --
> Kind regards,
> Michael
>
>

-- 
Best regards,
Michael

Bug#923942: postinst script error: mv: cannot move '/tmp/ca-certificates.crt.tmp.hi8W7j' to a subdirectory of itself, 'ca-certificates.crt'

[Michael Stapelberg]

Package: ca-certificates
Version: 20190110
Severity: normal

The i3 continuous integration testing on travis-ci.org currently fails:

Setting up ca-certificates (20190110) ...
Updating certificates in /etc/ssl/certs...
mv: cannot move '/tmp/ca-certificates.crt.tmp.hi8W7j' to a subdirectory of 
itself, 'ca-certificates.crt'
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 1

See https://travis-ci.org/i3/i3/jobs/503115864 for the full log.

Have not dug any deeper, but perhaps this rings a bell, or is obvious from the
error message. Let me know if you need more details.

Thanks,

Bug#923034: FreeRADIUS status

[Michael Stapelberg]

The freeradius package is generally in good shape these days, I think.

There are a few users who will report bugs, and there is at least one who
is interested in having the latest upstream version available.

The work required to maintain the package is moderate — let’s say a few
hours each month.

Hope this helps,

On Sun, Feb 24, 2019 at 8:47 AM Niels Thykier  wrote:

> Alan DeKok:
> >   We've been looking for a new Debian maintainer for a while.
> >
> >   What, exactly, is in "bad shape" about this package?  If there are
> issues, we can work towards fixing them.
> >
> >   The software is widely used by many tens of thousands of sites.  I
> hope it's not going to be removed from Debian.
> >
> >   I'll note that Debian also packages "livingston-radius", which hasn't
> had any source changes in 20 years.  There's no mailing list, no support,
> and it doesn't implement any of the modern RADIUS standards.
> >
> >   Including that package does a disservice to people who install it, and
> then realize it's next to useless.
> >
>
> Hi,
>
> I am CC'ing Michael on your reply as I am not sure he is subscribed to
> the bug (it is not the default for Debian bugs) and he is probably
> better at answering this given his prior work with the package.
>
> Thanks,
> ~Niels
>


-- 
Best regards,
Michael

Bug#923034: O: freeradius -- high-performance and highly configurable RADIUS server

[Michael Stapelberg]

Package: wnpp
Severity: normal

I am orphaning this package effective immediately. I have never personally used
FreeRADIUS, and only stepped in to help when I saw the package was in bad shape.

(I will share more details in a later post, but figured I would get this out of
 the way immediately because freeradius is marked for autoremoval from testing,
 so if anyone cares, now is the time to step up.)

Bug#922203: RM: upspin/experimental -- ROM; no progress upstream, no user interest in Debian

[Michael Stapelberg]

Package: ftp.debian.org
Severity: normal

The project seems dead looking at the upstream repository.

Personally, I am no longer using upspin, and there was never any user
interest. Hence, I feel the best move is to remove it altogether.

Thanks!

Bug#922148: sbuild-debian-developer-setup-update-all example quotes wrong path

[Michael Stapelberg]

Seems like this is the result of your commit
https://salsa.debian.org/debian/sbuild/commit/eed23f5b70449b60f91764e3ab23196d8ec76dff
:)

I don’t have the time to do any fixes at the moment, sorry.

On Tue, Feb 12, 2019 at 7:51 PM Johannes Schauer  wrote:

> Hi Michael,
>
> could you look into this bug?
>
> Thanks!
>
> Quoting Antoine Beaupre (2019-02-12 18:11:45)
> > Package: sbuild
> > Version: 0.78.1-1
> > Severity: minor
> > File:
> /usr/share/doc/sbuild/examples/sbuild-debian-developer-setup-update-all
> >
> > It looks like that file was renamed in a recent upload, which broke my
> > wrapper scripts. That's not too bad: it's an example script so that
> > may be expected (even though I would prefer if that script would be
> > publicly available in sbin or something).
> >
> > The problem though is that the script itself documents how to add
> > itself to cron jobs, like this:
> >
> > # 1. Update all sbuild chroots four times a day (at
> 00:15/06:15/12:15/18:15):
> > #
> > # 15 */6 * * * root /usr/share/doc/sbuild/examples/sbuild-update-all
> >
> > That path doesn't exist anymore, as the script was renamed.. It would
> > be nice to complete the process and fix the example code as well...
> >
> > Ideally, this should be handled automatically by the package, which
> > could deploy a cronjob itself, which might be tweakable with (say)
> > /etc/default/sbuild or something...
> >
> > A.
>


-- 
Best regards,
Michael

Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing

[Michael Stapelberg]

On Thu, Feb 7, 2019 at 8:46 AM Scott Kitterman  wrote:

> No.  It's an actual policy violation, so the bug is correct.  I'd leave it
> as is and ask the release team to mark it buster-ignore.
>

Could you kindly point me to where the process is described for this? I’m
not sure what I’d need to do to get it marked buster-ignore. Thanks.


>
> Scott K
>
> On February 7, 2019 7:29:01 AM UTC, Michael Stapelberg <
> stapelb...@debian.org> wrote:
> >On Wed, Feb 6, 2019 at 11:01 PM Scott Kitterman 
> >wrote:
> >
> >> It's not the FTP Team's job to fix policy compliance issues in
> >packages.
> >> If you have a problem with that being a policy must, then you should
> >take
> >> it up with the policy team.
> >>
> >
> >Yeah, I’ll post to #911165
> >
> >
> >>
> >> I completely understand the frustration, but in my own packages I
> >take the
> >> time to do it because Debian policy says it's required, not because I
> >> particularly care about sysvinit.
> >>
> >
> >I don’t think fulfilling the policy for fulfilling the policy’s sake is
> >a
> >good use of anyone’s time.
> >
> >Can we close this bug until someone comes along who actually cares? :)
> >
> >
> >>
> >> Scott K
> >>
> >> On February 6, 2019 9:23:46 PM UTC, Michael Stapelberg <
> >> stapelb...@debian.org> wrote:
> >> >Can you provide a patch if you care about sysvinit please? The Go
> >> >packaging
> >> >team is pretty manpower-constrained and non-systemd is a niche case,
> >so
> >> >any
> >> >help is appreciated. Thanks!
> >> >
> >> >On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman
> >
> >> >wrote:
> >> >
> >> >> Package: prometheus-postfix-exporter
> >> >> Version: 0.1.2-1
> >> >> Severity: serious
> >> >> Justification: Policy 9.11
> >> >>
> >> >> Excerpt from policy 9.11:
> >> >>
> >> >> However, any package integrating with other init systems
> >> >> must also be backwards-compatible with sysvinit by providing a
> >SysV-
> >> >> style init script with the same name as and equivalent
> >functionality
> >> >> to any init-specific job, as this is the only start-up
> >configuration
> >> >> method guaranteed to be supported by all init implementations.
> >> >>
> >> >> The package violates a policy must by not providing s sysvint init
> >> >script.
> >> >>
> >> >> Scott K
> >> >>
> >> >> ___
> >> >> Pkg-go-maintainers mailing list
> >> >> pkg-go-maintain...@alioth-lists.debian.net
> >> >>
> >> >
> >>
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
> >>
>


-- 
Best regards,
Michael

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

[Michael Stapelberg]

Hi,

I have recently been made aware that this policy is still around when
someone filed a bug asking for a package to be made compliant. I had
assumed that the requirement would have been dropped by now, so let me
echo/add a few thoughts.

When I have previously voiced discontent about the work required to
support multiple architectures in Debian, porters have reassured me that
they would help with that. In the same spirit, I have effectively been
relying on contributions for sysvinit support in all of my packages.

It was almost 10 years ago (!) that I have first read about systemd. I
have been using systemd exclusively for many many years. My working
knowledge of sysvinit has degraded over the years, and I have no
motivation or time left to even test sysvinit support in any capacity.

At this point, there are many computer users who have not ever used
anything but systemd. I worry that _demanding_ (instead of encouraging)
sysvinit support via policy is too much effort for package maintainers,
for very little practical gain. I can say with certainty that my time is
better spent elsewhere, and I think many others feel the same way.

My personal suggestion is to change policy to require support for
Debian’s most relevant init system and architecture combination
(i.e. package maintainers should ensure systemd/amd64 works). Anything
beyond that should be encouraged, but kept optional, so as to unburden
the package maintainers.

-- 
Best regards,
Michael

Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing

[Michael Stapelberg]

On Wed, Feb 6, 2019 at 11:01 PM Scott Kitterman 
wrote:

> It's not the FTP Team's job to fix policy compliance issues in packages.
> If you have a problem with that being a policy must, then you should take
> it up with the policy team.
>

Yeah, I’ll post to #911165


>
> I completely understand the frustration, but in my own packages I take the
> time to do it because Debian policy says it's required, not because I
> particularly care about sysvinit.
>

I don’t think fulfilling the policy for fulfilling the policy’s sake is a
good use of anyone’s time.

Can we close this bug until someone comes along who actually cares? :)


>
> Scott K
>
> On February 6, 2019 9:23:46 PM UTC, Michael Stapelberg <
> stapelb...@debian.org> wrote:
> >Can you provide a patch if you care about sysvinit please? The Go
> >packaging
> >team is pretty manpower-constrained and non-systemd is a niche case, so
> >any
> >help is appreciated. Thanks!
> >
> >On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman 
> >wrote:
> >
> >> Package: prometheus-postfix-exporter
> >> Version: 0.1.2-1
> >> Severity: serious
> >> Justification: Policy 9.11
> >>
> >> Excerpt from policy 9.11:
> >>
> >> However, any package integrating with other init systems
> >> must also be backwards-compatible with sysvinit by providing a SysV-
> >> style init script with the same name as and equivalent functionality
> >> to any init-specific job, as this is the only start-up configuration
> >> method guaranteed to be supported by all init implementations.
> >>
> >> The package violates a policy must by not providing s sysvint init
> >script.
> >>
> >> Scott K
> >>
> >> ___
> >> Pkg-go-maintainers mailing list
> >> pkg-go-maintain...@alioth-lists.debian.net
> >>
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
>


-- 
Best regards,
Michael

Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing

[Michael Stapelberg]

Can you provide a patch if you care about sysvinit please? The Go packaging
team is pretty manpower-constrained and non-systemd is a niche case, so any
help is appreciated. Thanks!

On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman  wrote:

> Package: prometheus-postfix-exporter
> Version: 0.1.2-1
> Severity: serious
> Justification: Policy 9.11
>
> Excerpt from policy 9.11:
>
> However, any package integrating with other init systems
> must also be backwards-compatible with sysvinit by providing a SysV-
> style init script with the same name as and equivalent functionality
> to any init-specific job, as this is the only start-up configuration
> method guaranteed to be supported by all init implementations.
>
> The package violates a policy must by not providing s sysvint init script.
>
> Scott K
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
Best regards,
Michael

Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit

[Michael Stapelberg]

Great, thank you for taking care of this!

On Fri, Jan 25, 2019 at 2:32 PM Mariusz Gronczewski 
wrote:

> Okay, I will just poke the upstream about it, seems that CentOS/RHEL
> package have exactly same problem so no point changing it just for
> Debian.
>
>
> On Thu, 24 Jan 2019 at 18:27, Michael Stapelberg 
> wrote:
> >
> > Ah, why didn’t you open with that suggestion? :)
> >
> >
> https://manpages.debian.org/stretch/systemd/systemd.service.5.en.html#OPTIONS
> outlines that switching to Type=simple (which is the consequence of your -f
> suggestion) means we won’t have start-up failure propagation anymore, and
> reverse-dependencies of freeradius will not be able to reliably sequence
> themselves.
> >
> > Now, I’m not sure whether these downsides are actually relevant in
> practice, as I don’t know much about the larger freeradius ecosystem. Maybe
> there are no communication channels, and no reverse dependencies of note?
> I’m not sure.
> >
> > If you could confirm with upstream that they are blessing use of -f and
> Type=simple as the default in Debian, I can make the change.
> >
> > Thanks,
> >
> > On Thu, Jan 24, 2019 at 4:49 PM Mariusz Gronczewski 
> wrote:
> >>
> >> Well, there is, adding -f option by default means it will always run
> >> in foreground, regardless of whether -X is used or not
> >>
> >> On Thu, 24 Jan 2019 at 15:58, Michael Stapelberg 
> wrote:
> >> >
> >> > The -X option is special in that it changes the way freeradius starts
> up.
> >> >
> >> > It’s expected that if your actions break the contract with the init
> system (in this case by specifying -X), you’re responsible to rectify that.
> >> >
> >> > If there was a simple way to make the package work in any/all cases,
> it’d be up for it, but I’m not aware of one. Hence my question for what
> your suggestion is — I just don’t see a way out of this situation.
> >> >
> >> > My personal recommendation is to not use /etc/default, but rather
> systemctl edit to do any overrides, but that’s not Debian’s official line.
> >> >
> >> > On Thu, Jan 24, 2019 at 3:37 PM Mariusz Gronczewski <
> xani...@gmail.com> wrote:
> >> >>
> >> >> In our case it was enough to add dropin changing execstart to include
> >> >> -f and type to simple:
> >> >>
> >> >> ExecStart=/usr/sbin/freeradius -f $FREERADIUS_OPTIONS
> >> >> Type=simple
> >> >>
> >> >> What do you mean by "it is expected" ? Currently enabling debug (by
> >> >> setting FREERADIUS_OPTIONS="-X") cause it to enter restart loop,
> >> >> surely that isn't an expected behaviour ?
> >> >>
> >> >> On Thu, 24 Jan 2019 at 13:52, Michael Stapelberg <
> stapelb...@debian.org> wrote:
> >> >> >
> >> >> > Yes, this is expected. What change are you suggesting?
> >> >> >
> >> >> > On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski <
> xani...@gmail.com> wrote:
> >> >> >>
> >> >> >> Package: freeradius
> >> >> >> Version: 3.0.12+dfsg-5+deb9u1
> >> >> >> Severity: normal
> >> >> >>
> >> >> >> Currently the type of systemd service is forking.
> >> >> >>
> >> >> >> Adding debug to cmdline causes freeradius to run in foreground
> (and dump debug
> >> >> >> to stdout), which means systemd timeouts on starting service
> because it assumes
> >> >> >> it will fork.
> >> >> >>
> >> >> >> Changing type to simple, and adding -f (run in foreground) option
> in unit file
> >> >> >> fixes that
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Mariusz Gronczewski (XANi) 
> >> >> >> GnuPG: 0xEA8ACE64
> >> >> >>
> >> >> >> ___
> >> >> >> Pkg-freeradius-maintainers mailing list
> >> >> >> pkg-freeradius-maintain...@alioth-lists.debian.net
> >> >> >>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Best regards,
> >> >> > Michael
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Mariusz Gronczewski (XANi) 
> >> >> GnuPG: 0xEA8ACE64
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> > Michael
> >>
> >>
> >>
> >> --
> >> Mariusz Gronczewski (XANi) 
> >> GnuPG: 0xEA8ACE64
> >
> >
> >
> > --
> > Best regards,
> > Michael
>
>
>
> --
> Mariusz Gronczewski (XANi) 
> GnuPG: 0xEA8ACE64
>


-- 
Best regards,
Michael

Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit

[Michael Stapelberg]

Ah, why didn’t you open with that suggestion? :)

https://manpages.debian.org/stretch/systemd/systemd.service.5.en.html#OPTIONS
outlines that switching to Type=simple (which is the consequence of your -f
suggestion) means we won’t have start-up failure propagation anymore, and
reverse-dependencies of freeradius will not be able to reliably sequence
themselves.

Now, I’m not sure whether these downsides are actually relevant in
practice, as I don’t know much about the larger freeradius ecosystem. Maybe
there are no communication channels, and no reverse dependencies of note?
I’m not sure.

If you could confirm with upstream that they are blessing use of -f and
Type=simple as the default in Debian, I can make the change.

Thanks,

On Thu, Jan 24, 2019 at 4:49 PM Mariusz Gronczewski 
wrote:

> Well, there is, adding -f option by default means it will always run
> in foreground, regardless of whether -X is used or not
>
> On Thu, 24 Jan 2019 at 15:58, Michael Stapelberg 
> wrote:
> >
> > The -X option is special in that it changes the way freeradius starts up.
> >
> > It’s expected that if your actions break the contract with the init
> system (in this case by specifying -X), you’re responsible to rectify that.
> >
> > If there was a simple way to make the package work in any/all cases,
> it’d be up for it, but I’m not aware of one. Hence my question for what
> your suggestion is — I just don’t see a way out of this situation.
> >
> > My personal recommendation is to not use /etc/default, but rather
> systemctl edit to do any overrides, but that’s not Debian’s official line.
> >
> > On Thu, Jan 24, 2019 at 3:37 PM Mariusz Gronczewski 
> wrote:
> >>
> >> In our case it was enough to add dropin changing execstart to include
> >> -f and type to simple:
> >>
> >> ExecStart=/usr/sbin/freeradius -f $FREERADIUS_OPTIONS
> >> Type=simple
> >>
> >> What do you mean by "it is expected" ? Currently enabling debug (by
> >> setting FREERADIUS_OPTIONS="-X") cause it to enter restart loop,
> >> surely that isn't an expected behaviour ?
> >>
> >> On Thu, 24 Jan 2019 at 13:52, Michael Stapelberg 
> wrote:
> >> >
> >> > Yes, this is expected. What change are you suggesting?
> >> >
> >> > On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski <
> xani...@gmail.com> wrote:
> >> >>
> >> >> Package: freeradius
> >> >> Version: 3.0.12+dfsg-5+deb9u1
> >> >> Severity: normal
> >> >>
> >> >> Currently the type of systemd service is forking.
> >> >>
> >> >> Adding debug to cmdline causes freeradius to run in foreground (and
> dump debug
> >> >> to stdout), which means systemd timeouts on starting service because
> it assumes
> >> >> it will fork.
> >> >>
> >> >> Changing type to simple, and adding -f (run in foreground) option in
> unit file
> >> >> fixes that
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Mariusz Gronczewski (XANi) 
> >> >> GnuPG: 0xEA8ACE64
> >> >>
> >> >> ___
> >> >> Pkg-freeradius-maintainers mailing list
> >> >> pkg-freeradius-maintain...@alioth-lists.debian.net
> >> >>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> > Michael
> >>
> >>
> >>
> >> --
> >> Mariusz Gronczewski (XANi) 
> >> GnuPG: 0xEA8ACE64
> >
> >
> >
> > --
> > Best regards,
> > Michael
>
>
>
> --
> Mariusz Gronczewski (XANi) 
> GnuPG: 0xEA8ACE64
>


-- 
Best regards,
Michael

Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit

[Michael Stapelberg]

The -X option is special in that it changes the way freeradius starts up.

It’s expected that if your actions break the contract with the init system
(in this case by specifying -X), you’re responsible to rectify that.

If there was a simple way to make the package work in any/all cases, it’d
be up for it, but I’m not aware of one. Hence my question for what your
suggestion is — I just don’t see a way out of this situation.

My personal recommendation is to not use /etc/default, but rather systemctl
edit to do any overrides, but that’s not Debian’s official line.

On Thu, Jan 24, 2019 at 3:37 PM Mariusz Gronczewski 
wrote:

> In our case it was enough to add dropin changing execstart to include
> -f and type to simple:
>
> ExecStart=/usr/sbin/freeradius -f $FREERADIUS_OPTIONS
> Type=simple
>
> What do you mean by "it is expected" ? Currently enabling debug (by
> setting FREERADIUS_OPTIONS="-X") cause it to enter restart loop,
> surely that isn't an expected behaviour ?
>
> On Thu, 24 Jan 2019 at 13:52, Michael Stapelberg 
> wrote:
> >
> > Yes, this is expected. What change are you suggesting?
> >
> > On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski 
> wrote:
> >>
> >> Package: freeradius
> >> Version: 3.0.12+dfsg-5+deb9u1
> >> Severity: normal
> >>
> >> Currently the type of systemd service is forking.
> >>
> >> Adding debug to cmdline causes freeradius to run in foreground (and
> dump debug
> >> to stdout), which means systemd timeouts on starting service because it
> assumes
> >> it will fork.
> >>
> >> Changing type to simple, and adding -f (run in foreground) option in
> unit file
> >> fixes that
> >>
> >>
> >>
> >>
> >> --
> >> Mariusz Gronczewski (XANi) 
> >> GnuPG: 0xEA8ACE64
> >>
> >> ___
> >> Pkg-freeradius-maintainers mailing list
> >> pkg-freeradius-maintain...@alioth-lists.debian.net
> >>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
> >
> >
> >
> > --
> > Best regards,
> > Michael
>
>
>
> --
> Mariusz Gronczewski (XANi) 
> GnuPG: 0xEA8ACE64
>


-- 
Best regards,
Michael

Bug#916642: golang CVE-2019-6486 (DoS in crypto/elliptic)

[Michael Stapelberg]

Thanks for the list. Do you mind sharing how you generated it?

On Thu, Jan 24, 2019 at 3:00 PM Dr. Tobias Quathamer 
wrote:

> Am 24.01.2019 um 09:12 schrieb Emilio Pozuelo Monfort:
> > On 24/01/2019 08:58, Michael Stapelberg wrote:
> >> Last time, pochu@ (cc'ed) helpfully scheduled binNMUs. pochu, would
> you be
> >> able to help this time, too?
> >
> > Sure. Can you give me a list of source packages to binNMU in unstable?
> If this
> > is public already, can you do that through a binNMU bug against
> release.debian.org?
> >
> > Emilio
>
> Hi all,
>
> there is already an outdated binNMU list as bug report available, so
> I'm reusing that report. Please ignore the previously attached
> binNMU list of that bug report.
>
> This should be a complete and current list of needed binNMUs:
>
>
>   nmu abci_0.0~git20170124.0.f94ae5e-2 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu acbuild_0.4.0+dfsg-3 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu acmetool_0.0.62-3 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu aptly_1.3.0+ds1-2 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu aptly-api_1.3.0+ds1-2 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu arduino-builder_1.3.25-1 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu autodeb-server_0.20.0-1 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu autodeb-worker_0.20.0-1 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu balboa_1.0-3 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu webext-browserpass_2.0.22-1 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu burrow_1.1.0-1 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu cadvisor_0.27.1+dfsg2-4 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu canid_0.0~git20180613.007c9af-2 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu certspotter_0.9-2 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu chasquid_0.06-1 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu codesearch_0.0~hg20120502-3 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu consul_1.0.7~dfsg1-5 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu consulfs_0.2-1 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu continuity_0.0~git20180216.d8fb858-1 . ANY . -m 'Rebuild with
> current golang-1.11 (CVE-2019-6486)'
>   nmu coyim_0.3.8+ds-6 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu debiman_0.0~git20180905.9955035-1 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu debos_1.0.0+git20181105.b02e058-1 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu dh-make-golang_0.0~git20180827.d94f0cb-1 . ANY . -m 'Rebuild with
> current golang-1.11 (CVE-2019-6486)'
>   nmu dnss_0.0~git20180721.0.2de63ab0-1 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu docker-registry_2.6.2~ds1-2 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu elvish_0.12+ds1-1 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu etcd-client_3.2.18+dfsg-1 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu etcd-server_3.2.18+dfsg-1 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu etcd-fs_0.0+git20140621.0.395eacb-4 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu ethflux_1.0-3 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu fdroidcl_0.4.0-1 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu fscrypt_0.2.4-2 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu libpam-fscrypt_0.2.4-2 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu git-sizer_1.2.0+dfsg-1 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu gitaly_0.129.0+debian-3 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu gitlab-runner_11.2.0+dfsg-2 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu gitlab-workhorse_7.6.0+debian-1 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu go-cve-dictionary_0.3.1-1 . ANY . -m 'Rebuild with current
> golang-1.11 (CVE-2019-6486)'
>   nmu go-dep_0.5.0-1 . ANY . -m 'Rebuild with current golang-1.11
> (CVE-2019-6486)'
>   nmu go-exploitdb_0.0~git20181130.7c961e7-1 . ANY . -m 'Rebuild with
> current golang-1.11 (CVE-2019-648

Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit

[Michael Stapelberg]

Yes, this is expected. What change are you suggesting?

On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski 
wrote:

> Package: freeradius
> Version: 3.0.12+dfsg-5+deb9u1
> Severity: normal
>
> Currently the type of systemd service is forking.
>
> Adding debug to cmdline causes freeradius to run in foreground (and dump
> debug
> to stdout), which means systemd timeouts on starting service because it
> assumes
> it will fork.
>
> Changing type to simple, and adding -f (run in foreground) option in unit
> file
> fixes that
>
>
>
>
> --
> Mariusz Gronczewski (XANi) 
> GnuPG: 0xEA8ACE64
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>


-- 
Best regards,
Michael

Bug#918925: i3: Status and title bar text do not appear with default config file

[Michael Stapelberg]

[+cc pkg-raspi-maintainers, in case someone has seen this issue or a
similar issue before]

I can reproduce the problem on a Raspberry Pi 3B.

Interestingly enough, running i3 in xserver-xephyr on that machine makes it
display correctly, so the issue is not (just) a missing dependency.

My guess is that there is some issue related to the graphics driver.
Unfortunately, I can’t seem to use the “vesa” driver; Xorg finds no screens
when I try.

I haven’t yet figured out whether other programs are affected, too, or just
i3. I can say that awesome and geeqie seem to work.

On Fri, Jan 18, 2019 at 8:21 PM Leo Singer  wrote:

> Package: i3
> Version: 4.16-1
> Followup-For: Bug #918925
>
> Actually, removing the 'pango:' string from the font option is just causing
> it to fall back to the fixed-width X core font.
>
> I tried using a handful of other fonts, such as:
>
> font pango:Bistream Vera Sans Mono 8
>
> And it turns out that the title and status bar text are missing for *any*
> pango
> font option.
>
> I looked through ~/.xsession-errors and I did not see any font-related
> errors.
>
> [libi3] ../../i3-wm-4.16/libi3/font.c Using Pango font monospace, size
> 8
> 01/18/19 14:13:30 - dpi.c:init_dpi:41 - Resource Xft.dpi not
> specified, skipping.
> 01/18/19 14:13:30 - dpi.c:init_dpi:64 - Using fallback for calculating
> DPI.
> 01/18/19 14:13:30 - dpi.c:init_dpi:66 - Using dpi = 96
> 01/18/19 14:13:30 - main.c:main:561 - root_depth = 32, visual_id =
> 0x0077.
> 01/18/19 14:13:30 - main.c:main:563 - root_screen->height_in_pixels =
> 1080, root_screen->height_in_millimeters = 285
> 01/18/19 14:13:30 - main.c:main:564 - One logical pixel corresponds to
> 1 physical pixels on this display.
>


-- 
Best regards,
Michael

Bug#919234: [Pkg-freeradius-maintainers] Bug#919234: ttls fails with tls 1.3, enabled by default

[Michael Stapelberg]

I have no time to look into this. Can you send a patch please?

On Sun, Jan 13, 2019 at 11:33 PM Sam Hartman  wrote:

> package: freeradius
> severity: important
> version: 3.0.17+dfsg-1
> justification: regression that totally breaks connectivity
> tags: upstream
>
>
> I've cc'd Kurt because he requested openssl 1.3 test results a while
> back.
>
> While writing automated tests for moonshot-gss-eap, I discovered that
> by default freeradius will not constrain  the version of TLS in use
> (probably good), but that its ttls implementation fails with TLS 1.3.
> Things work fine if I explicitly set the max TLS version to 1.2.
>
> Based on the errors I suspect that  the issue had to deal with the
> handling of the ttls TLS session ticket used by TTLS for fast
> reauthentication.
> My suspicion (and recollection from the spec) is that ttls knows more
> about session internals than it should.
>
> As a quick fix, I think the ttls code should limit the maximum TLS
> version to 1.2 until the code can be fixed to work with 1.3.
>
>
> Please do not limit all freeradius uses of TLS to 1.2: in particular I'd
> really like to be able to use tls 1.3 with radsec.
> Also, I strongly recommend making this change in code not in config
> files.  People tend not to update their configs once they get one
> working.
>
> To reproduce, grab the moonshot-gss-eap sources.
> Comment out the TLS_MAX_VERSION on line 366 of
> debian/tests/freeradius/eap and then rerun autopkgtest on the resulting
> source package.
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>


-- 
Best regards,
Michael

Bug#919236: [Pkg-freeradius-maintainers] Bug#919236: Inappropriately broad default CA for EAP configuration

[Michael Stapelberg]

Can you send a patch please? It’s been like that since before I touched the
package.

On Sun, Jan 13, 2019 at 11:39 PM Sam Hartman  wrote:

> package: freeradius
> tags: security
> version: 3.0.17+dfsg-1
> severity: important
> justification: Inappropriately broad default authorization
>
> The debian freeradius package changes the default eap configuration to
> use the default list of Debian certification authorities as the default
> CAs for verifying client certificates for incoming EAP connections.
>
> The package leaves the following notice in
> /etc/freeradius/3.0/mods-available/eap:
>
> #  See also:
> #
> #  http://www.dslreports.com/forum/remark,9286052~mode=flat
> #
> #  Note that you should NOT use a globally known CA here!
> #  e.g. using a Verisign cert as a "known CA" means that
> #  ANYONE who has a certificate signed by them can
>
> And then proceeds to do something even worse: it sets the default CA to
> the entire list of Debian trusted CAs.
>
> As discussed by the freeradius docs, you want the default for EAP
> certificates to be an organization-specific CA.
>
> --Sam
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>


-- 
Best regards,
Michael

Bug#918925: i3: Status and title bar text do not appear with default config file

[Michael Stapelberg]

Then use whichever tool has a font selection dialog :)

On Fri, Jan 11, 2019 at 5:18 PM Leo Pound Singer  wrote:

> gnome-specimen is not in buster. It has been removed from Debian.
>
>
>
> Sent from my iPhone
> On Jan 10, 2019, at 16:46, Michael Stapelberg 
> wrote:
>
> That’s weird. Something must be different in your system, though, as this
> is the first time anyone has ever reported this issue.
>
> Can you check gnome-specimen and see if fonts show up correctly there? Can
> you try using them with i3 and see if that works in general?
>
> On Thu, Jan 10, 2019 at 7:41 PM Leo Pound Singer  wrote:
>
>> No, all of the packages recommended by i3-wm are installed.
>>
>> On Jan 10, 2019, at 12:25, Michael Stapelberg 
>> wrote:
>>
>> Did you disable apt recommendations? The i3-wm package
>> recommends fonts-dejavu-core, which should be picked up as a suitable font.
>> Do you have that package installed?
>>
>> On Thu, Jan 10, 2019 at 5:48 PM Leo Singer  wrote:
>>
>>> Package: i3
>>> Version: 4.16-1
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>>
>>> I installed i3 under Debian Buster (armhf) on a Raspberry Pi 3B+. With
>>> the
>>> automatically generated configuration file, the i3 title and status bars
>>> are
>>> blank.
>>>
>>> I found that I could get the title and status bar text to show up by
>>> employing
>>> the workaround of uncommenting the following font option in
>>> ~/.config/i3/config:
>>>
>>> font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
>>>
>>> I do not know if this issue also occurs on more commonplace amd64
>>> systems.
>>>
>>> Would you please modify the package so that the title and status bar
>>> text are
>>> visible with the default, automatically generated i3 config file?
>>>
>>> Regards,
>>> Leo
>>>
>>>
>>>
>>> -- System Information:
>>> Debian Release: buster/sid
>>>   APT prefers testing
>>>   APT policy: (500, 'testing')
>>> Architecture: armhf (armv7l)
>>>
>>> Kernel: Linux 4.19.0-1-armmp (SMP w/4 CPU cores)
>>> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C
>>> (charmap=UTF-8)
>>> Shell: /bin/sh linked to /usr/bin/dash
>>> Init: systemd (via /run/systemd/system)
>>> LSM: AppArmor: enabled
>>>
>>> Versions of packages i3 depends on:
>>> ii  i3-wm  4.16-1
>>>
>>> Versions of packages i3 recommends:
>>> ii  dunst   1.3.2-1
>>> ii  i3lock  2.11.1-1
>>> ii  i3status2.12-1
>>> ii  suckless-tools  44-1
>>>
>>> i3 suggests no packages.
>>>
>>> -- no debconf information
>>>
>>
>>
>> --
>> Best regards,
>> Michael
>>
>>
>
> --
> Best regards,
> Michael
>
>

-- 
Best regards,
Michael

Bug#918925: i3: Status and title bar text do not appear with default config file

[Michael Stapelberg]

That’s weird. Something must be different in your system, though, as this
is the first time anyone has ever reported this issue.

Can you check gnome-specimen and see if fonts show up correctly there? Can
you try using them with i3 and see if that works in general?

On Thu, Jan 10, 2019 at 7:41 PM Leo Pound Singer  wrote:

> No, all of the packages recommended by i3-wm are installed.
>
> On Jan 10, 2019, at 12:25, Michael Stapelberg 
> wrote:
>
> Did you disable apt recommendations? The i3-wm package
> recommends fonts-dejavu-core, which should be picked up as a suitable font.
> Do you have that package installed?
>
> On Thu, Jan 10, 2019 at 5:48 PM Leo Singer  wrote:
>
>> Package: i3
>> Version: 4.16-1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> I installed i3 under Debian Buster (armhf) on a Raspberry Pi 3B+. With the
>> automatically generated configuration file, the i3 title and status bars
>> are
>> blank.
>>
>> I found that I could get the title and status bar text to show up by
>> employing
>> the workaround of uncommenting the following font option in
>> ~/.config/i3/config:
>>
>> font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
>>
>> I do not know if this issue also occurs on more commonplace amd64 systems.
>>
>> Would you please modify the package so that the title and status bar text
>> are
>> visible with the default, automatically generated i3 config file?
>>
>> Regards,
>> Leo
>>
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers testing
>>   APT policy: (500, 'testing')
>> Architecture: armhf (armv7l)
>>
>> Kernel: Linux 4.19.0-1-armmp (SMP w/4 CPU cores)
>> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C
>> (charmap=UTF-8)
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages i3 depends on:
>> ii  i3-wm  4.16-1
>>
>> Versions of packages i3 recommends:
>> ii  dunst   1.3.2-1
>> ii  i3lock  2.11.1-1
>> ii  i3status2.12-1
>> ii  suckless-tools  44-1
>>
>> i3 suggests no packages.
>>
>> -- no debconf information
>>
>
>
> --
> Best regards,
> Michael
>
>

-- 
Best regards,
Michael

Bug#918925: i3: Status and title bar text do not appear with default config file

[Michael Stapelberg]

Did you disable apt recommendations? The i3-wm package
recommends fonts-dejavu-core, which should be picked up as a suitable font.
Do you have that package installed?

On Thu, Jan 10, 2019 at 5:48 PM Leo Singer  wrote:

> Package: i3
> Version: 4.16-1
> Severity: normal
>
> Dear Maintainer,
>
> I installed i3 under Debian Buster (armhf) on a Raspberry Pi 3B+. With the
> automatically generated configuration file, the i3 title and status bars
> are
> blank.
>
> I found that I could get the title and status bar text to show up by
> employing
> the workaround of uncommenting the following font option in
> ~/.config/i3/config:
>
> font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
>
> I do not know if this issue also occurs on more commonplace amd64 systems.
>
> Would you please modify the package so that the title and status bar text
> are
> visible with the default, automatically generated i3 config file?
>
> Regards,
> Leo
>
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: armhf (armv7l)
>
> Kernel: Linux 4.19.0-1-armmp (SMP w/4 CPU cores)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C
> (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages i3 depends on:
> ii  i3-wm  4.16-1
>
> Versions of packages i3 recommends:
> ii  dunst   1.3.2-1
> ii  i3lock  2.11.1-1
> ii  i3status2.12-1
> ii  suckless-tools  44-1
>
> i3 suggests no packages.
>
> -- no debconf information
>


-- 
Best regards,
Michael

Bug#918592: apt update incredibly slow due to writing lists files using zstd

[Michael Stapelberg]

Thanks for the quick reply.

On Mon, Jan 7, 2019 at 7:37 PM Julian Andres Klode  wrote:

> On Mon, Jan 07, 2019 at 06:40:02PM +0100, Michael Stapelberg wrote:
> > Package: apt
> > Version: 1.8.0~alpha3
> > Severity: normal
> >
> > For the past few weeks, I haven’t been able to update my Debian system. I
> > finally took some time to look into what’s going wrong.
>
> We'd have to figure out when this started, I guess.
>

Sorry, didn’t keep track of that.


>
> >
> > The symptom is that “apt update” just hung forever after fetching all
> files from
> > my configured mirrors.
> >
> > A closer look revealed 100% CPU usage of 1 core in the
> > /usr/lib/apt/methods/store process, which was writing to files in
> > /var/lib/apt/lists/partial.
> >
> > Attaching gdb revealed that store was spending its time in a zstd
> function:
> >
> > #0  0x7f376cc0bf78 in ?? () from
> /usr/lib/x86_64-linux-gnu/libzstd.so.1
> > #1  0x7f376cbcc275 in ?? () from
> /usr/lib/x86_64-linux-gnu/libzstd.so.1
> > #2  0x7f376cbcdedf in ?? () from
> /usr/lib/x86_64-linux-gnu/libzstd.so.1
> > #3  0x7f376cbce461 in ZSTD_compressContinue () from
> /usr/lib/x86_64-linux-gnu/libzstd.so.1
> > #4  0x7f376cbcfe9e in ?? () from
> /usr/lib/x86_64-linux-gnu/libzstd.so.1
> > #5  0x7f376d9874af in ?? () from
> /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
> > #6  0x7f376d97ffd1 in FileFd::Write(void const*, unsigned long long)
> () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
> > #7  0x55afaedf1073 in StoreMethod::Fetch(pkgAcqMethod::FetchItem*)
> () at include/apt-pkg/fileutl.h:168
> > #8  0x7f376d939f83 in pkgAcqMethod::Run(bool) () from
> /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
> > #9  0x55afaedf0759 in main () at
> /usr/include/c++/8/bits/basic_string.h:252
> > #10 0x7f376d32e09b in __libc_start_main (main=0x55afaedf06e0 ,
> argc=1, argv=0x7ffe0782f238, init=, fini=,
> rtld_fini=, stack_end=0x7ffe0782f228) at
> ../csu/libc-start.c:308
> > #11 0x55afaedf083a in _start () at ../methods/store.cc:147
> >
> > Sure enough, raising the cost of the zstd compression in my apt config
> fixed the
> > issue:
> >
> > % cat /etc/apt/apt.conf.d/99disable-zstd
> > APT::Compressor::zstd::Cost "999";
> >
> > I have a few remarks:
> >
> > 1. Why are the lists re-compressed at all?
> >(Also note that I set Acquire::GzipIndexes "yes", so I have already
> signaled
> > that I would prefer to accept the lists as they are.)
>
> No. You have indicated that you want them stored compressed. Which picks
> the
> cheapest compressor, that's usually lz4.
>

Ugh. Is there a way to tell apt to not bother re-compressing files ever?


>
> Yes, it used to mean to not uncompress files and take them directly, but
> that
> changed a few years ago, in 1.2 or so, as lz4 basically has not much
> overhead,
> so it's much faster than keeping xz indexes around.
>
> >
> > 2. Why is store only using 1 of 16 CPU cores for compression?
>
> store is using 1 process per file (up to a limit that's a multiple of your
> cores), parallel compression of single files is meh.
>

That’s not what I’m observing. For me, precisely 1 store process is
running, and it seems to be handling all files sequentially.


>
> >
> > 3. Should we disable zstd for the time being, given that it turns a
> 1-minute apt
> >update into a many-minute apt update, to the point where I had
> assumed it was
> >hanging?
>
> It's not used by default. It's unclear to me why this happens to you. Do
> you have
> another config file which sets a lower zstd cost perhaps?
>

No, it doesn’t look like it:
% grep -ri zst /etc/apt
/etc/apt/apt.conf.d/99disable-zstd:APT::Compressor::zstd::Cost "999";
%


>
>
>
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en
>


-- 
Best regards,
Michael

Bug#918592: apt update incredibly slow due to writing lists files using zstd

[Michael Stapelberg]

Package: apt
Version: 1.8.0~alpha3
Severity: normal

For the past few weeks, I haven’t been able to update my Debian system. I
finally took some time to look into what’s going wrong.

The symptom is that “apt update” just hung forever after fetching all files from
my configured mirrors.

A closer look revealed 100% CPU usage of 1 core in the
/usr/lib/apt/methods/store process, which was writing to files in
/var/lib/apt/lists/partial.

Attaching gdb revealed that store was spending its time in a zstd function:

#0  0x7f376cc0bf78 in ?? () from /usr/lib/x86_64-linux-gnu/libzstd.so.1
#1  0x7f376cbcc275 in ?? () from /usr/lib/x86_64-linux-gnu/libzstd.so.1
#2  0x7f376cbcdedf in ?? () from /usr/lib/x86_64-linux-gnu/libzstd.so.1
#3  0x7f376cbce461 in ZSTD_compressContinue () from 
/usr/lib/x86_64-linux-gnu/libzstd.so.1
#4  0x7f376cbcfe9e in ?? () from /usr/lib/x86_64-linux-gnu/libzstd.so.1
#5  0x7f376d9874af in ?? () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#6  0x7f376d97ffd1 in FileFd::Write(void const*, unsigned long long) () 
from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#7  0x55afaedf1073 in StoreMethod::Fetch(pkgAcqMethod::FetchItem*) () at 
include/apt-pkg/fileutl.h:168
#8  0x7f376d939f83 in pkgAcqMethod::Run(bool) () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#9  0x55afaedf0759 in main () at /usr/include/c++/8/bits/basic_string.h:252
#10 0x7f376d32e09b in __libc_start_main (main=0x55afaedf06e0 , 
argc=1, argv=0x7ffe0782f238, init=, fini=, 
rtld_fini=, stack_end=0x7ffe0782f228) at ../csu/libc-start.c:308
#11 0x55afaedf083a in _start () at ../methods/store.cc:147

Sure enough, raising the cost of the zstd compression in my apt config fixed the
issue:

% cat /etc/apt/apt.conf.d/99disable-zstd 
APT::Compressor::zstd::Cost "999";

I have a few remarks:

1. Why are the lists re-compressed at all?
   (Also note that I set Acquire::GzipIndexes "yes", so I have already signaled
that I would prefer to accept the lists as they are.)

2. Why is store only using 1 of 16 CPU cores for compression?

3. Should we disable zstd for the time being, given that it turns a 1-minute apt
   update into a many-minute apt update, to the point where I had assumed it was
   hanging?

Thanks,

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "false";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.14\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.18\.0-2-amd64$";
APT::NeverAutoRemove:: "^postgresql-";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: 

Bug#918327: ERROR #80 extracting when an ISO file contains non-english characters.

[Michael Stapelberg]

Can you report this upstream please? This is not Debian-related.

On Sat, Jan 5, 2019 at 7:15 AM Gong S.  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Package: wit
> Version: 3.01a-2
>
> It looks like that "wit" expects that everything is in English, and
> crashed when dealing with files that contain non-english entries.
> ===BEGIN OUTPUT===
> pthfdr:/r/m/s/W/q>wit copy --fst test.iso Popn\ Music_\[R83EA4].wbfs/
> *  wit: Wiimms ISO Tool v3.01a r0 x86_64 - Dirk Clemens - 2018-10-25
> *
> wit: EXTRACT 1/1 ISO:test.iso -> Popn Music_[R83EA4].wbfs/
> !! wit: ERROR #80 [CAN'T CREATE FILE] in CreateFileFST() @
> src/iso-interface.c#2987
> !!  Can't create temp file: Popn
> Music_[R83EA4].wbfs/./files/g3ddemo/3ddemo/CutieLiveHouse/nw4reffect/t@C
> ¼Íeffect_liveŨ袵ܷB
> !! wit: ERROR #80 [CAN'T CREATE FILE] in CreateFileFST() @
> src/iso-interface.c#2987
> !!  Can't create temp file: Popn
> Music_[R83EA4].wbfs/./files/g3ddemo/3ddemo/SpecialDJClub/nw4reffect/t@C
> ¼Íeffect_djŨ袵ܷB
> !! wit: ERROR #80 [CAN'T CREATE FILE] in CreateFileFST() @
> src/iso-interface.c#2987
> !!  Can't create temp file: Popn
> Music_[R83EA4].wbfs/./files/g3ddemo/3ddemo/SweetsStage/nw4reffect/t@C
> ¼Íeffect_sweetsŨ袵ܷB
> !! wit: ERROR #80 [CAN'T CREATE FILE] in ExtractImage() @ src/lib-sf.c#3408
> !!  3 files and/or directories not created.
> ===END OUTPUT===
> --
> "And in the naked light, I saw ten thousand people, maybe more. People \
> talking without speaking, people hearing without listening. People writ\
> ing songs that voices never shared, no one dared disturb the sound of s\
> ilence." --MA Bo'yong
> -BEGIN PGP SIGNATURE-
> Version: ProtonMail
> Comment: https://protonmail.com
>
> wsBcBAEBCAAGBQJcMErkAAoJENi1YDlFXXQfVpkIAJgJJz4Bcv0UiVYsOqq2
> V4z7UkwCCFcsRc9ljEY/jaft8WdxIW4I0Zd38C4O3+By4zqZcWLXMjcmgSbG
> QSnpNRIR2negr6X0y03klDsyVW9wC9kVXtS5107g8+LfEtVimcryH5G6CGer
> jXjHc+ZdAxiWXMgALoAODc/XwVCGqOUPUHAXOEspJLhpjHsXEXCRYtUn9Tgp
> tzRQbrfVfJ5ArQ3KbQoX+pP8mbOU8H3VoC2EHvGsc4lTN8ifDTOrlIqVENLM
> tB87vjyZV0k+KhgpPjIEcV04uYPCLK4tKNWtpcA3twbKhDQlKOwktjiKHaJ/
> GrxpOc49I2Q4ymJh3wnd43k=
> =UPdi
> -END PGP SIGNATURE-
>
>

-- 
Best regards,
Michael

Bug#908204: git-buildpackage: cannot use gbp push without tagging a release

[Michael Stapelberg]

Hi,

Yves-Alexis Perez  writes:
> I started using gbp push/pull recently and I'm also surprised by the current
> behavior. What is the rationale for *not* pushing the Debian branch as part of
> the push?
>
> For me, gbp push semantics are: “just push everything needed”, but it's
> obviously not the intended behavior. What is the intended behavior then?

+1.

For Go packaging, our tooling recommends users use “gbp push” to
transfer their local repository state to salsa. The fact that this now
only works after you tag a release trips people up:
https://github.com/Debian/dh-make-golang/issues/107

Any chance we could get the new behavior hidden behind a flag, or at
least get a flag to restore the old behavior?

Thank you,

-- 
Best regards,
Michael

Bug#911180: [Pkg-freeradius-maintainers] Bug#911180: Bug#911180: freeradius: freeradius refuses to start - missing libs

[Michael Stapelberg]

Dimitri, friendly ping? Would you prefer if I took care of this? If I don’t
hear back from you over the next week, I’ll go ahead :).

(An affected user just asked me in person about the status of this issue.)

On Tue, Nov 6, 2018 at 4:51 PM Michael Stapelberg 
wrote:

> Thanks for the reminder. It’s hard to keep track of everything that’s
> going on.
>
> The lintian tag description states:
>
> > The only time a binary or shared library in a Debian package should set
> RPATH or RUNPATH is if it is linked to private shared libraries in the same
> package. In that case, place those private shared libraries in
> /usr/lib/package. Libraries used by binaries in other packages should be
> placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which
> case RPATH/RUNPATH is unnecessary.
>
> It seems like this is exactly what’s happening here?
>
> Can we try removing the rpath from where it can be removed, and overriding
> the lintian tag for the legitimate cases?
>
> I’d prefer to not open libraries to the public unless coordinated with
> upstream, as they need to be aware of the stability guarantees (e.g. when
> to bump the SONAME).
>
> Thanks!
>
> On Tue, Nov 6, 2018 at 4:27 PM Dimitri John Ledkov 
> wrote:
>
>> Hey,
>>
>> On Mon, 5 Nov 2018 at 21:07, Michael Stapelberg 
>> wrote:
>> >
>> > I still don’t quite understand why you stripped the rpaths to begin
>> with. Can you explain? I think that’d be good to understand before making a
>> decision :)
>> >
>>
>> Please recall that when you last tried to upload freeradius it got
>> autorejected by ftp masters due to rpath email from 2nd of June
>> from you to me
>>
>> """
>> freeradius-postgresql: lintian output: 'binary-or-shlib-defines-rpath
>> usr/lib/freeradius/rlm_sql_postgresql.so /usr/lib/x86_64-linux-gnu',
>> automatically rejected package.
>> freeradius-postgresql: If you have a good reason, you may override
>> this lintian tag.
>> freeradius-iodbc: lintian output: 'binary-or-shlib-defines-rpath
>> usr/lib/freeradius/rlm_sql_iodbc.so /usr/lib', automatically rejected
>> package.
>> freeradius-iodbc: If you have a good reason, you may override this
>> lintian tag.
>> freeradius-python2: lintian output: 'binary-or-shlib-defines-rpath
>> usr/lib/freeradius/rlm_python.so /usr/lib/python2.7/config',
>> automatically rejected package.
>> freeradius-python2: If you have a good reason, you may override this
>> lintian tag.
>> """
>>
>> And spot checking this revealed that rpath is redundant for most of
>> the modules shipped - hence i stripped rpath from them all.
>> However, clearly that was false for all of them as some of them do use
>> private lib as now analyzed.
>>
>> My preference is to not have rpath set on any of these, and simply
>> expose libfreeradius-dhcp.so and libfreeradius-eap.so as public
>> libraries.
>>
>> Also i'm pondering how come freeradius does not set ldpath when trying
>> to dlopen the plugins from the plugin dir cause that would also
>> work without rpath set on every plugin.
>>
>> Regards,
>>
>> Dimitri.
>>
>>
>>
>> > On Mon, Nov 5, 2018 at 9:06 PM Dimitri John Ledkov 
>> wrote:
>> >>
>> >> Hello,
>> >>
>> >> On Mon, 5 Nov 2018 at 18:19, Michael Stapelberg 
>> wrote:
>> >> >
>> >> > Sorry, didn’t see the merge request. I fixed my notification
>> settings, merged the MR, and gave you permission to the repository.
>> >> >
>> >>
>> >> No worries. I myself only starting to figure out how to correctly use
>> >> salsa. It is quite new in how everything works.
>> >>
>> >> So about the bug, here is the full scope of affected files:
>> >>
>> >> /usr/lib/freeradius# readelf -d *.so | grep -e '\[libfreeradius' -e
>> File:
>> >> File: libfreeradius-dhcp.so
>> >> File: libfreeradius-eap.so
>> >> File: libfreeradius-radius.so
>> >> File: libfreeradius-server.so
>> >> File: proto_dhcp.so
>> >>  0x0001 (NEEDED) Shared library:
>> [libfreeradius-dhcp.so]
>> >> File: proto_vmps.so
>> >> File: rlm_always.so
>> >> File: rlm_attr_filter.so
>> >> File: rlm_cache.so
>> >> File: rlm_cache_memcached.so
>> >> File: rlm_cache_rbtree.so
>> >> File: rlm_chap.so
>> >> File: rlm_counter.so
>> >> File: rlm

Bug#913935: mxallowd: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Michael Stapelberg]

Thanks for your contribution.

However, after taking a closer look at mxallowd’s situation, I have decided
to file a request for removal instead of sinking more work into the
package. Please see https://bugs.debian.org/913966
 for the rationale.

Thanks for understanding,

On Sat, Nov 17, 2018 at 10:36 AM Adriano Rafael Gomes 
wrote:

> Package: mxallowd
> Tags: l10n patch
> Severity: wishlist
>
> Hello,
>
> Please, Could you update the Brazilian Portuguese Translation?
>
> Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
> tested with msgfmt and podebconf-display-po.
>
> Kind regards.
>


-- 
Best regards,
Michael

Bug#913966: RM: mxallowd -- ROM; unmaintained upstream, unused

[Michael Stapelberg]

Package: ftp.debian.org
Severity: normal

The upstream (me) stopped using/maintaining mxallowd many years ago. Given that
the package’s presence causes people work (e.g. https://bugs.debian.org/913935),
yet nobody actually uses the package (it has 1 installation in popcon, and I
doubt it’s actively used even on that one machine). I think it is time to remove
the package for good.

Bug#913905: i3-wm: focus sometimes stucks on the previous window

[Michael Stapelberg]

Hey, thanks for your report. This does not seem like a Debian-specific
issue. Could you please open an issue at https://github.com/i3/i3?

On Fri, Nov 16, 2018 at 6:39 PM Nicolas Évrard  wrote:

> Package: i3-wm
> Version: 4.16-1
> Severity: normal
>
> Dear Maintainer,
>
> This is a quite difficult bug to trigger but it happens at least on
> time per hour since the update to i3 version 4.16
>
> The symptom is pretty easy to describe: when switching from one window
> to another (either by calling a window from the scratchpad or by using
> "focus left/right") the focus stays on the previous window yet the
> window I expected to receive the focus appears (in case it's coming
> from the scratchpad) and is decorated just like a focused window.
>
> I have tried numerous way to reproduce this bug but I failed to find a
> pattern. I am sorry about that as I know that such an erratic bug can
> be a PITA without a reproducible scenario.
>
> But since it's pretty annoying I though I would report it anyway.
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages i3-wm depends on:
> ii  libc6 2.27-8
> ii  libcairo2 1.16.0-1
> ii  libev41:4.22-1+b1
> ii  libglib2.0-0  2.58.1-2
> ii  libpango-1.0-01.42.4-3
> ii  libpangocairo-1.0-0   1.42.4-3
> ii  libpcre3  2:8.39-11
> ii  libstartup-notification0  0.12-5
> ii  libxcb-cursor00.1.1-4
> ii  libxcb-icccm4 0.4.1-1+b1
> ii  libxcb-keysyms1   0.4.0-1+b2
> ii  libxcb-randr0 1.13.1-1
> ii  libxcb-util0  0.3.8-3+b2
> ii  libxcb-xinerama0  1.13.1-1
> ii  libxcb-xkb1   1.13.1-1
> ii  libxcb-xrm0   1.0-3
> ii  libxcb1   1.13.1-1
> ii  libxkbcommon-x11-00.8.2-1
> ii  libxkbcommon0 0.8.2-1
> ii  libyajl2  2.1.0-3
> ii  perl  5.28.0-3
>
> Versions of packages i3-wm recommends:
> ii  fonts-dejavu-core   2.37-1
> ii  libanyevent-i3-perl 0.17-1
> ii  libjson-xs-perl 3.040-1+b1
> ii  rxvt-unicode [x-terminal-emulator]  9.22-4+b1
> ii  xfonts-base 1:1.0.4+nmu1
>
> i3-wm suggests no packages.
>
> -- no debconf information
>


-- 
Best regards,
Michael

Bug#913409: libasound2: plugging in RME ADI2-DAC causes pulseaudio to crash in libasound2

[Michael Stapelberg]

The steps I used to verify the patch were:

% wget '
http://git.alsa-project.org/?p=alsa-plugins.git;a=patch;h=a4e7e1282c57a2f4e83afe9a4008042d8b4c5bb9'
-O /tmp/alsa.patch
% pk4 libasound2-plugins
% patch -p1 < /tmp/alsa.patch
% pk4-replace

On Sat, Nov 10, 2018 at 11:51 PM Florin Iucha  wrote:

> Elimar,
>
>
> Seems to be a duplicate. I noticed that Michael was able to test the patch
> from alsa (git). I tried to build pulseaudio and alsa from source to debug
> the issue, but I'm getting to
>
>
> libtool: link: gcc -shared  -fPIC -DPIC
> modules/alsa/.libs/libalsa_util_la-alsa-util.o
> modules/alsa/.libs/libalsa_util_la-alsa-ucm.o modules/alsa/.libs/libals
> a_util_la-alsa-mixer.o modules/alsa/.libs/libalsa_util_la-alsa-sink.o
> modules/alsa/.libs/libalsa_util_la-alsa-source.o
> modules/.libs/libalsa_util_la-reserve-wr
> ap.o modules/.libs/libalsa_util_la-udev-util.o
> modules/.libs/libalsa_util_la-reserve.o
> modules/.libs/libalsa_util_la-reserve-monitor.o  -Wl,--whole-archive /ho
> me/florin/tools/alsa-lib/src/mixer//.libs/libmixer.a
> /home/florin/tools/alsa-lib/src/control//.libs/libcontrol.a
> -Wl,--no-whole-archive  -Wl,-rpath -Wl,/home/f
> lorin/tools/pulseaudio/src/.libs -Wl,-rpath -Wl,/usr/local/lib/pulseaudio
> ./.libs/libpulsecore-12.2.so ./.libs/libpulsecommon-12.2.so
> ./.libs/libpulse.so -L/ho
> me/florin/tools/alsa-lib/src/ -L/home/florin/tools/alsa-lib/src/mixer/
> -L/home/florin/tools/alsa-lib/src/control/ -ludev -ldbus-1 -lcap -lpthread
> -lrt -ldl -lm
>   -g -O2   -Wl,-soname -Wl,libalsa-util.so -o .libs/libalsa-util.so
> /usr/bin/ld: .libs/libalsa-util.so: version node not found for symbol
> snd_ctl_elem_info_get_dimension@@ALSA_0.9.3
>
>
> How can I test the patch? Do I need to try and re-build the package? Can I
> build alsa and pulseaudio just in some normal directories and try it that
> way?
>
>
> Thank you,
>
> florin
>
>
> On 11/10/18 2:01 PM, Elimar Riesebieter wrote:
>
> Control: reassign -1 libasound2-plugins 1.1.7-2
> Control: forcemerge 912921 -1
>
> * Florin Iucha   [2018-11-10 12:12 -0500]:
>
>
> Package: libasound2
> Version: 1.1.7-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
>* What led up to the situation?
>
>Purchased a new USB DAC. It worked fine last night, then this morning
>it is crashing pulseaudio every time it is attached / turned on.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
>Plug the USB DAC.
>
>* What was the outcome of this action?
>
>Nov 10 12:03:07 herakles kernel: do_general_protection: 10 callbacks 
> suppressed
>Nov 10 12:03:07 herakles kernel: traps: pulseaudio[6311] general 
> protection ip:7f8f3e557532 sp:7fff1aa8bb20 error:0 in 
> libasound.so.2.0.0[7f8f3e51e000+8f000]
>
>* What outcome did you expect instead?
>
>Music coming out from the headphones.
>
>
> Please check https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912921
>
>
> Elimar
>
>

-- 
Best regards,
Michael

Bug#912921: libasound2-plugins: Crashes pulseaudio

[Michael Stapelberg]

Hi Elimar,

Elimar Riesebieter  writes:
> There is a similar bug in https://bugs.archlinux.org/task/60616.
> Upstream has a patch at 
> http://git.alsa-project.org/?p=alsa-plugins.git;a=commit;h=a4e7e1282c57a2f4e83afe9a4008042d8b4c5bb9
> which I can't test because here is no a52 device available..

I just ran into the same issue and can confirm that the patch fixes the
issue for me.

-- 
Best regards,
Michael

Bug#911180: [Pkg-freeradius-maintainers] Bug#911180: freeradius: freeradius refuses to start - missing libs

[Michael Stapelberg]

Thanks for the reminder. It’s hard to keep track of everything that’s going
on.

The lintian tag description states:

> The only time a binary or shared library in a Debian package should set
RPATH or RUNPATH is if it is linked to private shared libraries in the same
package. In that case, place those private shared libraries in
/usr/lib/package. Libraries used by binaries in other packages should be
placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which
case RPATH/RUNPATH is unnecessary.

It seems like this is exactly what’s happening here?

Can we try removing the rpath from where it can be removed, and overriding
the lintian tag for the legitimate cases?

I’d prefer to not open libraries to the public unless coordinated with
upstream, as they need to be aware of the stability guarantees (e.g. when
to bump the SONAME).

Thanks!

On Tue, Nov 6, 2018 at 4:27 PM Dimitri John Ledkov  wrote:

> Hey,
>
> On Mon, 5 Nov 2018 at 21:07, Michael Stapelberg 
> wrote:
> >
> > I still don’t quite understand why you stripped the rpaths to begin
> with. Can you explain? I think that’d be good to understand before making a
> decision :)
> >
>
> Please recall that when you last tried to upload freeradius it got
> autorejected by ftp masters due to rpath email from 2nd of June
> from you to me
>
> """
> freeradius-postgresql: lintian output: 'binary-or-shlib-defines-rpath
> usr/lib/freeradius/rlm_sql_postgresql.so /usr/lib/x86_64-linux-gnu',
> automatically rejected package.
> freeradius-postgresql: If you have a good reason, you may override
> this lintian tag.
> freeradius-iodbc: lintian output: 'binary-or-shlib-defines-rpath
> usr/lib/freeradius/rlm_sql_iodbc.so /usr/lib', automatically rejected
> package.
> freeradius-iodbc: If you have a good reason, you may override this lintian
> tag.
> freeradius-python2: lintian output: 'binary-or-shlib-defines-rpath
> usr/lib/freeradius/rlm_python.so /usr/lib/python2.7/config',
> automatically rejected package.
> freeradius-python2: If you have a good reason, you may override this
> lintian tag.
> """
>
> And spot checking this revealed that rpath is redundant for most of
> the modules shipped - hence i stripped rpath from them all.
> However, clearly that was false for all of them as some of them do use
> private lib as now analyzed.
>
> My preference is to not have rpath set on any of these, and simply
> expose libfreeradius-dhcp.so and libfreeradius-eap.so as public
> libraries.
>
> Also i'm pondering how come freeradius does not set ldpath when trying
> to dlopen the plugins from the plugin dir cause that would also
> work without rpath set on every plugin.
>
> Regards,
>
> Dimitri.
>
>
>
> > On Mon, Nov 5, 2018 at 9:06 PM Dimitri John Ledkov 
> wrote:
> >>
> >> Hello,
> >>
> >> On Mon, 5 Nov 2018 at 18:19, Michael Stapelberg 
> wrote:
> >> >
> >> > Sorry, didn’t see the merge request. I fixed my notification
> settings, merged the MR, and gave you permission to the repository.
> >> >
> >>
> >> No worries. I myself only starting to figure out how to correctly use
> >> salsa. It is quite new in how everything works.
> >>
> >> So about the bug, here is the full scope of affected files:
> >>
> >> /usr/lib/freeradius# readelf -d *.so | grep -e '\[libfreeradius' -e
> File:
> >> File: libfreeradius-dhcp.so
> >> File: libfreeradius-eap.so
> >> File: libfreeradius-radius.so
> >> File: libfreeradius-server.so
> >> File: proto_dhcp.so
> >>  0x0001 (NEEDED) Shared library:
> [libfreeradius-dhcp.so]
> >> File: proto_vmps.so
> >> File: rlm_always.so
> >> File: rlm_attr_filter.so
> >> File: rlm_cache.so
> >> File: rlm_cache_memcached.so
> >> File: rlm_cache_rbtree.so
> >> File: rlm_chap.so
> >> File: rlm_counter.so
> >> File: rlm_cram.so
> >> File: rlm_date.so
> >> File: rlm_detail.so
> >> File: rlm_dhcp.so
> >>  0x0001 (NEEDED) Shared library:
> [libfreeradius-dhcp.so]
> >> File: rlm_digest.so
> >> File: rlm_dynamic_clients.so
> >> File: rlm_eap.so
> >>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_fast.so
> >>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_gtc.so
> >>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_leap.so
> >>  0

Bug#911180: [Pkg-freeradius-maintainers] Bug#911180: freeradius: freeradius refuses to start - missing libs

[Michael Stapelberg]

I still don’t quite understand why you stripped the rpaths to begin with.
Can you explain? I think that’d be good to understand before making a
decision :)

On Mon, Nov 5, 2018 at 9:06 PM Dimitri John Ledkov  wrote:

> Hello,
>
> On Mon, 5 Nov 2018 at 18:19, Michael Stapelberg 
> wrote:
> >
> > Sorry, didn’t see the merge request. I fixed my notification settings,
> merged the MR, and gave you permission to the repository.
> >
>
> No worries. I myself only starting to figure out how to correctly use
> salsa. It is quite new in how everything works.
>
> So about the bug, here is the full scope of affected files:
>
> /usr/lib/freeradius# readelf -d *.so | grep -e '\[libfreeradius' -e File:
> File: libfreeradius-dhcp.so
> File: libfreeradius-eap.so
> File: libfreeradius-radius.so
> File: libfreeradius-server.so
> File: proto_dhcp.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-dhcp.so]
> File: proto_vmps.so
> File: rlm_always.so
> File: rlm_attr_filter.so
> File: rlm_cache.so
> File: rlm_cache_memcached.so
> File: rlm_cache_rbtree.so
> File: rlm_chap.so
> File: rlm_counter.so
> File: rlm_cram.so
> File: rlm_date.so
> File: rlm_detail.so
> File: rlm_dhcp.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-dhcp.so]
> File: rlm_digest.so
> File: rlm_dynamic_clients.so
> File: rlm_eap.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_eap_fast.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_eap_gtc.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_eap_leap.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_eap_md5.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_eap_mschapv2.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_eap_peap.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_eap_pwd.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_eap_sim.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_eap_tls.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_eap_ttls.so
>  0x0001 (NEEDED) Shared library:
> [libfreeradius-eap.so]
> File: rlm_exec.so
> File: rlm_expiration.so
> File: rlm_expr.so
> File: rlm_files.so
> File: rlm_ippool.so
> File: rlm_krb5.so
> File: rlm_ldap.so
> File: rlm_linelog.so
> File: rlm_logintime.so
> File: rlm_mschap.so
> File: rlm_otp.so
> File: rlm_pam.so
> File: rlm_pap.so
> File: rlm_passwd.so
> File: rlm_perl.so
> File: rlm_preprocess.so
> File: rlm_python.so
> File: rlm_radutmp.so
> File: rlm_realm.so
> File: rlm_redis.so
> File: rlm_rediswho.so
> File: rlm_replicate.so
> File: rlm_rest.so
> File: rlm_soh.so
> File: rlm_sometimes.so
> File: rlm_sql.so
> File: rlm_sql_freetds.so
> File: rlm_sql_iodbc.so
> File: rlm_sql_mysql.so
> File: rlm_sql_null.so
> File: rlm_sql_postgresql.so
> File: rlm_sql_sqlite.so
> File: rlm_sqlcounter.so
> File: rlm_sqlippool.so
> File: rlm_test.so
> File: rlm_unix.so
> File: rlm_unpack.so
> File: rlm_utf8.so
> File: rlm_wimax.so
> File: rlm_yubikey.so
>
> The majority of files indeed are fine. But a few that use
> libfreeradius-dhcp.so and libfreeradius-eap.so are not. I have two
> options to fix this:
>
> (1) do not strip rpath from files that use libfreeradius-eap|dhcp.so
>
> or
>
> (2) make these two libraries public by creating symlinks
> /usr/lib/libfreeradius-eap|dhcp.so ->
> freeradius/libfreeradius-eap|dhcp.so
>
> because in practice they are public system soname-less libraries
> shipped in libfreeradius3 and one can compile against them using
> libfreeradius-dev.
>
> In other packages, I went ahead and added sonames to such libraries
> and made them public - even if soname .0 and strict << versioning.
>
> I can implement either of the above two options, what do you prefer?
>
> > Thanks for looking into this!
> >
> > On Mon, Nov 5, 2018 at 6:53 PM Dimitri John Ledkov 
> wrote:
> >>
> >> Hi,
> >>
> >> On Tue, 16 Oct 2018 at 21:48, Michael Stapelberg 
> wrote:
> >> >
> >> > Dimitri, this is a result of your change
> https://salsa.debian.org/freeradius-team/freeradius/commit/1fad1d069a8148c5c64015714

Bug#911180: [Pkg-freeradius-maintainers] Bug#911180: freeradius: freeradius refuses to start - missing libs

[Michael Stapelberg]

Sorry, didn’t see the merge request. I fixed my notification settings,
merged the MR, and gave you permission to the repository.

Thanks for looking into this!

On Mon, Nov 5, 2018 at 6:53 PM Dimitri John Ledkov  wrote:

> Hi,
>
> On Tue, 16 Oct 2018 at 21:48, Michael Stapelberg 
> wrote:
> >
> > Dimitri, this is a result of your change
> https://salsa.debian.org/freeradius-team/freeradius/commit/1fad1d069a8148c5c640157147f4ad1b111ca919.
> Could you revert it for the time being, and, if you chose to go forward
> with a fix, outline the rationale? The commit only describes the what, not
> the why. Specifically, in which way was the rpath “bogus”?
> >
>
> Digging more into this, to understand how to fix this right.
>
> > Also, while at it, could you please ensure that
> https://salsa.debian.org/freeradius-team/freeradius is in sync with
> what’s in the archive? Your NMU is not reflected in the changelog, for
> example :-/
> >
>
> I can't actually do this. "Ready to be merged automatically. Ask
> someone with write access to this repository to merge this request"
> that's why when I uploaded NMU I opened the merge request on 25th of
> September at
> https://salsa.debian.org/freeradius-team/freeradius/merge_requests/2
>  please merge that, I think you are the only one who has the rights to
> the repository.
>
>
> --
> Regards,
>
> Dimitri.
>


-- 
Best regards,
Michael

Bug#911180: [Pkg-freeradius-maintainers] Bug#911180: freeradius: freeradius refuses to start - missing libs

[Michael Stapelberg]

Dimitri, friendly ping? This is also blocking the introduction of the new
upstream freeradius version.

On Tue, Oct 16, 2018 at 10:48 PM Michael Stapelberg 
wrote:

> control: reassign -1 freeradius-dhcp
> control: severity -1 important
>
> (Downgrading severity because this only affects installations which have
> the optional freeradius-dhcp package installed and enabled.)
>
> Dimitri, this is a result of your change
> https://salsa.debian.org/freeradius-team/freeradius/commit/1fad1d069a8148c5c640157147f4ad1b111ca919.
> Could you revert it for the time being, and, if you chose to go forward
> with a fix, outline the rationale? The commit only describes the what, not
> the why. Specifically, in which way was the rpath “bogus”?
>
> Also, while at it, could you please ensure that
> https://salsa.debian.org/freeradius-team/freeradius is in sync with
> what’s in the archive? Your NMU is not reflected in the changelog, for
> example :-/
>
> Thanks!
>
> On Tue, Oct 16, 2018 at 10:09 PM Kamil Jonca 
> wrote:
>
>> Package: freeradius
>> Version: 3.0.16+dfsg-4.1+b1
>> Severity: grave
>> Justification: renders package unusable
>>
>> After upgrade, freeradius refuses to start.
>> In its log we can see:
>>
>> Tue Oct 16 21:59:52 2018 : Error:
>> /etc/freeradius/3.0/mods-enabled/dhcp[18]: Failed to link to module
>> 'rlm_dhcp': libfreeradius-dhcp.so: cannot open shared object file: No such
>> file or directory
>>
>> bug is mysterious because:
>> [from /etc/freeradius/3.0/radiusd.conf]
>> libdir = /usr/lib/freeradius/
>>
>> #ls -la /usr/lib/freeradius/rlm_dhcp*
>> -rw-r--r-- 1 root root 14344 Oct 13 06:49 /usr/lib/freeradius/rlm_dhcp.so
>>
>>
>> moreover (I do not know if it is important)
>> #ldd /usr/lib/freeradius/rlm_dhcp.so
>> linux-vdso.so.1 (0x7fff15dcc000)
>> libfreeradius-dhcp.so => not found
>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4c96b7a000)
>> /lib64/ld-linux-x86-64.so.2 (0x7f4c96d78000)
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8),
>> LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages freeradius depends on:
>> ii  freeradius-common  3.0.16+dfsg-4.1
>> ii  freeradius-config  3.0.16+dfsg-4.1+b1
>> ii  libc6  2.27-6
>> ii  libcap21:2.25-1.2
>> ii  libct4 1.00.82-2+b1
>> ii  libfreeradius3 3.0.16+dfsg-4.1+b1
>> ii  libgdbm6   1.18-2
>> ii  libpam0g   1.1.8-3.8
>> ii  libpcre3   2:8.39-11
>> ii  libperl5.265.26.2-7+b1
>> ii  libreadline7   7.0-5
>> ii  libsqlite3-0   3.25.2-1
>> ii  libssl1.1  1.1.1-1
>> ii  libtalloc2 2.1.14-1
>> ii  libwbclient0   2:4.8.5+dfsg-1
>> ii  lsb-base   9.20170808
>>
>> Versions of packages freeradius recommends:
>> ii  freeradius-utils  3.0.16+dfsg-4.1+b1
>>
>> Versions of packages freeradius suggests:
>> pn  freeradius-krb5
>> ih  freeradius-ldap3.0.16+dfsg-4.1+b1
>> pn  freeradius-mysql   
>> ih  freeradius-postgresql  3.0.16+dfsg-4.1+b1
>> pn  freeradius-python2 
>> ii  snmp   5.7.3+dfsg-3
>>
>> -- Configuration Files:
>> /etc/default/freeradius changed:
>> FREERADIUS_OPTIONS="-xxx -l /var/log/freeradius/radius.log"
>>
>> /etc/logrotate.d/freeradius changed:
>> /var/log/freeradius/*.log {
>> weekly
>> compress
>> delaycompress
>> notifempty
>> missingok
>> postrotate
>> /etc/init.d/freeradius reload > /dev/null
>> endscript
>> }
>>
>>
>> -- no debconf information
>>
>> ___
>> Pkg-freeradius-maintainers mailing list
>> pkg-freeradius-maintain...@alioth-lists.debian.net
>>
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>>
>
>
> --
> Best regards,
> Michael
>


-- 
Best regards,
Michael

Bug#911804: wit: please make the build reproducible

[Michael Stapelberg]

Thanks for your patch. Would you mind submitting it as a merge request on
https://salsa.debian.org/debian/wit please?

Thank you!

On Thu, Oct 25, 2018 at 4:36 AM Chris Lamb  wrote:

> Source: wit
> Version: 3.01a-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the Reproducible Builds effort [0], we noticed
> that wit could not be built reproducibly.
>
> This because the binaries and the load-titles.sh scripts (etc.)
> embedded the build path.
>
> Patch attached. It's a bit complicated due to some weirdness in
> the upstream Makefile; hopefully should be documented enough.
>
>   [0] https://reproducible-builds.org/
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
Best regards,
Michael

Bug#911180: [Pkg-freeradius-maintainers] Bug#911180: freeradius: freeradius refuses to start - missing libs

[Michael Stapelberg]

control: reassign -1 freeradius-dhcp
control: severity -1 important

(Downgrading severity because this only affects installations which have
the optional freeradius-dhcp package installed and enabled.)

Dimitri, this is a result of your change
https://salsa.debian.org/freeradius-team/freeradius/commit/1fad1d069a8148c5c640157147f4ad1b111ca919.
Could you revert it for the time being, and, if you chose to go forward
with a fix, outline the rationale? The commit only describes the what, not
the why. Specifically, in which way was the rpath “bogus”?

Also, while at it, could you please ensure that
https://salsa.debian.org/freeradius-team/freeradius is in sync with what’s
in the archive? Your NMU is not reflected in the changelog, for example :-/

Thanks!

On Tue, Oct 16, 2018 at 10:09 PM Kamil Jonca  wrote:

> Package: freeradius
> Version: 3.0.16+dfsg-4.1+b1
> Severity: grave
> Justification: renders package unusable
>
> After upgrade, freeradius refuses to start.
> In its log we can see:
>
> Tue Oct 16 21:59:52 2018 : Error:
> /etc/freeradius/3.0/mods-enabled/dhcp[18]: Failed to link to module
> 'rlm_dhcp': libfreeradius-dhcp.so: cannot open shared object file: No such
> file or directory
>
> bug is mysterious because:
> [from /etc/freeradius/3.0/radiusd.conf]
> libdir = /usr/lib/freeradius/
>
> #ls -la /usr/lib/freeradius/rlm_dhcp*
> -rw-r--r-- 1 root root 14344 Oct 13 06:49 /usr/lib/freeradius/rlm_dhcp.so
>
>
> moreover (I do not know if it is important)
> #ldd /usr/lib/freeradius/rlm_dhcp.so
> linux-vdso.so.1 (0x7fff15dcc000)
> libfreeradius-dhcp.so => not found
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4c96b7a000)
> /lib64/ld-linux-x86-64.so.2 (0x7f4c96d78000)
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8),
> LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages freeradius depends on:
> ii  freeradius-common  3.0.16+dfsg-4.1
> ii  freeradius-config  3.0.16+dfsg-4.1+b1
> ii  libc6  2.27-6
> ii  libcap21:2.25-1.2
> ii  libct4 1.00.82-2+b1
> ii  libfreeradius3 3.0.16+dfsg-4.1+b1
> ii  libgdbm6   1.18-2
> ii  libpam0g   1.1.8-3.8
> ii  libpcre3   2:8.39-11
> ii  libperl5.265.26.2-7+b1
> ii  libreadline7   7.0-5
> ii  libsqlite3-0   3.25.2-1
> ii  libssl1.1  1.1.1-1
> ii  libtalloc2 2.1.14-1
> ii  libwbclient0   2:4.8.5+dfsg-1
> ii  lsb-base   9.20170808
>
> Versions of packages freeradius recommends:
> ii  freeradius-utils  3.0.16+dfsg-4.1+b1
>
> Versions of packages freeradius suggests:
> pn  freeradius-krb5
> ih  freeradius-ldap3.0.16+dfsg-4.1+b1
> pn  freeradius-mysql   
> ih  freeradius-postgresql  3.0.16+dfsg-4.1+b1
> pn  freeradius-python2 
> ii  snmp   5.7.3+dfsg-3
>
> -- Configuration Files:
> /etc/default/freeradius changed:
> FREERADIUS_OPTIONS="-xxx -l /var/log/freeradius/radius.log"
>
> /etc/logrotate.d/freeradius changed:
> /var/log/freeradius/*.log {
> weekly
> compress
> delaycompress
> notifempty
> missingok
> postrotate
> /etc/init.d/freeradius reload > /dev/null
> endscript
> }
>
>
> -- no debconf information
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>


-- 
Best regards,
Michael

Bug#910997: i3-wm: please avoid dependency on x11-utils if possibly

[Michael Stapelberg]

control: tags -1 + pending

Thanks, addressing this in https://github.com/i3/i3/pull/3455

On Sun, Oct 14, 2018 at 5:39 PM Jonas Smedegaard  wrote:

> Package: i3-wm
> Version: 4.15-1
> Severity: minor
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> i3-wm depends on x11-utils.
>
> This indirectly pulls in Mesa which is consumes quite some diskspace.
>
> Please, if possible, avoid that dependency.
>
>  - Jonas
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlvDYksACgkQLHwxRsGg
> ASGgyA/8DY4HJeyx9xdjlcJ31tTNut0hLQKFH1K7Voki5jZWDD8J9zi+wNhIOnKp
> Paaa/Rnmxy4lTl09l9Bg5ShK5+KrdrZGG0jFMKC15FkSyEEXq7YzKdZhq9oa2LmX
> CHA5FeYcM+Hk3KnNdIyDqYRJw1iSXhrVsegD4AOPAAFb6oArlawfrEvu6VqmKabJ
> ZEqgrHozle9nQfA8Xg7sPbEivPUGdbPoH66ct/1wf/D2Wb5qdydscYklhUsY5nSb
> 2UyA/z+a2bHK40Xv8JT/cobZ0Qf/WZlZlLce+lHhJFPde7f/Mxd/OMF+P1of9gYk
> 2DXHfHsSauQC9jtuJgMiv/f+jPXHefvr+b/qsPnSLAiCOWuTQg0kfGqVEc794/it
> JE/BuYJfgHM9jweNrv9W3BvWRWUbOrhgCFuBBr22WshDWKbJ/rdO4gdodRUp0lSH
> 5/1LX9RI7PTa4aD/HnDzHli/4Uu6PUDejXF9SRwaRlZ3Qk0/Idw2wPE7rs6+LV4o
> m84JQYQ7UdIB88GT7Fw7EBI1U0a39xY4GK0wz8JNfvR5wUS639gjijSQvDjsIheV
> 9AsEg9HJibauq3JtP9cdpYz0tmJbCdxt/zaYA6HekwSu+/DYgE8q+cBPJa6eyXIC
> AS3dDzMe/AF+R8D7Tt5OHSqv2lGWeQ6W1B/U/3yetNB3IXWfsno=
> =AytD
> -END PGP SIGNATURE-
>


-- 
Best regards,
Michael

Bug#908083: [pkg-go] Bug#908083: golang-gopkg-macaroon-bakery.v2: Autobuilder hangs when building with eatmydata

[Michael Stapelberg]

This is not a bug with this package, but with mongodb-server:

root@gce1535991:~# mongod --version
db version v3.4.15
git version: 52e5b5fbaa3a2a5b1a217f5e647b5061817475f9
OpenSSL version: OpenSSL 1.1.0f  25 May 2017
allocator: tcmalloc
modules: none
build environment:
distarch: x86_64
target_arch: x86_64
root@gce1535991:~# eatmydata mongod --version
^C

This package uses mongodb in its tests, hence the hang.

I’ll leave it up to you to merge and reassign accordingly.


On Thu, Sep 6, 2018 at 1:05 AM, Santiago Vila  wrote:

> Package: src:golang-gopkg-macaroon-bakery.v2
> Version: 0.0~git20171221.21d9e9a-5
> Severity: wishlist
>
> Dear maintainer:
>
> When I build this package using sbuild + eatmydata this is what happens:
>
> 
> 
> [...]
>  debian/rules build-indep
> dh build-indep --buildsystem=golang --with=golang
>dh_update_autotools_config -i -O--buildsystem=golang
>dh_autoreconf -i -O--buildsystem=golang
>dh_auto_configure -i -O--buildsystem=golang
>dh_auto_build -i -O--buildsystem=golang
> cd obj-x86_64-linux-gnu && go install -gcflags=\"-trimpath=/<<
> BUILDDIR>>/golang-gopkg-macaroon-bakery.v2-0.0\~
> git20171221.21d9e9a/obj-x86_64-linux-gnu/src\" -asmflags=\"-trimpath=/<<
> BUILDDIR>>/golang-gopkg-macaroon-bakery.v2-0.0\~
> git20171221.21d9e9a/obj-x86_64-linux-gnu/src\" -v -p 1
> gopkg.in/macaroon-bakery.v2/bakery gopkg.in/macaroon-bakery.v2/
> bakery/checkers gopkg.in/macaroon-bakery.v2/bakery/identchecker
> gopkg.in/macaroon-bakery.v2/bakery/internal/macaroonpb
> gopkg.in/macaroon-bakery.v2/bakery/mgorootkeystore
> gopkg.in/macaroon-bakery.v2/bakerytest gopkg.in/macaroon-bakery.v2/
> httpbakery gopkg.in/macaroon-bakery.v2/httpbakery/agent
> gopkg.in/macaroon-bakery.v2/httpbakery/form gopkg.in/macaroon-bakery.v2/
> internal/httputil
> github.com/juju/loggo
> github.com/rogpeppe/fastuuid
> golang.org/x/crypto/curve25519
> golang.org/x/crypto/internal/subtle
> golang.org/x/crypto/poly1305
> golang.org/x/crypto/salsa20/salsa
> golang.org/x/crypto/nacl/secretbox
> golang.org/x/crypto/nacl/box
> golang.org/x/net/context
> gopkg.in/errgo.v1
> gopkg.in/macaroon.v2
> gopkg.in/macaroon-bakery.v2/bakery/checkers
> github.com/golang/protobuf/proto
> gopkg.in/macaroon-bakery.v2/bakery/internal/macaroonpb
> gopkg.in/macaroon-bakery.v2/bakery
> gopkg.in/macaroon-bakery.v2/bakery/identchecker
> gopkg.in/mgo.v2/internal/json
> gopkg.in/mgo.v2/bson
> gopkg.in/mgo.v2/internal/scram
> gopkg.in/mgo.v2
> gopkg.in/macaroon-bakery.v2/bakery/mgorootkeystore
> github.com/julienschmidt/httprouter
> golang.org/x/net/html/atom
> golang.org/x/net/html
> gopkg.in/httprequest.v1
> github.com/juju/webbrowser
> golang.org/x/net/context/ctxhttp
> golang.org/x/net/publicsuffix
> gopkg.in/macaroon-bakery.v2/internal/httputil
> gopkg.in/macaroon-bakery.v2/httpbakery
> gopkg.in/macaroon-bakery.v2/bakerytest
> gopkg.in/macaroon-bakery.v2/httpbakery/agent
> github.com/juju/errors
> github.com/juju/utils/clock
> golang.org/x/crypto/pbkdf2
> gopkg.in/yaml.v2
> github.com/juju/utils
> github.com/juju/schema
> github.com/juju/utils/keyvalues
> gopkg.in/juju/environschema.v1
> golang.org/x/sys/unix
> golang.org/x/crypto/ssh/terminal
> gopkg.in/juju/environschema.v1/form
> gopkg.in/macaroon-bakery.v2/httpbakery/form
>dh_auto_test -i -O--buildsystem=golang
> cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1
> gopkg.in/macaroon-bakery.v2/bakery gopkg.in/macaroon-bakery.v2/
> bakery/checkers gopkg.in/macaroon-bakery.v2/bakery/identchecker
> gopkg.in/macaroon-bakery.v2/bakery/internal/macaroonpb
> gopkg.in/macaroon-bakery.v2/bakery/mgorootkeystore
> gopkg.in/macaroon-bakery.v2/bakerytest gopkg.in/macaroon-bakery.v2/
> httpbakery gopkg.in/macaroon-bakery.v2/httpbakery/agent
> gopkg.in/macaroon-bakery.v2/httpbakery/form gopkg.in/macaroon-bakery.v2/
> internal/httputil
> === RUN   TestPackage
> OK: 71 passed
> --- PASS: TestPackage (0.05s)
> PASS
> ok  gopkg.in/macaroon-bakery.v2/bakery  0.050s
> === RUN   TestPackage
> OK: 19 passed
> --- PASS: TestPackage (0.00s)
> PASS
> ok  gopkg.in/macaroon-bakery.v2/bakery/checkers 0.003s
> === RUN   TestPackage
> OK: 19 passed
> --- PASS: TestPackage (0.01s)
> PASS
> ok  gopkg.in/macaroon-bakery.v2/bakery/identchecker 0.012s
> ?   gopkg.in/macaroon-bakery.v2/bakery/internal/macaroonpb  [no test
> files]
> === RUN   TestPackage
> SIGQUIT: quit
> PC=0x472258 m=0 sigcode=0
>
> goroutine 5 [syscall]:
> syscall.Syscall6(0xf7, 0x1, 0x3d5d, 0xc420069600, 0x104, 0x0, 0x0,
> 0x0, 0xba1480, 0x0)
> /usr/lib/go-1.10/src/syscall/asm_linux_amd64.s:44 +0x5
> fp=0xc4200695a8 sp=0xc4200695a0 pc=0x472235
> os.(*Process).blockUntilWaitable(0xc4200267b0, 0x0, 0x0, 0x2)
> /usr/lib/go-1.10/src/os/wait_waitid.go:31 +0x98 fp=0xc4200696a8
> sp=0xc4200695a8 pc=0x493358
> os.(*Process).wait(0xc4200267b0, 0xc420106a80, 0xc4200cc918, 0xc4200cc918)
> 

Bug#908082: [pkg-go] Bug#908082: golang-github-juju-testing: Autobuilder hangs when building with eatmydata

[Michael Stapelberg]

This is not a bug with this package, but with mongodb-server:

root@gce1535991:~# mongod --version
db version v3.4.15
git version: 52e5b5fbaa3a2a5b1a217f5e647b5061817475f9
OpenSSL version: OpenSSL 1.1.0f  25 May 2017
allocator: tcmalloc
modules: none
build environment:
distarch: x86_64
target_arch: x86_64
root@gce1535991:~# eatmydata mongod --version
^C

This package uses mongodb in its tests, hence the hang.

I’ll leave it up to you to merge and reassign accordingly.

On Thu, Sep 6, 2018 at 1:05 AM, Santiago Vila  wrote:

> Package: src:golang-github-juju-testing
> Version: 0.0~git20170608.2fe0e88-3
> Severity: wishlist
>
> Dear maintainer:
>
> When I build this package using sbuild + eatmydata this is what happens:
>
> 
> 
> [...]
>  debian/rules build-indep
> dh build-indep --buildsystem=golang --with=golang
>dh_update_autotools_config -i -O--buildsystem=golang
>dh_autoreconf -i -O--buildsystem=golang
>dh_auto_configure -i -O--buildsystem=golang
>dh_auto_build -i -O--buildsystem=golang
> cd obj-x86_64-linux-gnu && go install -gcflags=\"-trimpath=/<<
> BUILDDIR>>/golang-github-juju-testing-0.0\~git20170608.
> 2fe0e88/obj-x86_64-linux-gnu/src\" -asmflags=\"-trimpath=/<<
> BUILDDIR>>/golang-github-juju-testing-0.0\~git20170608.
> 2fe0e88/obj-x86_64-linux-gnu/src\" -v -p 1 github.com/juju/testing
> github.com/juju/testing/checkers github.com/juju/testing/filetesting
> github.com/juju/testing/httptesting
> github.com/juju/errors
> github.com/juju/loggo
> github.com/juju/retry
> gopkg.in/check.v1
> gopkg.in/mgo.v2/internal/json
> gopkg.in/mgo.v2/bson
> gopkg.in/yaml.v2
> github.com/juju/testing/checkers
> github.com/juju/utils/clock
> golang.org/x/crypto/pbkdf2
> golang.org/x/net/context
> github.com/juju/utils
> github.com/juju/version
> gopkg.in/mgo.v2/internal/scram
> gopkg.in/mgo.v2
> github.com/juju/testing
> github.com/juju/testing/filetesting
> github.com/juju/testing/httptesting
>dh_auto_test -i -O--buildsystem=golang
> cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1
> github.com/juju/testing github.com/juju/testing/checkers
> github.com/juju/testing/filetesting github.com/juju/testing/httptesting
> === RUN   Test
> SIGQUIT: quit
> PC=0x472298 m=0 sigcode=0
>
> goroutine 6 [syscall]:
> syscall.Syscall6(0xf7, 0x1, 0x7d43, 0xc420069600, 0x104, 0x0, 0x0,
> 0x0, 0xbafe20, 0x0)
> /usr/lib/go-1.10/src/syscall/asm_linux_amd64.s:44 +0x5
> fp=0xc4200695a8 sp=0xc4200695a0 pc=0x472275
> os.(*Process).blockUntilWaitable(0xc420026780, 0x0, 0x0, 0x2)
> /usr/lib/go-1.10/src/os/wait_waitid.go:31 +0x98 fp=0xc4200696a8
> sp=0xc4200695a8 pc=0x493668
> os.(*Process).wait(0xc420026780, 0xc4200feb60, 0xc4200ce4f8, 0xc4200ce4f8)
> /usr/lib/go-1.10/src/os/exec_unix.go:22 +0x3c fp=0xc420069720
> sp=0xc4200696a8 pc=0x48d5ac
> os.(*Process).Wait(0xc420026780, 0x936048, 0x936050, 0x936040)
> /usr/lib/go-1.10/src/os/exec.go:123 +0x2b fp=0xc420069750
> sp=0xc420069720 pc=0x48cb5b
> os/exec.(*Cmd).Wait(0xc4200ce420, 0x0, 0x0)
> /usr/lib/go-1.10/src/os/exec/exec.go:461 +0x5c fp=0xc4200697c8
> sp=0xc420069750 pc=0x53cc8c
> os/exec.(*Cmd).Run(0xc4200ce420, 0xc420088910, 0x1)
> /usr/lib/go-1.10/src/os/exec/exec.go:305 +0x5c fp=0xc4200697f0
> sp=0xc4200697c8 pc=0x53c16c
> os/exec.(*Cmd).Output(0xc4200ce420, 0xf, 0xc4200578b8, 0x1, 0x1,
> 0xc4200ce420)
> /usr/lib/go-1.10/src/os/exec/exec.go:500 +0xf5 fp=0xc420069840
> sp=0xc4200697f0 pc=0x53d085
> github.com/juju/testing.detectMongoVersion(0xc420154b40, 0xf, 0x0, 0x0,
> 0x0, 0x0, 0x0, 0x0, 0xc420057cb0, 0xe0)
> /<>/obj-x86_64-linux-gnu/src/github.com/juju/
> testing/mgo.go:396 +0xb0 fp=0xc4200699b8 sp=0xc420069840 pc=0x7f0e90
> github.com/juju/testing.(*mongodCache).Get(0xbaf180, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0, 0x0, 0x0, 0x0, ...)
> /<>/obj-x86_64-linux-gnu/src/github.com/juju/
> testing/mgo.go:359 +0x170 fp=0xc420069a58 sp=0xc4200699b8 pc=0x7f0830
> github.com/juju/testing.(*MgoInstance).run(0xbaf300, 0xc, 0xc420057e78)
> /<>/obj-x86_64-linux-gnu/src/github.com/juju/
> testing/mgo.go:260 +0x1a8 fp=0xc420069da0 sp=0xc420069a58 pc=0x7ef848
> github.com/juju/testing.(*MgoInstance).Start(0xbaf300, 0x0, 0x17f7a0e4,
> 0x17f7a0e400a2d078)
> /<>/obj-x86_64-linux-gnu/src/github.com/juju/
> testing/mgo.go:206 +0x38f fp=0xc420069f48 sp=0xc420069da0 pc=0x7ef1bf
> github.com/juju/testing.MgoTestPackage(0xc4201660f0, 0x0)
> /<>/obj-x86_64-linux-gnu/src/github.com/juju/
> testing/mgo.go:455 +0x3b fp=0xc420069f88 sp=0xc420069f48 pc=0x7f186b
> github.com/juju/testing_test.Test(0xc4201660f0)
> /<>/obj-x86_64-linux-gnu/src/github.com/juju/
> testing/package_test.go:13 +0x34 fp=0xc420069fa8 sp=0xc420069f88
> pc=0x805d34
> testing.tRunner(0xc4201660f0, 0x935870)
> /usr/lib/go-1.10/src/testing/testing.go:777 +0xd0 fp=0xc420069fd0
> sp=0xc420069fa8 pc=0x4ed330
> 

Bug#907263: dh-golang: Failed to build with gccgo-8

[Michael Stapelberg]

If that’s required to fix the bug, then so be it :)

On Sun, Aug 26, 2018 at 5:52 PM, Shengjing Zhu  wrote:

> On Sun, Aug 26, 2018 at 11:33 PM Michael Stapelberg
>  wrote:
> >
> > There is a way, dh-make-golang does it: https://github.com/Debian/dh-
> make-golang/blob/f0afc0f7169eb4f261449d8c4bd6fc
> 7950583617/make.go#L177-L192
> >
>
> Thanks for this info, first time to know `go list std` usage.
>
> However if we go with filtering out std libraries(only for gccgo?),
> more lines will be in dh_golang...lol. And different logic for gccgo?
>
> --
> Best regards,
> Shengjing Zhu
>



-- 
Best regards,
Michael

Bug#907263: [pkg-go] Bug#907263: dh-golang: Failed to build with gccgo-8

[Michael Stapelberg]

There is a way, dh-make-golang does it:
https://github.com/Debian/dh-make-golang/blob/f0afc0f7169eb4f261449d8c4bd6fc7950583617/make.go#L177-L192

On Sun, Aug 26, 2018 at 12:34 PM, Shengjing Zhu  wrote:

> On Sun, Aug 26, 2018 at 5:44 PM Michael Hudson-Doyle
>  wrote:
> >
> > I've forgotten everything about this code even though I wrote it, but
> wouldn't it be better to filter out the standard library dependencies?
> >
>
> For golang-go, currently it uses std library to producing the
> Built-Using for golang-go compiler. For gccgo, there's no such need
> because it will depends libgo.
> So for gccgo, it's true that we can filter out the std library. But I
> doubt if there's clean way...
>
> --
> Best regards,
> Shengjing Zhu
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-go-maintainers




-- 
Best regards,
Michael

Bug#905839: [pkg-go] Bug#905839: debiman: autopkgtest fails with mdocml version 1.14.4-1

[Michael Stapelberg]

control: tag -1 + pending

On Fri, Aug 10, 2018 at 2:59 PM, Michael Stapelberg 
wrote:

> This is fixed upstream in https://github.com/Debian/debiman/commit/
> 210e94b3cf101d62b74211d0866f6308c6bee4db
>
> Feel free to do what is necessary to get the fix into Debian.
>
> On Fri, Aug 10, 2018 at 2:37 PM, Paul Gevers  wrote:
>
>> Source: debiman
>> Version: 0.0~git20180711.cb414bd-2
>> X-Debbugs-CC: debian...@lists.debian.org, mdo...@packages.debian.org
>> User: debian...@lists.debian.org
>> Usertags: needs-update
>> Control: affects -1 src:mdocml
>>
>> Dear maintainers,
>>
>> Recently version 1.14.4-1 of mdocml was uploaded to the Debian archive.
>> Your autopkgtest started to fail with the error copied below.
>>
>> Could you please investigate? It seems that you are comparing generated
>> output with a reference. Looking at the text I can't spot obvious
>> mistakes (but I may be missing details), so I think you need to update
>> your reference to the new output. Please reassign this bug to mdocml if
>> you think that package has this bug instead. This regression is
>> currently delaying the migration of mdocml to unstable by 10 days, so
>> cooperation to fix this swiftly is appreciated.
>>
>> Don't forget the set the appropriate Versioned (test) depends to let
>> autopkgtest figure out which version is needed and maybe consider making
>> your tests less sensitive to this kind of changes if they shouldn't
>> delay or block other packages. If your tests aren't suitable for gating
>> other packages, you can also mark them skippable and exit 77 in case of
>> regressions.
>>
>> Paul
>>
>> https://ci.debian.net/data/autopkgtest/testing/amd64/d/debim
>> an/796100/log.gz
>>
>> 2018/08/10 05:11:23 mandocd not found, falling back to fork+exec for
>> each manpage
>> --- FAIL: TestToHTML (0.00s)
>> --- FAIL: TestToHTML/i3lock (0.01s)
>> convert_test.go:92: unexpected conversion result: (diff from want
>> →
>> got):
>> --- /tmp/debiman-314812002  2018-08-10
>> 05:11:23.148127262 +
>> +++ /tmp/debiman-841037135  2018-08-10
>> 05:11:23.148127262 +
>> @@ -7,65 +7,65 @@
>>
>>  
>>  
>> +
>> +
>>  NAME> href="#NAME">¶
>>  i3lock - improved screen locker
>> - 
>> +
>>  SYNOPSIS> href="#SYNOPSIS">¶
>>  i3lock [-v] [-c color]
>> - 
>> +
>>  DESCRIPTION> class="anchor"
>> href="#DESCRIPTION">¶
>>  i3lock is a simple screen locker like slock. After
>> starting it, you will
>>see a white screen (you can configure the color/an
>> image). You
>> can return to
>>your screen by entering your password.
>> - 
>> +
>>  IMPROVEMENTS> class="anchor"
>> href="#IMPROVEMENTS">¶
>>  
>> -  •
>> -  i3lock forks, so you can combine it
>> with an
>> alias to
>> -  suspend to RAM (run i3lock  echo
>> mem 
>> -  /sys/power/state to get a locked screen after
>> waking
>> up your
>> -  computer from suspend to RAM)
>> +  •
>> +  i3lock forks, so you can combine it with an alias
>> to
>> suspend to RAM (run
>> +  i3lock  echo mem 
>> /sys/power/state
>> to get a
>> +  locked screen after waking up your computer from
>> suspend to
>> RAM)
>>  
>>  
>> -  •
>> -  You can specify either a background
>> color or
>> a PNG image
>> -  which will be displayed while your screen is
>> locked.
>> +  •
>> +  You can specify either a background color or a PNG
>> image
>> which will be
>> +  displayed while your screen is locked.
>>  
>>  
>> -  •
>> -  You can specify whether i3lock
>> should bell
>> upon a wrong
>> -   

Bug#905839: [pkg-go] Bug#905839: debiman: autopkgtest fails with mdocml version 1.14.4-1

[Michael Stapelberg]

   OPTIONS href="#OPTIONS">¶
>  
> -  -v, --version
> -  Display the version of your
> i3lock
> - 
> +  -v, --version
> +  Display the version of your i3lock
> +
>
>  
>  
> -  -c rrggbb,
> --color=rrggbb
> -  Turn the screen into the given color
> instead
> of white.
> -  Color must be given in 3-byte format: rrggbb (i.e.
> ff
> is red).
> - 
> +  -c rrggbb,
> --color=rrggbb
> +  Turn the screen into the given color instead of
> white.
> Color must be given
> +  in 3-byte format: rrggbb (i.e. ff is red).
> +
>
>  
>  DPMS href="#DPMS">¶
>  The -d (--dpms) option.
> - 
> +
>verbatim
>  
> - 
> +
>  SEE ALSO href="#SEE_ALSO">¶
>  xautolock(1) - use i3lock as your screen saver
> - 
> +
>  AUTHOR href="#AUTHOR">¶
>  Michael Stapelberg michael+i3lock@example.
> invalid
>  
>
> --- FAIL: TestToHTML/refs (0.01s)
> convert_test.go:92: unexpected conversion result: (diff from want →
> got):
> --- /tmp/debiman-766785508  2018-08-10
> 05:11:23.148127262 +
> +++ /tmp/debiman-681617497  2018-08-10
> 05:11:23.148127262 +
> @@ -9,19 +9,19 @@
>  
>  NAME href="#NAME">¶
>  refs - test file
> - 
> +
>  SEE ALSO href="#SEE_ALSO">¶
>  http://w3m.sourceforge.net;>project
> website
> - 
> +
>  More details can be found in the  href="testing/i3lock/i3lock.1.C">i3lock(1) or refs(1) man pages.
> - 
> +
>  References to i3-msg(1)
> might cause trouble when matching on word boundaries.
> - 
> +
>  References to  href="testing/systemd/systemd.service.5.C">systemd.service(5)
> contain a dot.
> - 
> +
>  URLs in plain text, like  href="http://debian.org;>http://debian.org are also recognized and
> converted.
>URLs in brackets, like  href="http://debian.org/;>http://debian.org/ are correctly
> recognized.
> - 
> +
>  Marked up URLs like  href="http://gnome.org;>http://gnome.org are also converted.
>  
>
>
> === RUN   TestXref
> --- PASS: TestXref (0.00s)
> === RUN   TestHref
> --- PASS: TestHref (0.00s)
> === RUN   TestXrefHref
> --- PASS: TestXrefHref (0.00s)
> === RUN   TestFormattedXref
> --- PASS: TestFormattedXref (0.00s)
> FAIL
> FAILgithub.com/Debian/debiman/internal/convert  0.016s
>
>
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-go-maintainers
>



-- 
Best regards,
Michael

Bug#905104: [pkg-go] Bug#905104: ratt fails with "Could not find InRelease file for unstable."

[Michael Stapelberg]

I think you’re missing a deb-src entry for unstable in your sources.list.

On Tue, Jul 31, 2018 at 12:17 PM, Jörg Frings-Fürst 
wrote:

> Package: ratt
> Version: 0.0~git20160202.0.a14e2ff-1+b3
> Severity: grave
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> if I run ratt I get allways:
>
> [quote]
> $ ratt ../sane-backends/sane-backends_1.0.27-1~
> experimental6_source.changes
> 2018/07/31 12:06:06 Loading changes file "../sane-backends/sane-
> backends_1.0.27-1~experimental6_source.changes"
> 2018/07/31 12:06:06  - 4 binary packages: sane-utils libsane-common
> libsane1
> libsane-dev
> 2018/07/31 12:06:06  - corresponding .debs (will be injected when
> building):
> 2018/07/31 12:06:07 Could not find InRelease file for unstable. Are you
> missing
> unstable in your /etc/apt/sources.list?
> [/quote]
>
> Unstable is in my sources.list.
>
> [quote]
> $ cat /etc/apt/sources.list
> #
>
> # deb cdrom:[Debian GNU/Linux jessie-DI-b1 _Jessie_ - Official Snapshot
> amd64
> NETINST Binary-1 20140812-10:58]/ jessie main
>
> # deb cdrom:[Debian GNU/Linux jessie-DI-b1 _Jessie_ - Official Snapshot
> amd64
> NETINST Binary-1 20140812-10:58]/ jessie main
>
> deb http://mirror.1und1.de/debian/ buster main non-free contrib
> deb-src http://mirror.1und1.de/debian/ buster main non-free contrib
>
> deb http://security.debian.org/ buster/updates main non-free contrib
> deb-src http://security.debian.org/ buster/updates main non-free contrib
>
> # stretch-updates, previously known as 'volatile'
> deb http://mirror.1und1.de/debian/ buster-updates main non-free contrib
> deb-src http://mirror.1und1.de/debian/ buster-updates main non-free
> contrib
>
> # stretch-backports, previously on backports.debian.org
> # deb http://mirror.1und1.de/debian/ stretch-backports main non-free
> contrib
> # deb-src http://mirror.1und1.de/debian/ stretch-backports main non-free
> contrib
>
>  unstable #
> deb http://mirror.1und1.de/debian unstable main contrib non-free
>
> # experimental #
> deb http://mirror.1und1.de/debian experimental main contrib non-free
> deb http://deb.debian.org/debian/ buster main non-free contrib
> [/quote]
>
>
>
> And the InRelease file exists.
>
> [quote]$ ls -l /var/lib/apt/lists/*InRelease
> - -rw-r--r-- 1 root root 149528 Jul 31 10:36
> /var/lib/apt/lists/deb.debian.org_debian_dists_buster_InRelease
> - -rw-r--r-- 1 root root   3561 Jul 31 03:55
> /var/lib/apt/lists/josm.openstreetmap.de_apt_dists_alldist_InRelease
> - -rw-r--r-- 1 root root 149528 Jul 31 10:36
> /var/lib/apt/lists/mirror.1und1.de_debian_dists_buster_InRelease
> - -rw-r--r-- 1 root root  47567 Jul 31 10:35
> /var/lib/apt/lists/mirror.1und1.de_debian_dists_buster-updates_InRelease
> - -rw-r--r-- 1 root root 101329 Jul 31 10:35
> /var/lib/apt/lists/mirror.1und1.de_debian_dists_experimental_InRelease
> - -rw-r--r-- 1 root root 232649 Jul 31 10:37
> /var/lib/apt/lists/mirror.1und1.de_debian_dists_unstable_InRelease
> - -rw-r--r-- 1 root root   4487 Jul 20 12:20
> /var/lib/apt/lists/repo.skype.com_deb_dists_stable_InRelease
> - -rw-r--r-- 1 root root  38336 Jul 30 03:32
> /var/lib/apt/lists/security.debian.org_dists_buster_updates_InRelease
> - -rw-r--r-- 1 root root   9282 Jun 20 10:26 /var/lib/apt/lists/wire-
> app.wire.com_linux_debian_dists_stable_InRelease
> [/quote]
>
> CU
> Jörg
>
>
>
> - -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (300, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.17.0-1-amd64 (SMP w/6 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages ratt depends on:
> ii  libc6  2.27-5
>
> ratt recommends no packages.
>
> ratt suggests no packages.
>
> - -- no debconf information
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAltgNzgACgkQCfifPIyh
> 0l1/CBAA1fkPG20J2nwrutybSkF74FGOEQ2avTGcM0KJYHuDtw6MWIM+0elhqRmL
> 6MWz0C/Mu06+dV35w6mypEbbIK6pzbr7iZ/MtbpDZZjXaT2YKRRsy8QY4g8vchJ7
> k7fkBfCvCfafKwbsZr7/0Kt1FOcxKZoJ1M417Hv/Oe105U9u5ilEbW6EbXnEKbay
> 6PldlmM3/y2/99JJGN+Xe6P7jxJTcrQR9omcDJTOXTYctSuCRVe5kQB3+s27GDBt
> IqfPRPBz33ojUFbAZzK2s8OYcLfRvKdrUUtoC1Vdxpzhf79E778VsV4z7TguybU9
> rq4l/E7gTUhsxj7MDVxEus7x9DVEmGpTp+2M5s96e9ODzmIBpmFQzo2xoAqZH41X
> YYKx4IEu6rMq1L6D5ZamluRzp/a0Ur8lWu7hEUPrVRirqGd+6Yrw/q2Jk+Su6mn/
> MYTN+ev/4VMP19cCRJkaZKOv0RQ+DHNgQcgB+/1xLnVoBa4p8rA+Y0h64DO+vKyK
> 4ErTR5oD+xtIYYSoXXciZnR9sdWvBfBw3JH30SWvxR+PFPD4Y5hYilIc3IvEdbDY
> RxovOwkvDKLIfIIDExfIlmhkPx982kfiMzxCOD03abLN+GSA+xI/3PV3aACEBYL/
> bCbwsblqKel3OxXcIwEZSTlnRipwXW+BG0mzJY0pl5Dh4DXk9PQ=
> =bMK6
> -END PGP SIGNATURE-
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> 

Bug#904574: [pkg-go] Bug#904574: ratt should depend on dose-extra

[Michael Stapelberg]

Sounds reasonable. Could you send a merge request at
https://salsa.debian.org/go-team/packages/ratt/blob/master/debian/control
please? You can use the Edit button to perform the edit in your browser
(but please test the resulting package). If you don’t have an account yet,
see https://signup.salsa.debian.org/

Thanks!

On Wed, Jul 25, 2018 at 11:42 AM, Nicolas Braud-Santoni <
nico...@braud-santoni.eu> wrote:

> Package: ratt
> Version: 0.0~git20160202.0.a14e2ff-1+b3
> Severity: normal
>
> Hi,
>
> When using ratt, it attempts to call dose-ceve (from the dose-extra
> package)
> and if the binary is missing it falls back to interpreting the sources
> index
> itself.
>
> As such, I believe ratt should declare an optional dependency (Recommends
> or
> Suggests) on dose-extra; I believe Recommends would be appropriate as ratt
> has degraded functionality without it (as far as I understand).
>
>
> Best,
>
>   nicoo
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored:
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages ratt depends on:
> ii  libc6  2.27-5
>
> ratt recommends no packages.
>
> ratt suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-go-maintainers




-- 
Best regards,
Michael

Bug#904261: [pkg-go] Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Michael Stapelberg]

There was a discussion on the pkg-go mailing list titled “honoring
DH_GOLANG_EXCLUDES for sources” a while ago, started by Clément (cc'ed).

On Sun, Jul 22, 2018 at 1:58 PM, Shengjing Zhu  wrote:

> Package: dh-golang
> Severity: wishlist
>
> Dear Maintainer,
>
> In install phase, dh-golang just calls `cp -r -T src/$ENV{DH_GOPKG}
> $dest_src`,
> which installs DH_GOLANG_EXCLUDES files to /usr/share/gocode/src/.
>
> Shouldn't these files not be installed as well?
>
> A real example is, paride asked on irc that why golang-github-prometheus-
> client-golang
> installs `examples` files twice in -dev package, (once installed by
> dh-golang,
> once installed by dh_installexamples).
>
> --
> Best regards,
> Shengjing Zhu
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-go-maintainers




-- 
Best regards,
Michael

Bug#902361: [pkg-go] Bug#902361: Bug#902361: golang-pault-go-archive: Please update to >= 0.0~git20180624.470edde

[Michael Stapelberg]

As you have probably guessed by now, I’m very pressed on time. If someone
else could do it, I’d prefer that.

On Mon, Jun 25, 2018 at 4:21 PM, Benjamin Drung <
benjamin.dr...@profitbricks.com> wrote:

> Am Montag, den 25.06.2018, 10:16 -0400 schrieb Paul R. Tagliamonte:
> > I'm happy to tag a release for whoever's packaging. File a bug on the
> > repo before you want to dput 
>
> Michael, will you update the package?
>
> --
> Benjamin Drung
> System Developer
> Debian & Ubuntu Developer
>
> ProfitBricks GmbH
> Greifswalder Str. 207
> 10405 Berlin
>
> Email: benjamin.dr...@profitbricks.com
> URL: https://www.profitbricks.de
>
> Sitz der Gesellschaft: Berlin
> Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
> Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-go-maintainers
>



-- 
Best regards,
Michael

Bug#903385: [pkg-go] Bug#903385: dh-golang: Allow the "build" dh stage to call "go build" instead of "go install"

[Michael Stapelberg]

Would such a flag be useful for any other package than the fscrypt package?

If no, I’d recommend to not change dh-golang for the time being, and let
this be a one-off in the fscrypt package until it makes sense to centralize
the logic.

On Mon, Jul 9, 2018 at 12:15 PM, Paride Legovini  wrote:

> Package: dh-golang
> Version: 1.34
> Severity: normal
>
> Hi,
>
> There is at least one case when it would be preferable to have the build
> dh stage to call ’go build’ instead of ’go install’. This is when
> building c-shared libraries with -buildmode=c-shared. In this case ‘go
> install’ builds the shared library object, but gives it a ‘.a’ extension
> and installs it in a not well defined location. This is discussed in this
> upstream issue:
>
> https://github.com/golang/go/issues/24253
>
> The upstream indication is that "The expectation is that people will use
> go build -buildmode=c-shared -o foo.so" and that using ‘go install’ "will
> put the shared library in a relatively unpredictable place".
>
> Given these facts, I think dh-golang should support a ‘go build’ mode.
> One way this could be implemented is via a --build-only flag to be
> passed to dh_auto_build. If there is consensus on this I can send a
> patch implementing it.
>
> This problem arose while packaging fscrypt, see in particular:
>
> https://salsa.debian.org/go-team/packages/fscrypt/blob/
> d15d123eb301d50c0376a10615e472054dd3b88d/debian/rules#L36
>
> Paride
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-go-maintainers




-- 
Best regards,
Michael

Bug#892764: stretch-pu: package i3-wm/4.13-1

[Michael Stapelberg]

On Tue, Jul 3, 2018 at 10:29 PM, Adam D. Barratt 
wrote:

> On Tue, 2018-07-03 at 22:20 +0200, Michael Stapelberg wrote:
> >
> >
> > On Tue, Jul 3, 2018 at 10:01 PM, Adam D. Barratt  > barratt.org.uk> wrote:
> [...]
> > > The metadata for #891919 suggests that it affects the version of
> > > i3-wm
> > > in unstable - is that correct? If it is, then please fix the
> > > package in
> > > unstable first; if not, then please fix the metadata.
> >
> > i3 ≥ 4.14 contain the fix, so the versions in testing and unstable
> > are fixed.
> >
> > I’m not good with the BTS. Can you share the correct command to do
> > what’s required before we can move forward please?
>
> 4.14-1 seems to have been the first unstable upload from that upstream
> release, so either send "fixed 891919 4.14-1" to control@bugs.d.o or
> use the bts tool from devscripts to do the same.
>

Thanks, done.


>
> Regards,
>
> Adam
>



-- 
Best regards,
Michael

Bug#892764: stretch-pu: package i3-wm/4.13-1

[Michael Stapelberg]

On Tue, Jul 3, 2018 at 10:01 PM, Adam D. Barratt 
wrote:

> Control: tags -1 + moreinfo
>
> On Mon, 2018-03-12 at 19:23 +0100, Michael Stapelberg wrote:
> > I would like to apply the attached update to the i3-wm package to
> > satisfy a user
> > request (#891919) for a backported upstream fix to address a crash
> > when using
> > window marks and restarting i3 in-place.
> >
>
> Apologies for the delay in getting back to you.
>
> The metadata for #891919 suggests that it affects the version of i3-wm
> in unstable - is that correct? If it is, then please fix the package in
> unstable first; if not, then please fix the metadata.
>

i3 ≥ 4.14 contain the fix, so the versions in testing and unstable are
fixed.

I’m not good with the BTS. Can you share the correct command to do what’s
required before we can move forward please?


>
> Regards,
>
> Adam
>



-- 
Best regards,
Michael

Bug#901626: libtomcrypt: CVE-2018-12437

[Michael Stapelberg]

Filed https://github.com/libtom/libtomcrypt/issues/407, let’s see when
upstream comes up with a patch.

On Fri, Jun 15, 2018 at 9:22 PM, Salvatore Bonaccorso 
wrote:

> Source: libtomcrypt
> Version: 1.18.1-1
> Severity: grave
> Tags: security upstream
>
> Hi,
>
> The following vulnerability was published for libtomcrypt.
>
> CVE-2018-12437[0]:
> | LibTomCrypt through 1.18.1 allows a memory-cache side-channel attack on
> | ECDSA signatures, aka the Return Of the Hidden Number Problem or ROHNP.
> | To discover an ECDSA key, the attacker needs access to either the local
> | machine or a different virtual machine on the same physical host.
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2018-12437
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12437
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore
>



-- 
Best regards,
Michael

Bug#901257: Please consider adopting zchunk for efficient updates

[Michael Stapelberg]

Source: apt
Severity: wishlist

I recently stumbled upon this blog post:
https://www.jdieter.net/posts/2018/05/31/what-is-zchunk/

The zchunk format, outlined in the post, is being introduced in Fedora for
efficient metadata transfer.

I can imagine (but haven’t verified it) that this format is more efficient and
flexible (suitable for both fast and slow internet connections/computers) than
our current pdiff approach.

Thanks for considering,

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/bazel.list present, but not submitted) --


-- (/etc/apt/sources.list.d/cc65.list present, but not submitted) --


-- (/etc/apt/sources.list.d/google-chrome.list present, but not submitted) --


-- (/etc/apt/sources.list.d/i3-autobuild.list present, but not submitted) --


-- (/etc/apt/sources.list.d/keybase.list present, but not submitted) --


-- (/etc/apt/sources.list.d/vscode.list present, but not submitted) --


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.14.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#898397: [pkg-go] Bug#898397: dh-make-golang: allow authentication to github API to avoid hitting limits

[Michael Stapelberg]

fixed in
https://github.com/Debian/dh-make-golang/commit/db00c3774281436cc182d81463fbc86d791ec019

On Fri, May 11, 2018 at 6:58 AM, Paul Wise  wrote:

> Package: dh-make-golang
> Version: 0.0~git20180410.bcfd5bf-1
> Severity: wishlist
>
> I packaged a bunch of dependencies for git-lab and then I started
> getting 403 errors from github URLs. It looks like dh-make-golang
> easily hits the github API rate limit for anonymous users.
>
> Allowing authenticated requests could help to avoid the limit.
>
> $ dh-make-golang make github.com/avast/retry-go
> 2018/05/11 12:51:52 Downloading "github.com/avast/retry-go/..."
> 2018/05/11 12:51:53 Determining upstream version number
> 2018/05/11 12:51:53 Package version is "1.0.2"
> 2018/05/11 12:51:53 Determining dependencies
> 2018/05/11 12:51:57 Could not determine long description for "
> github.com/avast/retry-go": unexpected HTTP status: got 403, want 200
> 2018/05/11 12:51:58 Could not determine copyright for "
> github.com/avast/retry-go": parsing time "" as "2006-01-02T15:04:05Z":
> cannot parse "" as "2006"
> 2018/05/11 12:51:59 Could not determine author for "
> github.com/avast/retry-go": parsing time "" as "2006-01-02T15:04:05Z":
> cannot parse "" as "2006"
> 2018/05/11 12:51:59 Could not determine long description for "
> github.com/avast/retry-go": unexpected HTTP status: got 403, want 200
> ...
>
> $ curl -s https://api.github.com/users/pabs3 | jq
> {
>   "message": "API rate limit exceeded for . (But here's the good
> news: Authenticated requests get a higher rate limit. Check out the
> documentation for more details.)",
>   "documentation_url": "https://developer.github.com/v3/#rate-limiting;
> }
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
> LANGUAGE=en_AU.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages dh-make-golang depends on:
> ii  git   1:2.17.0-1
> ii  git-buildpackage  0.9.8
> ii  golang-any2:1.10~5
> ii  libc6 2.27-3
> ii  pristine-tar  1.42
>
> Versions of packages dh-make-golang recommends:
> ii  exim4-daemon-light [mail-transport-agent]  4.91-3
>
> dh-make-golang suggests no packages.
>
> -- no debconf information
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-go-maintainers
>



-- 
Best regards,
Michael

Bug#896952: [Pkg-freeradius-maintainers] Bug#896952: freeradius: NT/LM password check fails, if Calling-Station-Id per user check activated

[Michael Stapelberg]

Thanks for your message. This seems like an upstream issue, not like an
issue with the Debian packaging.

Hence, could you please redirect your question to the FreeRADIUS mailing
list? See https://freeradius.org/support/

On Thu, Apr 26, 2018 at 11:46 AM, Marek Lukács 
wrote:

> Package: freeradius
> Version: 3.0.12+dfsg-5+deb
> Architecture: amd64
>
> I want to have per user MAC address checking and per user VLAN
> assignment. It is possible if:
>
>
>
> 1/ Requests attributes are copied into inner tunnel by adding
>
> copy_request_to_tunnel = yes
>
> into
>
> eap { peap { } }
>
> in file /etc/freeradius/3.0/mods-enabled/eap
>
>
>
> 2/ Send inner tunnel attributes to outside by adding
>
> use_tunneled_reply = yes
>
> into
>
> eap { peap { } }
>
> in file /etc/freeradius/3.0/mods-enabled/eap
>
>
>
> 3/ users are defined like:
>
> username Cleartext-Password := "password" , Calling-Station-ID ==
> "00-DE-AD-BE-EF-00"
> Tunnel-Type = VLAN,
> Tunnel-Medium-Type = IEEE-802,
> Tunnel-Private-Group-ID = 100,
> Fall-Through = Yes
>
> in file /etc/freeradius/3.0/users
>
>
>
> This works fine and MAC address is checked for Android devices. But if
> using Windows 10 device, authentication fails with:
>
> (7) eap_mschapv2: # Executing group from file
> /etc/freeradius/3.0/sites-enabled/inner-tunnel
> (7) eap_mschapv2:   authenticate {
> (7) mschap: WARNING: No Cleartext-Password configured.  Cannot create
> NT-Password
> (7) mschap: WARNING: No Cleartext-Password configured.  Cannot create
> LM-Password
> (7) mschap: Creating challenge hash with username: czpzlpwd0006
> (7) mschap: Client is using MS-CHAPv2
> (7) mschap: ERROR: FAILED: No NT/LM-Password.  Cannot perform
> authentication
> (7) mschap: ERROR: MS-CHAP2-Response is incorrect
> (7) [mschap] = reject
> (7)   } # authenticate = reject
>
>
>
>
> But it happens only if Calling-Station-ID is next to
> Cleartext-Password in users file. If that line does not have
> Calling-Station-ID and user is defined like:
>
> username Cleartext-Password := "password"
> Tunnel-Type = VLAN,
> Tunnel-Medium-Type = IEEE-802,
> Tunnel-Private-Group-ID = 100,
> Fall-Through = Yes
>
> Authentication works and Windows 10 device is authenticated, but no
> MAC address is checked.
>
>
>
> My other modifications to my configurations:
>
> 1/ enabled ntdomain realms in
> /etc/freeradius/3.0/sites-enabled/default and
> /etc/freeradius/3.0/sites-enabled/inner-tunnel
>
> 2/ configured local DOMAIN in /etc/freeradius/3.0/proxy.conf
>
> realm DOMAIN {
> }
>
>
>
> It looks, like mschap is using NTLM password checking if MS Windows
> device is authenticating, but another method (MD5?) if it is Android
> device.
>
> It results that users with Android device can be configured including
> Calling-Station-ID, but Windows devices must be configured without
> Calling-Station-ID, so no MAC address checking for Windows devices.
> For me it looks, like mschap NT/LM auth is not parsing correctly the
> line, if there is Calling-Station-ID.
>
> I expect, that I can use per user MAC address checking independently
> on used end device, so Android and Windows users can be configured
> with Calling-Station-ID.
>
>
>
> I am using Debian GNU/Linux 9.4, kernel 4.9.0-6-amd64 #1 SMP Debian
> 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux and libc6
> 2.24-11+deb9u3.
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-freeradius-maintainers
>



-- 
Best regards,
Michael

Bug#893577: sbuild-debian-developer-setup: Should not rely on files in /usr/share/doc

[Michael Stapelberg]

josch, could you let me know whether the attached patch does what you have
in mind please? Thanks!

On Tue, Mar 27, 2018 at 2:47 PM, Johannes Schauer  wrote:

> Hi all,
>
> > At the end of the script, it runs
> >
> > symlink("/usr/share/doc/sbuild/examples/sbuild-update-all",
> "/etc/cron.daily/sbuild-debian-developer-setup-update-all");
> >
> > which requires the file in /usr/share/doc to be present. Policy 12.3
> says that
> > packages can't do that and says that such files should be in
> > /usr/share/package with a symlink into /usr/share/doc/package/ as
> > appropriate.
>
> probably the right thing to do would be to let the
> sbuild-debian-developer-setup package directly install sbuild-update-all
> into
> /etc/cron.daily/sbuild-debian-developer-setup-update-all. If necessary,
> sbuild-update-all has to be adapted such that it will not barf if the user
> has
> not yet run sbuild-debian-developer-setup.
>
> This would mean that the same copy of sbuild-update-all would potentially
> exist
> twice on a system, but I don't think that's much of a problem.
>
> Michael, can you take care of this?
>
> Thanks!
>
> cheers, josch
>



-- 
Best regards,
Michael
diff --git i/debian/rules w/debian/rules
index bc15c043..b1bfe785 100755
--- i/debian/rules
+++ w/debian/rules
@@ -3,5 +3,10 @@
 %:
 	dh $@
 
+override_dh_install:
+	cp etc/sbuild-update-all etc/sbuild-debian-developer-setup-update-all
+	chmod +x etc/sbuild-debian-developer-setup-update-all
+	dh_install
+
 override_dh_installinit:
 	dh_installinit --no-start --no-restart-on-upgrade
diff --git i/debian/sbuild-debian-developer-setup.install w/debian/sbuild-debian-developer-setup.install
index 406b3af9..6d2a1699 100644
--- i/debian/sbuild-debian-developer-setup.install
+++ w/debian/sbuild-debian-developer-setup.install
@@ -1 +1,2 @@
 usr/bin/sbuild-debian-developer-setup
+etc/sbuild-debian-developer-setup-update-all etc/cron.daily
diff --git i/etc/sbuild-update-all w/etc/sbuild-update-all
index 12a394cb..3e22d05a 100644
--- i/etc/sbuild-update-all
+++ w/etc/sbuild-update-all
@@ -76,7 +76,7 @@ exec 1>&8
 if ! ls /etc/schroot/chroot.d/$PATTERN >/dev/null 2>&1
 then
 	echo "No chroots defined"
-	break
+	exit 0
 fi
 
 for fullname in /etc/schroot/chroot.d/$PATTERN

Bug#894862: [pkg-go] Bug#894862: dh-golang: DH_GOPKG is empty in debian/rules, while documentation states that it's automatically set

[Michael Stapelberg]

dpkg-buildpackage calls debian/rules (see
https://people.debian.org/~stapelberg//2016/11/25/build-tools.html), which
calls debhelper, including Debian::Debhelper::Buildsystem::golang(3pm),
which uses the DH_GOPKG variable (either from the environment, i.e. via
debian/rules, or from debian/control).

In other words: the value you specify in debian/control unfortunately
cannot be made available in debian/rules.

If you need to use DH_GOPKG in debian/rules, I recommend to define it both
in debian/control and in debian/rules as well.

This issue should be fixed with a documentation update. Could you supply a
patch please? You know best at which point the wording becomes clear enough
:). Thanks!

On Thu, Apr 5, 2018 at 4:55 AM, Arnaud Rebillout <
arnaud.rebill...@collabora.com> wrote:

> Package: dh-golang
> Version: 1.34
> Severity: normal
>
> Dear Maintainer,
>
> According to `man dh-golang`:
>
>   "DH_GOPKG" (string) contains the Go package name which this Debian
>   package is building.
>
>   "DH_GOPKG" is automatically set to the value of the first import path
>   of the "XS-Go-Import-Path" "debian/control" field, which can contain
>   several comma-separated import paths.
>
> However, I tried to use this variable in the debian/rules file, in
> targets such as `override_dh_auto_test` and `override_dh_auto_build`,
> and this variable is empty.
>
> I added some debug to dh-golang, and I clearly see the code from
> `_set_dh_gopkg` being executed, and the variable is set there. So it
> looks like the environment in `debian/rules` is unrelated to the
> environment that is set by dh-golang.
>
> If it's expected, then maybe the man page needs a little rewording. If
> it's not expected, then it's a bug?
>
> Regards,
>
>   Arnaud
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages dh-golang depends on:
> ii  debhelper 11.1.5
> ii  dpkg  1.19.0.5
> ii  libdpkg-perl  1.19.0.5
> ii  perl  5.26.1-5
>
> dh-golang recommends no packages.
>
> dh-golang suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
Best regards,
Michael

Bug#893608: sbuild: Silent arch:all defaults change breaks buildd setups

[Michael Stapelberg]

control: tags -1 + pending

Hi James,

James Clarke  writes:
> In the latest upload, #870263 was fixed (which I support, for what it's worth;
> any+all builds is the right default for users), meaning that buildd setups now
> build arch:all packages, which we *have* to work around by setting
> $build_arch_all=0 in sbuild.conf. Without this, uploads are rejected by the
> archive (the buildd's signing key does not have upload rights for arch:all
> packages, the arch:all packages already exist, etc). This is therefore a
> breaking change, and so deserves at least a mention in the NEWS file. 
> Moreover,
> having to configure this in sbuild.conf is sub-optimal; ideally, buildd would
> pass --no-arch-all to sbuild when an arch:any build is requested by 
> wanna-build;
> as far as I know, the assumption is always that a non-Architecture:all build 
> is
> arch:any.

Addressed by the following commit IIUC:
https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=821144b5ef48bb11bf98657349ba808c25452721

> We probably also don't want lintian run during buildd builds as it fork-bombs 
> on
> packages like gcc-8-cross-ports (#890873), and there's lintian.debian.org 
> doing
> that for x86, which is probably good enough, though I suppose in an ideal 
> world
> it would be run too.

https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=e8da1ee764d8b3b5aaa0fe82aac8e877f1cc4f4d

-- 
Best regards,
Michael

Bug#848101: [Pkg-raspi-maintainers] Bug#848101: Bug#848101: marked as done (Package name + config.txt & cmdline.txt as conffiles)

[Michael Stapelberg]

Thanks for the hint, I missed that location. Uploaded -3 with a fix.

On Wed, Mar 21, 2018 at 1:49 PM, Arjen Balfoort 
wrote:

> Error on postinst raspi3-firmware 1.20180316-2:
>
> DEB_MAINT_PARAMS="configure" /etc/kernel/postinst.d/raspi3-firmware
>
> should be:
>
> DEB_MAINT_PARAMS="configure" /etc/kernel/postinst.d/50raspi3-firmware
>
>
> After fixing that the package installed correctly and I could set up a
> hook to overwrite cmdline.txt and config.txt on kernel update.
> Custom package created for SolydX RPi3: https://github.com/SolydXK/sol
> ydx-raspi3-adjustments
>
> ___
> Pkg-raspi-maintainers mailing list
> pkg-raspi-maintain...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-raspi-maintainers
>



-- 
Best regards,
Michael

Bug#848101: [Pkg-raspi-maintainers] Bug#848101: cmdline.txt and config.txt overwritten with each initramfs update

[Michael Stapelberg]

On Tue, Mar 13, 2018 at 10:14 AM, Arjen Balfoort 
wrote:

> I'm currently building a RPi3 version of SolydX. For the Xfce desktop to
> successfully load I need to change the boot parameters.
>
> cmdline.txt:
> console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw elevator=deadline
> fsck.repair=yes net.ifnames=0 rootwait cma=256M quiet splash loglevel=0
> vt.global_cursor_default=0 plymouth.ignore-serial-consoles
>
> config.txt:
> arm_control=0x200
> kernel=vmlinuz-4.14.0-3-arm64
> initramfs initrd.img-4.14.0-3-arm64 followkernel
> disable_splash=1
> enable_uart=1
> device_tree=bcm2837-rpi-3-b.dtb
> gpu_mem=16
> dtoverlay=pi3-disable-bt
> dtparam=audio=on
>
> Note: I needed the "cma=256M" in cmdline.txt. Any lower Xfce would freeze
> on login.
>
> As the OP mentioned, these files are now overwritten with each initramfs
> update. I tried to create a hook script for initramfs-tools to restore
> backup files to cmdline.txt and config.txt but so far I didn't succeed in
> that.
>
> In a desktop environment it regularly happens that initramfs is updated
> and overwriting these files always results in a frozen desktop and that is
> not something I can trust our users with.
>
> Is there a way to prevent this behavior or does anybody know how to run a
> script after initramfs has been updated?
>

I think we should rename our hook from “raspi3-firmware” to
“50raspi3-firmware”. update-initramfs uses run-parts(8) to invoke hooks, so
you could then ship a hook with a higher number which would be guaranteed
to run after the raspi3-firmware hook.

Let me know if that sounds good, and I’ll prepare a package upload.


>
> ___
> Pkg-raspi-maintainers mailing list
> pkg-raspi-maintain...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-raspi-maintainers
>



-- 
Best regards,
Michael

Bug#893470: ITP: debiman -- generate a static manpage HTML repository out of a Debian archive

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg <stapelb...@debian.org>

* Package name: debiman
  Version : 0.0~git20180224.8582b7f-1
  Upstream Author : Michael Stapelberg
* URL : https://github.com/Debian/debiman
* License : Apache-2.0
  Programming Lang: Go
  Description : generate a static manpage HTML repository out of a Debian 
archive

 debiman makes (Debian) manpages accessible in a web browser. Its
 goals are, in order:
 .
 completeness: all manpages in Debian should be available.
 .
 visually appealing and convenient: reading manpages should be fun, convenience
 features (e.g. permalinks, URL redirects, easy navigation) should be available
 .
 speed: manpages should be quick to load, new manpages should be quickly
 ingested, the program should run quickly for pleasant development

Bug#893171: Support non git packages

[Michael Stapelberg]

Hi Pirate,

Pirate Praveen  writes:

> Package: dh-make-golang
> Version: 0.0~git20180129.37f630a-1+b1
> severity: wishlist
>
> I'm trying to update gitaly to new upstream version.
>
> I got
> src/gitlab.com/gitlab-org/gitaly/internal/rubyserver/balancer/balancer.go:24:2:
> cannot find package "google.golang.org/grpc/resolver" in any of:
>   
> /<>/gitaly-0.88.0+debian/obj-x86_64-linux-gnu/src/gitlab.com/gitlab-org/gitaly/vendor/google.golang.org/grpc/resolver
>  (vendor tree)
>   /usr/lib/go-1.10/src/google.golang.org/grpc/resolver (from $GOROOT)
>   
> /<>/gitaly-0.88.0+debian/obj-x86_64-linux-gnu/src/google.golang.org/grpc/resolver
>  (from $GOPATH)
>
> So I try to package it.
>
> $ dh-make-golang google.golang.org/grpc/resolver
> 2018/03/17 05:52:13 Downloading "google.golang.org/grpc/resolver/..."
> 2018/03/17 05:52:21 Could not create a tarball of the upstream source:
> Not a git repository, dh-make-golang currently only supports git

FYI, this issue has already been fixed in
https://github.com/Debian/dh-make-golang/commit/4fdef9cee722e23f8b07657eef1502b79366183e,
which the version you have installed does not yet contain.

With the fix, I’m getting:

% dh-make-golang google.golang.org/grpc/resolver
2018/03/19 08:14:21 Continuing with repository root "google.golang.org/grpc" 
instead of specified import path "google.golang.org/grpc/resolver" 
(repositories are the unit of packaging in Debian)
[…]

-- 
Best regards,
Michael

Bug#892936: ITP: golang-pault-go-archive -- bindings to work with a Debian archive

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg <stapelb...@debian.org>

* Package name: golang-pault-go-archive
  Version : 0.0~git20180223.29fe7b6-1
  Upstream Author : Paul Tagliamonte
* URL : https://github.com/paultag/go-archive
* License : Expat
  Programming Lang: Go
  Description : bindings to work with a Debian archive
 pault.ag/go/archive is a set of non-production test bindings to work with a
 Debian archive

This is a (transitive) dependency of Debiman.

Bug#892934: ITP: golang-pault-go-blobstore --

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg <stapelb...@debian.org>

* Package name: golang-pault-go-blobstore
  Version : 0.0~git20180314.d6d187c-1
  Upstream Author : Paul Tagliamonte
* URL : https://github.com/paultag/go-blobstore
* License : Expat
  Programming Lang: Go
  Description : de-duplicating storage abstraction
 pault.ag/go/blobstore is a de-duplicating storage abstraction, useful for
 example for building Debian repositories with pault.ag/go/archive.

This is a (transitive) dependency of Debiman.

Bug#859867: [buildd-tools-devel] Bug#859867: Please add a package which automatically configures sbuild for Debian packaging

[Michael Stapelberg]

Okay.

Given the severely constrained manpower from all involved sides, I think
the best path forward to make some progress is to continue the review (and
eventual merge, hopefully) of my proposed patch in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859867#105. If we want to
expand scope, we can do that later.

josch, could you take another look at the patch, please? Thank you.

On Fri, Jan 5, 2018 at 2:09 PM, Raphael Hertzog <hert...@debian.org> wrote:

> On Fri, 05 Jan 2018, Michael Stapelberg wrote:
> > Raphaël, Benjamin, what’s the current status? It’s been quite a number
> > of months since https://bugs.debian.org/859867#122, and I’m still very
> > interested in having sbuild easily installable.
>
> Benjamin never answered on the willingness to host this new infrastructure
> within packaging-dev.
>
> As for me, while I'm still supportive of the idea, I'm afraid that I won't
> be able to contribute code in the near future. I have other priorities
> related to tracker.debian.org. Hopefully my ideas will help you design
> something modular enough to cover the needs of derivatives. Please keep
> me in the loop, I might be able to help once it becomes a bit more
> concrete and then I might be able to invest some time as part of my work
> on Kali.
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: https://www.freexian.com/services/debian-lts.html
> Learn to master Debian: https://debian-handbook.info/get/
>



-- 
Best regards,
Michael