Bug#1069023: Using the library with cmake fails because of wrong path calculation in apriltagTargets.cmake

2024-04-15 Thread Thorsten Jordan
Package: libapriltag-dev
Version: 3.3.0-2.1

When using the library with cmake it doesn't work, because the file is placed 
one level of directories deeper than are unwinded in the cmake file.

See the patch below that fixes it.

--- /usr/lib/x86_64-linux-gnu/cmake/apriltag/apriltagTargets.cmake  
2024-01-05 17:49:51.0 +
+++ /usr/lib/x86_64-linux-gnu/cmake/apriltag/apriltagTargets.cmake  
2024-02-14 09:40:27.219443228 +
@@ -49,10 +49,11 @@
 # Compute the installation prefix relative to this file.
 get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
 get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
 get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
 get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
+get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
 if(_IMPORT_PREFIX STREQUAL "/")
   set(_IMPORT_PREFIX "")
 endif()
 
 # Create imported target apriltag::apriltag



Bug#1064899: nix-bin: fails to find nixpkgs, no $NIX_PATH found

2024-03-19 Thread Jordan Justen
On 2024-02-27 04:20:02, Walter Bleach wrote:
> 
> This is my first time trying out nix, however I could not get it to
> work. 
> 
> ~$ sudo nix-shell -p cowsay
> [sudo] password for farhad:
> error: file 'nixpkgs' was not found in the Nix search path (add it using 
> $NIX_PATH or -I)

Do you want to run this as root (sudo)? If you add your user to the
nix-users group, I think you should be able to run `nix-shell -p
cowsay` as your user without sudo. (Assuming you also added a channel
like mention in the nix-channel man page.)

Oh, I also manually added this in ~/.bashrc:

if [ -e "$HOME/.nix-defexpr/channels" ]; then
  export NIX_PATH="$HOME/.nix-defexpr/channels${NIX_PATH:+:$NIX_PATH}"
fi

This seems like something we might want to consider handling in the
nix debian packaging by updating /etc/profile.d. (Or, at least mention
in /usr/share/doc/nix-bin/README.Debian.)

-Jordan


signature.asc
Description: signature


Bug#1064496: chromium ignores orca say all settings and makes orca read by line instead

2024-02-23 Thread jordan
Package: chromium
Version: 122.0.6261.57-1~deb12u1
Severity: important
X-Debbugs-Cc: jordanlives...@gmail.com

Dear Maintainer,
there is a problem with chromium and orca, regardless of how you set up orca's 
say all settings, chromium content is being read by line instead. this bug has 
been present since version 99 released in march 2022
*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***
the only valid option was to get an old copy of chromium 98 and use that, but 
that isn't ideal and its old at this point. version 98 doesn't have the issue 
and I haven't heard anything since updating my chromium bugtracker report, if 
you need that I can send that in a reply

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common 122.0.6261.57-1~deb12u1
ii  libasound2  1.2.8-1+b1
ii  libatk-bridge2.0-0  2.46.0-5
ii  libatk1.0-0 2.46.0-5
ii  libatomic1  12.2.0-14
ii  libatspi2.0-0   2.46.0-5
ii  libc6   2.36-9+deb12u4
ii  libcairo2   1.16.0-7
ii  libcups22.4.2-3+deb12u5
ii  libdbus-1-3 1.14.10-1~deb12u1
ii  libdouble-conversion3   3.2.1-1
ii  libdrm2 2.4.114-1+b1
ii  libevent-2.1-7  2.1.12-stable-8
ii  libexpat1   2.5.0-1
ii  libflac12   1.4.2+ds-2
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgbm1 22.3.6-1+deb12u1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.38-2~deb12u1
ii  libjpeg62-turbo 1:2.1.5-2
ii  libjsoncpp251.9.5-4
ii  liblcms2-2  2.14-2
ii  libminizip1 1.1-8+deb12u1
ii  libnspr42:4.35-1
ii  libnss3 2:3.87.1-1
ii  libopenh264-7   2.3.1+dfsg-3
ii  libopenjp2-72.5.0-2
ii  libopus01.3.1-3
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpng16-16 1.6.39-2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsnappy1v51.1.9-3
ii  libstdc++6  12.2.0-14
ii  libwebp71.2.4-0.2+deb12u1
ii  libwebpdemux2   1.2.4-0.2+deb12u1
ii  libwebpmux3 1.2.4-0.2+deb12u1
ii  libwoff11.0.2-2
ii  libx11-62:1.8.4-2+deb12u2
ii  libxcb1 1.15-1
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.6-1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2
ii  libxkbcommon0   1.5.0-1
ii  libxml2 2.9.14+dfsg-1.3~deb12u1
ii  libxnvctrl0 525.85.05-3~deb12u1
ii  libxrandr2  2:1.5.2-2+b1
ii  libxslt1.1  1.1.35-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend  1.14.1-1
]
ii  zlib1g  1:1.2.13.dfsg-1

Versions 

Bug#1063338: [regression 6.1.76] dlm: cannot start dlm midcomms -97 after backport of e9cdebbe23f1 ("dlm: use kernel_connect() and kernel_bind()")

2024-02-09 Thread Jordan Rife
I sent this patch out to sta...@vger.kernel.org. Everyone should be
CCd. Thanks for your help in confirming the fix works.

-Jordan



Bug#1063338: [regression 6.1.76] dlm: cannot start dlm midcomms -97 after backport of e9cdebbe23f1 ("dlm: use kernel_connect() and kernel_bind()")

2024-02-08 Thread Jordan Rife
Hi Valentin,

Would you be able to confirm that the attached patch fixes your issue as well?

-Jordan

