Hi,
Please find attached a patch for sbuild-createschroot which allows it
to work on jessie/sid.
Sincerely,
-Alex
sbuild-createschroot-jessie.patch
Description: Binary data
Hi Axel,
Thanks for the notification. I'll prepare an upload tomorrow, as I'm
quite busy today.
Sincerely,
-Alex
On Wed, Apr 23, 2014 at 8:06 PM, Axel Beckert a...@debian.org wrote:
Hi Alexander,
Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
affects
tags 731928 patch
thanks
Dear Maintainer,
Please find attached a man page for mitmproxy, in both roff and ronn
formats. If you wish to use the ronn format, ruby-ronn as a build
dependency to generate the roff documentation. I am more than happy to
provide a debdiff with this change should you
tags 750771 confirmed
thanks
Hi Marcin,
I've looked at your packaging, and have the following comments:
sbuild reports:
pyversions: missing X(S)-Python-Version in control file, fall back to
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
Per
Sorry, I forgot to state earlier that I am only a Debian Maintainer
and cannot upload this package.
Sincerely,
-Alex
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I've done a bit of digging:
- rebuilding rpcbind has no effect
- rebuilding libtirpc has no effect
The crash appears to be occuring inside of libpthread, on a TSX-only code path:
Program received signal SIGSEGV, Segmentation fault.
__lll_unlock_elision (lock=0x77ddafe0 authnone_lock,
-2.19.so[7f07f4e48000+18000]
Sincerely,
-Alex
On Fri, Jun 13, 2014 at 12:32 AM, Alex Chernyakhovsky acher...@mit.edu wrote:
I've done a bit of digging:
- rebuilding rpcbind has no effect
- rebuilding libtirpc has no effect
The crash appears to be occuring inside of libpthread, on a TSX-only
reassign 750792 libtirpc1
retitle 750792 libtirpc authnone_marshal unlocks already unlocked mutex
severity 750792 serious
tags 750792 patch
thanks
Last bit of debugging; patch to fix this is attached. The underlying
bug is in libtirpc1, used by rpcinfo. I've verified this by building a
custom
Hi John,
Could you please provide $TERM inside and outside of byobu? I suspect
this is an issue with tmux/screen; if inside byobu it is not
screen-256color-bce, could you perhaps try setting it to that before
running less?
Sincerely,
-Alex
On Wed, Sep 3, 2014 at 11:25 PM, John Gruenenfelder
Hi Jeff,
You've reached the Debian bugs list for byobu -- we're actually
*downstream* of Ubuntu in this case, and while I can take a look, the
Ubuntu maintainer is the author of byobu, and is likely to be able to
find it faster than I can.
Sincerely,
-Alex
On Tue, Nov 18, 2014 at 6:33 AM,
silly to do that.
>
> Please help!
> Tx
> Ivan.
>
>
>
>
> -Original Message-
> From: Alex Chernyakhovsky [mailto:acher...@mit.edu]
> Sent: Thursday, May 26, 2016 1:46 AM
> To: Ivan Frimmel <i...@hatrixsec.com>; 825...@bugs.debian.org
> Cc: Debian Bug
tags 825324 moreinfo unreproducible
thanks
Hi Ivan,
Did your apt-get dist-upgrade include an update to tmux and/or screen?
byobu has not been pushed to sid or stretch recently, so I do not see
how it can be at fault. It is likely that some change in the
underlying tmux and/or screen backend you
Hi Helge,
I am planning to do an upload within the next 2 weeks. If I have not
done so by then, by all means, please proceed with the NMU.
Sincerely,
-Alex
On Fri, Jun 22, 2018 at 2:31 PM, Helge Kreutzmann wrote:
> Hello Alexander,
> I intend to NMU byobu early August to fix longstanding l10n
I am still willing to maintain this package am and in communication
with the Ubuntu maintainer and will be dcut'ing him privileges to do
both uploads simultaneously.
Sincerely,
-Alex
On Tue, Feb 5, 2019 at 4:57 PM Boyuan Yang wrote:
>
> Package: byobu
> Version: 5.112-1.1
> Severity: important
Package: yubikey-manager
Version: 2.1.0
Dear maintainer,
The package yubikey-manager currently appears to fail to build, using
a stretch host with an sbuild chroot for sid-amd64:
yubikey-manager-2.1.0$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian
> (replace user with the debian ID)
> $ finger user/k...@db.debian.org | gpg --list-options show-keyring 2>/dev/null
It was my understanding this is the confirmation the key had made it
to the keyring package. I was hoping to confirm the key had been
successfully received, and then later rolled
Thank you for implementing this service. It was a great reminder and
easy to follow the instructions. The only thing I may suggest is
perhaps mention how to verify that the keyring.debian.org server
received the update. It seems that doing --recv-keys a few minutes
later (but not immediately!)
block 1072233 by 1072237
thanks
I agree with Keith -- marking the relationship with the src:libutempter
but, but leaving this one open to track potentially doing a binary rebuild
if a binNMU doesn't happen automatically.
Sincerely,
-Alex
18 matches
Mail list logo
