Bug#647162: ITP: python-mimeparse -- basic functions for parsing mime-type names
Package: wnpp Severity: wishlist Owner: Mathias Ertl * Package name: python-mimeparse Version : 0.1.3 Upstream Author : Joe Gregorio * URL : http://code.google.com/p/mimeparse/ * License : MIT Programming Lang: Python Description : basic functions for parsing mime-type names This pure python module parses mime-types and parameters commonly found in the Accept header in HTTP requests. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031075017.23463.13213.report...@haumea.htu.tuwien.ac.at
Re: Debian unstable/expirental missing some bnx2 firmwares
On Sun, 2011-10-30 at 08:06 -0700, Ben Hutchings wrote: > On Sun, 2011-10-30 at 10:49 +0100, Sébastien Riccio wrote: > > On 30.10.2011 10:42, Niels Thykier wrote: > Our upstream for (most of) firmware-nonfree is the linux-firmware > repository, and it appears that Broadcom never sent version 6.2.9.0 of > the bnx2x firmware there. It's also possible that the request was > dropped somewhere along the way. > Hi Ben, The firmware was submitted to firmware/bnx2x folder using 96b8e1a0e96bd30ffb07e739b29b8c4c5759b93f in IHEX form with appropriate changes in firmware/Makefile and firmware/WHENCE. You should be able to build binaries using all this. Please let me know if you need any more assistance. Dmitry. > Ben. > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1320053136.21301.9.camel@lb-tlvb-dmitry
Bug#647171: ITP: python-passlib -- comprehensive password hashing framework supporting over 20 schemes
Package: wnpp Severity: wishlist Owner: Julien Danjou * Package name: python-passlib Version : 1.5.3 Upstream Author : Eli Collins * URL : http://code.google.com/p/passlib/ * License : BSD Programming Lang: Python Description : comprehensive password hashing framework supporting over 20 schemes PassLib is a password hashing library for Python, which provides cross-platform implementations of over 20 password hashing algorithms; as well as a framework for managing and migrating existing password hashes. It's designed to be useful for any task from quickly verifying a hash found in a unix system's /etc/shadow file, to providing full-strength password hashing for multi-user application. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031094029.28535.10148.report...@zelenka.enovance.com
Re: Possible mass bug filling for package depending on
[Frank lin Piat] > Any chance to go ahead? It would be a pity if the only solution was > to fork su-to-root (and possible merge xdg-su[2]) in a new > source+binary package :-( Is there no other package installed on most/all desktop installations that can be the home of such script? A quick look on popcon.debian.org could give some ideas? Random ideas are base-files, lsb-base, x11-common and desktop-base based on a quick look. I am sure there might be better alternatives. Or perhaps some wrapper script provided using alternatives is a better idea. Then the providers of this script could replace each other, and those needing the wrapper could depend on the virtual package. I suspect all that is needed is someone to focus on the problem to figure out and implement a solution. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl62j5zclu@login2.uio.no
Re: Announcing derivatives patches and call for help and feedback
On Mon, Oct 31, 2011 at 5:28 PM, Karl Goetz wrote: > As a (largely) non coder, what should I look for in (say) gNewSenses > patches to know if it can be filtered out automatically? Are there any > common indicators? Anything that looks like cruft or things that the Debian maintainer does not need to see. It was suggested on IRC that I should delegate the filtering to maintainers with an easy interface. I'm not sure what that would look like but it sounds a much more useful way to do things. Hopefully Mehdi would be willing to work on it too :) -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6hbye2cexf0hjrrsv23bhsqft+uwt0o_rjfuoht8mb...@mail.gmail.com
Re: Possible mass bug filling for package depending on "menu".
On Sat, Oct 29, 2011 at 08:49:01PM +0200, Frank lin Piat wrote: > Specious "depends" relationship [AFAICT]: > backintime-gnome - GNOME front-end for backintime > backintime-kde- KDE front-end for backintime This is because of su-to-root. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: Debian unstable/expirental missing some bnx2 firmwares
On Mon, 2011-10-31 at 11:25 +0200, Dmitry Kravkov wrote: > On Sun, 2011-10-30 at 08:06 -0700, Ben Hutchings wrote: > > On Sun, 2011-10-30 at 10:49 +0100, Sébastien Riccio wrote: > > > On 30.10.2011 10:42, Niels Thykier wrote: > > > Our upstream for (most of) firmware-nonfree is the linux-firmware > > repository, and it appears that Broadcom never sent version 6.2.9.0 of > > the bnx2x firmware there. It's also possible that the request was > > dropped somewhere along the way. > > > Hi Ben, > The firmware was submitted to firmware/bnx2x folder using > 96b8e1a0e96bd30ffb07e739b29b8c4c5759b93f in IHEX form with appropriate > changes in firmware/Makefile and firmware/WHENCE. So it's in the linux tree but not linux-firmware? Well that's fairly useless. David, we need to either keep on importing changes from the linux tree or get rid of the firmware directory altogether. I notice that one new driver has even added a blob there recently. Ben. > You should be able to build binaries using all this. > > Please let me know if you need any more assistance. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Re: Advocating the use of RDF for Debian's published metadata - Was: Re: Proposal for additional metadata in Debian archives (DEP-11)
Le Thu, Oct 27, 2011 at 05:49:12PM +0200, Matthias Klumpp a écrit : > > For us, it is necessary that APT can process this data (will be > implemented if DEP-11 can make it) and that parts of it can be written > into a Xapian-DB for fast searching. - Both would work perfectly well > with any format. > > It would be very nice, if ftpmasters could tell if they would accept a > new format in the archive or if we should stay with RFC822 which is > used for nearly everything else already. Dear Matthias, I am still not sure to understand how the data will be used. Is it only to be used via Internet ? In that case perhaps it is not needed to distribute it via the Debian archive. What is the Debian-specific data ? If it is the association between a FreeDesktop menu “.desktop” file and a package name, there is already a file in the Debian archive that provides this. Then, a repository of the contents of FreeDesktop menu entries would definitely be valuable, especially if served semantically, but as it would not contain data specific to Debian, wouldn't it be better to develop it with less ties to the Debian archive ? That would be a great contribution from Debian to the the rest of the Free software ecosystem. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031143235.ga18...@merveille.plessy.net
seeking comaintainer for debmirror
I've been maintaining debmirror since we lost fjp. But moving to a cabin with dialup internet shortly after adopting a mirror program turns out to be a bad idea for developing it (though a nice use-case for using it). So I'm seeking comaintainer(s). All that's needed is basic perl, and an understanding of how the archive is laid out. Source is in collab-maint git so you already have commit access. Some examples of changes that need to be made: * mirror per-section Contents files #637442 * More robust i18n/Index file parsing. Alternatively, find a way to not need to parse those files. #644609 * support InRelease files #644609 debmirror could use some refactoring of cruft accumulated over the years, but I may not be the one to do it, since every time I think about that I have an urge to rewrite it in haskell. -- see shy jo signature.asc Description: Digital signature
Bug#647197: ITP: python-snappy -- Python library for the snappy compression library from Google.
Package: wnpp Severity: wishlist Owner: XuZhiXiang * Package name: python-snappy Version : 0.3.2 Upstream Author : Andres Moreira * URL : http://github.com/andrix/python-snappy * License : BSD Programming Lang: C, Python Description : Python library for the snappy compression library from Google. Snappy is a compression/decompression library. It does not aim for maximum compression, or compatibility with any other compression library; instead, it aims for very high speeds and reasonable compression. For instance, compared to the fastest mode of zlib, Snappy is an order of magnitude faster for most inputs, but the resulting compressed files are anywhere from 20% to 100% bigger. On a single core of a Core i7 processor in 64-bit mode, Snappy compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more. . Snappy is widely used inside Google, in everything from BigTable and MapReduce to our internal RPC systems. (Snappy has previously been referred to as “Zippy” in some presentations and the likes.) . python-snappy is Python library for the snappy compression library from Google. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031154215.27087.54853.report...@debox.lan
Re: Dealing with embedded javascript libraries
* Raphael Hertzog , 2011-10-26, 18:47: For instance I just noticed that we can't install new widgets with the current wordpress package due to some javascript related problem. I'm not familiar enough with the codebase to investigate it easily. I can't ask upstream about it because it works with the version of the libraries that they are shipping. Why you can't? Do they bite if you do? For the very same reason we don't like Ubuntu bugs that have not been reproduced on Debian. If the bug looks like "foo doesn't work on Ubuntu!!1one", then indeed it won't be welcome. Even if I wanted to help the poor little user, surely I won't bother to install Ubuntu to debug the problem. On the other hand, I do appreciate "If you upgrade baz to 3.14 and turn on quux (incidentally, this is what we did in Ubuntu), foo explodes" bugs. This is something I can try to reproduce in a (modified) Debian environment. And maybe it's something worth fixing, because some day Debian will have baz 3.14, and enabling quux might be not such a bad idea after all. That said, I acknowledge that this is delicate matter. That's why I asked if your upstream bite. ;) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031174214.gb1...@jwilk.net
Re: Dealing with embedded javascript libraries
On Thu, Oct 27, 2011 at 1:28 AM, Ian Jackson wrote: > The difficulty is that if we end up with ten different versions of > some random javascript library, when it turns out to have a security > vulnerability we need to somehow backport the patch to each of those > ten versions. > > And here "we" means the security team, not the people who uploaded the > ten versions in the first place. > > So this is rather unpalatable. What's the alternative? It seems that we only have two choices: - Either all packages use the same version of the JavaScript library (what we have been doing until now, which results in some packages not working properly due to changes in the JavaScript library that manifest only in some situations in runtime). This is essentially what we do with C, C++, etc libraries, btw: the whole Debian is built against the same zlib, same glibc, same libpng, etc or - Each package works with the upstream-bundled version of the JavaScript library (and then we have the problem of backporting security fixes). The advantage being we are sure the application works as expected because it has been tested by upstream. I'm not sure what's worse: a malfunctioning application or an insecure one. Zygmunt's proposal of adding unit testing, etc to upstream is a noble one but highly unrealistic, IMHO. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakcbokuijju-o_w1vtmx0ayruqsz9cheucoslf3tsb3fjwx...@mail.gmail.com
Re: segfault error 4 in libpthread-2.13.so X86_64
Just pointing out that I'm seeing a segfault inside pthread_join of libpthread-2.13.so. I need to look at the pthread source before I can tell why it crashed. I will also try to roll back to an older version of this library to confirm that I was not seeing this crash earlier. Will report back what I find. On Mon, Oct 31, 2011 at 1:53 AM, Chow Loong Jin wrote: > On 31/10/2011 13:13, Dallas Clement wrote: >> The symbols are definitely present on my system. When I step through >> the execution, I can see where it is crashing inside the pthread >> library. The last thing it does is join with one thread that was >> previously spawned. > > And so? > > -- > Kind regards, > Loong Jin > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE9DZURoqEbsc4Xf1vA78T=n7be5mxdbyspugrsbp2fvtz8...@mail.gmail.com
Re: segfault error 4 in libpthread-2.13.so X86_64
Dallas Clement wrote: > Will report back what I find. Please don't. This is the wrong list --- it is about development _of_ Debian, not development _on_ Debian. You might find the libc-help list[1] to be more helpful. Or if your questions are Debian-specific, debian-user[2] can be a great help. Hope that helps, Jonathan [1] see http://sourceware.org/glibc/ [2] http://lists.debian.org/debian-user/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031194208.ga10...@elie.hsd1.il.comcast.net
Re: Proposal for additional metadata in Debian archives (DEP-11)
2011/10/31 Charles Plessy : > Le Thu, Oct 27, 2011 at 05:49:12PM +0200, Matthias Klumpp a écrit : >> >> For us, it is necessary that APT can process this data (will be >> implemented if DEP-11 can make it) and that parts of it can be written >> into a Xapian-DB for fast searching. - Both would work perfectly well >> with any format. >> >> It would be very nice, if ftpmasters could tell if they would accept a >> new format in the archive or if we should stay with RFC822 which is >> used for nearly everything else already. > > Dear Matthias, Hi! :) > I am still not sure to understand how the data will be used. Is it only to be > used via Internet ? No, it is used by applications running on Debian. The application which will use this data the most is the Software-Center and related apps for sure, but with the components-metadata, every application needing to find extra-components (like plugins) in the archive using a distro-agnostic way will use this data. The data will be accessible via APT and PackageKit. (and via aptd too, I guess) > In that case perhaps it is not needed to distribute it via > the Debian archive. What is the Debian-specific data ? If it is the > association between a FreeDesktop menu “.desktop” file and a package name, > there is already a file in the Debian archive that provides this. Not only. It also exposes some content-elements of the .desktop-file to a new file which is easily-searchable. And it will provide extra informations about which package contains which python module, shared lib etc. This is basically a metadata <-> deb-package matching. It is good to have this in a extra file, because the Contents.tar.gz does not provide all of this information and because Contents.tar.gz is a very, very huge file. We don't want to download, process and cache this file everytime the archive updates. The Components.gz file would be much smaller. So, two important reasons for the new approach :) > Then, a > repository of the contents of FreeDesktop menu entries would definitely be > valuable, especially if served semantically, but as it would not contain data > specific to Debian, wouldn't it be better to develop it with less ties to the > Debian archive ? That would be a great contribution from Debian to the the > rest of the Free software ecosystem. Others can fetch the data if they want, but the data is specific to Debian's current archive state... There are some other things you might be able to do with it, like matching it with Fedora's data and produce messages like "Fedora has packaged library X version Y which is not yet present in the archive." or sharing patches more easily because finding the "related" RPM package to a DEB package in other distros would be easier and faster. But that's of course not the main goal of DEP-11, although it's a nice possibility, IMHO. Have a nice day too! Cheers, Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caknhny_wdvjgfvdsozi+byq-8wtkhydvx_fvx2n9ahnqpg0...@mail.gmail.com
Re: segfault error 4 in libpthread-2.13.so X86_64
On Mon, Oct 31, 2011 at 02:05:03PM -0500, Dallas Clement wrote: > Just pointing out that I'm seeing a segfault inside pthread_join of > libpthread-2.13.so. I need to look at the pthread source before I can > tell why it crashed. I will also try to roll back to an older version > of this library to confirm that I was not seeing this crash earlier. This thread is off-topic for debian-devel. And this crash is almost certainly not a bug in libpthread. Most likely your program has corrupted the thread state in some way. You may find that valgrind or helgrind (both in the valgrind package) can find the bug. Please do not ask for further help on this list. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031205912.gt3...@decadent.org.uk
Re: Could the multiarch wiki page be explicit about pkgconfig files?
* Simon McVittie , 2011-09-19, 18:56: The correct place for debug files is a hash-based path, instead of the crapfuck we have today. ... but until then, for gdb to pick them up, debug symbols for $THING must be in /usr/lib/debug/$THING (a general rule, independent of multiarch), resulting in paths like /usr/lib/debug/lib/x86_64-linux-gnu/libdbus-1.so.3.6.3 /usr/lib/debug/usr/bin/dbus-send for a typical multi-arch library and executable (those two are in dbus-dbg). This means any -dbg package that contains symbols for an executable can't have the Multi-Arch flag set on it yet, Not everybody was paying attention to this issue when multiarchifying their packages. A few of them have "Multi-Arch: same" set, but contain files in /usr/lib/debug/bin or such: libpango1.0-0-dbg libpcre3-dbg liblua5.1-0-dbg libgtk2.0-0-dbg libc0.1-dbg libc6-dbg libnss3-1d-dbg librsvg2-dbg until we have the hash-based paths Josselin mentions. If you can't wait for proper build-id support in debhelper, you can use this hacky debhelper script (to be called after dh_strip): http://anonscm.debian.org/viewvc/python-modules/packages/gamera/trunk/debian/dh_buildid?view=co -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031221251.ga2...@jwilk.net
Re: Possible mass bug filling for package depending on [X-KDE-SubstituteUID]
> On Mon 31/10/11 11:20 , Petter Reinholdtsen wrote:: > > [Frank lin Piat] > > Any chance to go ahead? It would be a pity if the only solution was > > to fork su-to-root (and possible merge xdg-su[2]) in a new > > source+binary package :-( FYI ... a KDE specific solution... For those interested in the su-to-root. I noticed that KDE is (or was?) using a different mecanism to su-to-root... They introduced a statement in XDG menu file: | X-KDE-SubstituteUID=true Which obviously led to a bug in Debian when running those program in other desktop enironment, like : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359962 Synaptics, kvpnc and other seems to use a hack like this : synaptic-kde.desktop | [Desktop Entry] | Exec=synaptic | X-KDE-SubstituteUID=true | OnlyShowIn=KDE; synaptic.desktop | [Desktop Entry] | Exec=su-to-root -X -c /usr/sbin/synaptic | NotShowIn=KDE; -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51723.1320099...@klabs.be
Re: Dealing with embedded javascript libraries
W dniu 31.10.2011 14:49, Pau Garcia i Quiles pisze: On Thu, Oct 27, 2011 at 1:28 AM, Ian Jackson wrote: The difficulty is that if we end up with ten different versions of some random javascript library, when it turns out to have a security vulnerability we need to somehow backport the patch to each of those ten versions. And here "we" means the security team, not the people who uploaded the ten versions in the first place. So this is rather unpalatable. What's the alternative? It seems that we only have two choices: - Either all packages use the same version of the JavaScript library (what we have been doing until now, which results in some packages not working properly due to changes in the JavaScript library that manifest only in some situations in runtime). This is essentially what we do with C, C++, etc libraries, btw: the whole Debian is built against the same zlib, same glibc, same libpng, etc or - Each package works with the upstream-bundled version of the JavaScript library (and then we have the problem of backporting security fixes). The advantage being we are sure the application works as expected because it has been tested by upstream. I'm not sure what's worse: a malfunctioning application or an insecure one. Zygmunt's proposal of adding unit testing, etc to upstream is a noble one but highly unrealistic, IMHO. For the record. I stated the reverse, what you described above was proposed by someone else. I on the other hand agree that we should: 1) Ship _bundled_ libraries that upstream provides. The rationale is that version is what upstream supports. I don't believe in our capacity to support random applications out there better than upstreams already do. OR 2) Have broad multi-version support (perhaps eventually at dpkg level), package multiple versions of javascript libraries, depend on the precise version that upstream used. The motivation for this is similar to my previous point except that it might be, theoretically, better to support security fixes. The more direct advantage is easier support for incompatible, co-installable versions of a single library. I think that security aspect is moot because failing to find a proper package people will just revert to _not_ using dpkg for their web deployments and the world will NOT be a single bit more secure. Best regards ZK -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eaf5e5b.50...@canonical.com
Re: Announcing derivatives patches and call for help and feedback
On Mon, 31 Oct 2011 18:34:47 +0800 Paul Wise wrote: > On Mon, Oct 31, 2011 at 5:28 PM, Karl Goetz wrote: > > > As a (largely) non coder, what should I look for in (say) gNewSenses > > patches to know if it can be filtered out automatically? Are there > > any common indicators? > > Anything that looks like cruft or things that the Debian maintainer > does not need to see. ok. > It was suggested on IRC that I should delegate the filtering to > maintainers with an easy interface. I'm not sure what that would look > like but it sounds a much more useful way to do things. Hopefully Sounds smart :) thanks, kk > Mehdi would be willing to work on it too :) > -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