On Thu, Feb 8, 2024 at 9:42 AM Jordan Rife  wrote:
>
> On Thu, Feb 8, 2024 at 3:37 AM Valentin Kleibel  wrote:
> >
> > Hi Jordan, hi all
> >
> > > Just a quick look comparing dlm_tcp_listen_bind between the latest 6.1
> > > and 6.6 stable branches,
> > > it looks like there is a mismatch here with the dlm_local_addr[0] 
> > > parameter.
> > >
> > > 6.1
> > > 
> > >
> > > static int dlm_tcp_listen_bind(struct socket *sock)
> > > {
> > > int addr_len;
> > >
> > > /* Bind to our port */
> > > make_sockaddr(dlm_local_addr[0], dlm_config.ci_tcp_port, _len);
> > > return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
> > > addr_len);
> > > }
> > >
> > > 6.6
> > > 
> > > static int dlm_tcp_listen_bind(struct socket *sock)
> > > {
> > > int addr_len;
> > >
> > > /* Bind to our port */
> > > make_sockaddr(_local_addr[0], dlm_config.ci_tcp_port, _len);
> > > return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
> > > addr_len);
> > > }
> > >
> > > 6.6 contains commit c51c9cd8 (fs: dlm: don't put dlm_local_addrs on heap) 
> > > which
> > > changed
> > >
> > > static struct sockaddr_storage *dlm_local_addr[DLM_MAX_ADDR_COUNT];
> > >
> > > to
> > >
> > > static struct sockaddr_storage dlm_local_addr[DLM_MAX_ADDR_COUNT];
> > >
> > > It looks like kernel_bind() in 6.1 needs to be modified to match.
> >
> > We tried to apply commit c51c9cd8 (fs: dlm: don't put dlm_local_addrs on
> > heap) to the debian kernel 6.1.76 and came up with the attached patch.
> > Besides the different offsets there is a slight change dlm_tcp_bind()
> > where in 6.1.76 kernel_bind() is used instead of sock->ops->bind() in
> > the original commit.
> >
> > This patch solves the issue we experienced.
> >
> > Thanks for your help,
> > Valentin
>
> Good to hear that works for you! We should fix this in the 6.1 stable
> kernel as well.
>
> IMO it may be less risky and simpler to fix the backport of my patch
> e9cdebbe23f1 ("dlm: use kernel_connect() and
> kernel_bind()") and just switch (struct sockaddr *)_local_addr[0]
> to (struct sockaddr *)dlm_local_addr[0]
> in the call to kernel_bind() rather than backporting c51c9cd8 (fs:
> dlm: don't put dlm_local_addrs on
> heap) to 6.1.
>
> I will have some time soon to fix the 6.1 backport, but it may make
> sense just to revert in the meantime.
>
> -Jordan
From dec5ffd309967e429b616a9d498037a5eb437c54 Mon Sep 17 00:00:00 2001
From: Jordan Rife 
Date: Thu, 8 Feb 2024 12:09:55 -0600
Subject: [PATCH] dlm: Treat dlm_local_addr[0] as sockaddr_storage *

Backport e11dea8 ("dlm: use kernel_connect() and kernel_bind()") to
Linux stable 6.1 caused a regression. The original patch expected
dlm_local_addrs[0] to be of type sockaddr_storage, because c51c9cd ("fs:
dlm: don't put dlm_local_addrs on heap") changed its type from
sockaddr_storage* to sockaddr_storage in Linux 6.5+ while in older Linux
versions this is still the original sockaddr_storage*.

Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063338
Fixes: e11dea8 ("dlm: use kernel_connect() and kernel_bind()")
Signed-off-by: Jordan Rife 
---
 fs/dlm/lowcomms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 72f34f96d0155..8426073e73cf2 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -1900,7 +1900,7 @@ static int dlm_tcp_listen_bind(struct socket *sock)
 
 	/* Bind to our port */
 	make_sockaddr(dlm_local_addr[0], dlm_config.ci_tcp_port, _len);
-	return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
+	return kernel_bind(sock, (struct sockaddr *)dlm_local_addr[0],
 			   addr_len);
 }
 
-- 
2.43.0.687.g38aa6559b0-goog



Bug#1063338: [regression 6.1.76] dlm: cannot start dlm midcomms -97 after backport of e9cdebbe23f1 ("dlm: use kernel_connect() and kernel_bind()")

2024-02-08 Thread Jordan Rife
On Thu, Feb 8, 2024 at 3:37 AM Valentin Kleibel  wrote:
>
> Hi Jordan, hi all
>
> > Just a quick look comparing dlm_tcp_listen_bind between the latest 6.1
> > and 6.6 stable branches,
> > it looks like there is a mismatch here with the dlm_local_addr[0] parameter.
> >
> > 6.1
> > 
> >
> > static int dlm_tcp_listen_bind(struct socket *sock)
> > {
> > int addr_len;
> >
> > /* Bind to our port */
> > make_sockaddr(dlm_local_addr[0], dlm_config.ci_tcp_port, _len);
> > return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
> > addr_len);
> > }
> >
> > 6.6
> > 
> > static int dlm_tcp_listen_bind(struct socket *sock)
> > {
> > int addr_len;
> >
> > /* Bind to our port */
> > make_sockaddr(_local_addr[0], dlm_config.ci_tcp_port, _len);
> > return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
> > addr_len);
> > }
> >
> > 6.6 contains commit c51c9cd8 (fs: dlm: don't put dlm_local_addrs on heap) 
> > which
> > changed
> >
> > static struct sockaddr_storage *dlm_local_addr[DLM_MAX_ADDR_COUNT];
> >
> > to
> >
> > static struct sockaddr_storage dlm_local_addr[DLM_MAX_ADDR_COUNT];
> >
> > It looks like kernel_bind() in 6.1 needs to be modified to match.
>
> We tried to apply commit c51c9cd8 (fs: dlm: don't put dlm_local_addrs on
> heap) to the debian kernel 6.1.76 and came up with the attached patch.
> Besides the different offsets there is a slight change dlm_tcp_bind()
> where in 6.1.76 kernel_bind() is used instead of sock->ops->bind() in
> the original commit.
>
> This patch solves the issue we experienced.
>
> Thanks for your help,
> Valentin

Good to hear that works for you! We should fix this in the 6.1 stable
kernel as well.

IMO it may be less risky and simpler to fix the backport of my patch
e9cdebbe23f1 ("dlm: use kernel_connect() and
kernel_bind()") and just switch (struct sockaddr *)_local_addr[0]
to (struct sockaddr *)dlm_local_addr[0]
in the call to kernel_bind() rather than backporting c51c9cd8 (fs:
dlm: don't put dlm_local_addrs on
heap) to 6.1.

I will have some time soon to fix the 6.1 backport, but it may make
sense just to revert in the meantime.

-Jordan



Bug#1063338: [regression 6.1.67] dlm: cannot start dlm midcomms -97 after backport of e9cdebbe23f1 ("dlm: use kernel_connect() and kernel_bind()")

2024-02-07 Thread Jordan Rife
On Wed, Feb 7, 2024 at 2:39 AM Salvatore Bonaccorso  wrote:
>
> Hi Valentin, hi all
>
> [This is about a regression reported in Debian for 6.1.67]
>
> On Tue, Feb 06, 2024 at 01:00:11PM +0100, Valentin Kleibel wrote:
> > Package: linux-image-amd64
> > Version: 6.1.76+1
> > Source: linux
> > Source-Version: 6.1.76+1
> > Severity: important
> > Control: notfound -1 6.6.15-2
> >
> > Dear Maintainers,
> >
> > We discovered a bug affecting dlm that prevents any tcp communications by
> > dlm when booted with debian kernel 6.1.76-1.
> >
> > Dlm startup works (corosync-cpgtool shows the dlm:controld group with all
> > expected nodes) but as soon as we try to add a lockspace dmesg shows:
> > ```
> > dlm: Using TCP for communications
> > dlm: cannot start dlm midcomms -97
> > ```
> >
> > It seems that commit "dlm: use kernel_connect() and kernel_bind()"
> > (e9cdebbe) was merged to 6.1.
> >
> > Checking the code it seems that the changed function dlm_tcp_listen_bind()
> > fails with exit code 97 (EAFNOSUPPORT)
> > It is called from
> >
> > dlm/lockspace.c: threads_start() -> dlm_midcomms_start()
> > dlm/midcomms.c: dlm_midcomms_start() -> dlm_lowcomms_start()
> > dlm/lowcomms.c: dlm_lowcomms_start() -> dlm_listen_for_all() ->
> > dlm_proto_ops->listen_bind() = dlm_tcp_listen_bind()
> >
> > The error code is returned all the way to threads_start() where the error
> > message is emmitted.
> >
> > Booting with the unsigned kernel from testing (6.6.15-2), which also
> > contains this commit, works without issues.
> >
> > I'm not sure what additional changes are required to get this working or if
> > rolling back this change is an option.
> >
> > We'd be happy to test patches that might fix this issue.
>
> Thanks for your report. So we have a 6.1.76 specific regression for
> the backport of e9cdebbe23f1 ("dlm: use kernel_connect() and
> kernel_bind()") .
>
> Let's loop in the upstream regression list for tracking and people
> involved for the subsystem to see if the issue can be identified. As
> it is working for 6.6.15 which includes the commit backport as well it
> might be very well that a prerequisite is missing.
>
> # annotate regression with 6.1.y specific commit
> #regzbot ^introduced e11dea8f503341507018b60906c4a9e7332f3663
> #regzbot link: https://bugs.debian.org/1063338
>
> Any ideas?
>
> Regards,
> Salvatore


Just a quick look comparing dlm_tcp_listen_bind between the latest 6.1
and 6.6 stable branches,
it looks like there is a mismatch here with the dlm_local_addr[0] parameter.

6.1


static int dlm_tcp_listen_bind(struct socket *sock)
{
int addr_len;

/* Bind to our port */
make_sockaddr(dlm_local_addr[0], dlm_config.ci_tcp_port, _len);
return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
   addr_len);
}

6.6

static int dlm_tcp_listen_bind(struct socket *sock)
{
int addr_len;

/* Bind to our port */
make_sockaddr(_local_addr[0], dlm_config.ci_tcp_port, _len);
return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
   addr_len);
}

6.6 contains commit c51c9cd8 (fs: dlm: don't put dlm_local_addrs on heap) which
changed

static struct sockaddr_storage *dlm_local_addr[DLM_MAX_ADDR_COUNT];

to

static struct sockaddr_storage dlm_local_addr[DLM_MAX_ADDR_COUNT];

It looks like kernel_bind() in 6.1 needs to be modified to match.


-Jordan



Bug#985017: python3-whoosh: SyntaxWarning during package installation

2024-01-03 Thread AJ Jordan

Here is the upstream patch for backporting:

https://github.com/mchaput/whoosh/commit/d9a3fa2a4905e7326c9623c89e6395713c189161

-AJ



Bug#1053119: orca fails to read file names when navigating some folders in caja+mate menu issues

2023-09-27 Thread Jordan Livesey
sometimes the bug is reproducible sometimes it isn't, this has been
reported on the orca mailing list at freelists.org and the upstream
maintainer of orca is aware of this

On Wed, Sep 27, 2023 at 10:10 PM Jean-Philippe MENGUAL 
wrote:

> Hi,
>
> Many thanks for this report. 2 questions:
> - does the bug in the file manager appear randomly or do you have a
> reproductible scenario?
> - have you reported too on the orca mailing list?
>
> The next steps for me are to inform upstream of the problem in order to
> get a fix in the definitive release orca 45. But I dont want to do
> duplicate report. My report upstream also will include a debug file to
> help the maintainer.
>
> Thanks for your info
>
> Best regards
>
>
>
> Jean-Philippe MENGUAL
> Debian Developer non uploading
> Community team member
> Accessibility team member
> debian-l10n-french team member
> President of Debian France non-profit organization
>
> Le 27/09/2023 à 19:43, jordan a écrit :
> > Package: orca
> > Version: 45.0-1~bpo12+1
> > Severity: important
> > X-Debbugs-Cc: jordanlives...@gmail.com
> >
> > Dear Maintainer, I've noticed a bug in this version of orca, for some
> reason in the mate desktop, you could be navigating files with the file
> manager and orca sometimes fails to read file names even if the orca curser
> is on it, there is also a bug in the mate menu where orca will just keep
> reading, preferences menu when navigating the submenus of that menu
> >
> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >
> > * What led up to the situation?
> > * What exactly did you do (or not do) that was effective (or
> >   ineffective)?
> > * What was the outcome of this action?
> > * What outcome did you expect instead?I expected orca to behave
> normally as it usually does when navigating files or the mate menu
> >
> > *** End of the template - remove these template lines ***
> >
> >
> > -- System Information:
> > Debian Release: 12.1
> >APT prefers stable-updates
> >APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 6.1.0-12-amd64 (SMP w/6 CPU threads; PREEMPT)
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages orca depends on:
> > ii  gir1.2-glib-2.01.74.0-3
> > ii  gir1.2-gstreamer-1.0   1.22.0-2
> > ii  gir1.2-gtk-3.0 3.24.37-2
> > ii  gir1.2-pango-1.0   1.50.12+ds-1
> > ii  gir1.2-wnck-3.043.0-3
> > ii  gsettings-desktop-schemas  43.0-1
> > ii  gstreamer1.0-plugins-good  1.22.0-5+deb12u1
> > ii  python33.11.2-1+b1
> > ii  python3-brlapi 6.5-7
> > ii  python3-cairo  1.20.1-5+b1
> > ii  python3-gi 3.42.2-3+b1
> > ii  python3-louis  3.24.0-1
> > ii  python3-pyatspi2.46.0-2
> > ii  python3-speechd0.11.5-1~bpo12+1
> > ii  speech-dispatcher  0.11.5-1~bpo12+1
> > ii  xkbset 0.6-3
> >
> > Versions of packages orca recommends:
> > ii  xbrlapi  6.5-7
> >
> > Versions of packages orca suggests:
> > pn  brltty  
> >
> > -- no debconf information
> >
> > ___
> > Pkg-a11y-devel mailing list
> > pkg-a11y-de...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-a11y-devel
>


Bug#1053119: orca fails to read file names when navigating some folders in caja+mate menu issues

2023-09-27 Thread jordan
Package: orca
Version: 45.0-1~bpo12+1
Severity: important
X-Debbugs-Cc: jordanlives...@gmail.com

Dear Maintainer, I've noticed a bug in this version of orca, for some reason in 
the mate desktop, you could be navigating files with the file manager and orca 
sometimes fails to read file names even if the orca curser is on it, there is 
also a bug in the mate menu where orca will just keep reading, preferences menu 
when navigating the submenus of that menu

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?I expected orca to behave normally as 
it usually does when navigating files or the mate menu

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-12-amd64 (SMP w/6 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages orca depends on:
ii  gir1.2-glib-2.01.74.0-3
ii  gir1.2-gstreamer-1.0   1.22.0-2
ii  gir1.2-gtk-3.0 3.24.37-2
ii  gir1.2-pango-1.0   1.50.12+ds-1
ii  gir1.2-wnck-3.043.0-3
ii  gsettings-desktop-schemas  43.0-1
ii  gstreamer1.0-plugins-good  1.22.0-5+deb12u1
ii  python33.11.2-1+b1
ii  python3-brlapi 6.5-7
ii  python3-cairo  1.20.1-5+b1
ii  python3-gi 3.42.2-3+b1
ii  python3-louis  3.24.0-1
ii  python3-pyatspi2.46.0-2
ii  python3-speechd0.11.5-1~bpo12+1
ii  speech-dispatcher  0.11.5-1~bpo12+1
ii  xkbset 0.6-3

Versions of packages orca recommends:
ii  xbrlapi  6.5-7

Versions of packages orca suggests:
pn  brltty  

-- no debconf information



Bug#956803: libteam-utils: teamd using 100% cpu

2023-08-11 Thread Jordan Ayers
Package: libteam-utils
Version: 1.31-1
Followup-For: Bug #956803
X-Debbugs-Cc: adin...@gmail.com

Dear Maintainer,

This bug still exists as of version 1.31-1. My current team config is:

{
  "device": "team1",
  "runner": {
"name": "loadbalance",
"tx_hash": ["eth"],
"tx_balancer": {
  "name": "basic"
}
  },
  "link_watch": {
"name": "ethtool"
  },
  "ports": {
"enp13s0": {},
"wlp12s0": {
  "link_watch": {
"delay_up": 4000,
"delay_down": 1000
  }
}
  }
}

But I have 100% cpu utlization even with a simple config like:

{
  "runner": {
"name": "loadbalance"
  },
  "ports": {
"enp13s0": {}
  }
}

I *do not* have the same issue with any of the other runners. (Well, I don't
have LACP set up on my router, so *maybe* LACP would have the same problem as
well, but I can't test it).

This happens regardless of the current traffic on the network.

I can verify that the "team_mode_loadbalance" and "team" kernel modules are
loaded.

I can provide more info if needed.


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libteam-utils depends on:
ii  libc6 2.36-9+deb12u1
ii  libdaemon00.14-7.1
ii  libdbus-1-3   1.14.8-2~deb12u1
ii  libjansson4   2.14-2
ii  libteam5  1.31-1
ii  libteamdctl0  1.31-1

libteam-utils recommends no packages.

libteam-utils suggests no packages.

-- no debconf information



Bug#1018168: nix-bin: fails to list packages?

2023-07-24 Thread Jordan Justen
Wim,

Is the issue you describe similar to #1004113, and therefore, was it
fixed by Thomas in 2.7.0+dfsg-1?

-Jordan


signature.asc
Description: signature


Bug#1019013:

2023-07-22 Thread Jordan Justen
Control: retitle -1 ITA: nix -- Purely functional package manager (binaries)
Control: owner -1 !


Bug#1019013: (no subject)

2023-07-22 Thread Jordan Justen
Control: owner -1 Jordan Justen 
Control: retitle -1 ITA: nix -- Purely functional package manager (binaries)


signature.asc
Description: signature


Bug#1037314: geary: you can't read emails using orca

2023-06-11 Thread jordan
Package: geary
Version: 43.0-1+b1
Severity: important
X-Debbugs-Cc: jordanlives...@gmail.com

Dear Maintainer,
it is impossible for visually impaired users to use this package with orca as 
it doesn't read emails when you use the arrow keys
*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
I tried to read emails by scrolling with the down arrow keys, when tutorial and 
child posission messeges are turned on in orca, orca correctly states the 
number and how many items there are, for instance, 3 of 19 when you scroll to 
email number 3 in a list of 19 emails
*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages geary depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gnome-keyring42.1-1+b2
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libenchant-2-2   2.3.3-2
ii  libfolks26   0.15.5-2+b1
ii  libgck-1-0   3.41.1-1+b1
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgee-0.8-2 0.20.6-1
ii  libglib2.0-0 2.74.6-2
ii  libgmime-3.0-0   3.2.13+dfsg-2
ii  libgoa-1.0-0b3.46.0-1
ii  libgsound0   1.0.3-2
ii  libgspell-1-21.12.0-1+b2
ii  libgtk-3-0   3.24.37-2
ii  libhandy-1-0 1.8.1-1
ii  libicu72 72.1-3
ii  libjavascriptcoregtk-4.1-0   2.40.1-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmessaging-menu0   22.9.0-1+b1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpeas-1.0-01.34.0-1+b1
ii  libsecret-1-00.20.5-3
ii  libsoup-3.0-03.2.2-2
ii  libsqlite3-0 3.40.1-2
ii  libstemmer0d 2.2.0-2
ii  libunwind8   1.6.2-3
ii  libwebkit2gtk-4.1-0  2.40.1-1
ii  libxml2  2.9.14+dfsg-1.2
ii  libytnef02.0-1+b1

geary recommends no packages.

geary suggests no packages.

-- no debconf information



Bug#1037232: google-chrome-stable: when reading webpages, chrome returns lines instead of sentences when using orca screen reader

2023-06-08 Thread jordan
Package: google-chrome-stable
Version: 114.0.5735.106-1
Severity: important
X-Debbugs-Cc: jordanlives...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
I tried reading webpages using orca in the latest chrome but a 1 year old bug 
tells orca to use lines rather than sentences as per orca default settings
*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages google-chrome-stable depends on:
ii  ca-certificates 20230311
ii  dpkg1.21.22
ii  fonts-liberation1:1.07.4-11
ii  libasound2  1.2.8-1+b1
ii  libatk-bridge2.0-0  2.46.0-5
ii  libatk1.0-0 2.46.0-5
ii  libatspi2.0-0   2.46.0-5
ii  libc6   2.36-9
ii  libcairo2   1.16.0-7
ii  libcups22.4.2-3
ii  libcurl3-gnutls 7.88.1-10
ii  libcurl47.88.1-10
ii  libdbus-1-3 1.14.6-1
ii  libdrm2 2.4.114-1+b1
ii  libexpat1   2.5.0-1
ii  libgbm1 22.3.6-1+deb12u1
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.37-2
ii  libgtk-4-1  4.8.3+ds-2
ii  libnspr42:4.35-1
ii  libnss3 2:3.87.1-1
ii  libpango-1.0-0  1.50.12+ds-1
ii  libu2f-udev 1.1.10-3
ii  libvulkan1  1.3.239.0-1
ii  libx11-62:1.8.4-2
ii  libxcb1 1.15-1
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.6-1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2
ii  libxkbcommon0   1.5.0-1
ii  libxrandr2  2:1.5.2-2+b1
ii  wget1.21.3-1+b2
ii  xdg-utils   1.1.3-4.1

google-chrome-stable recommends no packages.

google-chrome-stable suggests no packages.
 
-- no debconf information



Bug#1037197: snapd: applications installed via snap don't appear in the desktop launcher like on derivatives

2023-06-07 Thread jordan
Package: snapd
Version: 2.49-1+deb11u2
Severity: important
X-Debbugs-Cc: jordanlives...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 11.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-23-amd64 (SMP w/6 CPU threads)
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages snapd depends on:
ii  adduser  3.118
ii  apparmor 2.13.6-10
ii  ca-certificates  20210119
ii  gnupg2.2.27-2+deb11u2
ii  libapparmor1 2.13.6-10
ii  libc62.31-13+deb11u6
ii  libcap2  1:2.44-1
ii  libseccomp2  2.5.1-1+deb11u1
ii  libudev1 247.3-7+deb11u2
ii  openssh-client   1:8.4p1-5+deb11u1
ii  squashfs-tools   1:4.4-2+deb11u2
ii  systemd  247.3-7+deb11u2
ii  udev 247.3-7+deb11u2

Versions of packages snapd recommends:
ii  gnupg  2.2.27-2+deb11u2

Versions of packages snapd suggests:
ii  zenity  3.32.0-6

-- no debconf information



Bug#1032148: debian-installer: when installing debian bookworm via the netinstaller even though non free firmware is included it still tells you that some of your hardware requires it and that you can

2023-02-28 Thread jordan
Package: debian-installer
Severity: minor
X-Debbugs-Cc: jordanlives...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-5-amd64 (SMP w/6 CPU threads; PREEMPT)
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#1027944: neofetch: Color blocks do not render on bash >=5.2 and can cause text overlap

2023-01-04 Thread Jordan Atwood
Package: neofetch
Version: 7.1.0-4
Severity: normal
Tags: patch upstream

Dear Maintainer,

I found that installing and using neofetch on Debian testing (bookworm),
it had different behavior than that on stable (bullseye). Namely, the
color block output using the default configuration (via the `info cols`
directive) does not work correctly. Instead of printing a grid of
terminal colors, it exits early due to a syntax error in bash 5.2 and
can cause the terminal prompt to overlap the distribution logo.

Running `neofetch -v` with the default config gives the following
output:

```
$ neofetch -v
   _,met$gg.  nightfirecat@debian
,g$$$P.   ---
  ,g$$P" """Y$$.".OS: Debian GNU/Linux bookworm/sid x86_64
 ,$$P'  `$$$. Host: Laptop (12th Gen Intel Core) A6
',$$P   ,ggs. `$$b:   Kernel: 6.0.0-6-amd64
`d$$' ,$P"'   .$$$Uptime: 37 mins
 $$P  d$' ,$$PPackages: 2697 (dpkg), 12 (flatpak)
 $$:  $$.   -,d$$'Shell: bash 5.2.2
 $$;  Y$b._   _,d$P'  Resolution: 2256x1504
 Y$$.`.`"YP"' DE: Plasma 5.26.4
 `$$b  "-.__  WM: KWin
grep: /etc/gtk-2.0/gtkrc: No such file or directory
   `Y$$.  Theme: Breeze [Plasma], Breeze [GTK2/3]
grep: /etc/gtk-2.0/gtkrc: No such file or directory
   `Y$$b. Icons: [Plasma], candy-icons [GTK2/3]
  `"Y$b._ Terminal: konsole
qtpaths: could not find a Qt installation of ''
/usr/bin/neofetch: line 2110: /sys/devices/system/cpu/cpu0/cpufreq/bios_limit: 
No sucy
/usr/bin/neofetch: line 2111: /sys/devices/system/cpu/cpu0/cpufreq/bios_limit: 
No sucy
  CPU: 12th Gen Intel i7-1260P (16) @ 4.700GHz
  GPU: Intel Alder Lake-P
  Memory: 4745MiB / 15714MiB
/usr/bin/neofetch: line 3803: bad substitution: no closing `}' in 
${block_spaces// /$}
```

And running `neofetch` [using my own config][1], I get this output:
(prompt is not part of neofetch; it merely overlaps it)

```
$ neofetch
   _,met$gg.  nightfirecat@debian.framework 
,g$$$P.   - 
  ,g$$P" """Y$$.".OS: Debian GNU/Linux bookworm/sid x86_64 
 ,$$P'  `$$$. Kernel: Linux 6.0.0-6-amd64 
',$$P   ,ggs. `$$b:   Uptime: 9 mins 
`d$$' ,$P"'   .$$$Packages: 2697 (dpkg), 12 (flatpak) 
 $$P  d$' ,$$PShell: bash 5.2.2 
 $$:  $$.   -,d$$'DE: Plasma 5.26.4 
 $$;  Y$b._   _,d$P'  WM: KWin 
 Y$$.`.`"YP"' Theme: Breeze [Plasma], Breeze [GTK2/3] 
 `$$b  "-.__  Icons: [Plasma], candy-icons [GTK2/3] 
  `Y$$CPU: 12th Gen Intel i7-1260P (16) @ 4.7GHz 
   `Y$$.  Memory: 3.63GiB / 15.35GiB (23%) 
 `$$b.Disk (/): 31G / 914G (4%) 
   `Y$$b.
[nightfirecat@debian.framework ~]
$ `"""
```

This bug has been [reported upstream][2], though no fix has been merged
due to apparent inactivity on the project. I found that [applying a
patch from a fork of the project][3] fixes the issue neatly without
causing regression for older bash versions. The following diff, adapted
from said patch, fixes the issue for me:

```
diff --git a/neofetch b/neofetch
index 1e4b564..effa048 100755
--- a/neofetch
+++ b/neofetch
@@ -3800,8 +3800,13 @@ get_cols() {
 printf -v block_spaces "%${block_height}s"

 # Convert the spaces into rows of blocks.
-[[ "$blocks"  ]] && cols+="${block_spaces// /${blocks}nl}"
-[[ "$blocks2" ]] && cols+="${block_spaces// /${blocks2}nl}"
+if [[ $BASH_VERSION == 3* ]]; then
+[[ "$blocks"  ]] && cols+="${block_spaces// /${blocks}nl}"
+[[ "$blocks2" ]] && cols+="${block_spaces// /${blocks2}nl}"
+else
+    [[ "$blocks"  ]] && cols+="${block_spaces// /${blocks}\[mnl}"
+[[ "$blocks2" ]] && cols+="${block_spaces// /${blocks2}\[mnl}"
+fi

 # Add newlines to the string.
 cols=${cols%%nl}
```

Thanks,
Jordan

[1]: 
https://git.nightfirec.at/nightfirecat/dotfiles/src/commit/91ac846246fab70a99336169058d6ba301b6e538/src/.neofetch.config.json
[2]: https://github.com/dylanaraps/neofetch/issues/2195
[3]: https://github.com/hykilpikonna/hyfetch/pull/24#issuecomment-1296304767

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF

Bug#1022295: llvm-toolchain-13: FTBFS: build-dependency not installable: llvm-spirv

2022-11-01 Thread Jordan Justen
Lucas,

The llvm-spirv dependency has " | hello". Shouldn't this package be
usable as an alternative to llvm-spirv in bookworm?

https://packages.debian.org/bookworm/hello

I see that the "Filtered Build-Depends" drops this as an alternative.
Do you happen to know why?

-Jordan


signature.asc
Description: signature


Bug#1008518: nmu: libxxf86vm_1:1.1.4-1+b2

2022-03-28 Thread Jordan Justen
On 2022-03-28 12:57:38, Paul Gevers wrote:
> Right, multiarch.



> Rebuilding on all architectures wouldn't help, as the other
> architectures would be bumped too, so we only want to rebuild ia64
> and riscv64. Scheduled.

Thanks for the clarifications. I think based on this that in the
future I should do 2 things differently.

1. Don't select all architectures, but instead choose only the
   affected architectures. (I saw this as an option in reportbug, but
   the irc advice specifically said all, so I thought it best to go
   with that.)

2. In the comment field I should mention multiarch, so the motivation
   is clearer.

Thanks again!

-Jordan


signature.asc
Description: signature


Bug#1008518: nmu: libxxf86vm_1:1.1.4-1+b2

2022-03-28 Thread Jordan Justen
On 2022-03-28 11:57:14, Paul Gevers wrote:
> Hi Jordan,
> 
> On 28-03-2022 10:20, Jordan Justen wrote:
> > nmu libxxf86vm_1:1.1.4-1+b2 . ANY . unstable . -m "riscv64 arch is at 
> > 1:1.1.4-1
> > while others are at 1:1.1.4-1+b2"
> 
> It may be obvious to you, but, so what? Why is that a problem and how 
> does rebuilding on all architectures solve that?

I want to install libxxf86vm packages, such as libxxf86vm1:riscv64 on
amd64. When I try to install it on amd64, apt wants to remove many
amd64 packages. I think the difference of 1:1.1.4-1 vs 1:1.1.4-1+b2
might be the cause, but I will admit that I am not certain.

As far as building "all architecures" is concerned, I don't know if
this is required. If there was a way to only build riscv64 libxxf86vm
1:1.1.4-1+b2 to match the other architectures, then I think that would
work as well.

When I mentioned this issue on #debian-riscv, it was recommended that
I "could `reportbug release.debian.org`, select binNMU to request a
rebuild on all arches to get the issue fixed", which is what lead me
to file this bug.

The reportbug program only provided a single line comment, so I
assumed I should keep the explanation short. I apologize if I didn't
file the bug properly.

-Jordan


signature.asc
Description: signature


Bug#1008518: nmu: libxxf86vm_1:1.1.4-1+b2

2022-03-28 Thread Jordan Justen
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu libxxf86vm_1:1.1.4-1+b2 . ANY . unstable . -m "riscv64 arch is at 1:1.1.4-1
while others are at 1:1.1.4-1+b2"



Bug#993904: Adding amdgcn-mesa-mesa3d back to libclc build

2021-10-17 Thread Jordan Justen
Hopefully this merge-request can help fix #993904 & #995069.

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/74


signature.asc
Description: signature


Bug#986517: waffle: diff for NMU version 1.6.3-1.1

2021-04-24 Thread Jordan Justen
On 2021-04-24 00:49:14, Adrian Bunk wrote:
> I've prepared an NMU for waffle (versioned as 1.6.3-1.1) and uploaded it 
> to DELAYED/2. Please feel free to tell me if I should cancel it.

I pulled your change in along with a couple other changes and uploaded
1.6.3-2. Let me know if you still see an issue with the package.

Thanks,

-Jordan


signature.asc
Description: signature


Bug#980608: renderdoc autorm

2021-02-13 Thread Jordan Justen
Lucas,

The renderdoc package was marked with autorm based on this bug.

The issue arose because glslang 11.1.0-1 was uploaded to unstable.

I therefore released renderdoc 1.11+dfsg-5 which fixed the
compatibility issue with glslang 11.

Unfortunately, I then found out that glslang 11 was actually blocked
from migrating to testing because of an autopkgtest failure.

Timo released glslang 11.1.0-2 which we thought would fix the
autopkgtest failure. Unfortunately, it still did not fix it.

I reproduced this autopkgtest failure with glslang, and I think I have
a fix for it here:

https://salsa.debian.org/xorg-team/vulkan/glslang/-/merge_requests/3

My concern now is that the renderdoc package only has 5 days left in
the autorm countdown.

Do you have any suggestions for how I can prevent renderdoc from being
removed from testing?

Thanks for your time,

-Jordan


signature.asc
Description: signature


Bug#973697: thunderbird: missing libresolv.so breaks OpenPGP key search by email

2020-12-04 Thread Jordan Glover
There is upstream fix that should work for all debian editions[1]. See also 
upstream ticket at[2]

[1] https://bug1634053.bmoattachments.org/attachment.cgi?id=9191200
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1634053

Jordan



Bug#975119: RFS: cglm/0.7.9-1 -- Optimized OpenGL Mathematics library for C

2020-11-20 Thread Jordan Justen
On 2020-11-20 15:04:56, Paul Wise wrote:
> On Fri, Nov 20, 2020 at 7:36 AM Jordan Justen wrote:
> 
> > This Standards-Version is not yet recognized by lintian.
> 
> When lintian is wrong about the Standards-Version being too new, it is
> best to ignore it and wait until lintian is updated.

It sound like you recommend incrementing the standards version and
ignoring lintian, right?

As lintian helps to validate the package against the standards
version, is there much benefit to updating the standards version
before lintian can start to help validate it?

I guess there is not much benefit to updating it before lintian is
updated, but also probably not much harm.

Thanks,

-Jordan


signature.asc
Description: signature


Bug#975119: RFS: cglm/0.7.9-1 -- Optimized OpenGL Mathematics library for C

2020-11-19 Thread Jordan Justen
On 2020-11-19 01:01:28, Leon Marz wrote:
> 
>  cglm (0.7.9-1) unstable; urgency=medium
>  .
>* New upstream release
>* Bump Standards-Version to 4.5.1

This Standards-Version is not yet recognized by lintian. You can
verify this with lintian, and it is also shown in the lintian section
on mentors:

https://mentors.debian.net/package/cglm/

The debian sid package page also lists 4.5.0:

https://packages.debian.org/sid/lintian


signature.asc
Description: signature


Bug#898446: Please reconsider enabling the user namespaces by default

2020-10-23 Thread Jordan Glover
I think there are two aspects here. (In)security of unpriv user ns is one of 
them - personally I'm in favor of opinions from people who argue that the 
attack vector they open will remain for foreseeable future because kernel is 
simply too big to fix all bugs. The other thing is that containers & sandboxes 
ecosystem moved strong towards unpriv user ns which makes them nerfed or 
unusable on systems which don't support them. In result this is the choice 
between insecurity and obscurity.

In current state downstream devs may just not care about debian, ask users to 
enable unpriv user ns or prepare special "debian edition" version of their 
stuff like suid bwrap which brings security issues on their own[1] (among other 
problems).

As it was noted vast majority of other distros calculated the costs in favor of 
enabling unpriv user ns but one need to know that equation has two sides and 
whether you think unpriv user ns are secure or not is only one of them.

Jordan

[1] 
https://github.com/containers/bubblewrap/security/advisories/GHSA-j2qp-rvxj-43vj



Bug#969477:

2020-09-16 Thread Jordan Mendler
This issue still occurs as of 5.8.0-1. The work around to make it compile
is to symlink the missing folder from kernel source:

`sudo ln -s /usr/src/linux-headers-5.8.0-1-common/include/linux
/lib/modules/5.8.0-1-amd64/build/include/linux`


Bug#969477: Acknowledgement (zfs-dkms fails to compile with 5.7.0-3 kernel blocking kernel upgrade)

2020-09-03 Thread Jordan Mendler
FYI...

jordan@jordan-laptop:~$ cat /var/lib/dkms/zfs/0.8.4/build/make.log
DKMS make.log for zfs-0.8.4 for kernel 5.7.0-3-amd64 (x86_64)
Thu 03 Sep 2020 09:19:11 AM PDT
make: *** No targets specified and no makefile found.  Stop.

Jordan Mendler
[image: The Veloz Group]
The Veloz Group
President & Chief Technology Officer
jor...@thevelozgroup.com
www.thevelozgroup.com


Bug#969477: zfs-dkms fails to compile with 5.7.0-3 kernel blocking kernel upgrade

2020-09-03 Thread Jordan Mendler
Package: zfs-dkms
Version: 0.8.4-2
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: jordanmend...@gmail.com

jordan@jordan-laptop:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  enchant libenchant1c2a
Use 'sudo apt autoremove' to remove them.
The following packages have been kept back:
  vlc-data vlc-plugin-base
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up zfs-dkms (0.8.4-2) ...
Removing old zfs-0.8.4 DKMS files...

--
Deleting module version: 0.8.4
completely from the DKMS tree.
--
Done.
Loading new zfs-0.8.4 DKMS files...
Building for 5.7.0-2-amd64 5.7.0-3-amd64
Module build for kernel 5.7.0-2-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Building initial module for 5.7.0-3-amd64
grep: /lib/modules/5.7.0-3-amd64/build/include/linux/miscdevice.h: No such file 
or directory
configure: error:
*** None of the expected "global page state" interfaces were detected.
*** This may be because your kernel version is newer than what is
*** supported, or you are using a patched custom kernel with
*** incompatible modifications.
***
*** ZFS Version: zfs-0.8.4-2
*** Compatible Kernels: 2.6.32 - 5.6

Error! Bad return status for module build on kernel: 5.7.0-3-amd64 (x86_64)
Consult /var/lib/dkms/zfs/0.8.4/build/make.log for more information.
dpkg: error processing package zfs-dkms (--configure):
 installed zfs-dkms package post-installation script subprocess returned error 
exit status 10
dpkg: dependency problems prevent configuration of zfs-initramfs:
 zfs-initramfs depends on zfs-modules | zfs-dkms; however:
  Package zfs-modules is not installed.
  Package zfs-dkms which provides zfs-modules is not configured yet.
  Package zfs-dkms is not configured yet.

dpkg: error processing package zfs-initramfs (--configure):
 dependency problems - leaving unconfigured
Processing triggers for initramfs-tools (0.137) ...
update-initramfs: Generating /boot/initrd.img-5.7.0-3-amd64
I: The initramfs will attempt to resume from /dev/sda6
I: (UUID=ed50f26c-a201-4381-806d-a9c6b2b4766a)
I: Set the RESUME variable to override this.
Errors were encountered while processing:
 zfs-dkms
 zfs-initramfs
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- System Information:
Distributor ID: Debian Sid
Description:Debian Sid
Release:sid
Codename:   sid
Architecture: x86_64

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  dkms   2.8.3-4
ii  file   1:5.38-5
ii  libc6-dev [libc-dev]   2.31-3
ii  libpython3-stdlib  3.8.2-3
ii  lsb-release11.1.0
ii  perl   5.30.3-4
ii  python3-distutils  3.8.5-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  5.7.17-1
ii  zfs-zed 0.8.4-2
ii  zfsutils-linux  0.8.4-2

Versions of packages zfs-dkms suggests:
ii  debhelper  13.2

-- debconf information:
  zfs-dkms/stop-build-for-32bit-kernel: true
* zfs-dkms/note-incompatible-licenses:
  zfs-dkms/stop-build-for-unknown-kernel: true



Bug#964116: mailman3-web: mailman-web.py config file falsely says you can enable Django admin documentation

2020-07-01 Thread AJ Jordan
Package: mailman3-web
Version: 0+20180916-8
Severity: normal

/etc/mailman/mailman-web.py contains the following snippet in
INSTALLED_APPS:

# Uncomment the next line to enable admin documentation:
#'django.contrib.admindocs',

but the comment is inaccurate. Uncommenting it does not produce a
documentation link in the upper-right hand corner of the Django admin
interface.

Installing the `python3-docutils` Debian package does not help.

See https://docs.djangoproject.com/en/3.0/ref/contrib/admin/admindocs/
for requirements for this mechanism.

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mailman3-web depends on:
ii  dbconfig-mysql 2.0.11+deb10u1
ii  debconf [debconf-2.0]  1.5.71
ii  lsb-base   10.2019051400
ii  node-less  1.6.3~dfsg-3
ii  python33.7.3-1
ii  python3-django-hyperkitty  1.2.2-1
ii  python3-django-postorius   1.2.4-1
ii  python3-mysqldb1.3.10-2
ii  python3-psycopg2   2.7.7-1
ii  python3-whoosh 2.7.4+git6-g9134ad92-4
ii  sassc  3.5.0-1
ii  ucf3.0038+nmu1
ii  uwsgi  2.0.18-1
ii  uwsgi-plugin-python3   2.0.18-1

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.4.38-3+deb10u3

Versions of packages mailman3-web suggests:
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.22-0+deb10u1
ii  postgresql  11+200+deb10u3

-- Configuration Files:
/etc/mailman3/uwsgi.ini changed [not included]

-- debconf information:
  mailman3-web/pgsql/authmethod-user: password
  mailman3-web/upgrade-error: abort
  mailman3-web/remove-error: abort
  mailman3-web/pgsql/authmethod-admin: ident
  mailman3-web/dbconfig-remove: true
  mailman3-web/remote/host: localhost
* mailman3-web/emailname: lists.strugee.net
  mailman3-web/pgsql/method: TCP/IP
  mailman3-web/remote/port: 3306
  mailman3-web/passwords-do-not-match:
  mailman3-web/remote/newhost:
  mailman3-web/pgsql/manualconf:
  mailman3-web/missing-db-package-error: abort
* mailman3-web/dbconfig-reinstall: false
  mailman3-web/db/app-user: mailman3web@localhost
* mailman3-web/mysql/admin-user: debian-sys-maint
* mailman3-web/superuser-mail: a...@strugee.net
  mailman3-web/db/dbname: mailman3web
  mailman3-web/db/basepath: /var/lib/mailman3/web
* mailman3-web/dbconfig-install: true
* mailman3-web/restart-webserver: false
  mailman3-web/mysql/method: Unix socket
  mailman3-web/internal/skip-preseed: false
  mailman3-web/pgsql/admin-user: postgres
  mailman3-web/pgsql/changeconf: false
* mailman3-web/database-type: mysql
  mailman3-web/purge: false
  mailman3-web/dbconfig-upgrade: true
* mailman3-web/superuser-name: alex
* mailman3-web/configure-webserver: apache2
  mailman3-web/nginx-choice:
  mailman3-web/internal/reconfiguring: false
  mailman3-web/pgsql/no-empty-passwords:
  mailman3-web/upgrade-backup: true
  mailman3-web/install-error: abort



Bug#951202: RFS review of cglm 0.7.1-1

2020-04-27 Thread Jordan Justen
Leon,

I reviewed the 0.7.1-1 packaging you posted on mentors.debian.net. I
didn't see any major issues, but maybe some suggestions.

The license is MIT, and debian/copyright has it listed properly.

I think packages often will call out the debian directory in
debian/copyright, even if it matches the upstream license. I don't
know that this is required, but here's an example:

https://salsa.debian.org/xorg-team/lib/libglvnd/-/blob/debian-unstable/debian/copyright#L50

You can also move the license text to a separate section if multiple
sections list the same license. (Like the MIT license in the example
above.)

I did see that `lintian --display-info` prints some issues relating to
fonts in the doc package. From `build-rdeps python3-sphinx-rtd-theme`,
I found the dbus-python package also uses the rtd theme. I notice they
use dh_sphinxdoc, and I wonder if it could be useful for the cglm
package. (And, perhaps fix the lintian note.)

lintian --display-info also flags no-symbols-control-file
usr/lib/x86_64-linux-gnu/libcglm.so.0.0.1. (See dpkg-gensymbols)

lintian --pedantic --display-experimental flags
debian-watch-does-not-check-gpg-signature, but I see upstream doesn't
sign the releases. You could ask upstream to do this, and pointing
them at https://wiki.debian.org/Creating%20signed%20GitHub%20releases
might make it easier for them.

I don't these the info or experimental lintian items would block the
package from debian, since they aren't even at the warning level.

One easy cleanup change for the package would be to run wrap-and-sort.

Do you plan to try to maintain the package going forward? (Watch for
new upstream releases, work on bugs, etc?)

Do you have plans to manage the package files in git, perhaps on
salsa.debian.net? I'm not sure if it is allowed to start using salsa
for a project before it makes it into debian. The salsa FAQ is vague
on this point:

https://wiki.debian.org/Salsa/FAQ#What_can_be_hosted_on_salsa

But I think it is often allowed. I know of at least 2 cases where a
repo was created for a package before it got included into Debian. I
expect some basic review of the package is probably good first, and
perhaps this email can serve for that.

If not salsa.debian.net, you could still host it in a github repo and
include the links to it in the control file. (And, that could move to
salsa later too.)

-Jordan

Some more info, mainly for Thomas to know what I checked.

I looked over https://wiki.debian.org/SponsorChecklist.

I checked the provided orig tarball vs upstream.

I built the package with sbuild.

I looked over the lib, dev and doc packages in the control file and
.deb outputs.

I *did not* use the library with any code, but I did note that the
upstream package has 633 tests which all passed during the sbuild
build.

I ran piuparts, and it reported that all tests passes.

I reviewed each item on https://ftp-master.debian.org/REJECT-FAQ.html:

Serious violations checklist (REJECT-FAQ):

 * OpenSSL - not linked => Ok
 * CDBS - doesn't use => Ok
 * PHP License - MIT license => Ok
 * License - upsteam has LICENSE file => Ok
 * Transition - Ok
 * Experimental Library - not linked => Ok
 * Hijack - no => Ok
 * Package split
 * FTBFSIASW - built with sbuild => Ok
 * debian/control breakage #2 - Ok
 * Copyright - Ok, with comment
   * optionally, could add a separate debian section
   * 
https://salsa.debian.org/xorg-team/lib/libglvnd/-/blob/debian-unstable/debian/copyright#L50
   * Need to check for multiple copyright holders
 * License II - upsteam has LICENSE file => Ok
 * License III - Ok
   * Using `licensecheck`, it appears "Recep Aslantas" is the only listed 
copyright holder
 * Non-Main - checked Depends on .deb files, Build-Depends, Recommended 
manually =>  Ok
 * Non-Main II - Ok
 * Package Content - Ok
 * Policy Violation -
   * manually inspected - looks ok
   * lintian reports some font issues at "info" level
 * font-in-non-font-package 
usr/share/doc/libcglm-doc/html/_static/fonts/Lato-Bold.woff2.gz
 * and, several more. this appears to come from debian/libcglm-doc.links
 * Contents of orig.tar.gz - not being rebuilt; no *.{a,so} => Ok
 * Lintian (with --display-info)
   * libcglm-dev: capitalization-error-in-description api API
   * libcglm-doc: font-in-non-font-package usr/share/doc/**/*.woff2.gz
   * libcglm-doc: font-outside-font-dir usr/share/doc/**/*.woff2.gz
   * libcglm0: no-symbols-control-file usr/lib/x86_64-linux-gnu/libcglm.so.0.0.1
 * rpath - not used => Ok
 * Package name - Ok
 * Common license - MIT not under common-license => Ok
 * Renaming source for DFSG-removals - not dfsg repacked => Ok
 * Wrong license pointer - no common-license is used => Ok
 * Symbol file wrong - no symbol file currently (but, suggested) => Ok
 * Source missing - no missing source => Ok
 * Generated files - none seen, or flagged by lintian => Ok
 * Package uses waf as build system - autotools => 

Bug#955070: possible fix with new upstream location and 0.8.1-rc3 release

2020-04-20 Thread Jordan Justen
I opened a merge request in salsa to potentially help fix this bug:

https://salsa.debian.org/openstack-team/libs/python-doc8/-/merge_requests/1

It seems like the python-oslosphinx package is causing the FTBFS,
since it's not compatible with Sphinx 2.4.

I found a new upstream location for doc8, but they only had an rc3 for
a new release. The rc3 release did not depend on oslosphinx, and
therefore, the package was able to build.

Looking at `apt showpkg python3-doc8`, I wasn't able to find a
specific package to test against the new python3-doc8 build.

If this looks like the right direction to fix the FTBFS, I can upload
a build to debian.mentors.net if that would be helpful.


signature.asc
Description: signature


Bug#955193: upstream patch merged

2020-04-11 Thread Jordan Justen
I got this fixed in upstream:

https://github.com/pazz/alot/commit/916b446317980e9794a02bfb79456da4fc2768a4

Since it's a warning, I was planning to *not* bother adding an `alot`
package patch, and just wait for the next upstream release. Or, do you
think I should cherry-pick the upstream patch into the package?

-Jordan


signature.asc
Description: signature


Bug#922063: Possible upstream bug for debian #922063

2020-04-09 Thread Jordan Justen
Jonas,

This upstream bug sounds similar.

https://github.com/pazz/alot/issues/1434

What do you think?

-Jordan


signature.asc
Description: signature


Bug#951179: RM: glslang [s390x] -- ROM; Blocking migration of glslang to testing

2020-02-11 Thread Jordan Justen
Package: ftp.debian.org
Severity: normal

s390x was removed from the latest glslang (8.13.3559-2) unstable upload:

https://salsa.debian.org/xorg-team/vulkan/glslang/commit/6466e35acadc5de8d75b7285eaaf1312b81b054d

the s390x arch missing is preventing glslang from migrating to testing:

https://qa.debian.org/excuses.php?package=glslang



Bug#946370: Packaging problems with yubikey-luks-open

2019-12-15 Thread Jordan Glover
The fix [1] for PATH issue was sent long time ago to debian package
repository but it seem no longer maintained.

[1] https://salsa.debian.org/auth-team/yubikey-luks/merge_requests/1

Jordan



Bug#207434: Staff Symposium

2019-11-14 Thread Stallings, Jordan
Dear Colleague,

We have a compulsory Symposium , we would like to draw your attention to the 
following event:

Public lectures in the context of Your occupation and roles to improve our 
organization.

For details and seat reservations, please refer to the Staff Symposium 
Reservation Portal at https://staff-symposium.securechkout.com/  And reserve 
your Seat.

You are welcome to forward this to Other Staff.

Remember, this is compulsory .Best regards





















































































































































































































































































This e-mail (including attachments) is confidential and may be privileged. 
Please delete if obtained in error and email confirmation to the sender. Thank 
you for your cooperation.


Bug#884372: openshot-qt hangs at start: No module named 'PyQt5.QtWebKitWidgets'

2019-10-05 Thread Jordan Christiansen
I have a workaround for this. I noticed that I had PyQt5 installed in my 
~/.local/lib directory. This version had most of the PyQt5 submodules, 
but not QtWebKit or QtWebKitWidgets. When I removed my local libraries with


pip3 uninstall PyQt5

then openshot searched for all the PyQt5 modules in the system 
directories and was able to find QtWebKit.




Bug#903153: nasm does not handle rdf2 output correctly due to incorrect use of pure_func

2019-02-12 Thread Jordan Justen
Hi. Does the 2.14-1 release fix this? I see that upstream included at
patch exactly like yours:

commit 9f45a77f46829e666b35530939b9237cf978d4dc
Author: Cyrill Gorcunov 
Date:   Sat Feb 10 00:40:46 2018 +0300

nasmlib: Drop pure_func attrib from seg_alloc

This patch should have been included is 2.14-1.

Thanks,

-Jordan



Bug#906335: alot bug #906335

2018-12-19 Thread Jordan Justen
On 2018-08-25 03:38:08, Santiago Vila wrote:
> On Sat, Aug 25, 2018 at 07:52:28AM +0200, Johannes Schauer wrote:
> 
> > Santiago, how were you able to reproduce the issue?
> 
> My building environment is described here:
> 
> https://people.debian.org/~sanvila/my-building-environment.txt

I haven't had a chance to setup a similar environment to try to
reproduce this.

But, upstream has released alot 0.8, so I'm working to release 0.8-1
of the package.

One big change in 0.8 is that python3 is used rather than python2.

I know it might be a long shot, but I wondered if you might want to
try testing the unreleased 0.8 package to see if python3 helps with
the build issue inside the VM.

I uploaded the 'UNRELEASED' changes for 0.8-1 into the debian/master
branch of:

https://salsa.debian.org/python-team/applications/alot/

Thanks for your time,

-Jordan


signature.asc
Description: signature


Bug#916277: alot: please package new upstream release 0.8

2018-12-19 Thread Jordan Justen
On 2018-12-12 06:05:57, Jonas Smedegaard wrote:
> alot 0.8 is out, with exciting changes - esp. notmuch named queries.
> 
> Please package it.
> 

I'm almost done with the changes for 0.8. :)

-Jordan



Bug#904162: yubikey-luks: keyscript not run during boot

2018-11-25 Thread Jordan Glover
This bug is fixed upstream with:
https://github.com/cornelinux/yubikey-luks/commit/e6c20a349b0d7f3d02c69bf86ef2ab179691bb1e

which don't rely on cryptsetup package internals anymore but needs manual 
system config adjustment.

There are also couple more fixes in master, including debian downstream 
patches. You may consider syncing upstream master with debian if you want to 
make new release in debian.

Jordan



Bug#904423: irqbalance: initscript refers to typo'd IRCBALANCE_ARGS variable

2018-07-24 Thread AJ Jordan
Package: irqbalance
Version: 1.1.0-2.3
Severity: normal
Tags: patch

Attached is a patch to fix what I assume is a typo in
/etc/init.d/irqbalance. I would send a version control patch, but I
was unable to find source control for the irqbalance Debian
packaging. Instead I have generated a unified diff (or you could just
make the change yourself; it's pretty trivial).

-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 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)

Versions of packages irqbalance depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  libc6  2.24-11+deb9u3
ii  libcap-ng0 0.7.7-3+b1
ii  libglib2.0-0   2.50.3-2
ii  libnuma1   2.0.11-2.1
ii  libsystemd0232-25+deb9u4
ii  lsb-base   9.20161125

irqbalance recommends no packages.

irqbalance suggests no packages.

-- debconf information excluded



Bug#904421: installation-report

2018-07-24 Thread Jordan Jones
Package: installation-reports

Boot method: DVD-1
Image version: 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso
Date: 23 July 2018, 03:30 UTC

Machine: Fujitsu Lifebook T4410
Processor: Intel(R) Core(TM)2 Duo CPU P8700  @ 2.53GHz
Memory: 4GB
Partitions:FilesystemType 1K-blocks  Used
Available Use% Mounted on
udev  devtmpfs   197 0   197   0% /dev
tmpfs tmpfs   398148 11380386768   3% /run
/dev/mapper/jdeb--vg-root ext4 148479768  44795480  96072284  32% /
tmpfs tmpfs  1990736277064   1713672  14% /dev/shm
tmpfs tmpfs 5120 4  5116   1% /run/lock
tmpfs tmpfs  1990736 0   1990736   0%
/sys/fs/cgroup
/dev/sda1 ext2240972 37468191063  17% /boot
tmpfs tmpfs   39814416398128   1%
/run/user/118
tmpfs tmpfs   39814448398096   1%
/run/user/1000


Output of lspci -knn (or lspci -nn):00:00.0 Host bridge [0600]: Intel
Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40]
(rev 07)
Subsystem: Fujitsu Limited. Mobile 4 Series Chipset Memory Controller
Hub [10cf:144e]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4
Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
Subsystem: Fujitsu Limited. Mobile 4 Series Chipset Integrated
Graphics Controller [10cf:1458]
Kernel driver in use: i915
Kernel modules: i915
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
Subsystem: Fujitsu Limited. Mobile 4 Series Chipset Integrated
Graphics Controller [10cf:1458]
00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #4 [8086:2937] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #5 [8086:2938] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #6 [8086:2939] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB2 EHCI Controller #2 [8086:293c] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB2 EHCI Controller
[10cf:1473]
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD
Audio Controller [8086:293e] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) HD Audio Controller
[10cf:1475]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 1 [8086:2940] (rev 03)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 2 [8086:2942] (rev 03)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 3 [8086:2944] (rev 03)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #1 [8086:2934] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #2 [8086:2935] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #3 [8086:2936] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB2 EHCI Controller #1 [8086:293a] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB2 EHCI Controller
[10cf:1473]
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge
[8086:2448] (rev 93)
00:1f.0 ISA bridge 

Bug#890005: (no subject)

2018-02-09 Thread Jordan Waughtal
Subject: unison-gtk requires the unison package inorder to use an ssh profile.
Package: unison-gtk
Version: 2.48.3-1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-5-amd64 (SMP w/12 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)

Versions of packages unison-gtk depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo21.14.8-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1

Versions of packages unison-gtk recommends:
ii  openssh-client [ssh-client]  1:7.4p1-10+deb9u2
ii  ssh-askpass  1:1.2.4.1-9+b2

Versions of packages unison-gtk suggests:
ii  unison-all-gtk  2.48+2

-- no debconf information



Bug#886310: ITP: filter-other-days -- filter logfiles for today's date in an Artificial Ignorance-compatible way

2018-01-04 Thread AJ Jordan
Package: wnpp
Severity: wishlist
Owner: AJ Jordan <a...@strugee.net>

* Package name: filter-other-days
  Version : 1.0.1
  Upstream Author : AJ Jordan <a...@strugee.net> (me)
* URL : https://github.com/strugee/filter-other-days
* License : AGPL
  Programming Lang: POSIX sh
  Description : filter logfiles for today's date in an Artificial 
Ignorance-compatible way

 filter-other-days filters logfiles for today's date in an Artificial
 Ignorance-compatible way. That means it throws away entries that it's
 sure aren't from today, instead of filtering for entries it thinks
 are from today.

 This is done for security reasons; it's better to receive irrelevant
 information than it is to miss relevant information. Thus
 filter-other-days is useful as a part of a larger Artificial
 Ignorance setup if the administrator wants to e.g. get a daily report
 emailed to them.

The package description above pretty much covers why I think this
package is useful. The last time I sent this ITP my mail got sent to
/dev/null due to a local misconfiguration; at the time I found at
least one package in Debian that provided similar functionality, but
that package provided a larger suite of tools to deal with logfiles
whereas filter-other-days has a more limited purpose.

Note that I would need a sponsor to get this into the archive as I am
neither a DD nor a DM. I am, however, the upstream maintainer. I
intend to maintain Debian packaging in tandem with the source code in
the upstream repository and in fact already have packaging written
which passes Lintian with no errors or warnings in pedantic mode.

filter-other-days will run on any system with POSIX and GNU `seq`,
which Debian fulfills handily even with nothing but essential
installed.

Cheers!

AJ


signature.asc
Description: PGP signature


Bug#884962: gnome-calendar: Cannot Sync without gnome-control-center

2017-12-21 Thread Jordan Waughtal
Package: gnome-calendar
Version: 3.22.4-2
Severity: wishlist

Dear Maintainer,

   I use a very modest computer. I run very minimal openbox desktop.
I noticed I could not sync my other accounts with out installing gnome-
control-center.  I think this should be listed as a recomended/suggested
 package.

In the future, I would like to see some of the functionality be directly 
part of this package, as I do not need nor want gnome-control-center, which
was over 100MBs to download (With all the dependancies).

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 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)

Versions of packages gnome-calendar depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gsettings-desktop-schemas3.22.0-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libecal-1.2-19   3.22.7-1
ii  libedataserver-1.2-223.22.7-1
ii  libedataserverui-1.2-1   3.22.7-1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libgoa-1.0-0b3.22.5-1
ii  libgtk-3-0   3.22.11-1
ii  libical2 2.0.0-0.5+b1
ii  libicu57 57.1-6+deb9u1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libsecret-1-00.18.5-3.1
ii  libsoup2.4-1 2.56.0-2+deb9u1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u1

Versions of packages gnome-calendar recommends:
ii  evolution-data-server  3.22.7-1

gnome-calendar suggests no packages.

-- no debconf information



Bug#884335: network-manager: Network-Manager Fails to Start after update

2017-12-13 Thread Jordan Waughtal
Package: network-manager
Version: 1.6.2-3
Severity: important

Dear Maintainer,

   * I changed all my sources from jessie to stretch and updated. Upon a 
reboot, NetworkManager does not start.
 
   * I uninstalled the package, rebooted and reinstalled it.
   * I still get this:
 Dec 13 22:22:58 orangepione systemd[1]: Starting Network Manager...
-- Subject: Unit NetworkManager.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit NetworkManager.service has begun starting up.
Dec 13 22:22:58 orangepione systemd[27121]: NetworkManager.service: Failed at 
step NAMESPACE spawning /usr/sbin/Net
-- Subject: Process /usr/sbin/NetworkManager could not be executed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The process /usr/sbin/NetworkManager could not be executed and failed.
-- 
-- The error number returned by this process is 9.
Dec 13 22:22:58 orangepione systemd[1]: NetworkManager.service: Main process 
exited, code=exited, status=226/NAMESP
Dec 13 22:22:58 orangepione systemd[1]: Failed to start Network Manager.
-- Subject: Unit NetworkManager.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support

   * I was hoping it was an old config file causing the issue, so I thought a 
reinstall could fix the solution.



-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.4.113-sun8i (SMP w/4 CPU cores; PREEMPT)
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)

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.24-0+deb9u1
ii  init-system-helpers1.48
ii  libaudit1  1:2.6.7-2
ii  libbluetooth3  5.43-2+deb9u1
ii  libc6  2.24-11+deb9u1
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5+deb9u3
ii  libgudev-1.0-0 230-3
ii  libjansson42.9-1
ii  libmm-glib01.6.4-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.19-1+b1
ii  libnl-3-2003.2.27-2
ii  libnm0 1.6.2-3
ii  libpam-systemd 232-25+deb9u1
ii  libpolkit-agent-1-00.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libreadline7   7.0-3
ii  libselinux12.6-3+b3
ii  libsoup2.4-1   2.56.0-2+deb9u1
ii  libsystemd0232-25+deb9u1
ii  libteamdctl0   1.26-1+b1
ii  libuuid1   2.29.2-1
ii  lsb-base   9.20161125
ii  policykit-10.105-18
ii  udev   232-25+deb9u1
ii  wpasupplicant  2:2.4-1+deb9u1

