Re: bash exorcism experiment ('bug' 762923 & 763012)
On 09/28/2014 10:33 AM, Colin Watson wrote: > On Sat, Sep 27, 2014 at 09:11:44PM -0500, Troy Benjegerdes wrote: >> Does update-menus really need bash? Why? > > pipefail is actually a fairly useful bashism. Use mispipe from moreutils instead. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54310554.2060...@bzed.de
Bug#764071: ITP: toxic -- a curses Tox based instant messenging client
Package: wnpp Severity: wishlist Owner: Per Andersson Control: block -1 by 739860 * Package name: toxic Version : 0.5.2 Upstream Author : JFreegman * URL : https://github.com/tox/toxic * License : GPL Programming Lang: C Description : a curses Tox based instant messenging client Toxic is a Tox-based instant messenging client which formerly resided in the Tox core repository, and is now available as a standalone application. . Tox is a secure and distributed Skype replacement. . At its heart it’s a client dealing with our core library communicating on our own protocol. All communications are encrypted using the peer audited NaCl cypto library and this encryption can not be turned off. . Tox is powered by a distributed network which uses P2P connections for chats between people, unlike other Skype replacements no federated servers, centralized servers, or supernodes are used. This is a way to replace Skype. It is decentralized, as opposed to Jabber/XMPP, SIP, Jitsi etc. If anyone wants to co-maintain they are very welcome. Is there a communications team? I know of the OTR team, but that is only for OTR... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005084026.7698.97390.report...@saturn.foo.nu
finding out why a package is not in testing
Since there is no longer a search functionality in https://release.debian.org/migration/ to find out why a particular package is not in testing yet, can we please put a link to https://ftp-master.debian.org/testing/update_excuses.html (or something more appropriate) on that page? This way someone can open up the link and search for the package name they are interested in. thanks raju -- Kamaraju S Kusumanchi http://malayamaarutham.blogspot.com/
Re: finding out why a package is not in testing
[not sure if you're subscribed to debian-devel, so CCing] On Sun, 2014-10-05 at 06:52 -0400, kamaraju kusumanchi wrote: > Since there is no longer a search functionality > in https://release.debian.org/migration/ to find out why a particular > package is not in testing yet, can we please put a link to > https://ftp-master.debian.org/testing/update_excuses.html (or > something more appropriate) on that page? The correct place to ask for changes to release.debian.org isn't debian-devel; that would be the debian-release list. > This way someone can open up the link and search for the package name > they are interested in. https://release.debian.org/migration/testing.pl?package=foo still works perfectly fine, the search functionality is simply disabled because it's too easy to overload the host (e.g. when it's hit by bots). Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412513286.26144.15.ca...@jacala.jungle.funky-badger.org
Bug#764112: ITP: mlbviewer -- Curses interface to the MLB.TV media offering
Package: wnpp Severity: wishlist Owner: Sebastien Delafond * Package name: mlbviewer Version : 2014.sf.3 Upstream Author : straycat...@yahoo.com * URL : https://sourceforge.net/projects/mlbviewer/ * License : GPL 2 Programming Lang: Python Description : Curses interface to the MLB.TV media offering A collection of tools to view and listen to streaming baseball games from MLB.TV. While the main streaming content is mostly for paid MLB.TV subscribers only, there are a significant number of features and views available to non-subscribers as well including one free game each day. You can watch MLB classic content from YouTube without a browser, and MiLB.TV and Postseason.TV are also integrated into the same mlbviewer interface. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005135538.16315.40806.report...@hetz1.mine.nu
Bug#764115: ITP: baloo-kcmadv -- advanced configuration module for KDE Desktop Search
Package: wnpp Severity: wishlist Owner: Luigi Toscano * Package name: baloo-kcmadv Version : 0~git20140427 Upstream Author : Lindsay Mathieson * URL : https://gitorious.org/baloo-kcmadv * License : LGPL2 Programming Lang: C++ Description : advanced configuration module for KDE Desktop Search This module allows users to fine-tune the configuration of the Baloo Desktop Search technology for KDE applications. The source package will generate a binary package called kde-config-baloo-advanced I'm looking for sponsors but I'm in touch with the Debian Qt/KDE team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005135946.1352.16057.reportbug@nomaios.toscano
Re: Allow encfs into jessie?
Hallo, * Matthias Urlichs [Mon, Sep 29 2014, 07:29:44AM]: > > > According to a security audit by Taylor Hornby (Defuse Security), the > > > current > > > implementation of Encfs is vulnerable or potentially vulnerable to > > > multiple > > > attacks on the encrypted data. This especially affects use cases where > > > the > > > attacker has read/write access to the encrypted directory or has enough > > > knowledge of the unencrypted file system contents. > > > . > s/especially/only/, AFAIK. Maybe, but: "only" could sound like absolution to clueless users and I am not willing to make such suggestions. > > > In the current situation encfs should not be considered a safe home for > > > sensible data. This package should be only used to retrieve information > > > from > > s/sensible/sensitive/ Ouch, thank you. > > > previously encrypted sources, and even this action contains some risk of > > > receiving compromised data. > > > To recap the security analysis, as I understood it: There's a problem if > somebody has, or had, access to the encrypted files _and_ can store random > data of their choosing there (by manipulating either the encrypted or the > unencrypted files). The notice should unequivocally state exactly that, > instead of the current level of (IMHO) panic mongering. > > In most scenarios (encrypt some personal or corporate data stored on NFS, > use reverse mode to store an encrypted backup of sensitive stuff to the > cloud, whatever) this is a non-problem. I agree regarding most scenarios and I changed the text now. However, it's hard to keep the text understandable for average user and mention all relevant dangers without goind too much into details. So, I suggest this new version. Added below for review; I consider uploading this to Experimental and submitting for l10n in a couple of days. Regards, Eduard. Template: encfs/security-information Type: error _Description: Encfs security information According to a security audit by Taylor Hornby (Defuse Security), the current implementation of Encfs is vulnerable or potentially vulnerable to multiple types of attacks. For example, an attacker with read/write access to encrypted data might lower the decryption complexity for subsequently encrypted data without being noticed by the legimitate user, or may compute encryption information by timing analysis. . Until these issues are resolved, encfs should not be considered a safe home for sensitive data in certain scenarios. signature.asc Description: Digital signature
Re: Bug#762949: ITP: obs-build -- scripts for building RPM/debian packages for multiple distributions
On 26 September 2014 14:58, Neil Williams wrote: > On Fri, 26 Sep 2014 14:19:24 +0100 > Dimitri John Ledkov wrote: > >> Package: wnpp >> Owner: Dimitri John Ledkov >> Severity: wishlist >> >> * Package name: obs-build >> Version : 20140918 >> Upstream Author : Adrian Schröter >> * URL or Web page : https://github.com/openSUSE/obs-build >> * License : GPL-2+ >> Description : scripts for building RPM/debian packages for >> multiple distributions >> >> This package provides scripts for building RPM and debian packages in >> contained environments for various build distributions. These tools >> are use by Open Build Service workers and openSUSE distribution by >> default. >> >> By default it claims very generic paths: >> /usr/bin/build >> /usr/lib/build >> >> I'm planning to keep those as per upstream, if however there are >> strong objections I'd be happy to change those to obs-build. > > Any number of packages could have claimed /usr/bin/build by now, > instead we have sbuild, debuild, pdebuild, make, dpkg-buildpackage, > git-buildpackage and a host of others. I don't see that obs deserves to > be the "one true build" which may be the impression given by an overly > common binary name. > So i've patched obs-build to use obs-build and tested out osc with it. Which turned out hardcoded paths to /var/lib/build in some legacy support checks. Filed bug-report which has been fixed upstream. obs-build uploaded, and should hit new queue soon. Once it's in, I'll propose for osc to cherry-pick that upstream commit, set build-cmd to "obs-build" and depend/recommend/suggest obs-build package. Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUjPibkyVnEqB8cQH_wfYgt98=kumxz1a8eogsckcq_...@mail.gmail.com
Inert DEB_BUILD_OPTIONS noopt in debian/rules files
Hi! While going through the dpkg codebase, I realized that any debian/rules file that calls dpkg-buildflags through make's $(shell) function will not honor at least noopt from DEB_BUILD_OPTIONS, which affects the build flags returned by dpkg-buildflags. This is fixed in dpkg 1.17.14 buildflags.mk, but any package handling the flags inline will probably be affected, as I don't expect that case to be currently handled. Packages using dh(1) or cdbs are not affected. I'm not sure how many packages might be affected, but I think the current situation is *bad*. Regards, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005233308.ga31...@gaara.hadrons.org
Re: Inert DEB_BUILD_OPTIONS noopt in debian/rules files
* Guillem Jover , 2014-10-06, 01:33: I realized that any debian/rules file that calls dpkg-buildflags through make's $(shell) function will not honor at least noopt from DEB_BUILD_OPTIONS, which affects the build flags returned by dpkg-buildflags. Why? any package handling the flags inline will probably be affected, as I don't expect that case to be currently handled. I've just checked a random package of mine[0], and it honours noopt just fine. [0] https://sources.debian.net/src/rc/1.7.1-5/debian/rules/?hl=11:13#L11 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005235500.ga5...@jwilk.net
Re: Inert DEB_BUILD_OPTIONS noopt in debian/rules files
Hi! On Mon, 2014-10-06 at 01:55:01 +0200, Jakub Wilk wrote: > * Guillem Jover , 2014-10-06, 01:33: > >I realized that any debian/rules file that calls dpkg-buildflags through > >make's $(shell) function will not honor at least noopt from > >DEB_BUILD_OPTIONS, which affects the build flags returned by > >dpkg-buildflags. > > Why? Because make does not (yet) pass make variables to $(shell) subshells. > >any package handling the flags inline will probably be affected, as I > >don't expect that case to be currently handled. > > I've just checked a random package of mine[0], and it honours noopt just > fine. Try this: $ make -f debian/rules DEB_BUILD_OPTIONS=noopt build instead. This just breaks the interface. We could of course simply just document that people should not do that… it's still a regression from when people switched to dpkg-buildflags (me included). (Or get the make bug #327154 fixed. :) Rereading my mail again, it sounded a bit alarmist, the situation is not *that* bad, as in the consequences on normal usage, it just affects probably lots of packages, in case we care. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006003821.ga19...@gaara.hadrons.org
Re: apache2 issues
On 23 September 2014 17:58, Jeroen Dekkers wrote: > > > Isn't that an implementation detail? Is Python version relevant for the > > on-the-wire WSGI protocol? > > WSGI is an API, not a wire protocol. The Python version of the WSGI > server would also be the Python version the code is run under, so we > must distinguish between Python 2 and 3. The best way would probably > be to specify that httpd-wsgi is for Python 2 and create a httpd-wsgi3 > virtual package for Python 3. > How do we make this change? Does this require reopening #588497 and/or creating a new bug against debian-policy? -- Brian May
Re: Bug#763930: ITP: mysecureshell -- SFTP Server with ACL
Thanks, I've corrected it Le 10/04/2014 10:18 AM, Adam D. Barratt a écrit : > On Fri, 2014-10-03 at 22:08 +, Pierre Mavro wrote: >> MySecureShell is a solution which has been made to bring more features to >> sftp/scp protocol given by OpenSSH. By default, OpenSSH brings a lot of >> liberty to connected users which imply to thrust in your users. > This seems to be a common error, but the word you're looking for is > "trust". > > Thrusting your users would be something quite different... > > Regards, > > Adam > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54323282.8000...@mavro.fr
Re: Allow encfs into jessie?
Hi, Eduard Bloch: > So, I suggest this new version. Added below for review; I consider > uploading this to Experimental and submitting for l10n in a couple of > days. > Fair enough. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006065051.gt3...@smurf.noris.de
