Bug#1072233: mosh: use wtmpdb to write wtmp entries
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
Bug#892058: debian-keyring: please automatically send reminder emails to people whose keys will expire soon
> (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 out. Sincerely, -Alex
Bug#892058: Thank you for the reminder
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!) will show the updated key, with the new expiry. Sincerely, -Alex
Bug#926816: yubikey-manager FTBFS in some common situations
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 GNU/Linux 9.8 (stretch) Release:9.8 Codename: stretch yubikey-manager-2.1.0$ sbuild -A -c sid-amd64 dh clean --with python3 --buildsystem=pybuild dh: Compatibility levels before 5 are no longer supported (level 1 requested) debian/rules:6: recipe for target 'clean' failed make: *** [clean] Error 25 If I then `echo 10 > debian/compat`, sbuild is able to proceed. The package builds normally against a sid schroot. If I try to use debuild normally, the package FTBFS with help2man -o debian/ykman.1 \ --no-info --version-string=2.1.0 \ --name 'YubiKey Manager' -- /tmp/tmp.3fY41n5LsH/bin/ykman help2man: can't get `--help' info from /tmp/tmp.3fY41n5LsH/bin/ykman Try `--no-discard-stderr' if option outputs to stderr debian/rules:15: recipe for target 'override_dh_installman' failed Interestingly enough, I cannot reproduce with a buster schroot; the behavior seems to be dependent on debuild vs sbuild. Some further investigation with with --no-discard-stderr shows a Python stacktrace in python3-click, complaining about the locale. If we pass --locale=C.UTF-8 to help2man, then everything builds properly, even with debuild in this situation. I've attached a debdiff that makes this package build more reliably. Sincerely, -Alex yubikey-manager.debdiff Description: Binary data
Bug#921468: ITS: byobu
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 > X-Debbugs-CC: acher...@mit.edu > > Dear byobu maintainers, > > I noticed that package byobu in Debian has received no maintainer activity for > over 2 years and it's diverging from downstream Ubuntu's package [2]. As a > result, I'm starting the package ITS process [1] as defined by Developers' > Reference §5.12 in order to improve the maintenance status of byobu in Debian. > > Please let me know if you are still willing to maintain this package in > Debian. Otherwise, I will upload an NMU for byobu 21 days onto DELAYED/7 to > take over maintainership. > > Thank you very much for your understanding and looking forward to your reply. > > -- > Regards, > Boyuan Yang > > > [1] https://wiki.debian.org/PackageSalvaging > [2] https://tracker.debian.org/pkg/byobu
Bug#712398: Intent to NMU byobu to fix longstanding l10n bugs
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 > bugs[1]. The changelog would be something like the following: > > * Non-maintainer upload. > * Obvious lintian fixes: > -possible-missing-colon-in-closes > -script-needs-depends-on-sensible-utils > * Add Debconf translations: > -pt_BR from Adriano Rafael Gomes (Closes: #804096) > -nl from Frans Spiesschaert (Closes: #835134) > -it from Beatrice Torracca (Closes: #712398) > > Please tell me if you are currently preparing a new release yourself > and would like me to skip the NMU. > > Greetings > > Helge > > [1] https://i18n.debian.org/nmu-radar/nmu_bypackage.html > -- > > -- > Dr. Helge Kreutzmann deb...@helgefjell.de >Dipl.-Phys. http://www.helgefjell.de/debian.php > 64bit GNU powered gpg signed mail preferred >Help keep free software "libre": http://www.ffii.de/
Bug#825324: byobu: Byobu session closes on SSH disconnect
tags 825324 -moreinfo -unreproducible tags 825324 wontfix thanks Marking as wontfix as this is an issue due to tmux/screen and systemd interactions, discussed in #825394. On Thu, May 26, 2016 at 2:17 AM, Ivan Frimmel wrote: > HI .. Thanks for your quick response. TBH .. I didn’t know where to > start. It looks like nohup and screen are doing the same thing. And > its only recent. I created a brand new user - enabled byobu and ran > something simple .. disconnect .. and the session closes completely. > > Screen sadly does the same thing from what I can see. Just to repeat - > byoby/screen and nohup are all doing it - I love Byobu - so this is > my first port of call ! :) ( please be gentle ) .. > > executing nohup /usr/bin/python /foo/pythonthing.py & works fine > while I am connected and then instantly terminates on disconnect of > the SSH. It is only very recent. And I don't think its anything I > did.. > > the baffling thing is that ROOT is unaffected by this disconnection .. > I wonder if their isn’t some new permission being pushd that makes > persistence a "option ?" seems 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 ; 825...@bugs.debian.org > Cc: Debian Bug Tracking System ; > cont...@bugs.debian.org > Subject: Re: Bug#825324: byobu: Byobu session closes on SSH disconnect > > 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 are using has changed. Try > `tmux list-sessions` or `screen -ls` depending on which byobu backend > you are using (tmux is currently the default) to see if the sessions > are present. Additionally, please try reproducing with tmux/screen > directly, without byobu. > > Sincerely, > -Alex > > > On Thu, May 26, 2016 at 1:19 AM, Ivan Frimmel wrote: >> Package: byobu >> Version: 5.87-1 >> Severity: important >> >> Dear Maintainer, >> >> *** Reporter, please consider answering these questions, where >> appropriate *** >> >>* What led up to the situation? >> Did a apt-get dist-upgrade >>* What exactly did you do (or not do) that was effective (or >> ineffective)? >> root sessions will persist for some reason, but regular account >> sessions that used to allow disconnect of ssh now terminate immediately on >> disconnect and do not persist at all. I am not sure if byobu is crashing, I >> looked for dump files but here arent any that I can see. >>* What was the outcome of this action? >> I can't fix the problem. I searched all the byobu an bash >> documentation and /etc/profile and /etc/skel etc and I can't find anything >> that would be causing this all of a suddent. I don't think it's anything I >> did specifically. >>* What outcome did you expect instead? >> The sessions would persist after ssh disconnect. >> *** End of the template - remove these template lines *** >> >> >> -- System Information: >> Debian Release: stretch/sid >> APT prefers unstable >> APT policy: (500, 'unstable') >> Architecture: amd64 (x86_64) >> >> Kernel: Linux 4.5.0-2-amd64 (SMP w/8 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 byobu depends on: >> ii debconf [debconf-2.0] 1.5.59 >> ii gawk 1:4.1.3+dfsg-0.1 >> ii gettext-base 0.19.7-2 >> ii python 2.7.11-1 >> ii python-newt0.52.18-3 >> ii screen 4.3.1-3 >> ii tmux 2.2-2 >> >> Versions of packages byobu recommends: >> pn run-one >> ii screen 4.3.1-3 >> ii tmux 2.2-2 >> >> Versions of packages byobu suggests: >> pn apport >> pn ccze >> ii lsb-release 9.20160110 >> ii po-debconf 1.0.19 >> pn ttf-ubuntu-font-family >> pn update-notifier-common >> pn vim >> ii w3m 0.5.3-28 >> pn wireless-tools >> >> -- debconf information: >> byobu/launch-by-default: false
Bug#825324: byobu: Byobu session closes on SSH disconnect
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 are using has changed. Try `tmux list-sessions` or `screen -ls` depending on which byobu backend you are using (tmux is currently the default) to see if the sessions are present. Additionally, please try reproducing with tmux/screen directly, without byobu. Sincerely, -Alex On Thu, May 26, 2016 at 1:19 AM, Ivan Frimmel wrote: > Package: byobu > Version: 5.87-1 > Severity: important > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > Did a apt-get dist-upgrade >* What exactly did you do (or not do) that was effective (or > ineffective)? > root sessions will persist for some reason, but regular account > sessions that used to allow disconnect of ssh now terminate immediately on > disconnect and do not persist at all. I am not sure if byobu is crashing, I > looked for dump files but here arent any that I can see. >* What was the outcome of this action? > I can't fix the problem. I searched all the byobu an bash > documentation and /etc/profile and /etc/skel etc and I can't find anything > that would be causing this all of a suddent. I don't think it's anything I > did specifically. >* What outcome did you expect instead? > The sessions would persist after ssh disconnect. > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.5.0-2-amd64 (SMP w/8 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 byobu depends on: > ii debconf [debconf-2.0] 1.5.59 > ii gawk 1:4.1.3+dfsg-0.1 > ii gettext-base 0.19.7-2 > ii python 2.7.11-1 > ii python-newt0.52.18-3 > ii screen 4.3.1-3 > ii tmux 2.2-2 > > Versions of packages byobu recommends: > pn run-one > ii screen 4.3.1-3 > ii tmux 2.2-2 > > Versions of packages byobu suggests: > pn apport > pn ccze > ii lsb-release 9.20160110 > ii po-debconf 1.0.19 > pn ttf-ubuntu-font-family > pn update-notifier-common > pn vim > ii w3m 0.5.3-28 > pn wireless-tools > > -- debconf information: > byobu/launch-by-default: false
Bug#760431: byobu prevents inverted text from displaying and shows as italics instead
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, Jeffery To wrote: > Hello, > > I recently upgraded to Ubuntu 14.10 and ran into this issue; it does appear > tmux is at fault (or rather, screen's terminfo description). > > The tmux FAQ (http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ) has an > entry "vim displays reverse video instead of italics, while less displays > italics (or just regular text) instead of reverse. What's wrong?" which > describes a fix involving creating a new terminfo file. The only wrinkle for > byobu is the "default-terminal" command should go in ~/.byobu/.tmux.conf > instead of ~/.tmux.conf. > > I suppose this may be too much for byobu to fix automagically, but it does > seem to be a head-scratcher for users who don't investigate deep enough to > find a fix in tmux. > > HTH, > Jeff > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760431: byobu prevents inverted text from displaying and shows as italics instead
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 wrote: > Package: byobu > Version: 5.77-1 > Severity: normal > > Dear Maintainer, > > Sometime in the last several weeks (four to eight, I think), many programs run > in a shell under byobu no longer correctly display inverted text. Instead, > the text is displayed in an italics face. > > The easiest way to reproduce this is to run 'less' on some file. The status > line that less displays at the bottom of the screen (typically showing the > file name and the position in the file) is normally displayed in an inverted > style. > > It does not appear to be related to the choice of terminal. If I run the less > command in a bash shell spawned by byobu, I get the incorrect display. If I > run the same command in another terminal window which is not using byobu then > the display is correct. > > Other than selecting a handful of status notifications, I have not altered the > byobu configuration. As per the defaults, it is using tmux as the back-end. > > > > -- > --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. > Try Weasel Reader for PalmOS -- http://weaselreader.org > "This is the most fun I've had without being drenched in the blood > of my enemies!" > --Sam of Sam & Max > > > > -- System Information: > Debian Release: jessie/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.14-2-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 byobu depends on: > ii cdebconf [debconf-2.0] 0.191 > ii debconf [debconf-2.0] 1.5.53 > ii gawk1:4.1.1+dfsg-1 > ii gettext-base0.19.2-1 > ii python 2.7.8-1 > ii python-newt 0.52.17-1 > ii screen 4.2.1-2 > ii tmux1.9-6 > > Versions of packages byobu recommends: > pn run-one > ii screen 4.2.1-2 > ii tmux 1.9-6 > > Versions of packages byobu suggests: > pn apport > ii lsb-release 4.1+Debian13 > ii po-debconf 1.0.16+nmu3 > pn ttf-ubuntu-font-family > pn update-notifier-common > ii vim 2:7.4.335-1+b1 > ii w3m 0.5.3-17 > > -- debconf information: > byobu/launch-by-default: false > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731928: missing man pages for mitmproxy and mitmdump
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 desire. Sincerely, -Alex mitmproxy-manpages.patch Description: Binary data
Bug#750792: rpcbind: rpcinfo segfaults
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 libtirpc1 and setting LD_LIBRARY_PATH. This fixes the crash on TSX-bearing CPUs.] Sincerely, -Alex libtirpc-mutex-lock.patch Description: Binary data
Bug#750792: rpcbind: rpcinfo segfaults
Was just thinking about this some more and was surprised at the segmentation fault, as I was expecting a general protection fault if the instruction is wrong, and sure enough, dmesg has: [96649.067868] traps: rpcinfo[9287] general protection ip:7f07f4e59218 sp:7fff54e78cf8 error:0 in libpthread-2.19.so[7f07f4e48000+18000] Sincerely, -Alex On Fri, Jun 13, 2014 at 12:32 AM, Alex Chernyakhovsky 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 code > path: > > Program received signal SIGSEGV, Segmentation fault. > > __lll_unlock_elision (lock=0x77ddafe0 , private=0) > at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 > 29 ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such > file or directory. > (gdb) bt > #0 __lll_unlock_elision (lock=0x77ddafe0 , > private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 > #1 0x77bbb9c1 in ?? () from /lib/x86_64-linux-gnu/libtirpc.so.1 > #2 0x77bc084b in ?? () from /lib/x86_64-linux-gnu/libtirpc.so.1 > #3 0x00403cda in rpcbdump (dumptype=dumptype@entry=8, > netid=netid@entry=0x0, argc=, argv=) > at src/rpcinfo.c:849 > #4 0x00401a0b in main (argc=1, argv=0x7fffe418) at > src/rpcinfo.c:311 > > elision-unlock.c:29 corresponds to an _xend() function call, which > seems to inline to the xend opcode: > > (gdb) disas > Dump of assembler code for function __lll_unlock_elision: >0x779a7200 <+0>: mov(%rdi),%eax >0x779a7202 <+2>: mov%rdi,%rdx >0x779a7205 <+5>: test %eax,%eax >0x779a7207 <+7>: je 0x779a7218 > <__lll_unlock_elision+24> >0x779a7209 <+9>: lock decl (%rdx) >0x779a720c <+12>:jne0x779a721e <_L_unlock_13> >0x779a720e <+14>:xor%eax,%eax >0x779a7210 <+16>:retq >0x779a7211 <+17>:nopl 0x0(%rax) > => 0x779a7218 <+24>:xend >0x779a721b <+27>:xor%eax,%eax >0x779a721d <+29>:retq > End of assembler dump. > > My processor is a Intel E3-1240v3, which has TSX: > > $ grep -o rtm /proc/cpuinfo > rtm > rtm > rtm > rtm > rtm > rtm > rtm > rtm > > Unfortunately, it looks like eglibc currently in jessie is new enough > to have TSX support, but not new enough for the environment variables > to disable it, so I cannot disable it that way. However, making the > binary setuid root causes it to work: > > sudo chown root:root rpcinfo > sudo chmod +s rpcinfo > > ./rpcinfo >program version netid addressserviceowner > 104tcp6 ::.0.111 portmapper superuser > 103tcp6 ::.0.111 portmapper superuser > 104udp6 ::.0.111 portmapper superuser > 103udp6 ::.0.111 portmapper superuser > 104tcp 0.0.0.0.0.111 portmapper superuser > 103tcp 0.0.0.0.0.111 portmapper superuser > 102tcp 0.0.0.0.0.111 portmapper superuser > 104udp 0.0.0.0.0.111 portmapper superuser > 103udp 0.0.0.0.0.111 portmapper superuser > 102udp 0.0.0.0.0.111 portmapper superuser > 104local /run/rpcbind.sock portmapper superuser > 103local /run/rpcbind.sock portmapper superuser > > At this point, I mildly suspect libc. > > Sincerely, > -Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750792: rpcbind: rpcinfo segfaults
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 , private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 29 ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such file or directory. (gdb) bt #0 __lll_unlock_elision (lock=0x77ddafe0 , private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 #1 0x77bbb9c1 in ?? () from /lib/x86_64-linux-gnu/libtirpc.so.1 #2 0x77bc084b in ?? () from /lib/x86_64-linux-gnu/libtirpc.so.1 #3 0x00403cda in rpcbdump (dumptype=dumptype@entry=8, netid=netid@entry=0x0, argc=, argv=) at src/rpcinfo.c:849 #4 0x00401a0b in main (argc=1, argv=0x7fffe418) at src/rpcinfo.c:311 elision-unlock.c:29 corresponds to an _xend() function call, which seems to inline to the xend opcode: (gdb) disas Dump of assembler code for function __lll_unlock_elision: 0x779a7200 <+0>: mov(%rdi),%eax 0x779a7202 <+2>: mov%rdi,%rdx 0x779a7205 <+5>: test %eax,%eax 0x779a7207 <+7>: je 0x779a7218 <__lll_unlock_elision+24> 0x779a7209 <+9>: lock decl (%rdx) 0x779a720c <+12>:jne0x779a721e <_L_unlock_13> 0x779a720e <+14>:xor%eax,%eax 0x779a7210 <+16>:retq 0x779a7211 <+17>:nopl 0x0(%rax) => 0x779a7218 <+24>:xend 0x779a721b <+27>:xor%eax,%eax 0x779a721d <+29>:retq End of assembler dump. My processor is a Intel E3-1240v3, which has TSX: $ grep -o rtm /proc/cpuinfo rtm rtm rtm rtm rtm rtm rtm rtm Unfortunately, it looks like eglibc currently in jessie is new enough to have TSX support, but not new enough for the environment variables to disable it, so I cannot disable it that way. However, making the binary setuid root causes it to work: sudo chown root:root rpcinfo sudo chmod +s rpcinfo ./rpcinfo program version netid addressserviceowner 104tcp6 ::.0.111 portmapper superuser 103tcp6 ::.0.111 portmapper superuser 104udp6 ::.0.111 portmapper superuser 103udp6 ::.0.111 portmapper superuser 104tcp 0.0.0.0.0.111 portmapper superuser 103tcp 0.0.0.0.0.111 portmapper superuser 102tcp 0.0.0.0.0.111 portmapper superuser 104udp 0.0.0.0.0.111 portmapper superuser 103udp 0.0.0.0.0.111 portmapper superuser 102udp 0.0.0.0.0.111 portmapper superuser 104local /run/rpcbind.sock portmapper superuser 103local /run/rpcbind.sock portmapper superuser At this point, I mildly suspect libc. Sincerely, -Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750771: RFS: python-fysom/1.0.15-1 [ITP] (bootstrap-vz dependency)
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
Bug#750771: RFS: python-fysom/1.0.15-1 [ITP] (bootstrap-vz dependency)
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 https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions, please specify X-Python-Version: (>= 2.6) [as per the module's documentation of being tested on 2.6-3.3). The files in the debian/ directory look good, and the package is lintian clean. I've noticed you're using debhelper, and specify a compat level of 8. As far as I can tell, you're only using debhelper 7 features; perhaps consider setting the compat level to 7 (and depending on debhelper >= 7) to ease backporting? Sincerely, -Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745679: Processed: affects 745631, cloning 745631, reassign -1 to byobu, tagging -1 ...
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 wrote: > Hi Alexander, > > Debian Bug Tracking System wrote: >> Processing commands for cont...@bugs.debian.org: >> >> > affects 745631 - byobu >> Bug #745631 [screen] screen: byobu >= 5.77 can crash screen server process >> Removed indication that 745631 affects >> > # byobu fixed what triggered this issue in it's 5.78 release >> > clone 745631 -1 >> Bug #745631 [screen] screen: byobu >= 5.77 can crash screen server process >> Bug 745631 cloned as bug 745679 >> > reassign -1 byobu 5.77-1 >> Bug #745679 [screen] screen: byobu >= 5.77 can crash screen server process >> Bug reassigned from package 'screen' to 'byobu'. >> No longer marked as found in versions screen/4.2.0-1, >> screen/4.1.0~20120320gitdb59704-9, and screen/4.1.0~20120320gitdb59704-7. >> Ignoring request to alter fixed versions of bug #745679 to the same values >> previously set >> Bug #745679 [byobu] screen: byobu >= 5.77 can crash screen server process >> Marked as found in versions byobu/5.77-1. >> > tags -1 + fixed-upstream >> Bug #745679 [byobu] screen: byobu >= 5.77 can crash screen server process >> Added tag(s) fixed-upstream. >> > retitle -1 byobu: Using screen-style Ctrl-A in byobu 5.77 can crash screen >> > server process >> Bug #745679 [byobu] screen: byobu >= 5.77 can crash screen server process >> Changed Bug title to 'byobu: Using screen-style Ctrl-A in byobu 5.77 can >> crash screen server process' from 'screen: byobu >= 5.77 can crash screen >> server process' > > Upstream fixed in byobu what triggered this crash in Screen. > > So far the issue only surfaced with byobu 5.77 and it has been fixed > with byobu 5.78 which was released just now. > > Since the issue seems to affect to all byobu users, which use the > screen backend and use Ctrl-A as escape sequence (and only byobu users > but not pure screen users), please upload byobu 5.78 soonish. > > Regards, Axel > -- > ,''`. | Axel Beckert , http://people.debian.org/~abe/ > : :' : | Debian Developer, ftp.ch.debian.org Admin > `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE > `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724858: PATCH for sbuild-createschroot
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
