Bug#907307: ITP: openssh-ldap-publickey -- Tool for OpenSSH to use public keys stored in LDAP
Package: wnpp Severity: wishlist Owner: Andrii Senkovych * Package name: openssh-ldap-publickey Version : 1.0 Upstream Author : Andrii Grytsenko * URL : https://github.com/AndriiGrytsenko/openssh-ldap-publickey * License : MIT Programming Lang: Perl Description : Tool for OpenSSH to use public keys stored in LDAP openssh-ldap-publickey allows OpenSSH to use public keys stored in the user attribute 'sshPublicKey' on the LDAP server . Integration with OpenSSH is done by means of the AuthorizedKeysCommand option and does not require to patch OpenSSH in comparison to LPK solution. LDAP connection settings can be read from common LDAP configuration files such as /etc/pam_ldap.conf and /etc/libnss-ldap.conf. I'm using this tool quite happily for a few years already on both Debian and CentOS systems instead of maintaining a patched version of openssh-server with patches from LPK project and I believe this utility would be quite useful for the Debian community. It would be great to maintain the package with the Perl Group as it is written in Perl though I am not a member of this group. -- Best regards, Andrii Senkovych
Bug#890884: lxc: Fail to create wheezy container: couldn't find iproute2 package
Package: lxc Version: 1:2.0.9-6 Followup-For: Bug #890884 Updating patch according to DEP-3 guidelines. -- Best regards, Andrii Senkovych Description: Create LXC container for Debian Wheezy using correct iproute package Author: Andrii Senkovych Bug-Debian: https://bugs.debian.org/890884 --- a/usr/share/lxc/templates/lxc-debian2018-02-08 16:02:25.496742719 +0200 +++ b/usr/share/lxc/templates/lxc-debian2018-02-20 12:16:19.870712786 +0200 @@ -250,20 +250,22 @@ case "$release" in wheezy) init=sysvinit +iproute=iproute ;; *) init=init +iproute=iproute2 ;; esac packages=\ $init,\ +$iproute,\ ifupdown,\ locales,\ dialog,\ isc-dhcp-client,\ netbase,\ net-tools,\ -iproute2,\ openssh-server cache=$1
Bug#890892: lxc: Fail to create and run CentOS 6 container with kernel >= 4.11 due to segfaults
Package: lxc Version: 1:2.0.9-6 Severity: normal Dear Maintainer, An attempt to create and run CentOS 6 container fails due to numerous segfaults during initial "yum install" steps: Feb 16 17:21:11 jollyroger-pc kernel: [4422208.105178] sh[16250]: segfault at ff600400 ip ff600400 sp 7ffc42714e38 error 15 Feb 16 17:21:12 jollyroger-pc kernel: [4422208.391146] sh[16253] vsyscall attempted with vsyscall=none ip:ff600400 cs:33 sp:7ffdc2e581d8 ax:ff600400 si:7ffdc2e58e5d di:0 Steps to reproduce: 1. Clean up /var/cache/lxc/centos/*/6 2. Check linux kernel >= 4.11 with default options 3. Run lxc-create -n centos6 -t centos 4. Observe numerous errors during RPMs installation with text "Non-fatal POSTIN scriptlet failure in rpm package ..." and segfault notifications in dmesg Logs provide a sample run of the lxc-create command. Adding "vsyscall=emulate" to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and restarting host resolves the issue. Additional resources show the issue is related to changes in Linux image 4.11 and affects docker as well: https://github.com/docker/for-linux/issues/58#issuecomment-315133361 Thank you. -- Best regards, Andrii Senkovych -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-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) LSM: AppArmor: enabled Versions of packages lxc depends on: ii libapparmor1 2.12-2 ii libc6 2.26-6 ii libcap2 1:2.25-1.2 ii libgnutls30 3.5.18-1 ii liblxc1 1:2.0.9-6 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.7-2+b1 ii lsb-base 9.20170808 ii python3 3.6.4-1 ii python3-lxc 1:2.0.9-6 Versions of packages lxc recommends: ii bridge-utils 1.5-14 ii debootstrap 1.0.93 ii dirmngr 2.2.4-3 ii dnsmasq-base 2.78-3 ii gnupg 2.2.4-3 ii iptables 1.6.2-1 ii libpam-cgfs 2.0.8-1 ii lxcfs 2.0.8-1 ii openssl 1.1.0g-2 ii rsync 3.1.2-2.1 ii uidmap1:4.5-1 Versions of packages lxc suggests: ii apparmor 2.12-2 pn btrfs-progs pn lvm2 -- no debconf information Host CPE ID from /etc/os-release: This is not a CentOS or Redhat host and release is missing, defaulting to 6 use -R|--release to specify release Checking cache download in /var/cache/lxc/centos/x86_64/6/rootfs ... Downloading CentOS minimal ... Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package chkconfig.x86_64 0:1.3.49.5-1.el6 will be installed --> Processing Dependency: rtld(GNU_HASH) for package: chkconfig-1.3.49.5-1.el6.x86_64 --> Processing Dependency: libpopt.so.0(LIBPOPT_0)(64bit) for package: chkconfig-1.3.49.5-1.el6.x86_64 --> Processing Dependency: libc.so.6(GLIBC_2.8)(64bit) for package: chkconfig-1.3.49.5-1.el6.x86_64 --> Processing Dependency: libsepol.so.1()(64bit) for package: chkconfig-1.3.49.5-1.el6.x86_64 --> Processing Dependency: libselinux.so.1()(64bit) for package: chkconfig-1.3.49.5-1.el6.x86_64 --> Processing Dependency: libpopt.so.0()(64bit) for package: chkconfig-1.3.49.5-1.el6.x86_64 ---> Package cronie.x86_64 0:1.4.4-16.el6_8.2 will be installed --> Processing Dependency: pam >= 1.0.1 for package: cronie-1.4.4-16.el6_8.2.x86_64 --> Processing Dependency: bash >= 2.0 for package: cronie-1.4.4-16.el6_8.2.x86_64 --> Processing Dependency: sed for package: cronie-1.4.4-16.el6_8.2.x86_64 --> Processing Dependency: libpam.so.0(LIBPAM_1.0)(64bit) for package: cronie-1.4.4-16.el6_8.2.x86_64 --> Processing Dependency: dailyjobs for package: cronie-1.4.4-16.el6_8.2.x86_64 --> Processing Dependency: coreutils for package: cronie-1.4.4-16.el6_8.2.x86_64 --> Processing Dependency: /usr/sbin/sendmail for package: cronie-1.4.4-16.el6_8.2.x86_64 --> Processing Dependency: /bin/sh for package: cronie-1.4.4-16.el6_8.2.x86_64 --> Processing Dependency: /bin/sh for package: cronie-1.4.4-16.el6_8.2.x86_64 --> Processing Dependency: libpam.so.0()(64bit) for package: cronie-1.4.4-16.el6_8.2.x86_64 --> Processing Dependency: libaudit.so.1()(64bit) for package: cronie-1.4.4-16.el6_8.2.x86_64 ---> Package dhclient.x86_64 12:4.1.1-53.P1.el6.centos.1 will be installed --> Processing Dependency: dhcp-common = 12:4.1.1-53.P1.el6.centos.1 for package: 12:dhclient-4.1.1-53.P1.el6.centos.1.x86_64 --> Processing Dependency: grep for package: 12:dhclient-4.1.1-53.P1.el6.centos.1.x86_64 --> Processing Dependency: gawk for package: 12:dhclient-4.1.1-53.P1.el6.centos.1.x86_64 --> Processing Dependency: li
Bug#890884: lxc: Fail to create wheezy container: couldn't find iproute2 package
Package: lxc Version: 1:2.0.9-6 Severity: normal Tags: patch Dear Maintainer, Thank you for your efforts maintaining LXC in Debian! I've found a small annoying issue with Debian wheezy containers, here are the details: Creation of the Debian Wheezy container fails due to wrong name of the iproute package: debootstrap looks for the iproute2 package while there is only iproute package available. Here's a sample run: ~~~ lxc-create -n wheezy -t debian -- -r wheezy debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-wheezy-amd64 ... Downloading debian minimal ... I: Retrieving InRelease I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id ED6D65271AACF0FF15D123036FB2A1C265FFB764) I: Retrieving Packages I: Validating Packages I: Found packages in base already in required: sysvinit I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Found additional required dependencies: insserv libbz2-1.0 libdb5.1 libsemanage-common libsemanage1 libslang2 libustr-1.0-1 I: Found additional base dependencies: adduser debian-archive-keyring gnupg gpgv iproute isc-dhcp-common libapt-pkg4.12 libbsd0 libedit2 libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libncursesw5 libprocps0 libreadline6 libssl1.0.0 libstdc++6 libusb-0.1-4 libwrap0 openssh-client procps readline-common I: Checking component main on http://deb.debian.org/debian... E: Couldn't find these debs: iproute2 Failed to download the rootfs, aborting. Failed to download 'debian base' failed to install debian lxc-create: lxccontainer.c: create_run_template: 1427 container creation template for wheezy failed lxc-create: tools/lxc_create.c: main: 326 Error creating container wheezy ~~~ Providing a simple patch that gently fixes this issue. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-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) LSM: AppArmor: enabled Versions of packages lxc depends on: ii libapparmor1 2.12-2 ii libc6 2.26-6 ii libcap2 1:2.25-1.2 ii libgnutls30 3.5.18-1 ii liblxc1 1:2.0.9-6 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.7-2+b1 ii lsb-base 9.20170808 ii python3 3.6.4-1 ii python3-lxc 1:2.0.9-6 Versions of packages lxc recommends: ii bridge-utils 1.5-14 ii debootstrap 1.0.93 ii dirmngr 2.2.4-3 ii dnsmasq-base 2.78-3 ii gnupg 2.2.4-3 ii iptables 1.6.2-1 ii libpam-cgfs 2.0.8-1 ii lxcfs 2.0.8-1 ii openssl 1.1.0g-2 ii rsync 3.1.2-2.1 ii uidmap1:4.5-1 Versions of packages lxc suggests: ii apparmor 2.12-2 pn btrfs-progs pn lvm2 -- no debconf information --- /usr/share/lxc/templates/lxc-debian 2018-02-08 16:02:25.496742719 +0200 +++ /usr/share/lxc/templates/lxc-debian.new 2018-02-20 12:16:19.870712786 +0200 @@ -250,20 +250,22 @@ case "$release" in wheezy) init=sysvinit + iproute=iproute ;; *) init=init + iproute=iproute2 ;; esac packages=\ $init,\ +$iproute,\ ifupdown,\ locales,\ dialog,\ isc-dhcp-client,\ netbase,\ net-tools,\ -iproute2,\ openssh-server cache=$1
Bug#790241: 0.9.1 is out
Hi Paolo, I'm going to prepare and upload 0.8.14 (both master and slave) based on the old git repositories asap. This is to assure that if it's not possible to prepare 0.9.x for stretch then we'll at least have the last of the previous major version thus we'll won't break the people's setup badly. I hope to fix most of the issues in the BTS with this release. Once this is done I'll gladly switch to working on 0.9.x. Here are some points you could have missed: - in addition to the "buildbot" and "buildbot-worker" Python packages upstream now ships its web interface in the separate package called "buildbot-www" that is built into standard Python module with nodejs and friends; - "buildbot-www" also has modular architecture and provides some plugins out of the box; - additional plugins can be developed using package called "buildbot-pkg" that is available in the upstream repository as well. As for your points: I agree on every point though this won't be too easy. Perhaps we should start by providing binary packages for master and worker in experimental and then grow the number of packages. -- Best regards, Andrii Senkovych 2016-11-14 15:14 GMT+02:00 Paolo Greppi : > Hi and thanks for the suggestion. > > While I wait for my *-guest account to join collab-main and somebody to > pick up the RFP for RAMLfications I have noticed that: > > - upstream has renamed the buildslave component "worker", also on pypi: > https://pypi.python.org/pypi/buildbot-worker > > - the upstream git repo https://github.com/buildbot/buildbot has the > code for both the master component (which matches the Debian buildbot > package) and the worker component (which matches the Debian > buildbot-slave package) > > therefore I **think** that: > > - we should rename the buildbot-slave package to buildbot-worker > > - we should generate both buildbot and buildbot-worker binary packages > from the same source package "buildbot" > > - we can forget about the tarballs on pypi; debian/watch should point to > the https://github.com/buildbot/buildbot/tags > > - the packaging for 0.9.1 should start from a fresh git repo; reusing > https://github.com/buildbot/debian-buildbot and > https://github.com/buildbot/debian-buildbot-slave is possible by > manually transferring the files / patches, but the upstream branch will > be radically different > > what do you think ? > > Paolo > > On 10/11/2016 13:54, Andrii Senkovych wrote: >> Hi Paolo, >> >> I think collab-maint is the right place for it. Also, what did you use >> as an upstream source? Was it pip URL or the repo on github? I think >> we should move to the github repo because buildbot-www package is >> already a build artifact produced by build procedures from github >> repo. That's where nodejs and friends come in. Granted, buildbot as a >> standalone pip package does not need nodejs to be built. >> >> Info on collab-maint and collaborative maintenance of the package: >> https://wiki.debian.org/Alioth/Git
Bug#843518: webdis: new upstream version
Hello, Ricardo! Thank you for the heads up and for interest in webdis. I've done packaging of the new upstream version along with some other changes and sent a request to sponsor the package. Hope to see it in the Debian Archive soon. Meanwhile you can review the package in the new Git repo: https://anonscm.debian.org/cgit/collab-maint/webdis.git Have a nice day! -- Best regards, Andrii Senkovych 2016-11-07 13:13 GMT+02:00 Ricardo Mones : > Source: webdis > Severity: wishlist > > Hi maintainer! > > There's a new upstream release of webdis since february (0.1.2). > Would be nice to have it packaged for Debian before the release. > > Thanks in advance and best regards, > > -- System Information: > Debian Release: 8.6 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.16-3-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)
Bug#790241: 0.9.1 is out
Hi Paolo, I think collab-maint is the right place for it. Also, what did you use as an upstream source? Was it pip URL or the repo on github? I think we should move to the github repo because buildbot-www package is already a build artifact produced by build procedures from github repo. That's where nodejs and friends come in. Granted, buildbot as a standalone pip package does not need nodejs to be built. Info on collab-maint and collaborative maintenance of the package: https://wiki.debian.org/Alioth/Git -- Best regards, Andrii Senkovych 2016-11-10 14:25 GMT+02:00 Paolo Greppi : > Control: retitle 790241 please package 0.9.1 > > I have given it a try, and found that it requires RAMLfications (see the > RFP: https://bugs.debian.org/843882) > > For buildbot, I have set up a local git repo using the git-buildpackage > branch / tag standard (the VCS link pointed to by tracker.d.o is not > compatible with gbp). Assuming someone is willing to help, where would I > push the git repo ? (I would not like to host it on github) > > P >
Bug#794452:
Hi, Lennart I'm sorry for the late reply. I'll update the packages during this weekend. Thank you! 2015-09-04 10:01 GMT+03:00 Lennart Weller : > I keep updating the packages and newer versions now require 0.1.16. > If you'd like I could help out with updating the package.
Bug#735169: os-prober cannot work with the latest upstream blkid (util-linux-2.24)
Hello, I've tested the patch as well and it works. Thank you, Andreas! -- Best regards, Andrii Senkovych -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762015: Subject: RFS: s3fs-fuse/1.78-1 [ITP #601789] -- FUSE-based file system backed by Amazon S3
Jakub, Can you perhaps give an advice where sponsor could be found? Unfortunately, there's no dedicated team for FUSE modules support. By looking on the list of packages FUSE maintained supports It seems he is already busy with lots of stuff. Is it ok to look for a sponsor in some user lists? It seems readers of debian-cloud@lists.d.o may be interested in the package. But, sure, I don't want to bother people too much. Thanks. -- Best regards, Andrii Senkovych -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762015: Subject: RFS: s3fs-fuse/1.78-1 [ITP #601789] -- FUSE-based file system backed by Amazon S3
Jakub, thank you for a review, answers inline
>> .orig.tar.gz is not bitwise-identical to the one uscan downloads. Why?
It seems git-buildpackage has repacked the tarball, I've done new
upload with the correct orig tarball.
>> Current standards version is 3.9.6. (But beware that Lintian doesn't know
>> about it yet!)
I've check the package against new standards version, no changes required.
>> You don't have to specify full debian-policy version in the
>> Standards-Version field. Only the first three components (that is, "3.9.5"
>> or "3.9.6") have to be specified. (Policy §5.6.11)
I used to write the full version in all my packages. If this is a
problem, I'll fix it.
>> I think it's customary not to put any space between "(" and "=" in
>> relationship fields.
Fixed.
>> There are some stray(?) 0x81 bytes in doc/man/s3fs.1 (line 74) and
>> src/s3fs_util.cpp (line 878).
Thank you, I haven't noticed them. I've prepared a patch and sent it
to upstream already.
As for spelling errors, I've sent the request to upstream author. Some
of those found by spellintian seem to be false positives ("ressize"
variable meant "resource size"). [1,2] For now I have added quilt
patch for stray chars but left spelling errors to be merged by
upstream.
[1]: https://github.com/s3fs-fuse/s3fs-fuse/pull/62
[2]: https://github.com/s3fs-fuse/s3fs-fuse/pull/63
2014-09-26 14:28 GMT+03:00 Jakub Wilk :
> [I don't intend to sponsor this package. Sorry!]
>
> * Andriy Senkovych , 2014-09-17, 22:00:
>>
>>
>> http://mentors.debian.net/debian/pool/main/s/s3fs-fuse/s3fs-fuse_1.78-1.dsc
>
>
> .orig.tar.gz is not bitwise-identical to the one uscan downloads. Why?
>
> Current standards version is 3.9.6. (But beware that Lintian doesn't know
> about it yet!)
>
>
>
> You don't have to specify full debian-policy version in the
> Standards-Version field. Only the first three components (that is, "3.9.5"
> or "3.9.6") have to be specified. (Policy §5.6.11)
>
> I think it's customary not to put any space between "(" and "=" in
> relationship fields.
>
>
>
> There are some stray(?) 0x81 bytes in doc/man/s3fs.1 (line 74) and
> src/s3fs_util.cpp (line 878).
>
> codespell(1) finds a bunch of typos:
>
> README:64: happend ==> happened
> src/s3fs_util.cpp:499: infomation ==> information
> src/s3fs_util.cpp:501: infomation ==> information
> src/s3fs_util.cpp:535: infomation ==> information
> src/s3fs_util.cpp:537: infomation ==> information
> src/openssl_auth.cpp:134: destory ==> destroy
> src/curl.cpp:532: existance ==> existence
> src/curl.cpp:1908: occured ==> occurred
> src/curl.cpp:3475: charactor ==> character
> src/curl.cpp:3479: charactor ==> character
> src/curl.cpp:3514: charactor ==> character
> src/curl.cpp:3516: Charactor ==> Character
> src/s3fs.cpp:2043: responce ==> response
> src/s3fs.cpp:2565: occured ==> occurred
> src/s3fs.cpp:2691: Destory ==> Destroy
> src/s3fs.cpp:2947: occured ==> occurred
> src/s3fs.cpp:2955: Destory ==> Destroy
> src/s3fs.cpp:3903: compatability ==> compatibility
>
> spellintian[0] finds a few more:
>
> src/fdcache.h: ressize -> resize
> src/fdcache.cpp: ressize -> resize
> src/s3fs.cpp: ressize -> resize
> src/curl.h: failuer -> failure
>
> [0] https://bitbucket.org/jwilk/spellintian
>
> --
> Jakub Wilk
>
>
> --
> To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/20140926112824.ga3...@jwilk.net
>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758857: buildbot: Unable to upgrade master
David, Thank you for your report and your interest in Debian. It seems the code in buildbot/scripts/upgrade_master.py really exits upgrade process if there's a problem with buildbot.tac file. This means the message should be an ERROR and the text should be more descriptive telling you what to change and retry upgrade. As it is noted in upstream bug #2588 you mentioned [1], there's no simple way to automatically fix buildbot.tac file during upgrade. So this task will be left on the user to be handled manually. I'll add more information in /usr/share/doc/buildbot/NEWS.Debian As for other files you mentioned (public_html/*.new), these are created every time you run upgrade-master command. You may remove *.new suffix to apply them to your setup of remove these files at all. Upgrade process when files are overwritten if they weren't changed by user is currently not implemented. Please contact upstream developers to fix this. New master.cfg.sample config file is also an example of configuration file created after every upgrade-master command. Buildbot upstream has a great deal of supporting old configuration values for some time before deprecating. Release notes for 0.8.9 show this [2]: * slavePortnum option deprecated, please use c['protocols']['pb']['port'] to set up PB port This option is deprecated but not removed so you still can use it in this release (but keep in mind to fix it for later upgrades). So that was not exact issue you spotted when master didn't start. Moreover, I have multiple buildbot masters running at hand that have slavePortnum option. I wonder what your problem really was. At last, permission and owner checks before running upgrade would be good but seems to me not mandatory. You could run upgrade-master command from another user just using su or sudo. This is generally a good assumption that administrator checks permissions beforehand. Thank you again. [1]: http://trac.buildbot.net/ticket/2588 [2]: http://docs.buildbot.net/0.8.9/relnotes/index.html#deprecations-removals-and-non-compatible-changes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756999: new version 0.8.9 available
Martin, Thank you for your bug report. The package is on the way. -- Best regards, Andriy Senkovych 2014-08-04 13:47 GMT+03:00 W. Martin Borgert : > Package: buildbot > Version: 0.8.8-1.1 > Severity: wishlist > > The new version 0.8.9 is the last one in the 0.8 series and is > probably a good choice for jessie. I like esp. that the GitPoller can > now be configured to poll all available branches. This makes it easy > to e.g. poll (and build) all branches matching a regex. A backport to > wheezy would be nice, too. Currently, I use an adhoc backport of > 0.8.8-1.1 without any problems. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726262: O: python-m2crypto -- a crypto and SSL toolkit for Python
Hi. Sorry, I've found the library is going to be orphaned just now (just read debian-devel wnpp digest). I have also found that subject is a dependency for salt-common which is under team maintainership I'm a member of. I'm going to ask if it's better to support via DPMT or move under maintainership of pkg-salt-team since latter primarily uses git. Also asking Salt team if it's ok for me to maintain this library under team Maintainership if such decision is made. Thanks in advance. -- Best regards, Andriy Senkovych 2013/10/14 Charles Plessy : > Package: wnpp > Severity: normal > Subject: O: python-m2crypto -- a crypto and SSL toolkit for Python > >> Le Mon, Sep 23, 2013 at 12:44:56PM +0900, Charles Plessy a écrit : >> > >> > m2crypto currently has 5 bugs of severity "Important", which I am not able >> > to >> > solve. >> > >> > I was wondering if Dima was planning to solve them or is the Python >> > modules team >> > would be interested in taking care of m2crypto together with Dima. >> > >> > The source package is currenlty maintained in Git with patches commited >> > direclty to the master branch. Since this is definitely not (yet ?) a >> > standard >> > way, please let me know if you would like me to convert it to a more >> > classical >> > packaging style. > > Le Sat, Oct 05, 2013 at 08:46:18AM +0900, Charles Plessy a écrit : >> >> Dima, I think that I will orphan the package if you do not answer. Anyway, >> it is easy to be reverted. >> >> In case I orphan the package, would the Python modules team interested in >> adopting it ? > > Since nobody answered to my emails, I orphan this package. > > -- > Charles Plessy > Tsurumi, Kanagawa, Japan > > > -- > To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20131013232514.ga25...@falafel.plessy.net > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#715471: buildbot: Not installable in Sid
Meanwhile the packages are here: https://mentors.debian.net/package/buildbot https://mentors.debian.net/package/buildbot-slave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#715471: buildbot: Not installable in Sid
Hello, The packages are ready for quite some time, waiting for the sponsor to upload it to the archive. I'll wait a bit more for my sponsor to answer and upload the package. If I don't get response after a few days I'm going to ask someone to upload the package. Thank you for your support and sorry so much for the inconvenience. -- WBR, Andriy Senkovych 2013/8/15 Jan-Benedict Glaw : > Hi! > > Is there anything I can do to help porting this package forward to the > new sqlalchemy release? > > I'd really like to setup a buildbot, but I'd like to make sure that > the package is kept up-to-date with upstream (in `sid' or > `experimental', that is), as well as that is installable in the first > place. Alternatively, I'd install from source, but that'd make me > loose all of dpkg's nice features... > > So... Anything we can do about it? > > MfG, JBG > > -- > Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 > Signature of: Eine Freie Meinung in einem Freien Kopf > the second : für einen Freien Staat voll Freier Bürger. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698898: [Pkg-salt-team] Bug#698898: Bug#698898: Bug#698898: certificate file locations
2013/4/10 Joe Healy : > We don't actually need to change the default location via quilt as the > postinst script will change it. But it is probably more obvious for > newcomers and others to have the patch there. Downside is the work is > done in two places - but, in time we could probably delete the script > once we were confident there were not any very early versions out > there... I'd use patches+postinst scripts anyway. Patches declare what is done for why. DEP3[1] shows how to write patches that upstream refused to accept (i.e. they are Debian-specific). Postinst script should be written to work correctly any number of times anyway (according to Debian policy[2]), so i doubt there would be any problems if we leave this code for a reasonable long time. But this is worth noting in README.Debian 2013/4/10 Joe Healy : > The other thing that feels a little odd is running a search and > replace on a users config file, but anything else seems worse. I'd also mention conf.d directories as well (e.g. /etc/salt/minion.d and similar in other binary packages, if not modified by default). I don't see a problem here. Sure it would be better to parse config instead of using sed/grep/awk or other tools, since it's YAML. But this should be a top-level item anyway, so I hope there would be no problems. [1]: http://dep.debian.net/deps/dep3/ [2]: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697509: ITP: qt5 -- cross-platform application and UI framework for developers using C++ or QML
Hello, I'm sorry, but I couldn't find any qt5-related repository under the link you mentioned. Is there any progress? Is there any help needed? Thanks. -- Best regards, Andrii Senkovych -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702197: sqlparse: new upstream version available with Python 3 support
Hello, Sebastian, Thanks, it's work in progress already. -- best regards, Andrii Senkovych 2013/3/3 Sebastian Ramacher : > Source: sqlparse > Version: 0.1.4-1 > Severity: wishlist > > A new upstream version of sqlparse is available. 0.1.6 now includes > support for Python 3. Please package the new version and provide a > python3-sqlparse package. Thanks! > > Regards > -- > Sebastian Ramacher -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