Versions of packages network-manager recommends:
ii  crda 3.18-1
pn  dnsmasq-base 
ii  iptables 1.6.0+snapshot20161117-6
ii  iputils-arping   3:20161105-1
ii  isc-dhcp-client  4.3.5-3
pn  modemmanager 
pn  ppp  

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information



Bug#882158: Info received (LastChance: free trial pure cbdoil Zh)

2017-12-01 Thread Gregory Jordan
Unsubscribe me from you and your affiliates mailing list

On Dec 1, 2017 4:45 PM, "Debian Bug Tracking System" 
wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Release Team 
>
> If you wish to submit further information on this problem, please
> send it to 882...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 882158: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882158
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>


Bug#882158: LastChance: free trial pure cbdoil Zh

2017-12-01 Thread Gregory Jordan
Send it to 3833 liberty hill road chillicothe,ohio 45601

On Dec 1, 2017 4:26 PM, "Pure.cbd"  wrote:

> The New.cbd drug that is Sweeping the Nation
>
> Scientists are calling this the UltimateCure for StressRelief
>
> Prevents Anxiety and Stress
> Intensive Relief
> Relieves Nausea
> Helpsto Fight Cancer
> Lcwers Incidence of Diabetes
> Promotes Cardiovascular Health
>
>
> 
>
>
> unsubscrib
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 2017-11-19 18:36, Aurelien Jarno wrote: > Package: release.debian.org
> > Severity: normal > Tags: stretch > User: release.debian.org@packages.
> debian.org > Usertags: pu > > Dear stable release managers, > > I would
> like to upload a new glibc package for the next stretch release. > It
> mostly consists in pulling the release/2.24/master upstream branch. >
> Unfortunately this makes the patch big because: > - it includes patches
> that were applied as debian patches before (mostly > security ones) > -
> upstream decided to backport all the test support from master in order > to
> ease the backport of fixes from master including the corresponding > tests
> > > I have therefore included two diffs, the full debdiff compared to >
> version 2.24-11+deb9u1 currently in stable, and the one comparing the >
> tree with all the patches applied. The biggest part of the later diff >
> comes from the support infrastructure for tests (support/*) or from > tests
> (tst-*). After removing changes which don't end-up in the binary >
> packages, there are less than 600 lines changed. > > Most of the changes
> were already in buster/sid for quite some time, with > the notable
> exception of compatibility with Intel C++ which is only in > sid and
> experimental. > > Thanks for considering, and don't hesitate to ask for
> more details if > needed. I would also like to add the attached an
> additional patch to fix a critical bug which has been filled recently,
> breaking some systems during jessie to stretch upgrades (see bug#882272).
> Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net


Bug#867166: Future of linux-grec in Debian

2017-11-29 Thread Jordan Glover
I think this bug can be closed now.

Jordan

Bug#867166: Future of linux-grec in Debian

2017-10-27 Thread Jordan Glover
linux-grsec-base[1] is missing from stable-backports and I don't see it being 
prepared for upload there[2]. Other than that this bug can be closed. Thanks 
for your work.

[1] https://tracker.debian.org/pkg/linux-grsec-base
[2] https://anonscm.debian.org/git/collab-maint/linux-grsec-base.git

Bug#867166: Future of linux-grec in Debian

2017-10-04 Thread Jordan Glover
I saw that new version landed in unstable. Is it possible to have it in 
stable-backports? I think it will be best to have it in stable-backports ONLY 
(without unstable) where it can live until 4.9 kernel gets EOL. In case of 
unstable the gap between vanilla kernel and 4.9 will get bigger and bigger and 
userspace tools may want to use new features unavailable in 4.9 LTS thus grsec 
value is lower there. Of course if it's not possible let it be as it is. Thanks 
for your efforts.

BTW: Here's some tools for building grsec kernel reproducible in case it's 
useful to you.
https://github.com/hardenedlinux/grsecurity-reproducible-build

Bug#846314: alot: Migrate from pygpgme to python-gpg

2017-08-10 Thread Jordan Justen
On 2017-07-08 08:43:18, Jonathan Wiltshire wrote:
> I will be requesting removal of pygpgme from unstable at the end of
> this month (but it's up to ftp masters if they do so immediately and break
> things, or wait for dependencies to be resolved).

Jonathan, I wanted to give an update for 'alot' and the pygpgme
dependency. An upstream developer picked up the patch and rebased it.
While verifying it he discovered other GPG bugs in 'alot'. I believe
those bugs have been fixed, but the pygpgme=>python-gpg bug is just
now being finished up:

https://github.com/pazz/alot/pull/1086

Upstream plans to do a new release soon with all these GPG updates.
(Hopefully within a week base on the conversation in the pull request
above.)

I thought it was best to hold off on trying to merge the patch into
the older release when a new upstream release should address the
dependency issue soon.

I'm not sure if/when sid might lose pygpgme, but hopefully we'll have
a new upstream release of 'alot' to address the dependency issue
before that happens.

-Jordan


signature.asc
Description: signature


Bug#867166: Future of linux-grec in Debian

2017-07-04 Thread Jordan Glover
Thank you for the reply. It's great that you consider packaging one of the 
forward ports.
Just one more question - Is it possible for you to update current package to 
latest official version (from 4.9.18 to 4.9.24)? That would be nice temporary 
solution while you are too busy to make general decisions. I don't know how 
much work is needed to do it so ignore this if that work is still substantial.
You can find official patches archived in:
https://github.com/slashbeast/grsecurity-scrape/tree/master/test/4.9.24
https://github.com/linux-scraping/grsecurity-patches/tree/master/grsec-4.9

Bug#867166: Future of linux-grec in Debian

2017-07-04 Thread Jordan Glover
Source: linux-grsec
Severity: serious
I wanted to ask you about the future of linux-grsec in debian. The package 
wasn't updated for some time and it's now at 4.9.18 version while last official 
grsecurity version is 4.9.24. Additionally there are few forward ports of 
grsecurity for 4.9 LTS kernel line [1],[2] .
As 4.9 LTS kernel is used in current Debian stable release, something like 
linux-unofficial_grsec, based on forward grsec ports for 4.9 kernel would be a 
great addition for stable-backports and/or unstable. It could be abandoned when 
4.9 kernel gets EOL status. Hopefully by then mainline linux will get some 
security improvements, currently worked on linux-hardened project [2] and KSPP .
As for now there is nothing comparable to grsecurity and loosing it completely 
would be huge blow for debian community. I know that Alpine Linux developers 
decided to continue maintaining their grsec a like kernel [3].
It will be nice to clarify linux-grsec package situation as users now get stuck 
in limbo.
[1]https://github.com/dapperlinux/dapper-secure-kernel-patchset-stable
[2] https://github.com/minipli/linux-unofficial_grsec/releases
[3] https://github.com/thestinger/linux-hardened
[4] https://pkgs.alpinelinux.org/package/edge/main/x86_64/linux-hardened

Bug#865094: ITP: renderdoc -- a stand-alone graphics debugging tool

2017-06-19 Thread Jordan Justen
Package: wnpp
Severity: wishlist
Owner: Jordan Justen <jordan.l.jus...@intel.com>

* Package name: renderdoc
  Version : 0.34
  Upstream Author : Baldur Karlsson <bald...@baldurk.org>
* URL : https://renderdoc.org/
* License : MIT
  Programming Lang: C++
  Description : Renderdoc Graphics Debugging Tool

Renderdoc is a stand-alone graphics debugging tool. It can be used to
debug 3D graphics programs. Renderdoc captures the state and calls
made during a graphics frame draw. The developer may then replay and
debug the draw calls to diagnose issues with the application.

I plan to maintain the debian renderdoc package.


signature.asc
Description: signature


Bug#820194: nasm: please make the build reproducible (font ordering in documentation)

2017-05-22 Thread Jordan Justen
Control: owner -1 !

I rebased your patch. Some portions of the patch seem to have been
adopted upstream. I need to verify that it still fixes the issue.

https://anonscm.debian.org/cgit/collab-maint/nasm.git/commit/?id=6ca604a0


signature.asc
Description: signature


Bug#855354: RFS: alot/0.5.1-1 [ITA]

2017-04-21 Thread Jordan Justen
On 2017-04-21 06:12:21, Johannes Schauer wrote:
> Quoting Ben Finney (2017-04-21 14:44:52)
> > Jordan, have you made more changes that should be released?
> > 
> > Johannes, are you waiting on any changes before you approve and upload
> > this package?
> 
> Jordan and I were writing each other privately in February. Currently progress
> is stalled on the question of how to maintain the package. The options are:
> 
>  1. maintaining it under the umbrella of the Python Applications Packaging 
> Team
> but they use svn which Jordan wants to avoid in favour of git. There is 
> the
> question of whether it would be acceptable to use PAPT+git:
> 
> http://lists.alioth.debian.org/pipermail/python-apps-team/2017-February/013126.html
> But as the last message indicates, there seems to be no consensus yet
> whether to use git-dpm or switch to gbp-pq when moving python-apps from 
> svn
> to git...

I was trying to see if I could work with Stefano (Cc'd) to help with
the PAPT svn=>git transition, but that didn't end up going anywhere. :\

>  2. using collab-maint with whatever git packaging workflow but it seems that
> Jordan isn't sure yet which one to pick for maintenance of alot
> 
> Jordan, are you still on board? Otherwise I just pick the option I like and
> start committing your work. :)

Yes, I am still interested. I'd convinced myself that I just needed to
give up on using git for now, so I planning to commit the patches to
svn under the current PAPT packaging area. I'll do that and then work
with you (Johannes) to upload the new package.

-Jordan


signature.asc
Description: signature


Bug#726486: pump.io packaging help (from upstream)

2017-04-19 Thread Alex Jordan
Heya!

Relatively recently I became the primary maintainer of the pump.io
project and I just wanted to reach out and say hi!

I know there was [an effort][1] to package pump.io for Debian a while
back, though it seems to have stalled out. I just wanted to say that
we're very interested in getting pump.io into Debian - with the
upcoming 4.0.0 release the codebase will finally(!) in a state where
I'd feel comfortable about okaying it being frozen long-term.

If anyone is interested in restarting this effort, please feel free to
reach out to me! I'd be happy to consider upstream changes or offer
advice to make this (and npm packaging in general) easier. I can't
guarantee anything but we would also consider committing to long-term
security support for whatever release gets packaged for Debian.

As a side note, it would be great to be in the loop if this does end
up happening - from looking at [1] I see some things that would end
disastrously. For example, that page was tracking packaging a pump.io
version that used Express 2.x, but it seems that the plan was to
depend on Express 4.x packages? (Correct me if I'm wrong, obviously.)
Trying to do so would be a very bad idea - that upgrade took _months_
of work upstream and hundreds of commits, which is obviously untenable
for downstream packagers to maintain.

Anyway! Just wanted to say hi and that I hope to work with you all at
some point in the future.

Cheers!

AJ

 [1]: https://wiki.debian.org/Javascript/Nodejs/Tasks/Pump.io


signature.asc
Description: PGP signature


Bug#722223: gimp segfault

2017-03-21 Thread Jordan Michaels
Experienced this issue on Ubuntu 16.04 LTS and loading fonts using libpango 
1.38. Error message simply indicated segfault.

Found this URL:
https://docs.gimp.org/en/font-problems.html

...indicating that an upgrade to pango 1.4 would correct the issue.

Found this URL:
http://packages.ubuntu.com/search?keywords=libpango

Indicating that 1.4 was available in Ubuntu 16.10. Upgraded my machine. Started 
Gimp, still crashed. ::discouraged:: I reviewed the kern.log, found a better 
error message from libpango indicating the offending font! Removed corrupted 
font file, Gimp works without issues.

Suggestion: Can libpango and/or gimp gracefully fail over broken font files? 
Even better, show an error that it could not load a specific font?

--
Kind regards,
Jordan Michaels
Vivio Technologies



Bug#855354: RFS: alot/0.5.1-1 [ITA]

2017-02-21 Thread Jordan Justen
On 2017-02-17 05:29:44, Johannes Schauer wrote:
> Quoting Gianfranco Costamagna (2017-02-17 11:11:35)
> > lets review:
> > a) PAPT seems more appropriate
> > b) "alot (0.3.7-1) unstable; urgency=medium"
> > this never went in unstable, please merge the two changelog entries 
> > together with the correct
> > author attributions
> > c) #846314 <-- please fix it
> > d) please close #792108 in the correct "new upstream release" changelog
> > e) #701806 wontfix?
> > f) the runtime dependencies needs to match the versions on setup.py
> > and if oldstable/stable already have higher versions, you can just drop 
> > them and let
> > python:Depends fill them correctly
> > g) please consider using pybuild for building it
> > h) please consider bumping compat level to 10

I uploaded a new 0.5.1-1 to mentors.debian.net. I agree for (a). I
think the new version addresses (b) and (d) through (h).

For (c), I replied to the bug and took ownership. I think we should
see if this goes upstream soon since upstream seems interested in the
change.

> You may also want to close bug #792108 with that release.

Duplicate of (d) above.

> You may also want to add yourself to debian/copyright if your changes are
> substantial (like switching to pybuild and compat level 10 might be).

Done.

> Feel free to contact me for sponsorship as I'm an alot user and also
> fixed/filed a couple of bugs together with upstream. I'm thus very interested
> in keeping this package in Debian.

Thanks! Let me know if you'd like any additional changes made.

-Jordan

signature.asc
Description: signature


Bug#846314: alot: please use python-gpg instead of python-gpgme

2017-02-20 Thread Jordan Justen
Control: owner -1 !

It looks like upsteam is willing to pull in this change. In fact, the
project owner rebased the patches.

https://github.com/pazz/alot/pull/915

But, Daniel said he has also rebased the patches.

I think we should hold off a bit more to see if this gets merged
upstream soon.

-Jordan

signature.asc
Description: signature


Bug#855559: Use pybuild in packaging

2017-02-19 Thread Jordan Justen
Package: alot
Version: 0.3.6-1
Severity: wishlist
Owner: jljus...@gmail.com

Suggested by Gianfranco in #855354.


signature.asc
Description: signature


Bug#855354: RFS: alot/0.5.1-1 [ITA]

2017-02-17 Thread Jordan Justen
On 2017-02-16 23:59:07, Simon Chopin wrote:
> I do have reservations about moving the package from the PAPT umbrella into
> collab-maint, but it's not my call anymore.

I'm sorry. I meant to say that I planned to put it into git under the
PAPT, not collab-maint. So, the change would be moving from svn to
git. I did apply to be added to the alioth PAPT project.

-Jordan


signature.asc
Description: signature


Bug#855355: RFS: nasm/2.12.02-1 [ITA]

2017-02-16 Thread Jordan Justen


Package: sponsorship-requests
Severity: low

Dear mentors,

I am looking for a sponsor for my package "nasm"

 Package name: nasm
 Version : 2.12.02-1
 Upstream Author : "H. Peter Anvin" <h...@zytor.com>
 URL : http://www.nasm.us/
 License : BSD-2-clause
 Section : devel

It builds those binary packages:

  nasm  - General-purpose x86 assembler

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/nasm


Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/n/nasm/nasm_2.12.02-1.dsc

I have made the packaging available in git under collab-maint:

https://anonscm.debian.org/cgit/collab-maint/nasm.git/

Changes since the last upload:

nasm (2.12.02-1) experimental; urgency=low

  * New upstream version 2.12.02

-Jordan


signature.asc
Description: signature


Bug#855354: RFS: alot/0.5.1-1 [ITA]

2017-02-16 Thread Jordan Justen


Package: sponsorship-requests
Severity: low

Dear mentors,

I am looking for a sponsor for my package "alot"

 Package name: alot
 Version : 0.5.1-1
 Upstream Author : Patrick Totzke <patricktot...@gmail.com>
 URL : https://github.com/pazz/alot
 License : GPL-3+, LGPL-2.1+
 Section : mail

It builds those binary packages:

  alot  - Text mode MUA using notmuch mail
lot-doc   - Text mode MUA using notmuch mail - documentation

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/alot


Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/a/alot/alot_0.5.1-1.dsc

I have made the packaging available in git:

https://github.com/jljusten/alot

But, if I am able to adopt this package, then I would move this under
debian's collab-maint project.

Changes since the last upload:

alot (0.5.1-1) experimental; urgency=low

  * New upstream release (Closes: #848150).
  * Add Jordan as uploader.

-Jordan


signature.asc
Description: signature


Bug#846704: waffle: diff for NMU version 1.5.2-2.1

2016-12-14 Thread Jordan Justen
On 2016-12-14 09:58:16, Andrey Rahmatullin wrote:
> Control: tags 846704 + patch
> Control: tags 846704 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for waffle (versioned as 1.5.2-2.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

There's no need to delay the change.



Bug#838520: found bug fixed and closed already => #807707

2016-09-21 Thread Jordan
It was closed for ddclient 3.8.2-3.
I am using 3.8.2-2 which is the latest available on Raspbian/Jessie.

Sorry for reporting a dup.
Jordan



Bug#838520: ddclient: /etc/dhcp/dhclient-exit-hooks.d/ddclient uses explicit "exit" directives

2016-09-21 Thread jordan
Package: ddclient
Version: 3.8.2-2
Severity: important

Dear Maintainer

The hook scripts in the dhclient-exit-hooks.d directory are included (using the
dot command) in the /sbin/dhclient-script. Using explicit "exit" in a hook
script leads to immediate stop so that other hook scripts will be missed.

Using round brackets (..) around the executable part in the ddclient hook
script renders the "exit" directive into a stop/break statement while
preserving the exit code which is interpreted in /sbin/dhclient-script.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

Kernel: Linux 4.4.13-v7+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ddclient depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  initscripts2.88dsf-59
ii  lsb-base   4.1+Debian13+rpi1+nmu1
ii  perl [perl5]   5.20.2-3+deb8u6

Versions of packages ddclient recommends:
ii  libio-socket-ssl-perl  2.002-2+deb8u1

ddclient suggests no packages.

-- Configuration Files:
/etc/dhcp/dhclient-exit-hooks.d/ddclient changed:

( # -- fixed

[ -x /usr/sbin/ddclient ] || exit 0
[ -f /etc/default/ddclient ] || exit 0
.. /etc/default/ddclient
[ $run_dhclient = "true" ] || exit 0
case $reason in
BOUND | RENEW | REBIND)
/usr/bin/logger -t dhclient $reason, updating IP address with ddclient
/usr/sbin/ddclient -daemon=0 -syslog > /dev/null 2>&1
;;
*)
;;
esac

) # -- fixed


-- debconf information excluded



Bug#829662: gnome-tweak-tool: The "Typing" tab will check boxes of closed categories

2016-07-05 Thread Jordan Ayers
Package: gnome-tweak-tool
Version: 3.20.1-1
Severity: minor

In the "typing" tab, if you click slightly below a closed category (to low for
the category to open, but not so low that you click the category below it), you
will check the first box in that category. This can lead to a user
inadvertently checking a box they didn't not mean to check. The only indication
that as box has been checked is the category goes bold. However, if a user
already has at least one other box checked in that category, there will be no
visual indication whatsoever a setting has been changed (short of opening that
category and noticing).

It is quite minor, but also potentially frustrating if a user doesn't catch it
before they close the window.

I tried to replicate this bug in Evolution (the only other gnome program I
could find that has a similar collapsible-category check-boxes), and failed to
replicate it there. So it seems to be a gnome-tweak-tool issue and not a gtk
issue (but I've never written anything with gtk so I have little idea).



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-tweak-tool depends on:
ii  gir1.2-glib-2.01.48.0-2
ii  gir1.2-gnomedesktop-3.03.20.2-1
ii  gir1.2-gtk-3.0 3.20.6-2
ii  gir1.2-notify-0.7  0.7.6-2
ii  gir1.2-pango-1.0   1.40.1-1
ii  gir1.2-soup-2.42.54.1-1
ii  gnome-settings-daemon  3.20.1-2
ii  gnome-shell-common 3.20.2-3
ii  gsettings-desktop-schemas  3.20.0-3
ii  mutter-common  3.20.2-1
ii  python 2.7.11-2
ii  python-gi  3.20.1-1

gnome-tweak-tool recommends no packages.

gnome-tweak-tool suggests no packages.

-- no debconf information



Bug#805430: Patch

2016-01-18 Thread Alex Jordan

On Fri, 27 Nov 2015 14:35:52 +0100 Thomas Goirand wrote:


I'll upload as soon as I have a resolution for #805407 by the FTP
masters, which is blocking migration of things I want to upload to
jessie-backports. All packages are ready, and this doesn't depend on me
anymore.


This is now fixed, correct?



Bug#789650: ITP: ruby-buff-ruby-engine -- A Ruby mixin library for querying the platform

2015-06-22 Thread Jordan Metzmeier
Package: wnpp
Severity: wishlist
Owner: Jordan Metzmeier jmetzmeie...@gmail.com

* Package name: ruby-buff-ruby-engine
  Version : 0.1.0
  Upstream Author : Jamie Winsor ja...@vialstudios.com
* URL : https://github.com/reset/buff-ruby_engine
* License : Apache
  Programming Lang: Ruby
  Description : A Ruby mixin library for querying the platform running Ruby

A Ruby mixin library for querying the platform running Ruby

This library is a dependency for Berkshelf.

-- 
Jordan Metzmeier


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



Bug#775475: ITP: berkshelf -- Chef cookbook management

2015-01-15 Thread Jordan Metzmeier
Package: wnpp
Severity: wishlist
Owner: Jordan Metzmeier jmetzmeie...@gmail.com

* Package name: berkshelf
  Version : 3.2.3
  Upstream Author : Jamie Winsor (ja...@vialstudios.com)
* URL : http://berkshelf.com
* License : Apache 2.0
  Programming Lang: Ruby
  Description : Chef cookbook management

TBD


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



Bug#773635: python-wxgtk2.8: WXU_2.8 not defined: Cannot run apps that use wxPython 2.8

2014-12-21 Thread Jordan Irwin
Package: python-wxgtk2.8
Version: 2.8.12.1+dfsg2-2
Severity: important

Dear Maintainer,

I have an application that I develop that used wxPython. Currently my app
supports both version 2.8 and 3.0 of wxPython/wxWidgets. However, when
trying to run my app on Debian using 2.8 I get the following error:

ImportError: /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_gdi_.so:
symbol _ZTV14wxGraphicsPath, version WXU_2.8 not defined in file
libwx_gtk2u_core-2.8.so.0 with link time reference

I was curious if only my application was affected so I went into the source
code of an application from the Debian repository that uses wxPython. In
this case I used drPython. By default drPython will use the newest version of
wxPython (I believe). drPython started up fine as it was using wxPython 3.0
by default. However, I changed its code and forced it to use version 2.8.
Once I did that I received the same error output as above.

I believe that this is a problem with the build of wxpython2.8 on Debian.
I do not know if the main problem lies upstream.


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-wxgtk2.8 depends on:
ii  libc6 2.19-13
ii  libgcc1   1:4.9.2-9
ii  libstdc++64.9.2-9
ii  libwxbase2.8-02.8.12.1+dfsg2-2
ii  libwxgtk2.8-0 2.8.12.1+dfsg2-2
ii  python2.7.8-2
ii  python-wxversion  3.0.1.1+dfsg-2

python-wxgtk2.8 recommends no packages.

Versions of packages python-wxgtk2.8 suggests:
pn  editra  none
pn  wx2.8-doc   none
pn  wx2.8-examples  none

-- no debconf information


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



Bug#752709: Antimicro is Greate

2014-12-20 Thread Jordan Irwin
I sure hope this app gets added to Debian soon. I might be willing to
package and maintain it had I the knowledge and experience to do so.

Thank you,
- Jordan

http://antumdeluge.wordpress.com/


Bug#770758: libwxgtk2.8-0: wxSound does not work

2014-11-23 Thread Jordan Irwin
Package: libwxgtk2.8-0
Version: 2.8.12.1+dfsg2-2
Severity: normal

Dear Maintainer,

I have been having an issue with official builds of wxWidgets on Debian-based
systems for a couple years now. The wxSound object does not work. It does not
produce any audio output. I don't see any error output when building an app
using the module nor when it is used at runtime.

The bug only seems to affect Debian-based systems. Namely, I have tested it on
Debian, Ubuntu, and Linux Mint, on none of which it works. I have also tested
builds on non-Debian systems; Fedora, FreeBSD, Windows XP, and Windows 7. On
all of these systems the wxSound module works fine.

To further investigate the problem I custom built wxWidgets on my Debian
system using source from http://www.wxwidgets.org/. Running binaries produced
with the Debian build and custom build successfully executed the wxSound
module when linked to the custom libs. For these reasons I believe that there
is an error in the official Debian build of wxWidgets's shared libs:

- Only Debian-based systems are affected.
- A custom build of wxWidgets (wxGtk) produces a working wxSound module.

For reference, the build command/options that I used follow:

  ../configure --enable-shared --enable-unicode --disable-gtktest \
  --disable-sdltest --with-gtk --with-sdl --with-opengl \
  --with-gnomeprint --with-gnomevfs

I am unsure if current builds of the newer libwxgtk3.0-0 share this same bug. 

The project for which I am using wxWidgets and wxSound is located here for
reference as well: https://sourceforge.net/projects/myabcs

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libwxgtk2.8-0 depends on:
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-13
ii  libexpat1 2.1.0-6+b3
ii  libfontconfig12.11.0-6.2
ii  libfreetype6  2.5.2-2
ii  libgcc1   1:4.9.2-2
ii  libgdk-pixbuf2.0-02.31.1-2+b1
ii  libgl1-mesa-glx [libgl1]  10.3.2-1
ii  libglib2.0-0  2.42.1-1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgtk2.0-0   2.24.25-1
ii  libjpeg8  8d1-2
ii  libpango-1.0-01.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpng12-01.2.50-2+b1
ii  libsm62:1.2.2-1
ii  libstdc++64.9.2-2
ii  libtiff5  4.0.3-10+b3
ii  libwxbase2.8-02.8.12.1+dfsg2-2
ii  libxinerama1  2:1.1.3-1+b1
ii  libxxf86vm1   1:1.1.3-1+b1
ii  multiarch-support 2.19-13
ii  zlib1g1:1.2.8.dfsg-2

libwxgtk2.8-0 recommends no packages.

libwxgtk2.8-0 suggests no packages.

-- no debconf information


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



Bug#770758: Testing wxSound for libwxgtk3.0-0

2014-11-23 Thread Jordan Irwin
I'm trying to update my project to wxWidgets 3.x, so no problem that it
won't be fixed. I'll test wxSound in 3.x as soon as I can. Thanks for the
quick reply.

- Jordan

http://antumdeluge.wordpress.com/


Bug#769986: RFS: puppetlabs-vcsrepo/1.2.0-1 ITP

2014-11-22 Thread Jordan Metzmeier
On Mon, Nov 17, 2014 at 10:28 PM, Jordan Metzmeier
jmetzmeie...@gmail.com wrote:
 Package: sponsorship-requests
 Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package puppetlabs-vcsrepo

I have made a few updates to the package on mentors:

* Moved vcs to git.debian.org under pkg-puppet
* Add unit tests run to the package build
* Renamed source package to match the binary to remain consistent with
the existing packaged puppet modules
* Switched from the release tarball on puppet forge to the release
tarball on github. The former doesn't contain the fixtures required to
run the unit tests.

This module is the most downloaded module on puppet forge with
2,486,128 downloads at the time of writing this. It would make a good
addition to stretch (and jessie-backports).

http://mentors.debian.net/package/puppetlabs-vcsrepo

Regards,
Jordan Metzmeier


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



Bug#769851: ITP: puppetlabs-spec-helper -- Ruby library for puppet module testing

2014-11-17 Thread Jordan Metzmeier
close 769851
thanks

On Mon, Nov 17, 2014 at 8:07 AM, Stig Sandbeck Mathisen s...@debian.org wrote:
 Jordan Metzmeier jmetzmeie...@gmail.com writes:

 * Package name: puppetlabs-spec-helper

 This is already packaged as
 https://packages.debian.org/sid/ruby-puppetlabs-spec-helper

Thanks. I probably only searched stable by mistake when checking to
see if it was already packaged.


Regards,
Jordan Metzmeier


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



Bug#769986: RFS: puppetlabs-vcsrepo/1.2.0-1 ITP

2014-11-17 Thread Jordan Metzmeier
Package: sponsorship-requests
Severity: wishlist

 Dear mentors,

 I am looking for a sponsor for my package puppetlabs-vcsrepo

  * Package name: puppetlabs-vcsrepo
Version : 1.2.0-1
Upstream Author : Puppet Labs Inc. i...@puppetlabs.com
  * URL : https://forge.puppetlabs.com/puppetlabs/vcsrepo
  * License : GPL-2+
Section : admin

  It builds those binary packages:

  puppet-module-puppetlabs-vcsrepo - Puppet module to deploy content from a 
version control system

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/puppetlabs-vcsrepo


  Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/p/puppetlabs-vcsrepo/puppetlabs-vcsrepo_1.2.0-1.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

  Initial release (Closes: #769062)


  I would like this package to be team maintained under the Puppet Package 
Maintainers team. If no one from
  that team wishes to sponsor the upload, I can change the maintainer field for 
the package.

  Regards,
  Jordan Metzmeier


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



Bug#769851: ITP: puppetlabs-spec-helper -- Ruby library for puppet module testing

2014-11-16 Thread Jordan Metzmeier
Package: wnpp
Severity: wishlist
Owner: Jordan Metzmeier jmetzmeie...@gmail.com

* Package name: puppetlabs-spec-helper
  Version : 0.8.2
  Upstream Author : Puppet Labs Inc i...@puppetlabs.com
* URL : https://github.com/puppetlabs/puppetlabs_spec_helper
* License : Apache
  Programming Lang: Ruby
  Description : Ruby modules for puppet module testing

This project is meant to provide a single source of truth for how to initialize
different Puppet versions for spec testing. Differences in puppet versions are 
handled
for you. Convenience classes are provided for things such as creating 
tempfiles, common rspec
matchers, etc.


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



Bug#769062: ITP: puppet-module-puppetlabs-vcsrepo -- Puppet module to deploy content from a version control system

2014-11-10 Thread Jordan Metzmeier
Package: wnpp
Severity: wishlist
Owner: Jordan Metzmeier jmetzmeie...@gmail.com

* Package name: puppet-module-puppetlabs-vcsrepo
  Version : 1.2.0
  Upstream Author : Bruce Williams brwco...@gmail.com
* URL : https://forge.puppetlabs.com/puppetlabs/vcsrepo
* License : GPL-2+
  Programming Lang: Ruby
  Description : Puppet module to deploy content from a version control 
system

Puppet lets you centrally manage every important aspect of your system using a 
cross-platform
specification language that manages all the separate elements normally 
aggregated in different
files, like users, cron jobs, and hosts, along with obviously discrete elements 
like packages,
services, and files.

This module allows you to deploy content from a version control system. The 
following version
control systems are supported:

 * Git
 * Bazaar
 * CVS
 * Mercurial
 * Perforce
 * Subversion


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



Bug#755597:

2014-11-04 Thread Jordan Metzmeier
tags 755597 patch pending
thanks

There was a patch upstream that at least fixes the tests under django
1.7. I have not tested the installed functionality. I also did not
commit my changes to SVN, because there was a pending change to
debian/rules that never made it into the upload. Since this won't make
it in before the freeze, I thought it would be best to just provide
the debdiff without the rules change.


Regards,
Jordan Metzmeier


django-conneg-dj17.debdiff
Description: Binary data


Bug#767308: [Python-modules-team] Bug#767308: pypi-install fails without 'requests'-module

2014-10-29 Thread Jordan Metzmeier
On Wed, Oct 29, 2014 at 5:57 PM, Hendrik Jaeger d...@henk.geekmail.org wrote:
 Package: python-stdeb
 Version: 0.8.2-3
 Severity: normal

 % pypi-download cdist
 Traceback (most recent call last):
   File /usr/bin/pypi-download, line 4, in module
 from stdeb.downloader import myprint, get_source_tarball
   File /usr/lib/python2.7/dist-packages/stdeb/downloader.py, line 10,
 in module import requests
 ImportError: No module named requests

 Installing 'python-requests' fixes the issue.


It looks like not all of the changes I committed to svn to fix #759981
made it into that upload. Piotr, updating the changelog and uploading
what is currently in svn trunk will resolve this bug.

Regards,
Jordan Metzmeier


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



Bug#766393: debian-maintainers: Please add Jordan Justen as a Debian Maintainer

2014-10-22 Thread Jordan Justen
Package: debian-maintainers
Severity: normal

Hello,

Please add Jordan Justen jordan.l.jus...@intel.com as a Debian Maintainer.

I'm attaching here the jetring changeset.

Please, note that the adress I'm using for Packaging 
(jordan.l.jus...@intel.com) isn't the primary UID of my OpenPGP
key C274 8521 7414 C9DF 0231  6C2E 37F9 9F68 CAF9 92EB.

Thanks!
Comment: Add Jordan Justen jordan.l.jus...@intel.com as a Debian Maintainer
Date: Wed, 22 Oct 2014 11:23:48 -0700
Action: import
Recommended-By: 
  Carl Worth cwo...@cworth.org
Agreement: 
  https://lists.debian.org/debian-newmaint/2014/04/msg00016.html
Advocates: 
  https://lists.debian.org/debian-newmaint/2014/10/msg00021.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1
  
  mQINBFL4VYgBEAC/YCAGo2pq9L2dfh7qi0ctANDDZB/i9p9pvVrZTdvhTTEXDF0Y
  9XN/Op64TdgpFRCCkafgTHCTfdwfO+MWGmpDleXYinPX35mJq/N6NO0qW7R5kTi5
  4zIgIqPNP3GL7K2y1o5NQgYX2KZyeeMlA7AuMv+pw8DYvI2/vvQdxVadDSkxqJl2
  iRZ9T/Wau/lTcgl6H8+Bx9tOnZQTcsyj5MWGglhW2nP57OVGPkxX1TkzxPGxW2zp
  Iwi+nZUQb8JYb6qcHRsytWd54UD4146LO/7n9TtQvUy+uOmO1JSKe4ZHrvwoorR3
  mbeHNjzxwuW3UbjlQyJmzWcMZlG6xcgSNYSnl5uKf80CfRCTsu4vms0BhaBvfQHp
  p7vnyP0Rg92d+eZZuJha/38q0rWXiPywxQJqfxFR/2ADx3rijKVy2uOEzcILK2TL
  Iga/FR/dE+Ya7e1jIK3jVuh2tqkGOo6TXnY4VQd5hxSzaF93l8ISWupm08bukB+J
  3jd2bxn/xv5HKc/nj+86GN7ifBIbdWpsM/IHrhZgQMrDIixqIDRG0ke3drECuHCs
  6KBii4GE8HkmpNf97O309/S/Yr5qWFA5u/7ipwilMKBf/5mN3Cuhy2Cuo5/REiAH
  mm1EmGuPZJVjcZ+6/YLnKI17trwiQ0RKGEe/9wCCPDZTwXYGsVcuK/RD8wARAQAB
  tCJKb3JkYW4gSnVzdGVuIDxqbGp1c3RlbkBnbWFpbC5jb20+iQI6BBMBCAAkAhsD
  BQsJCAcDBRUKCQgLBRYCAwEAAh4BAheABQJS+ITWAhkBAAoJEDf5n2jK+ZLrXR0Q
  ALQG0OerOaL+6S/qqp0IpWVqb2wStE0PbCw88AJBTvSZU2LCGc8FGu167MQx1E+S
  Y3lZliFLQ53E3C2l622w8RQYxBIfruI6+F4tTctgxbi/2lHRzZeoNby3bv/uDT+7
  sYEtyI19c+PYRlRSb2bWzntP/8l+FplEs/PzvS2LV3n7E5dFm8OuDYzlukh1VX4k
  eP8yBjcl0TK/r8gk0ipzQA5XjKFWbX76bHKmxEkgXUtY2YSgNJ6/iyY/0TPUb+I+
  Ax59OiVav+ugAu8KEwrDQIE/foBfqp0ugoEyxC3oo/CxGOoiuFK+nvzuu48xzh+i
  Vj2VvWLaZgyr4nPt3KqGphd9bmAvvn1qX3WaEgdaVYyR7v5gfXQu67cmW/KEQNgx
  rtNujOrmn03CPN9h0oP/hMrzu7dhNCIPzr8HgUv4fAyn1QAYfDWPIH4LUeVJqf2r
  I6DUzPbbJQ/k1lXwBXDj92GBQGN0h/B1yI9uGwhrl+TwH3Aq/kLS5NIMAq9iYYrn
  8OIBumqmI9K8118x+vthbk0ss9EcHuDBc5NVLbRKBjCV32EaM6cGMzTMZ9wZViad
  IIAZSoSkZ8kD2dhhyanRjpOmD7v8ur9ngR1dUKmaidFWkKUqTxg7A7xUy01gdsTr
  i9m6gxDvdXNroI+ojQFznDs42VE+yKS4uisX5HgvNIaUiQEcBBABCAAGBQJS+Fzi
  AAoJEHGogoJzqpZGM7MH/RQeVaBKT+PFMTathDB5AR/egV+G6F9TMSPM0t1BlvpV
  dUM00YO2qB34wStuJ+WVczOFOaP1IeJgMYAoM3lsqj+93tWDHBo3U8WkPBuhr9+j
  VCAzQE08x14BSFVeDHQIWoQhQZdfTcuYdflT/Ji2xtuT308Vqxuee6l45GirU0kw
  KPzWgStM4Gtq/zTKB9HB7cHtqtP0DV1HNrUJZ7hzrJVyj4friQcESwzPzjNGFPI0
  atlqVelN7fjbKhPHiQ+f7lYBsRF2JwdSRCAw3MAtH9zuEA/zbDA7QZaGyMdSOUlq
  hue5FaeCmk8NEtpdosPzhgMH7MHCdIjYL+sZeZe/ctSJAhwEEAECAAYFAlL9GyIA
  CgkQYAIzup5U3GEezw/9Ec9yjltbKWJwHCGUF66ramAuwForhrSRXW6ZhQTv41la
  mCOSWltrsXRx2bY6J+lFLjhyREKZzZvokGlo3hXdWPzAdaRXexztSlXC1Fpm1fun
  oNt3SfHLFbhtkQaX5ycczMQ6t1aKpIFMAageze6nO2DuUzABNfHwwpPhpAT/+voH
  AIvkGsQ6V0s6BZhjpqIjMz5o072vV+JNskYbO3iQWl0bZR+zpXmJg51I7Qb9+peG
  x3UYG9mmmLtTX5tdUop5Uklwi/EIG44tvIjLzF1VKRa/CHQ8/ecPYGXiJXHNvrjn
  uz7LbwfYWoAW+fVfprNGi6t3CITAyvIZxHZ/Sq6dnppOXhc3ubFKMJwOFUYqz1wQ
  bCzS/5kOLfhn3KGztoqD8/Fk3PGk7z0Q6bJ0sQCde0odBt7tZUgfkT5Epp+sqbU/
  0etns25+rGxiIAAlreXrG+NZFWoRCOy3a3ONso7r2HhgjY8AKO/RgsXG0wMtV07i
  2ImxrbhPyb7G2OWDhvCtT+tdRw0SGW97w6QGMk9DYoPEI6YQ3LiKbhI0rx4LERym
  EAxfwuvQVLJ4Iynn62oOvrx0CemHZK4GSx1jreAzibBMeKGVxcirpoOdeTeLWzU/
  DVM63OGXpgrJIemEShWdr9k68Of41qHF1EqYLiQZL+I5eZgJxuOFtzo/LLBuSC+J
  AhwEEAECAAYFAlL9UhQACgkQD91oLZdMpyp6lw/8CR4e5bJ5f3wuPSuAVf7Izop+
  8hHlIJgW+IRtwakfWG/dCscmZ9KWyzkOgwSmJLYgeiO5+qSUCks3GjqUJkfXcV9S
  rJLvba2IkCYESsuWQyTmyOBi/L5daI9gNm4h99iylqBH8Y1FLeKVsaj00Eul6sk7
  ZlXppp6AqSHZhLt1Fgxm2wHasn1VWr3HUXEADFgYx4NmCuTy41PZfvBRfbc6K8yZ
  E5jStxLnVp+40HuoOabqG9Qps4qHdXYQTDcytK7Ykc38o6X5uA/dRcqRRXeHOd/N
  JX0i1IeNfCAmmvnaFUxVk84C3mntxXTOvk6tL+ovVVmc0SL35rJq7dLRhL6PpiSe
  WmtFhjd4b/cg206nm1u/fSCRBavI4jHh7QBHN4LK9zA/pmZB8TsdGqWprufyKUD6
  K+nX30HLoCb0Po3K1zLxG7IL2g1LdOqOVK1Q5DoCHwHUeQ7Ya79IUaSixUOEErj+
  vLUQ2xdCsGalQXam5sUoCsnkee8n8R8PE9wMURqmKMKDpYzVwViIf1d6KaQQws99
  j3hj6Vq1x+o+ENlv7tVBoqZGc0tx4Rrno+LQGxZyrWQhDPeLVxP7Bk80Vn4CAWtT
  l5rLIW4/eaI2l4ifDC8sR0JuZmmFz61rZeSlGq7HMXk4gjaNJexDLUr+tJ7z0yjl
  Y8XhTw6N1x6WYM35oQCJAhwEEAECAAYFAlL9Z1oACgkQ2yIaaQAAABFUFxAAs7Vx
  kuzsk112WgK3TLOsPCh75AuYahrAvKR93ixZtUO8rKCU0yOv031uaVigUDGaIAt+
  /UA+GqMV1nqzBxmfGP73iXlX5JH4hUutDDq3njnOxWpAvDA8BebIIP4zYkl/qijK
  OiyKQpCCsZveUfuCIgKI5mvIZvJLEXgpGV1PiUj45OsaNEiG9ZBh/cKxBkVcOkGq
  qQmjbRtFhkfxijFj3+5J5+DJafiK5c9IDLqz0CAxup9cjoRgpicKeKFYXGs3mTdr
  LylYckAO1JJkwGg8KmO3q5wkH9cooQChQyfd8b6d6sKo+i7dSedk+pinut51cT4p
  QgBDXa/muw0UfFXWqcgrEUdwTLaI08aC2HSLtcstSZqgQKvHsx/uC9ndIGH0Glze
  hLaVrb0KnVscAAXLzqNoct5a1LK/VG7wR+Tf4FWumyuhXAzjCqev6omnedM0IcKo
  XwSO9Tz9OponSZtxugjV64TFtwNm5SicAkaVCSd2nnXWISG9ix8Lac0t7hczSrN5
  JUjlI5lkABjWYAZZRmHwYJTkOVKL/i6IpG4Qh4O1MqGujlt12yv7OhrwJcLTfJXc
  YUvrzHbCpQ0T3pLLA8mfleo1VD0xcKPeChtIJyXpcMyKklQtr/ef3LgPb1YIUHG1

Bug#745135: Top 10 reasons you should sponsor MariaDB 10.0 into Debian this weekend (Re: Bug#745135: RFS: mariadb-10.0/10.0.13-1 [ITP] -- Latest version of worlds most popular non-Oracle database)

2014-09-23 Thread Jordan Metzmeier
On Tue, Sep 23, 2014 at 2:28 AM, Guido van Steen
vanst...@users.sourceforge.net wrote:
 Dear Otto,

 I would like Mariadb to be accepted before the freeze as well. However
 I am not a DD, so I cannot sponsor it myself.

 In order to get Mariadb sponsored you might handle at least the
 Lintian error 
 (https://lintian.debian.org/tags/build-depends-on-obsolete-package.html,
 http://labs.seravo.fi/~otto/mariadb-repo/logs/mariadb-10.0/mariadb-10.0_10.0.13-1_amd64.build-d992d30.log).
 If it is a false positive, please explain why.

 Yesterday Arnoud Fontaine expressed his willingness to sponsor
 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745135#69). He asks
 What's blocking the upload to unstable?. Other sponsors may have the
 same question.


I haven't performed a full review of the package, but there were a
couple things I noticed with the lintian overrides.

 O command-with-path-in-maintainer-script

 postinst:196 /bin/echo (override comment: ash's buildin has no -e so use 
 /bin/echo)
 postinst:210 /bin/echo (override comment: ash's buildin has no -e so use 
 /bin/echo)
 postinst:218 /bin/echo (override comment: ash's buildin has no -e so use 
 /bin/echo)

The POSIX way to accomplish this is not to use echo at all, use printf.

 O executable-not-elf-or-script

 usr/share/mysql/mysql-test/suite/parts/r/partition_exch_innodb.result 
 (override comment: OK, this file is part of test suite and only used for a 
 test)
 usr/share/mysql/mysql-test/suite/parts/r/partition_exch_qa.result (override 
 comment: OK, this file is part of test suite and only used for a test)

It's fine that these are for the test suite, but do they need to be executable?

 O arch-dependent-file-not-in-arch-specific-directory

 usr/lib/mysql/plugin/dialog.so (override comment: OK, file names don't 
 conflict with the MySQL version)
 usr/lib/mysql/plugin/mysql_clear_password.so (override comment: OK, file 
 names don't conflict with the MySQL version)

I am not sure I understand this override. The issue here is that
libmariadbclient18:amd64 and libmariadbclient18:i386 will not be
co-installable.


Regards,
Jordan Metzmeier


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



Bug#759981: sbuild?

2014-09-19 Thread Jordan Metzmeier
This was caused by a missing build dependency on python-requests. The
pypi-install script requires it. After installing the package in a
clean vagrant image:

root@10:~# pypi-install --help
Traceback (most recent call last):
  File /usr/bin/pypi-install, line 5, in module
from stdeb.downloader import myprint, get_source_tarball
  File /usr/lib/python2.7/dist-packages/stdeb/downloader.py, line
10, in module
import requests
ImportError: No module named requests

I have committed the change to the svn repo.

Piotr, can you tag and upload the package with the updated depends?

Regards,
Jordan Metzmeier


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



Bug#761015: ITP: piglit -- Piglit OpenGL test suite

2014-09-09 Thread Jordan Justen
Package: wnpp
Severity: wishlist
Owner: Jordan Justen jljus...@gmail.com

* Package name: piglit
  Version : 0.0.0
  Upstream Author : Piglit pig...@lists.freedesktop.org
* URL : http://piglit.freedesktop.org/
* License : MIT, GPL
  Programming Lang: C, C++, Python
  Description : Piglit OpenGL test suite

Piglit is an open-source test suite for OpenGL implementations.

Piglit is used extensively for testing of the open source Mesa
project.

Piglit has not previously done any official project releases. This is
why I set the version at 0.0.0. The piglit builds will use a version
of the form
  0.0.0~git[8 digit date]-[7 hex git sha1 prefix]-[debian version]

I plan to maintain debian piglit myself, although there are a few
Debian Developers that are also work on piglit which may end up
helping to maintain it. I plan to work with Carl Worth
cwo...@cworth.org to sponsor/upload the piglit packages.


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



Bug#757936: schroot: build-depends on cmake needs to specify 2.8.12

2014-08-12 Thread Jordan Metzmeier
Package: schroot
Version: 1.6.10-1
Severity: normal

Dear Maintainer,

While attempting to create a personal backport of schroot I discovered
that the build system requires cmake  2.8.12. The build-depends in
the package does not specify a cmake version.

dpkg-buildpackage: source package schroot
dpkg-buildpackage: source version 1.6.10-1
dpkg-buildpackage: source changed by Roger Leigh rle...@debian.org
dpkg-buildpackage: host architecture amd64
 dpkg-source --before-build schroot-1.6.10
 fakeroot debian/rules clean
dh clean --buildsystem=cmake --builddirectory=debian/build --parallel
   dh_testdir -O--buildsystem=cmake -O--builddirectory=debian/build -O--parallel
   debian/rules override_dh_auto_clean
make[1]: Entering directory `/home/jordan/prog/build/schroot-1.6.10'
dh_auto_clean
rm -f debian/dchroot-dsa.install debian/dchroot.install
debian/libsbuild1.install debian/libsbuild-dev.install
debian/schroot-common.install debian/schroot.install
rm -rf debian/build
rm -rf debian/install
make[1]: Leaving directory `/home/jordan/prog/build/schroot-1.6.10'
   dh_clean -O--buildsystem=cmake -O--builddirectory=debian/build -O--parallel
 dpkg-source -b schroot-1.6.10
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building schroot using existing ./schroot_1.6.10.orig.tar.xz
dpkg-source: info: building schroot in schroot_1.6.10-1.debian.tar.gz
dpkg-source: info: building schroot in schroot_1.6.10-1.dsc
 debian/rules build
dh build --buildsystem=cmake --builddirectory=debian/build --parallel
   dh_testdir -O--buildsystem=cmake -O--builddirectory=debian/build -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory `/home/jordan/prog/build/schroot-1.6.10'
mkdir -p debian/build/
cd debian/build/ ; \
  GTEST_ROOT=/home/jordan/prog/build/schroot-1.6.10/debian/build/gtest
\
  CFLAGS=-g -O2 -fPIE -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall
-D_FORTIFY_SOURCE=2 \
  CXXFLAGS=-g -O2 -fPIE -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall
-D_FORTIFY_SOURCE=2 \
  cmake -DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_INSTALL_SYSCONFDIR=/etc \
-DCMAKE_INSTALL_LOCALSTATEDIR=/var \
-DCMAKE_INSTALL_LIBEXECDIR=lib \
-DSCHROOT_LIBEXEC_DIR=/usr/lib/x86_64-linux-gnu/schroot \
-Ddebug=OFF -Ddchroot=ON -Ddchroot-dsa=ON \
-Dbash_completion_dir=/etc/bash_completion.d \
-Dlvm-snapshot=ON -Dbtrfs-snapshot=ON \
-DBTRFS_EXECUTABLE=/sbin/btrfs \
-DLVCREATE_EXECUTABLE=/sbin/lvcreate \
-DLVREMOVE_EXECUTABLE=/sbin/lvremove \
/home/jordan/prog/build/schroot-1.6.10
CMake Error at CMakeLists.txt:16 (cmake_minimum_required):
  CMake 2.8.12 or higher is required.  You are running version 2.8.9


-- Configuring incomplete, errors occurred!
make[1]: *** [debian/build/CMakeCache.txt] Error 1
make[1]: Leaving directory `/home/jordan/prog/build/schroot-1.6.10'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2



-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages schroot depends on:
ii  libboost-filesystem1.49.0   1.49.0-3.2
ii  libboost-iostreams1.49.01.49.0-3.2
ii  libboost-program-options1.49.0  1.49.0-3.2
ii  libboost-regex1.49.01.49.0-3.2
ii  libboost-system1.49.0   1.49.0-3.2
ii  libc6   2.17-97
ii  libgcc1 1:4.8.2-1
ii  liblockdev1 1.0.3-1.5
ii  libpam0g1.1.3-7.1
ii  libstdc++6  4.8.2-1
ii  libuuid12.20.1-5.3
ii  schroot-common  1.6.4-4

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-modules | unionfs-modules  none
pn  btrfs-tools none
ii  debootstrap 1.0.48+deb7u1
ii  lvm22.02.95-8
pn  qemu-user-staticnone


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



Bug#753034: libparse-debianchangelog-perl: FTBFS: test failures - patch

2014-07-24 Thread Jordan Metzmeier
Control: tags patch

I investigated this issue and the failures appear to be the result of
a change in dpkg-parsechangelog. The difference in the produced output
is this library had a trailing space after Changes: , but
dpkg-parsechangelog no longer had that. I believe the
dpkg-parsechangelog behavior is correct.

Attached is a patch that resolves the bug and fixes the FTBFS.

Regards,
Jordan Metzmeier
--- a/lib/Parse/DebianChangelog/Util.pm
+++ b/lib/Parse/DebianChangelog/Util.pm
@@ -104,7 +104,11 @@
$v =~ m/\n$/o  warn(__g(field %s has trailing newline %s,
  $f, $v ));
$v =~ s/\$\{\}/\$/go;
-   $rfc822_str .= $f: $v\n;
+# the changes have a space followed by a newline which was resulting
+# in a trailing space on Changes: . This caused the library to not
+# match the output of dpkg-parsechangelog
+$v = ' ' . $v if $v !~ m/^\s+/;
+   $rfc822_str .= $f:$v\n;
 }
 
 return $rfc822_str;


Bug#755910: collides with python-bzrlib

2014-07-24 Thread Jordan Metzmeier
Here is the upstream bug report: https://github.com/paramiko/paramiko/issues/285

It looks like someone is already working on a patch.

Regards,
Jordan Metzmeier


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



Bug#754354: nfs-kernel-server: hangs after hours or days, no login to server possible

2014-07-10 Thread Alexander Jordan
Package: nfs-kernel-server
Version: 1:1.2.6-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
it is not possible to reproduce and happens unexpectedly.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
1000241   udp  39965  status
1000241   tcp  40663  status
172   udp828  ypbind
171   udp828  ypbind
172   tcp829  ypbind
171   tcp829  ypbind
3910022   tcp695  sgi_fam
132   tcp   2049  nfs
133   tcp   2049  nfs
134   tcp   2049  nfs
1002272   tcp   2049
1002273   tcp   2049
132   udp   2049  nfs
133   udp   2049  nfs
134   udp   2049  nfs
1002272   udp   2049
1002273   udp   2049
1000211   udp  53968  nlockmgr
1000213   udp  53968  nlockmgr
1000214   udp  53968  nlockmgr
1000211   tcp  41171  nlockmgr
1000213   tcp  41171  nlockmgr
1000214   tcp  41171  nlockmgr
151   udp  42554  mountd
151   tcp  46496  mountd
152   udp  50250  mountd
152   tcp  44511  mountd
153   udp  48943  mountd
153   tcp  59313  mountd
-- /etc/default/nfs-kernel-server --
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS=--manage-gids
NEED_SVCGSSD=
RPCSVCGSSDOPTS=
-- /etc/exports --
/home/mag   139.17.74.0/255.255.255.0(rw,async,no_subtree_check)
/home/obs   139.17.74.0/255.255.255.0(rw,async,no_subtree_check)
/home/des   139.17.74.0/255.255.255.0(rw,async,no_subtree_check)
/home/mag   mag12(rw,async,no_subtree_check)
/home/mag   mag14(rw,async,no_subtree_check,no_root_squash)
/home/mag   192.168.1.0/255.255.255.0(rw,async,no_subtree_check)
/home/mag   mag25(rw,async,no_subtree_check,insecure)
/export/10days  139.17.74.0/255.255.255.0(rw,sync,subtree_check)
/export/10days  mag3(rw,sync,subtree_check)
/export/10days  mag12(rw,sync,subtree_check)
/export/10days  mag21(rw,sync,subtree_check)
/export/10days  192.168.1.0/255.255.255.0(rw,sync,subtree_check)
/export/10days  139.17.49.2(rw,sync,subtree_check)
/export/10days  139.17.57.20(rw,sync,subtree_check)
/export/10days  mag25(rw,async,no_subtree_check,insecure)
/BACKUP/mag4mag4(rw,sync,subtree_check,no_root_squash)
/export/Admin/teaching2014  mag12(rw,async,no_subtree_check)
/export/Admin/teaching2014  139.17.74.56(rw,async,no_subtree_check)
-- /proc/fs/nfs/exports --
# Version 1.1
# Path Client(Flags) # IPs
/export 
139.17.74.0/255.255.255.0,sec23c16.gfz-potsdam.de(ro,root_squash,sync,no_wdelay,no_subtree_check,v4root,uuid=471861a8:cd984ee0:a23cf06f:4217381d)
/export/Admin/teaching2014  
192.168.1.0/255.255.255.0,mag12.gfz-potsdam.de(rw,root_squash,async,wdelay,no_subtree_check,uuid=18a9162f:3b884e76:b2bd2868:7e3b886c)
/home/mag   
139.17.74.0/255.255.255.0(rw,root_squash,async,wdelay,no_subtree_check,uuid=b0df03d9:b1434b25:b590eeea:9b22136f)
/   
139.17.74.0/255.255.255.0(ro,root_squash,sync,no_wdelay,no_subtree_check,v4root,fsid=0,uuid=471861a8:cd984ee0:a23cf06f:4217381d)
/   
192.168.1.0/255.255.255.0(ro,root_squash,sync,no_wdelay,no_subtree_check,v4root,fsid=0,uuid=471861a8:cd984ee0:a23cf06f:4217381d)
/export/10days  
139.17.74.0/255.255.255.0(rw,root_squash,sync,wdelay,uuid=72c05ad7:29d04f82:91a4f5d3:901a5d52)
/home/mag   
192.168.1.0/255.255.255.0(rw,root_squash,async,wdelay,no_subtree_check,uuid=b0df03d9:b1434b25:b590eeea:9b22136f)
/home   
139.17.74.0/255.255.255.0(ro,root_squash,sync,no_wdelay,no_subtree_check,v4root,uuid=b0df03d9:b1434b25:b590eeea:9b22136f)
/export/10days  
139.17.74.0/255.255.255.0,sec23c16.gfz-potsdam.de(rw,root_squash,sync,wdelay,uuid=72c05ad7:29d04f82:91a4f5d3:901a5d52)
/home   
192.168.1.0/255.255.255.0(ro,root_squash,sync,no_wdelay,no_subtree_check,v4root,uuid=b0df03d9:b1434b25:b590eeea:9b22136f)
/home/mag   
139.17.74.0/255.255.255.0,sec23c16.gfz-potsdam.de(rw,root_squash,async,wdelay,no_subtree_check,uuid=b0df03d9:b1434b25:b590eeea:9b22136f)
/home/mag   
192.168.1.0/255.255.255.0,mag4.gfz-potsdam.de(rw,root_squash,async,wdelay,no_subtree_check,uuid=b0df03d9:b1434b25:b590eeea:9b22136f)
/   

Bug#752787: openstack-debian-images: Configure the user login for the default cloud-init user

2014-06-26 Thread Jordan Pittier
Package: openstack-debian-images
Version: 0.9
Severity: wishlist

Dear Maintainer,
I'd like to introduce a new option to this package. This would allow to
change the default (debian) user name created by cloud-init when it is
run. 

This patch introduce the option --login to this intent.

Configure the user login for the default cloud-init user


-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openstack-debian-images depends on:
ii  debootstrap  1.0.48+deb7u1
ii  dpkg 1.16.15
ii  extlinux 2:4.05+dfsg-6+deb7u1
ii  initramfs-tools  0.109.1
ii  kpartx   0.4.9+git0.4dfdaf2b-7~deb7u2
ii  mbr  1.1.11-5+b1
ii  parted   2.3-12
ii  qemu-utils   1.1.2+dfsg-6a+deb7u3

openstack-debian-images recommends no packages.

openstack-debian-images suggests no packages.

-- no debconf information
diff --git a/build-openstack-debian-image b/build-openstack-debian-image
index 65e6eb7..573ad1d 100755
--- a/build-openstack-debian-image
+++ b/build-openstack-debian-image
@@ -14,6 +14,7 @@ Options are:
  --image-size|-is image-size (default: 1G)
  --automatic-resize|-ar
  --automatic-resize-space|-ars suplementary-space (default: 50M)
+ --login|-l userlogin (default: debian)
  --password|-p root-password (dangerous option: avoid it if possible)
 For more info: man $0
 	exit 1
@@ -97,6 +98,15 @@ for i in $@ ; do
 			usage
 		fi
 	;;
+	--login|-l)
+		if [ -z ${2} ] ; then
+			echo No parameter defining the user login
+			usage
+		fi
+		USER_LOGIN=${2}
+		shift
+		shift
+	;;
 	--password|-p)
 		if [ -z ${2} ] ; then
 			echo No parameter defining the root password
@@ -129,6 +139,9 @@ fi
 if [ -z ${AUTOMATIC_RESIZE_SPACE} ] ; then
 	AUTOMATIC_RESIZE_SPACE=50
 fi
+if [ -z ${USER_LOGIN} ] ; then
+	USER_LOGIN=debian
+fi
 
 NEEDED_PACKAGES=sudo,adduser,locales,extlinux,openssh-server,linux-image-amd64,euca2ools,file,kbd
 if [ ${RELEASE} = jessie ] ; then
@@ -216,8 +229,8 @@ fi
 # is always the same.
 sed -i s/PermitRootLogin yes/PermitRootLogin without-password/ ${MOUNT_DIR}/etc/ssh/sshd_config
 
-# Add a default debian user which is used by cloud-init by default
-chroot ${MOUNT_DIR} adduser --gecos Debian-cloud-init-user --disabled-password --quiet debian
+# Add a default user which is used by cloud-init by default
+chroot ${MOUNT_DIR} adduser --gecos Cloud-init-user --disabled-password --quiet ${USER_LOGIN}
 
 # Adds the debian user to sudoers, since that is the way
 # cloud-init grant access
@@ -326,6 +339,9 @@ datasource_list: [ Ec2 ] ${MOUNT_DIR}/etc/cloud/cloud.cfg.d/90_dpkg.cfg
 echo mount_default_fields: [~, ~, 'auto', 'defaults,nofail', '0', '2'] ${MOUNT_DIR}/etc/cloud/cloud.cfg
 echo manage_etc_hosts: true ${MOUNT_DIR}/etc/cloud/cloud.cfg
 
+# Set the cloud init default user (required for the keypair to be put in the right home directory)
+sed -i s/name: debian/name: ${USER_LOGIN}/ ${MOUNT_DIR}/etc/cloud/cloud.cfg
+
 # Setting-up initramfs
 chroot ${MOUNT_DIR} update-initramfs -u
 
diff --git a/build-openstack-debian-image.1 b/build-openstack-debian-image.1
index ec1b6b7..2ae2496 100644
--- a/build-openstack-debian-image.1
+++ b/build-openstack-debian-image.1
@@ -19,11 +19,13 @@ during the boot process, cloud\-init will resize the root partition on the fly
 recent kernel allow that for ext3).
 
 Cloud\-init is setup to use an Ec2 metadata server, which is what OpenStack is
-compatible with. A debian user will be used to receive the ssh key from the
-user data blob. This user is setup without a password (eg: adduser
-\-\-disabled\-password).  Once logged as this debian user in your new virtual
-machine, you can sudo to root from that user, without needing a password. The
-root password is password by default, and ssh into the root user without
+compatible with. A debian (configurable with the use of the
+.B --login
+option) user will be used to receive the ssh key from the user data blob.
+This user is setup without a password (eg: adduser \-\-disabled\-password).
+Once logged as this debian user in your new virtual machine, you can
+sudo to root from that user, without needing a password. The root
+password is password by default, and ssh into the root user without
 using an ssh keypair is disabled by default (PermitRootLogin without-password
 is set in /etc/ssh/sshd_config).
 
@@ -115,6 +117,13 @@ to the minimum. If this option is ommited, then 50G is used. If
 isn't used, then it is useless to set this option, which will be ignored.
 
 .LP
+.B \-\-login|\-l
+.I user-login
+.IP
+
+Change the login name (default to debian) for the user created by Cloud-Init.
+
+.LP
 .B \-\-password|\-p
 .I root-password
 .IP


Bug#740800: ITP: python-crontab -- Python module for reading and writing crontab files

2014-03-04 Thread Jordan Metzmeier
Package: wnpp
Severity: wishlist
Owner: Jordan Metzmeier jmetzmeie...@gmail.com

* Package name: python-crontab
  Version : 1.7.2
  Upstream Author : Martin Owens docto...@gmail.com
* URL : https://launchpad.net/python-crontab
* License : GPL-3
  Programming Lang: Python
  Description : Python module for reading and writing crontab files

  python-crontab is a Python module for reading and writing crontab files
  and accessing the system cron automatically and simply using a direct
  API.
  .
  Features include:
  .
- Displaying and modifying system and user crontab files
- Adding comments to be displayed with jobs
- Validating jobs
- Searching for jobs


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



Bug#736822: Cannot purge/completely remove Steam

2014-02-26 Thread Jordan Metzmeier
tags 736822 moreinfo
thanks

Please run the following and add the output to the bug report:

sh -x /var/lib/dpkg/info/steam.postrm

This will run the post removal script in a debug mode, which should
make it easier to identify the issue.

-- 
Regards,
Jordan Metzmeier


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



  1   2   3   >