Bug#535116: ITP: pybtex -- BibTeX-compatible bibliography processor
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: pybtex Version : 20090402 Upstream Author : Andrey Golovizin * URL : http://pybtex.sourceforge.net/ * License : GPLv2 Programming Lang: Python Description : BibTeX-compatible bibliography processor Pybtex reads citation information from a file and produces a formatted bibliography. BibTeX style files are supported. Alternatively it is possible to write styles in Python. Pybtex currently understands the following bibliography formats: * BibTeX * BibTeXML * YAML-based format The resulting bibliography may be output in one of the following formats: * LaTeX * HTML * plain text -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
* Jonathan Yu , 2009-07-03, 21:03: Maybe an idea is to have a format like: Bug: #123456 (assumes Debian BTS) Bug: BTS#123456 (same as above, but explicit) Bug: RT#123456 (to point to the CPAN Request Tracker) So, you are expecting that someone who reviews a patch would known how to convert bug numbers to URLs for *all* these trackers? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New virtual package x-image-viewer?
* Jan Hauke Rahm , 2009-07-08, 19:36: I'd like to have a new virtual package 'x-image-viewer'. All packages providing that virtual package should be able to view images in common formats (png, jpeg etc.). I'm thinking but that's pretty much all I can say... It's obvious that I would want all image viewers to provide that virtual package then. And such a package is needed because...? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
* Bastian Blank , 2009-08-11, 22:24: > Not necessarily. Any sane implementation should just use wchar_t Which could be UTF16 and therefore still has complicatd length semantics. No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like Windows). And in the most esoteric (while still conforming to the C standard) implementations it is not related to Unicode at all. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Where should DLL files go?
* Sam Morris , 2009-08-25, 21:48: The gcc-mingw32 package provides GCC configured to target Microsoft Windows. The executables built by GCC will pick up a dependency on libgcc_s_sjlj-1.dll; the question of where that file should be placed on a Debian system has arisen. FYI, there is another DLL that is required by some programs compiled with (gcc-)mingw32: mingwm10.dll. See <http://bugs.debian.org/518770> for an unfruitful discussion on where the DLL should go. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543678: ITP: minidjvu -- bitonal DjVu encoder/decoder
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: minidjvu Version : 0.7 Upstream Author : Ilya Mezhirov * URL : http://minidjvu.sourceforge.net/ * License : GPLv2 Programming Lang: C++ Description : bitonal DjVu encoder/decoder minidjvu encodes and decodes single page black-and-white DjVu files, and can compress multiple pages, taking advantage from similarities between pages. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Manually providing popcon data (Was: Future of the s390 port)
* Andreas Tille , 2009-09-03, 13:12: So as long as there is no easy manual way to provide anonymized figures without installing software on our production servers we can't deliver such data :-( and yes, I know there are many reasons why a manual upload form would be a bad idea regarding accuracy and actuality. What about a popcon-offline package or configuration option of plain popcon which just generates the content of the mail that is sended to popcon.debian.org and leave it to the admin to send it manually. I believe that one can implement (sort of) popcon-offline by setting: MAILTO=root USEHTTP=no in the /etc/popularity-contest.conf file. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
* Josselin Mouette , 2009-09-08, 10:06: > Case 1, please. Either case 2 fails to handle the allocation error, or glib > is doing its own abort. Neither is acceptable. Yeah, sure. As if there was anything more sensible to do than aborting when a memory allocation fails. When this happens under Linux, the application will end up OOM-killed really soon anyway. Unless there is more physical memory than virtual memory (hint: ulimit -v). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: apt: cron.daily necessary?
* Raphael Geissert , 2009-09-08, 13:28: Since CFQ is the default IO scheduler, this kind of tasks should be launched with "ionice -c3", no ? But that would introduce a dependency on ionice. An option would be to use start-stop-daemon's IO nice capabilities. $ dlocate -S /bin/ionice util-linux: /usr/bin/ionice $ apt-cache show util-linux | grep ^Essential Essential: yes -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
* Adam Borowski , 2009-10-14, 21:34: A software which requires access to non-free documents over the network to work at all shouldn't go into main. It seems that gnaughty is currently in that category. Sure, just remember to file RM bugs for: gmailfs Not a very good example: http://bugs.debian.org/540773 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#551026: ITP: xcite -- exciting cite utility for Emacsen
* TANIGUCHI Takaki , 2009-10-15, 11:35: * Package name: xcite Version : 1.58 Upstream Author : HIROSE Yuuji [yu...@gentei.org] * URL or Web page : http://www.gentei.org/~yuuji/software/ * License : original This software is distributed as a free software without any warranty to anything as a result of using this. Especially, I am not responsible for the case when you cite your friend's mail with a silly citation prefix in a serious situation :) * Can I incorporate this program into Debian package? Yes. Upstream's agreement neither a necessary nor a sufficient condition for a piece of software to be included in Debian. First of all, it needs to have a clear, DFSG-free license attached... This "Yes" is NOT a special answer only for Debian. My recognition on `free software' is not the permanently constant notion. Therefore I won't define the fixed license sentences at any moment of my life. ...which upstream refuses to provide. All I can say now is I hope the free software be; freely usable, freely (re-)distributable without any charge for itself, freely modifiable unless the original author(=me)'s copyrights are infringed or neglected, absolutely not responsible to any result from itself. If there is A license clauses which implies these points above in some era, this software can be classified into the group that the clauses want to assume as `free'. This wording is far too vague. Please bug upstream to use a well-known license. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
get-orig-source: possible MBF
I performed an experiment, in which I tried to check if source packages are providing get-orig-source targets that comply with the Debian Policy. Let me quote: | `get-orig-source' (optional) | This target fetches the most recent version of the original | source package from a canonical archive site (via FTP or WWW, for | example), does any necessary rearrangement to turn it into the | original source tar file format described below, and leaves it in | the current directory. | | This target may be invoked in any directory, and should take care | to clean up any temporary files it may have left. | | This target is optional, but providing it if possible is a good | idea. Note that there is a disagreement what does "the most recent version" mean [1]. Therefore, I didn't actually check if get-orig-source downloads the correct version, but merely if it downloads tarballs into the current directory. Here are preliminary results: a) 12424 packages didn't have g-o-s targets; b) 928 packages had g-o-s targets and passed all my tests; c) 15 packages call interactive programs (like lynx); d) 21 packages unnecessarily call dh_testroot; accidentally, all of these packages put tarballs in a wrong directory; e) 327 packages put .orig.tar.gz in the ../tarballs/ directory; f) 368 packages use uscan without --destdir (or even with "--destdir ../") [2]; g) 100 packages (+ many more of the above categories) try to access files in ./debian/ directory, and thus fail when g-o-s is run in a different than usual directory; this includes packages using uscan with "--destdir ." [2]; h) I need to further investigate 422 more packages (out of which at least 134 create .orig.tar.gz in a wrong directory). If there is consensus, I'll post dd-lists for some of the above categories (except a, b and h, of course) and start mass bug-filling soon. [1] http://bugs.debian.org/466550 [2] For those who want to improve their g-o-s targets, here's a makefile fragment that appears to work: MAKEFILE = $(firstword $(MAKEFILE_LIST)) SOURCE_DIR = $(dir $(MAKEFILE))/.. .PHONY: get-orig-source get-orig-source: cd $(SOURCE_DIR) && \ uscan --rename --force-download --destdir $(CURDIR) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: get-orig-source: possible MBF
* Ben Finney , 2009-10-16, 10:08: c) 15 packages call interactive programs (like lynx); Does your test determine whether this usage is actually invoking the programs interactively? e.g. ‘lynx -dump $URL’ is not interactive. I determined failure reasons by manually grepping through logs. There were no cases of legitimate lynx/links/elinks use. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
MBF: embedded copies of Python modules
zope.testing (U) zope2.10 (U) zope2.11 (U) Jelmer Vernooij bzr (U) Michael Vogt smart Rob Weir bzr (U) Jonathan Wiltshire rednotebook Alexander Zangerl duplicity Bernd Zeimetz ipython (U) pywbem (U) zope2.10 (U) zope2.11 (U) Enrico Zini turbogears (U) -- Jakub Wilk signature.asc Description: Digital signature
Re: install-info changes
* Brian May , 2009-11-17, 12:30: [...] WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! install-info (due to sed) 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 258kB disk space will be freed. You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!' ?] ^C [...] Why does apt-get want to remove sed? Doesn't dpkg satisfy the depends? It wants to remove install-info, not sed. -- Jakub Wilk signature.asc Description: Digital signature
Re: Little endian /usr/share/locale/* files in epiphany-browser-data
* Neil Williams , 2009-01-20, 20:59: > Perhaps we could have a tool converting .mo files from one endianess to > the other and ship the two versions in epiphany-browser-data, Well, either msgfmt should be able to produce both or a special tool is required. The later would be easier as this tool may fix the location at the same time. msgfmt can do this already with --endian but it needs the original PO file which is in the source package. msgunfmt can uncompile .mo files. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512518: ITP: jbig2enc -- a JBIG2 encoder
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: jbig2enc Version : 0.27 Upstream Author : Adam Langley * URL : http://www.imperialviolet.org/jbig2.html * License : Apache License, Version 2.0 Programming Lang: C Description : a JBIG2 encoder JBIG2 encodes bitonal (1 bpp) images using a number of clever tricks to get better compression than G4. This encoder can: * generate JBIG2 files, or fragments for embedding in PDFs, * generic region encoding, * perform symbol extraction, classification and text region coding, * perform refinement coding and, * compress multipage documents. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (900, 'unstable'), (500, 'experimental') Architecture: i386 (i686) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#460103: ITP: python-pipeline -- iterator pipelines for Python
Package: wnpp Severity: wishlist Owner: Jakub Wilk <[EMAIL PROTECTED]> * Package name: python-pipeline Version : 0.1.1 Upstream Author : Jakub Wilk <[EMAIL PROTECTED]> * URL : http://python-pipeline.googlecode.com/ * License : GPL Programming Lang: Python Description : iterator pipelines for Python python-pipeline provides an easy way to construct pipelines of iterators, with a syntax resembling Unix shell. It supplies counterparts for some common command-line utilities: cat, cut, echo, grep, head, nl, sort, split, tail, uniq, wc, yes. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (500, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=pl_PL (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash -- Jakub Wilk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#566485: ITP: uncertainties -- transparent calculations with uncertainties on the quantities involved
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: uncertainties Version : 1.2.2 Upstream Author : Eric O. LEBIGOT * URL : http://pypi.python.org/pypi/uncertainties/ * License : GPLv2 Programming Lang: Python Description : transparent calculations with uncertainties on the quantities involved uncertainties is a Python module, which allows calculations such as (0.2 +/- 0.01)*2 = 0.4 +/- 0.02 to be performed transparently; much more complex mathematical expressions involving numbers with uncertainties can also be evaluated transparently. -- Jakub Wilk signature.asc Description: Digital signature
Re: override LDFLAGS with debhelper 7
* Simon Richter , 2010-02-27, 17:12: However, there's some packages using another method: override_dh_auto_configure: dh_auto_configure -- LDFLAGS="$(LDFLAGS) -Wl,--as-needed" NOTE: this method doesn't work ! That depends on the autoconf version. Earlier versions require an environment variable, later ones accept variables as arguments as well. It might be an interesting idea to have debhelper work around old configure scripts by exporting anything that looks like a variable definition on the configure command line. No, that would be silly. There's already too much magic behind debhelper these days. -- Jakub Wilk signature.asc Description: Digital signature
Re: Bug#540215: Introduce dh_checksums
* Peter Samuelson , 2010-03-09, 08:21: [Frank Lin PIAT] Why is that everyone seems to move away from MD5? That's the $64000 question, isn't it? There seems to be this knee-jerk reaction to all things md5, "OH NOES, MD5 is broken! Therefore it must be replaced in every possible use, never mind whether any particular use has anything to do with malicious attackers." Strange that rsync seems to have escaped this madness, nobody has been frantically calling for it to migrate to something more "up to date" than MD4. Which, IIRC, is just as "broken". I guess the masses must have realized, in a way they usually do not, that sometimes an integrity check is just an integrity check. FYI: $ zgrep MD5 /usr/share/doc/rsync/changelog.gz - Protocol 30 now uses MD5 checksums instead of MD4. That said, I totally agree with you. -- Jakub Wilk signature.asc Description: Digital signature
Re: Symbols from C++ templates and ABI versioning
* Christoph Egger , 2010-03-11, 19:31: Currently irrlicht released a new minor version which I want to upload to debian. Concerning the ABI the only relecvant change is the removal of 4 symbols which are template instantiations. I can, of course, force instantiation of these templates but that feels quite like a hack. Does someone with deeper insight into that topic know if just having that ABI change causes some potential harm or whether I can just go ahead ignoring it? [Disclaimer: I'm neither a shared libraries expert, nor a C++ expert. The following text is based only on my shallow knowledge and a couple of experiments.] If we are very rigid, then unfortunately it is possible that some programs/libraries are already using these symbols and having them gone is an ABI breakage. But then we are doomed anyway: it is also possible that some symbols will disappear after a simple recompilation, just because compiler decided to inline more stuff than previously. So, going back to reality: If we can assume some level of sanity, i.e.: - these templates are fully defined within the library headers (in all versions using the same SONAME); - all software is actually using the library headers; then it *looks* like that gcc will never generate binaries with the symbols in question undefined. Thus, it would be safe ignore disappearance of them. Side note #1: According to dpkg-gensymbols(1), “A symbol marked as optional can disappear from the library at any time and that will never cause dpkg-gensymbols to fail. […] most of C++ template instantiations fall into this category.” Now let's merely define “most”… Side note #2: I have the impression that maintaining shared libraries is a poorly understood topic for most upstreams *and* for most DD. However I also believe that we have some people within the project who are very knowledgeable about that. It is therefore sad that we lack good and properly maintained documentation on that matter. -- Jakub Wilk signature.asc Description: Digital signature
Re: Source format 3.0 (quilt) and new debhelper dh syntax (maint-guide)
* Bernhard R. Link , 2010-03-22, 18:34: I am talking about new style debian/rules: --- %: dh --with patch $@ --- That is missing some .PHONY: binary binary-arch binary-indep clean build build-arch build-indep line (I hope dh supports build-arch and build-indep, not yet looked). Without that make does not know those are phony, and will not run if any of those files already exist. Except that .PHONY doesn't play nice with %-patterns. -- Jakub Wilk signature.asc Description: Digital signature
Bug#579398: ITP: openfst -- weighted finite-state transducers library
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: openfst Version : 1.1 Upstream Author : Cyril Allauzen, Michael Riley * URL : http://www.openfst.org/ * License : Apache License, v.2.0 Programming Lang: C++ Description : weighted finite-state transducers library OpenFst is a library for constructing, combining, optimizing, and searching weighted finite-state transducers (FSTs). Weighted finite-state transducers are automata where each transition has an input label, an output label, and a weight. The more familiar finite-state acceptor is represented as a transducer with each transition's input and output label equal. Finite-state acceptors are used to represent sets of strings (specifically, regular or rational sets); finite-state transducers are used to represent binary relations between pairs of strings (specifically, rational transductions). The weights can be used to represent the cost of taking a particular transition. -- Jakub Wilk signature.asc Description: Digital signature
Bug#579401: ITP: pyopenfst -- Python bindings for the OpenFst library
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: pyopenfst Version : (not released yet) Upstream Author : Thomas Breuel, David Huggins-Daines * URL : http://code.google.com/p/pyopenfst/ * License : Apache License 2.0 Programming Lang: C++ Description : Python bindings for the OpenFst library The OpenFST library implements algorithms on weighted finite state transducers. The PyOpenFST project contains bindings for the library. -- Jakub Wilk signature.asc Description: Digital signature
Re: Libreadline6 is GPLv3: incompatible with GPLv2-only software
* James Y Knight , 2010-04-28, 11:32: One of those (#553741) was filed against CLisp, which is licensed under GPLv2-only. Unfortunately, readline is under the GPLv3+ as of version 6, so making that change is impossible to do legally. It's not the first time license change in a library triggers an incompatibility: http://bugs.debian.org/512776 -- Jakub Wilk signature.asc Description: Digital signature
Re: Libreadline6 is GPLv3: incompatible with GPLv2-only software
* Neil Williams , 2010-04-28, 17:48: After checking a scattering of random packages, I happened across one example of this already in Debian testing: socat. It is GPLv2-only, and is linked against GPLv3 libreadline6 in testing. (filed bug 579494). Umm: http://packages.debian.org/changelogs/pool/main/s/socat/current/copyright This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. I would assume that's rather a mistake in debian/copyright. README is very clear: | This program is free software; you can redistribute it and/or modify | it under the terms of the GNU General Public License as published by | the Free Software Foundation, version 2 of the License -- Jakub Wilk signature.asc Description: Digital signature
Bug#581244: ITP: poliqarp -- utilities for large corpora processing
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: poliqarp Version : 1.3.9 (yet to be released) Upstream Author : Jakub Wilk et al. * URL : http://poliqarp.sourceforge.net/ * License : GPLv2 Programming Lang: C Description : suite of utilities for large corpora processing Poliqarp is a universal suite of utilities for large corpora processing. The concordancer supports corpora morphosyntactically tagged with positional tagsets, deals with ambiguities in annotation, has a rich query language, is independent of the tagset and can process corpora of several hundred million words. -- Jakub Wilk signature.asc Description: Digital signature
Re: debian/watch problem due to http://code.google.com download page's link format change
* Asias He , 2010-05-15, 17:16: Recently, code.google.com changed the download page link format. As a result, the old debian/watch file in packages whose upstream source code hosted on code.google.com did work anymore. [...] The new download page contain the "detail" link, one has to follow the new "detail" link in order to find the real download url. something like this: http://code.google.com/p/ibus/downloads/list http://code.google.com/p/ibus/downloads/detail?name=ibus-1.3.3.tar.gz&can=2&q= http://ibus.googlecode.com/files/ibus-1.3.3.tar.gz I believe this problem affects all the packages whose upstream source code is hosted on code.google.com. Is there an easy way to deal this. Yes, there is (for some values of "easy"): http://bugs.debian.org/581622#10 -- Jakub Wilk signature.asc Description: Digital signature
Bug#584555: ITP: pdfminer -- PDF parser and analyzer
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: pdfminer Version : 20100424 Upstream Author : Yusuke Shinyama * URL : http://www.unixuser.org/~euske/python/pdfminer/ * License : MIT Programming Lang: Python Description : PDF parser and analyzer PDFMiner is a tool for extracting information from PDF documents. Unlike other PDF-related tools, it focuses entirely on getting and analyzing text data. PDFMiner allows to obtain the exact location of texts in a page, as well as other information such as fonts or lines. It includes a PDF converter that can transform PDF files into other text formats (such as HTML). It has an extensible PDF parser that can be used for other purposes instead of text analysis. -- Jakub Wilk signature.asc Description: Digital signature
Re: Bindv6only once again
* Bastian Blank , 2010-06-12, 11:01: In netbase 4.38, Marco d'Itri has unilaterally decided to change the value of the net.ipv6.bindv6only sysctl to 1. This change has the following effects: (1) it violates POSIX 2008, Volume 2, Section 2.10.20; (2) it violates RFC 3493, Section 5.3; (3) it breaks software that is written to comply to POSIX, most notably Sun's Java. Please start with "fixing" the FreeBSD kernel. It only supports this mode of operation. http://lists.debian.org/debian-devel/2010/04/msg00256.html -- Jakub Wilk signature.asc Description: Digital signature
Re: Autobuilding non-free packages?
* Russ Allbery , 2010-06-12, 18:56: Is the system described in: http://lists.debian.org/debian-devel-announce/2006/11/msg00012.html still in place? Or is it currently necessary to manually build non-free packages on their supported platforms? AFAIUI, the latter. (Or is there some other system now in place that replaces that one?) Something new is emerging, but it's not quite ready. -- Jakub Wilk signature.asc Description: Digital signature
Re: A lot of pending packages
* Neil Williams , 2010-06-15, 08:50: What about if Debian QA packages were all to be deemed suitable for DM upload, including those which have been orphaned for over 2 months without a change of maintainer? Maybe when an orphaned package is uploaded with the change of maintainer to Debian QA, the DM upload field could also be set? If a package is neglected, it is *harder* (sometimes way harder) to maintain, which makes it *less* suitable for DMs. I consider QA/adoption uploads without DD assistance unacceptable. -- Jakub Wilk signature.asc Description: Digital signature
Bug#594209: ITP: rst2texinfo -- reStructuredText to Texinfo converter
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: rst2texinfo Version : 0.2 Upstream Author : Jon Waltman * URL : http://bitbucket.org/jonwaltman/rst2texinfo * License : “the same license as the Docutils project” Programming Lang: Python Description : reStructuredText to Texinfo converter rst2texinfo is an extension of the Docutils text processing system which adds support for generating Texinfo. -- Jakub Wilk signature.asc Description: Digital signature
Re: /usr/share/info/dir.gz if install-info is installed
* Cyril Brulebois , 2010-09-14, 12:00: So this is to let you know, to remove this package in order to avoid further problems :) packages really ought to build if that package is installed… Should these kind of bugs (FTBFS or producing broken packages in non-clean environment) be considered RC? There are other packages, besides install-info, that are known to be disruptive for build process: - graphicsmagick-libmagick-dev-compat is very likely to break packages linking to imagemagick; - pythonX.Y-minimal can break packages that autodetects existence of Python. -- Jakub Wilk signature.asc Description: Digital signature
Re: Is a bug RC relevant if it has an influence on the health of a person
* Goswin von Brederlow , 2010-09-11, 19:46: Because you are a reportbug novice. Novices are not allowed to play with severity of bugs. :) I consider this a horrible misfeature of reportbug. Yes, we need RC bugs from novices, too. -- Jakub Wilk signature.asc Description: Digital signature
Re: /usr/share/info/dir.gz if install-info is installed
* Bernhard R. Link , 2010-09-15, 17:05: As this is not really a new problem and easy to check for, I'm more surprised that is not yet catched by lintian. It is: package-contains-info-dir-file. And it's even on ftp-master's autoreject list. -- Jakub Wilk signature.asc Description: Digital signature
Re: [RFC] Binary packages containing the source
* Hector Oron , 2010-09-15, 21:26: c) allow build depends on source packages, which it is probably a worst idea. On the contrary, I think that allowing source packages to be installable in the same way as binary packages is an excellent idea. Imagine you can do: apt-get install src:linux-2.6 which will install Linux sources into a standard location, or upgrade it if it's already installed. Incidentally, this will allow to trivially implement data packages[0]: a dummy binary package could depend on its own source package. [0] http://wiki.debian.org/DataPackages -- Jakub Wilk signature.asc Description: Digital signature
Re: [RFC] Binary packages containing the source
* Goswin von Brederlow , 2010-09-22, 11:39: apt-get install linux-2.6:src where "src" is just another architecture (at least for the user interface). apt-get install foo:src should then install the source and also all Build-Depends(-Indep) of the source. Besides packages Build-Depending on source packages this is also verry usefull for working on sources. The foo:src package will be marked manual while all Build-Depends remain automatic. When one is done working with a source one can purge foo:src and all the Build-Depends can be autoremoved if nothing else needs them. For the latter problem, you may find sourcedeps.debian.net useful: http://blog.djpig.de/2007/09/08 -- Jakub Wilk signature.asc Description: Digital signature
Re: Oops: I broke the lenny --> squeeze update
* Steve M. Robbins , 2010-11-22, 01:08: I just received notice (bug 603579) that upgrade lenny to squeeze will break if a boost package containing an "rtupdate" script is installed. In stable there are four such packages: libboost-python-dev libboost-dbg libboost-python1.35-dev libboost1.35-dbg The issue is that the rtupdate script in stable only recognizes python 2.4 and python 2.5, and dies if any other version is supplied. Squeeze python default is 2.6 and so this blocks the upgrade of python, which is very bad. The rtupdate script has since been changed (in unstable) to avoid this problem, but I'm not sure what can be done for stable users other than recommending to purge the above four packages prior to upgrade. Is there any way to do this automatically? Python maintainers can make python2.6-minimal break (or conflict, if breaking is not enough) the old libboost* packages. Please test if Breaks/Conflicts will help here, and if it does, file a bug against python2.6-minimal requesting such addition. -- Jakub Wilk signature.asc Description: Digital signature
Re: Untrusted search path vulnerabilities
* Mike Hommey , 2010-11-18, 12:17: A number of packages in the archive sets the PYTHONPATH environment variable in an insecure way. They do something like: PYTHONPATH=/spam/eggs:$PYTHONPATH This is wrong, because if PYTHONPATH were originally unset or empty, current working directory would be added to sys.path. I wonder if this class of vulnerabilities (inc the LD_LIBRARY_PATH ones) could be automatically warned about by lintian. This is bug #451559. I guess it will be tricky to implement reliably. I wonder if this wouldn't be our duty to remove the possibility of these vulnerabilities at all. Who relies on these PATH variables features to include the current directory instead of adding "." ? Why don't we fix python, ld.so and other stuff doing the same such that empty entries are skipped ? http://seclists.org/oss-sec/2010/q3/446 I don't know if "next stable release" means squeeze or wheezy here. IMO it's too late for such changes for squeeze. -- 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/20101122134515.ga6...@jwilk.net
Re: Introducing the "Debian's Automated Code Analysis" (DACA) project
* Raphael Geissert , 2010-12-16, 12:00: Automated Code Analysis helps detect and fix bugs and other issues in source code. The project aims to give users easy access to a wide variety of tools to improve quality of software distributed by Debian, while giving the tool's developers a test bed, more visibility, and more feedback. This is achieved by running those tools on the complete Debian archive. Sounds great, thanks for your work on this! the list of tools to be evaluated and possibly included goes over twenty. Do you have any particular tools in mind? Most of the tools are CPU-bound, limiting considerably the number of tools and time it takes to check the whole Debian archive. For example, with the typical sid repository update (i.e. not during the freeze and with a working ftp-master) it is impossible for the server running cppcheck to keep up with all the changes. I don't see this as a big problem. I'd find DACA useful even if test results were updated, say, monthly. -- Jakub Wilk signature.asc Description: Digital signature
Re: Introducing the "Debian's Automated Code Analysis" (DACA) project
* Wouter Verhelst , 2010-12-20, 13:56: = How can you help? = * First of all you can go and squash bugs! This would be greatly simplified if there was a way for a random packager to easily figure out if the DACA tools has found something in their packages. Most other tools that do per-package statistics (such as, say, lintian.d.o) provide such a page. Also, it would be nice if we could avoid showing links to pages that only say "Failed to parse xml" (whatever that means...) or "No issues found!". -- 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/20101220130409.ga...@jwilk.net
Re: Full install/removal/upgrade test results available
* Mike Hommey , 2010-11-19, 09:18:
Mike Hommey
python-xpcom (U)
I /think/ this could be solved by not using a pre-depends on
xulrunner-1.9.1.
Indeed.
OTOH, the pre-depends solves a part of another problem though not
entirely, due to triggers ordering: the xulrunner-1.9.1 trigger can't
work until the python-support trigger has been run...
I don't see how pre-depends could have helped here. On the first glance
it makes it only worse. E.g., when I install python-xpcom in a clean
chroot I get:
| Unpacking python-xpcom (from .../python-xpcom_1%3a0.0~hg20100212-2_i386.deb)
...
| Processing triggers for xulrunner-1.9.1 ...
| Obtaining the module object from Python failed.
|
| : No module named xpcom.server
| Obtaining the module object from Python failed.
|
| : No module named xpcom.server
When I moved ${xulrunner:Depends} from Pre-Depends to Depends,
everything was registered just fine.
The only fix for that issue that I can think of would be to stop using
python-support... If other people have ideas, I'm all ears.
I think you could manually trigger xulrunner-1.9.1 in python-xpcom's
postinst if it's not already registered. See the attached patch (well,
except maybe xulrunner version shouldn't be hardcoded).
--
Jakub Wilk
diff -u pyxpcom-0.0~hg20100212/debian/control pyxpcom-0.0~hg20100212/debian/control
--- pyxpcom-0.0~hg20100212/debian/control
+++ pyxpcom-0.0~hg20100212/debian/control
@@ -18,8 +18,8 @@
Provides: ${python:Provides}
Depends: ${shlibs:Depends},
${misc:Depends},
- ${python:Depends}
-Pre-Depends: ${xulrunner:Depends}
+ ${python:Depends},
+ ${xulrunner:Depends}
Breaks: epiphany-gecko (<< 2.28)
XB-Python-Version: ${python:Versions}
Description: XPCOM bindings for Python
diff -u pyxpcom-0.0~hg20100212/debian/postinst pyxpcom-0.0~hg20100212/debian/postinst
--- pyxpcom-0.0~hg20100212/debian/postinst
+++ pyxpcom-0.0~hg20100212/debian/postinst
@@ -9,2 +9,7 @@
+if ! grep -F '@mozilla.org/module-loader/python;' /usr/lib/xulrunner-1.9.1/components/compreg.dat > /dev/null
+then
+ dpkg-trigger /usr/lib/xulrunner-1.9.1/components
+fi
+
#DEBHELPER#
Re: Full install/removal/upgrade test results available
* Mike Hommey , 2010-12-21, 20:59: I think you could manually trigger xulrunner-1.9.1 in python-xpcom's postinst if it's not already registered. See the attached patch (well, except maybe xulrunner version shouldn't be hardcoded). I'd expect that to fail as well, because of python-support trigger not having been run yet. Part of the problem is that the xulrunner-1.9.1's postinst or trigger can run with python-xpcom unpacked but not registered with python-support. Adding update-python-modules -p in python-xpcom postinst could make things slightly better, "update-python-modules -p" is already in python-xpcom's postinst and it does exactly what python-support trigger would do. but that would still leave xulrunner-1.9.1's postinst complaining if it's run before python-xpcom's. Unfortunately, this is true. -- 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/20101221204154.ga3...@jwilk.net
Re: Bug#608910: ITP: osc-source_validator -- osc source validator
* Michal Čihař , 2011-01-04, 16:26: * Package name: osc-source_validator Underscores are not allowed in package names. -- 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/20110104155138.ga8...@jwilk.net
Re: DEP5: CANDIDATE and ready for use in squeeze+1
* Lars Wirzenius , 2011-01-09, 14:00: [3] http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?rev=153&sc=0 If you are interested, please give the spec a quick read. If you find any real problems, it is not too late to get them fixed. Let me see: | Example: | | Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 | Upstream-Name: SOFTware | Upstream-Contact: John Doe | Source: http://www.example.com/software/project r135 is quite an old version (and, in fact, this snippet doesn't even follow the r135 syntax). -- Jakub Wilk signature.asc Description: Digital signature
Bug#612694: ITP: scanmonitord -- scanner button daemon
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: scanmonitord Version : 1.2.6 Upstream Author : Simon Matter * URL : http://www.invoca.ch/pub/packages/scanmonitord/ * License : GPLv2+ Programming Lang: C, bash Description : scanner button daemon Scanmonitord is a daemon which runs device monitors on one or more devices. Every button or sensor event is then evaluated by user generated action scripts which can itself call whatever system command they want. For postprocessing scanned images, scanmonitord has the ability to start image processing scripts as daemons which can automate additional actions like OCR on scanned images by user defined scripts. (The above description was copied verbatim from upstream README. The actual package description will be likely different.) -- 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/20110210003211.ga9...@jwilk.net
Re: Bug#612694: ITP: scanmonitord -- scanner button daemon
* Simon Paillard , 2011-02-10, 16:02: Description : scanner button daemon Scanmonitord is a daemon which runs device monitors on one or more devices. [...] I'm curious (and you might want to add it to the description): does this tie in with modern desktop systems via DBUS or whatever, or is this a standalone thing? It's a standalone thing. What is the difference with scanbuttond ? http://packages.debian.org/sid/scanbuttond scanmonitord supports my pet scanner; scanbuttond does not. Or more generally, scanmonitord queries scanner via SANE. -- 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/20110210153329.ga8...@jwilk.net
Re: RFA: all my packages
* Vincent Fourmond , 2011-02-11, 10:05: I'd say there should be no place in Debian in 2011 for software that can't do UTF-8, especially if near-identical forks exist. That would make a nice addition to the policy, wouldn’t it? So long as it is not a MUST, else I have a feeling we'll find many many packages RC... *cough* #139861 -- 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/20110211093231.ga2...@jwilk.net
Re: Make Unicode bugs release critical? (was: Re: RFA: all my packages)
* Ian Jackson , 2011-02-14, 12:42: Kicking out software that doesn?t work at all in UTF-8 locales and requires the user to set a broken locale, OTOH, sounds like a sanitary emergency. Excellent, I look forward to the removal of python. I always hated that language anyway. $ LC_CTYPE=en_GB.utf-8 python -c 'print u"\u00a3"' $ But $ LC_CTYPE=en_GB.utf-8 python -c 'print u"\u00a3"' | cat Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in position 0: ordinal not in range(128) $ This is the expected behaviour. Incidentally, it has nothing to do with UTF-8. You'll get the same result if you use a locale with a legacy encoding. -- 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/20110214131425.ga4...@jwilk.net
Re: OT: Python (was: Make Unicode bugs release critical?)
* Klaus Ethgen , 2011-02-14, 14:37:
~> LC_CTYPE=en_GB.utf-8 perl -e 'print "\x{00a3}\n";'
~> LC_CTYPE=en_GB.utf-8 perl -e 'print "\x{00a3}\n";' | cat
Let me try...
$ LC_CTYPE=en_GB.utf-8 perl -e 'print "\x{00a3}\n";' | isutf8
stdin: line 1, char 1, byte offset 1: invalid UTF-8 code
But I don't blame Perl for that. It's documented behavior, so I can
either live with that or use another language.
--
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/20110214143302.ga6...@jwilk.net
Re: how come the buildd machines can't find python-vtk?
* Steve M. Robbins , 2011-02-17, 21:27: I uploaded insighttoolkit the other day, but the buildd machines refuse to build it, claiming an installability problem [1]: insighttoolkit/alpha dependency installability problem: insighttoolkit (= 3.20.0-8) build-depends on one of: - python-vtk (= 5.4.2-8) I *think* the problem is that python-vtk is temporarily uninstallable due to the FFmpeg transition: http://lists.debian.org/debian-release/2011/02/msg00079.html -- 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/20110218102752.ga1...@jwilk.net
Re: maintainer ignores bug
* Osamu Aoki , 2011-02-27, 02:50: I've filed a bug on reportbug, but its maintainer ignores it, No maintainer did not ignore it. He responded reasonably. He did not. Declaring "it's not a bug in my package" without even trying to diagnose the problem is not only unreasonable but also rude. One should not report bug to the wrong package. Yes, ideally one should also be omniscient... -- 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/20110226184117.ga7...@jwilk.net
Re: prepare to fix build failures with new GCC versions
* Raphael Hertzog , 2011-02-28, 16:01: symbols which should not be used can either be not listed in the symbols file (and be auto-added at build time with a strict dependency on the latest version) or be referenced in the symbols file but with an alternate dependency (either one that is unsolvable or one that is very strict in terms of version allowed). It'd nice if dpkg-gensymbols could generated such an alternate dependency automatically for all symbols that are tagged optional. -- 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/20110228155902.ga5...@jwilk.net
Re: new Contents generator on ftp-master
* Torsten Werner , 2011-03-12, 11:01: 2) The encoding in proper UTF-8. ISO8859-1 filenames are re-coded automatically. To find out what happens to other encodings is left as an exercise to the reader. :) What's the point of messing with encodings? 5) Packages with duplicate filenames are marked just as such and no contents is recorded, e.g. DUPLICATE_FILENAMES text/inorwegian,text/wnorwegian Shouldn't dak reject debs with duplicate filenames in the first place? Anyway, both packages are just fine (AFAICT). Reporting them as having duplicate filenames looks like a side effect of encoding mangling: $ dpkg -c inorwegian_2.0.10-3.2_i386.deb | grep -v /$ | tr -s ' ' | cut -d' ' -f 6 | sort | uniq -c 1 ./usr/lib/ispell/bokm\303\245l.aff 1 ./usr/lib/ispell/bokm\303\245l.hash 1 ./usr/lib/ispell/bokm\345l.aff 1 ./usr/lib/ispell/bokm\345l.hash 1 ./usr/lib/ispell/bokmaal.aff 1 ./usr/lib/ispell/bokmaal.hash 1 ./usr/lib/ispell/nb.aff 1 ./usr/lib/ispell/nb.hash 1 ./usr/lib/ispell/nn.aff 1 ./usr/lib/ispell/nn.hash 1 ./usr/lib/ispell/norsk.aff 1 ./usr/lib/ispell/norsk.hash 1 ./usr/lib/ispell/nynorsk.aff 1 ./usr/lib/ispell/nynorsk.hash 1 ./usr/share/doc/inorwegian/README.Debian 1 ./usr/share/doc/inorwegian/changelog.Debian.gz 1 ./usr/share/doc/inorwegian/copyright 1 ./var/lib/dictionaries-common/ispell/inorwegian $ dpkg -c wnorwegian_2.0.10-3.2_all.deb | grep -v /$ | tr -s ' ' | cut -d' ' -f 6 | sort | uniq -c 1 ./usr/share/dict/bokm\303\245l 1 ./usr/share/dict/bokm\345l 1 ./usr/share/dict/bokmaal 1 ./usr/share/dict/norsk 1 ./usr/share/dict/nynorsk 1 ./usr/share/doc/wnorwegian/changelog.Debian.gz 1 ./usr/share/doc/wnorwegian/copyright 1 ./var/lib/dictionaries-common/wordlist/wnorwegian -- 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/20110312133712.ga6...@jwilk.net
Bug#520108: ITP: libpam-alreadyloggedin -- PAM module to skip password authorization if user is already logged in
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: libpam-alreadyloggedin Version : 0.3 Upstream Author : Ilya Evseev * URL : http://ilya-evseev.narod.ru/posix/pam_alreadyloggedin/ * License : BSD Programming Lang: C Description : PAM module to skip password authorization if user is already logged in This pluggable authentication module (PAM) allows you to skip authorization stuff (like password entering, etc.), if you are already logged in on the another console. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (900, 'unstable'), (500, 'experimental') Architecture: i386 (i686) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition of initscripts to new order / sequence number
* Steve Langasek , 2009-03-21, 17:07: I know some package maintainers handle this by ignoring the existence of file-rc and just removing symlinks directly in /etc/rcX.d/. As long as file-rc exist and is supposed in Debian, I believe it is a bad idea. :( It seems to me that it would be a lot less effort to fix this by removing file-rc in Debian, which has only a handful (137) of popcon reports. Even if we take into consideration that popcon isn't a good source of absolute numbers, this comes out to .2% of popcon reports that we're spending this effort on, and for what benefit? Benefit of having an abstraction layer. Keep in mind that lost of users will not install file-rc, even if it is superior to sysv-rc, because: - sysv-rc is the default. - They never heard that alternatives to sysv-rc exist. - They never had to fiddle with runlevels, so they don't known what a nuisance it is with sysv-rc. - If you try to install file-rc, apt displays a big red warning which suggests that you are doing something utterly wrong. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Consistent formating long descriptions as input data
* Andreas Tille , 2009-04-26, 22:55: I tried to format a single paragraph according to some URL I found but thie does not really work without a header[3]. [...] [3] http://code.activestate.com/recipes/193890/ That's quite overcomplicated. The following code should do the thing: from docutils.core import publish_parts def reSTify(string): return publish_parts(string, writer_name='html')['body'] -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
* Simon Josefsson , 2009-05-11, 12:55: +1 for ssmtp I found ssmtp couldn't cope with mail my various systems were generating, something about fixed maximum buffer lengths from memory. Please not ssmtp. If I recall it correctly I found no way to get it to send mail to a exim-based smarthost via TLS in a sane way. What about msmtp? http://msmtp.sourceforge.net/ AFAIK msmtp does not support local mail delivery. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
* Simon Josefsson , 2009-05-11, 15:06: What about msmtp? http://msmtp.sourceforge.net/ AFAIK msmtp does not support local mail delivery. I suspect that is part of the design goal of msmtp. Local mail delivery can be handled by other tools, can't it? Generally, it seems like a good idea to separate these two separate tasks into different tools. Well, if anybody knows how to couple msmtp with an MDA, I'd be glad to see a solution. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531028: ITP: hg-git -- git plugin for Mercurial
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: hg-git Version : (not released yet) Upstream Author : Scott Chacon * URL : http://hg-git.github.com/ * License : GPLv2 Programming Lang: Python Description : Git plugin for Mercurial Th Hg-Git plugin for Mercurial adds the ability to push and pull to/from a Git server repository. This means you can collaborate on Git based projects from Mercurial, or use a Git server as a collaboration point for a team with developers using both Git and Mercurial. The plugin can convert commits/changesets losslessly from one system to another, so you can push via a Mercurial repository and another Mercurial client can pull it and their changeset node ids will be identical - Mercurial data does not get lost in translation. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532629: ITP: gmic -- GREYC's Magic Image Converter
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: gmic Version : 1.3.0.2 Upstream Author : David Tschumperle * URL : http://gmic.sourceforge.net/ * License : CeCILL License, version 2.0 Programming Lang: C++ Description : GREYC's Magic Image Converter G'MIC is an interpreter of image processing macros whose goal is to convert, manipulate and visualize generic 1D/2D/3D multi-spectral image files. This includes classical color images, but also more complex data as image sequences or 3D volumetric images. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Search for porterbox machines on the command line
* Jon Bernard , 2014-06-13, 14:48: I just created a small utility that dumps the porterbox machine list to stdout, which makes looking up a test machine for a particular architecture much quicker (at least for me). I wasn't aware of anything like this in existence, please correct me if I'm wrong. I've been using this: https://bitbucket.org/jwilk/debian-misc/src/default/list-porterboxes ISTR someone blogging about yet another similar utility. Output looks like: Architecture Hostname Access armel abel.debian.org public kfreebsd-amd64 asdfasdf.debian.net public (non-DSA-machine) amd64 barriere.debian.org restricted The Access column is kinda meaningless... (I know, not your fault.) -- 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/20140613185635.ga4...@jwilk.net
Re: improving downloader packages (was: Re: holes in secure apt)
* Christoph Anton Mitterer , 2014-06-16, 19:50: Thomas mentioned that things would have been more secure if the buildds and e.g. pbuilder pulls in debian-keyring automatically and verify maintainer signatures. debian-keyring is not useful for automatic authentication of source packages. The source package could have been signed years ago by a person who is no longer a DD. Or signed with a key that has been just replaced with another one. Or signed with a key that's not yet shipped in the package. Incidentally, this is how I discovered this bug. A friend of mine (hi, Marcin!) wondered how he can authenticate a source package that was signed by a key that is not included in debian-keyring. I ensured him that there's nothing to worry about, as apt takes care of this, but he remained skeptical[0]. So I started playing with mitmproxy... [0] And his skepticism was reinforced by (independent) discovery of this bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738 -- 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/20140616181439.ga...@jwilk.net
Re: HTTPS everywhere!
* Simon McVittie , 2014-06-17, 13:20: It should be possible to make a CA certificate that is only considered to be valid for the spi-inc.org and debian.org subtrees, and then trust the assertion that SPI control that certificate - but in widely-used applications, that isn't possible. In theory, the Name Constraints extension should allow one to achieve what you said: http://tools.ietf.org/html/rfc5280#section-4.2.1.10 No idea how well it is supported, though. -- 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/20140617123427.ga5...@jwilk.net
Re: sofftware outside Debian (Re: holes in secure apt)
* Holger Levsen , 2014-06-18, 12:46: usually one should depend on a fixed hash in such downloader packages... doing it with gpg is securely possible, but much more complicated. and then for each update you need to update the launcher package - thats an aweful lot of work for little / no gain Yes, maintaining packages properly takes time. If packaging new upstream releases is too much effort, why bother uploading it to Debian in the first place? It find the way flashplugin-nonfree currently works absolutely scandalous. It's non-NMU-able, and non-auditable. (and how do you handle downgrade attacks here?). There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; * apt refusing to install an older version of a package, unless specifically asked to do so; * security advisories and stable release announcements. -- 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/20140618115532.ga5...@jwilk.net
Future of Developer's Reference
Somewhere in another universe, someone proposed moving Developer's Reference to the wiki. One of the arguments was that it would let you make changes _quickly_. I'm shamelessly :-P disclosing a message in this thread: * Stefano Zacchiroli , 2014-06-18, 13:39: Right. But do we really want that kind of work-flow for a document like the Developers Reference? Granted, the process for publishing changes to the devref does not need to be as formal/onerous as the Policy process itself, but personally I wouldn't feel comfortable in following Debian development "best practices" found in a document that might have been changed, with all due respect, by a random stranger. To be comfortable in following the devref, I personally need to know that there is at least *some* maintenance process behind it, implemented by experienced fellow DDs. If the current process is getting in the way of motivated contributors that want to co-maintain the devref, let's change it. But please do not err on the extreme of making everyone in the world a devref maintainer. -- 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/20140618120859.ga7...@jwilk.net
Re: software outside Debian (Re: holes in secure apt)
* Christoph Anton Mitterer , 2014-06-22, 04:34: There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; I still think the time spans are far too long here... For the record, the validity periods currently are: unstable, experimental: 7 days testing: 7 days wheezy: no limit wheezy(-proposed)-updates: 7 days wheezy/updates at security.d.o: 10 days wheezy-backports: 7 days squeeze: no limit squeeze(-proposed)-updates: 7 days squeeze/updates at security.d.o: 10 days squeeze-lts: 7 days I agree than they could be shorter (particularly the security.d.o ones raised my eyebrows), but I'm not going to lose sleep over it. can someone please tell me against what I could report a bug (i.e. politely ask for enhancement by making the time span much smaller)? My guesses would be: "reportbug ftp.debian.org" for unstable and experimental; "reportbug release.debian.org" for testing, (old)stable and their (proposed-)updates; team@security.d.o for the security.d.o archive; debian-lts@lists.d.o for squeeze-lts. -- 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/20140623124258.ga7...@jwilk.net
Re: software outside Debian (Re: holes in secure apt)
* Adam D. Barratt , 2014-06-23, 14:24: * Christoph Anton Mitterer , 2014-06-22, 04:34: There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; I still think the time spans are far too long here... For the record, the validity periods currently are: [...] can someone please tell me against what I could report a bug (i.e. politely ask for enhancement by making the time span much smaller)? My guesses would be: "reportbug ftp.debian.org" for unstable and experimental; "reportbug release.debian.org" for testing, (old)stable and their (proposed-)updates; team@security.d.o for the security.d.o archive; debian-lts@lists.d.o for squeeze-lts. Those are all dak configuration, so controlled by ftpmaster. I don't doubt it. :-) What I doubt is that ftp-masters would be willing to alter the configuration without blessing of the respective teams. But I could be wrong, of course. -- 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/20140623170043.gb6...@jwilk.net
Re: How to avoid stealth installation of systemd?
* Juliusz Chroboczek , 2014-07-01, 15:25: I filed bug 753357 Why is this bug marked as fixed in systemd/204-9? -- 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/20140701160343.ga4...@jwilk.net
Re: Essential binaries and Pre-Depends on libraries
* Ansgar Burchardt , 2014-07-04, 13:26: essential binaries have to work also when the package is in an unpacked, but not configured, state. For that reason, packages including essential binaries use Pre-Depends on the shared libraries needed by those binaries. However, from my reading of policy I get the impression that this still leaves an open issue: the transitive dependencies. See bug #593177. -- 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/20140704113719.ga6...@jwilk.net
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
* The Wanderer , 2014-07-04, 12:00: Zurg (Jessie+1), Has that name actually been formalized in any way? No. But no worries, if RT chooses a different name, we'll have a GR to override them. :-P -- 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/20140704162226.ga1...@jwilk.net
Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters
* Adam Borowski , 2014-07-06, 21:04:
I see some legitimate scenarios for a single package to have something
both in $X/bin and $X/sbin, but not really across package boundaries.
These are deliberate:
* safe-rm ships /usr/bin/rm;
* molly-guard ships /usr/sbin/{halt,poweroff,reboot,shutdown}
* elvis-tiny ships /bin/vi (like other vi clones, it also installs an
alternative for /usr/bin/vi)
Would you call them “legitimate” or not?
--
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/20140706221915.ga1...@jwilk.net
Re: possible MBF: automatically detecting unused build dependencies
* Johannes Schauer , 2014-07-09, 16:50: ==> llvm-toolchain-3.4_3.4.1-4.arch-all.unusedbd.real <== automake=1:1.14.1-3 autotools-dev=20140510.1 diffstat=1.58-1 doxygen=1.8.7-1 flex=2.5.39-7 lcov=1.10-1 libtool=2.4.2-1.7 patchutils=0.3.3-1 procps=1:3.3.9-5 sharutils=1:4.14-2 tcl=8.6.0+8 texinfo=5.2.0.dfsg.1-3 No, building with DEB_BUILD_OPTIONS=codecoverage enables at least some of them, should build dependencies which the source package only requires after setting some DEB_BUILD_OPTIONS go into Build-Depends? Probably not, unless it's one of the optioned blessed by Policy §4.9.1. :-) and applying patches might require the autotools to be re-run, so I think lots of the requirements are sane. My naive assumption was that the Build-Depends line contains a list of binary packages needed to build the package. Not binary packages that might be needed in some situations during the lifetime of a source package? Agreed. But here I'd recommend regenerating auto* stuff unconditionally, rather than dropping the build-dependencies. -- 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/20140710104536.gb5...@jwilk.net
Re: people.debian.org will move from ravel to paradis and become HTTPS only
* Martin Zobel-Helas , 2014-07-13, 22:13: The plan is to execute a final sync of home directories on 2014-JUL-26 starting at 0800Z. http://xkcd.com/1179/ we will change the people.debian.org web-service such that only HTTPS connections will be supported (unencrypted requests will be redirected). This is great news. Thanks! :-) -- 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/20140713203139.ga9...@jwilk.net
Let's shrink Packages.xz
Food for thought: Which fields take up most space in Packages.xz[0]? (whole file) 6662.0 KiB 100.0% SHA256 1463.8 KiB 22.0% SHA1938.9 KiB 14.1% Description-md5 794.3 KiB 11.9% MD5sum 752.4 KiB 11.3% Depends 473.0 KiB7.1% Description 463.4 KiB7.0% Filename338.9 KiB5.1% Homepage183.1 KiB2.7% Tag 176.1 KiB2.6% Size168.3 KiB2.5% Maintainer 161.3 KiB2.4% Installed-Size 144.6 KiB2.2% Package 134.5 KiB2.0% Version 73.4 KiB1.1% Suggests 68.9 KiB1.0% Recommends 63.7 KiB1.0% [0] More precisely: for each field, how much would Packages.xz shrink if we removed this (and only this) field? -- 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/20140714162547.ga3...@jwilk.net
Re: Let's shrink Packages.xz
* Peter Palfrader , 2014-07-14, 20:25: The basic idea is that it's much harder to come up with a simultaneoush hash collision with both SHA-1 and SHA-2 than breaking either of them independently. ISTR reading papers that put this "much harder" into doubt. But I can't find those references, alas. You might have had this paper in mind: https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf Quoting §4: “If F and G are good iterated hash functions with no attack better than the generic birthday paradox attack, we claim that the hash function F||G obtained by concatenating F and G is not really more secure that F or G by itself.” -- 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/20140714191714.ga4...@jwilk.net
Re: people.debian.org will move from ravel to paradis and become HTTPS only
* Tollef Fog Heen , 2014-07-20, 08:47: Would you be happy with http://people.debian.org/THIS-IS-INSECURE/YES-I-WANT-TO-PROCEED/~user/file as the URLs? No need to be condescending. :-( Also, I wouldn't say “insecure”, which might be vague in this context. My proposal: http://nohttps.people.debian.org/~user/file -- 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/20140720100359.ga6...@jwilk.net
Re: myth(?): places in the world where https is illegal? Re: people.debian.org will move from ravel to paradis and become HTTPS only
* Jacob Appelbaum , 2014-07-21, 13:09: I'm also curious - is there a Debian developer who will not use HTTPS but does use SSH to access servers? Very unlikely, with or without the “but …” part. (But I'm afraid I don't understand what point you're trying to make.) Is Debian still offering telnet services too? I don't think so. What other unsafe protocols are standard and in use? Off the top of my head: e-mail, FTP, LDAP, IRC. (assuming that “unsafe” means “with no (or nonmandatory) encryption”) -- 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/20140721165251.ga4...@jwilk.net
Re: people.debian.org will move from ravel to paradis and become HTTPS only
* Peter Palfrader , 2014-07-20, 12:07: we have been moving towards https for most services over the last 12 months. Is that intentional that the http->https redirect for bugs.d.o is only temporary (302)? Should we update devscripts and python-debianbts to use HTTPS for accessing this host? Do you plan to enable HTTPS on incoming.d.o and lintian.d.o? -- 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/20140721174418.ga9...@jwilk.net
Re: people.debian.org will move from ravel to paradis and become HTTPS only
* Agustin Martin , 2014-07-28, 13:06: This can actually lead to a weird behavior for users. In a system having something under people.debian.org in apt sources.list and apt-transport-https not installed, in today's testing upgrade, $ sudo apt-get update [...] E: The method driver /usr/lib/apt/methods/https could not be found. N: Is the package apt-transport-https installed? $ sudo apt-get install apt-transport-https Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: apt-transport-https 0 upgraded, 1 newly installed, 0 to remove and 275 not upgraded. Need to get 132 kB of archives. After this operation, 221 kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! apt-transport-https Install these packages without verification? [y/N] E: Some packages could not be authenticated I can't reproduce it here. I do get the “method driver /usr/lib/apt/methods/https could not be found” error message. But, as one would expect, it doesn't have any effect on authentication of the packages from the main archive. But if the authentication troubles are really related to the HTTP->HTTPS switch, then it's a bug in apt that should be fixed. -- 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/20140730202607.ga6...@jwilk.net
Re: people.debian.org will move from ravel to paradis and become HTTPS only
* Jakub Wilk , 2014-07-30, 22:26: * Agustin Martin , 2014-07-28, 13:06: This can actually lead to a weird behavior for users. In a system having something under people.debian.org in apt sources.list and apt-transport-https not installed, in today's testing upgrade, $ sudo apt-get update [...] E: The method driver /usr/lib/apt/methods/https could not be found. N: Is the package apt-transport-https installed? $ sudo apt-get install apt-transport-https Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: apt-transport-https 0 upgraded, 1 newly installed, 0 to remove and 275 not upgraded. Need to get 132 kB of archives. After this operation, 221 kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! apt-transport-https Install these packages without verification? [y/N] E: Some packages could not be authenticated I can't reproduce it here. Scratch that. I reproduced it. Sorry for the noise. -- 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/20140730202924.gb6...@jwilk.net
Re: people.debian.org will move from ravel to paradis and become HTTPS only
* Jakub Wilk , 2014-07-30, 22:26: WARNING: The following packages cannot be authenticated! apt-transport-https Install these packages without verification? [y/N] E: Some packages could not be authenticated [...] But if the authentication troubles are really related to the HTTP->HTTPS switch, then it's a bug in apt that should be fixed. Filed as #756614. -- 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/20140731112609.ga7...@jwilk.net
Re: Bug#756325: CVE-2014-5044: gfortran integer overflows
Hi Matthias, I am very saddened with your mail. This is an unacceptable communication style. Your fellow developers deserve a little bit more respect. In the future please send argumenta ad hominem to /dev/null, not to the BTS, and not to any Debian mailing list. -- 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/20140801104047.ga1...@jwilk.net
Re: First steps towards source-only uploads
* Kurt Roeckx , 2014-08-01, 22:58: Build binary packages as usual, but sed-out _(amd64|i386).deb from resulting .changes before signing it. Please also make sure you rename the changes files to not conflict with the .changes files the buildd is going to use. Can we fix dak not to care about names of *.changes? These names are not cryptographically signed, so they shouldn't be trusted anyway. -- 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/20140801215149.ga8...@jwilk.net
Re: Time to drop debcheck on optional/extra and arch:all?
* Neil Williams , 2014-08-10, 12:31: The distinction between optional and extra is commonly ignored and yet debcheck continues to add reports to the PTS about packages which have dependencies which crossover from optional into extra. Do you mean the "debcheck" link in the "links" box? Or is there another place where debcheck pops out on PTS that I can't see? Do we care about any distinction between optional and extra any longer? I like "extra". If it was used in a policy-compliant way, it would be more useful than "standard", "important" or "required". But if we decide to kill it, I'm not going to cry over it. However, I don't think we should take any decision before we understand what is the problem size. That is, what is the number of packages that would have to have their priority adjusted to make all extra<->optional priority inversions go away? I assume that would be mostly s/extra/optional/ changes. A QA nag tool which is so commonly ignored is possibly not even worth running. Being wildly ignored is a common property of all QA tools... And the tool popularity doesn't depend only on the quality of its checks, but also on the way the results are delivered to maintainers. debcheck is never going to be successful if the maintainer has to find the link in the PTS jungle, and then they are presented with something as concise as this: https://qa.debian.org/debcheck.php?dist=unstable&package=awesome To add insult to injury, most likely the maintainer can't do much about the reported problems themselves, because they should be fixed by ftp-masters and maintainers of the dependent packages. -- 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/20140810195025.ga7...@jwilk.net
Re: Standardizing the layout of git packaging repositories
* Charles Plessy , 2014-08-17, 19:39: for suites that are never released, I think that it is fine to not use the codename. Otherwise, people will be confused with debian/rc-buggy. FWIW, "rc-buggy" is not the codename for experimental: $ wget -q -O- http://http.debian.net/debian/dists/experimental/Release | grep -m1 ^Codename: Codename: experimental See also bug #704124. -- 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/20140818121655.ga6...@jwilk.net
Re: Bug#759762: ITP: libz-mingw-w64 -- compression library (targeting Windows)
* Stephen Kitt , 2014-08-30, 03:55: I'm packaging this to allow Python to build its Windows executables, and also to test Colin Watson's idea of using apt-get during builds in lieu of full-blown source build-dependencies. You can't do that. Packages must mot access outside world at the build time. -- 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/20140831171014.gb3...@jwilk.net
Re: Two-minute(!)-survey on motivation and free time contribution of open source developers
* Bálint Réczey , 2014-08-31, 19:03: Here is the link to the survey: https://de.surveymonkey.com/s/MFKXYLP [...] I would happily take this survey if I could do it without enabling JavaScript on the page. FWIW, the survey worked for me in ELinks, which doesn't do JavaScript. -- 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/20140831174401.ga6...@jwilk.net
Re: Removing < 2048 bit keys from the Debian keyrings
* Jonathan McDowell , 2014-08-31, 04:31: Please sign responsibly[4], [...] [4] http://xkcd.com/364/ Do you have any non-joke documentation about signing responsibly? -- 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/20140831200905.gc6...@jwilk.net
Re: Bug#759762: ITP: libz-mingw-w64 -- compression library (targeting Windows)
* Philipp Kern , 2014-08-31, 12:09: I'm packaging this to allow Python to build its Windows executables, and also to test Colin Watson's idea of using apt-get during builds in lieu of full-blown source build-dependencies. You can't do that. Packages must mot access outside world at the build time. This is not enforced yet, though, It's now enforced in pbuilder. Also in Jakub's sbuild. :-P I believe that it's indeed not enforced on buildds, which is a shame. and might actually be different if we are talking about mirror accesses. For instance d-i also builds that way if I don't misremember. (Specifying a fallback mirror, though, I guess, which then requires proper internets.) Just look at this beautiful code: http://sources.debian.net/src/debian-installer/20140802/build/util/gen-sources.list.udeb/ (Just kidding. It's not beautiful. Don't even try reading it without having large amounts of eyebleach in reserve.) So yeah, d-i can't be built automatically without access to a mirror. Which is a bug, and not an easy one to fix. Let's admit for the moment that d-i is spethial, and don't use it as excuse for introducing more such weirdness into the archive. -- 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/20140831204320.ga9...@jwilk.net
Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
* Ritesh Raj Sarraf , 2014-09-01, 16:20: cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wunused -Wstrict-prototypes -fPIC -DLIB_STRING=\"lib\" -DLIBDM_API_FLUSH -D_GNU_SOURCE -DLIBDM_API_COOKIE -DUSE_SYSTEMD=208 -c -o uxsock.o uxsock.c uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory #include ^ compilation terminated. ../Makefile.inc:57: recipe for target 'uxsock.o' failed make[2]: *** [uxsock.o] Error 1 I fixed this one by adding a build-dep to systemd dev library. But for some reason, the build is failing on all architectures. But the same builds fine in my pbuilder. Any help ?? The error is: | dh_install: multipath-tools missing files (/usr/lib/systemd/system/*), aborting | make: *** [install] Error 2 Upstream build system uses systemctl(1) to decide whether or not build with systemd support enabled. Unsurprisingly, systemctl does not exist in buildd chroots. You should either add "systemd" to build-depends, or fix the build system to be less non-deterministic. -- 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/20140901112420.ga2...@jwilk.net
Re: Bug#758234: Raising priority of Debian packages
* Russ Allbery , 2014-08-31, 09:08: If we want, as a project, to monitor the size of the required, important, and standard sets, I feel like we should do that directly: run a cron job somewhere that remembers the previous size, calculates the new transitive closure, and mails out a report once a week or month or something listing which packages were added or removed and their sizes, as well as the total installed size of each of those sets. I think that would be more effective and more directly on point than mucking about with trying to monitor priority changes. Yes, that would be a good idea. We should probably also monitor package conflicts. We made a big fuss about node vs nodejs (and rightly so); but I bet that we have lots of other package pairs in the archive that can't be co-installed for no good reason. -- 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/20140904193554.ga3...@jwilk.net
Re: Bug#758234: Raising priority of Debian packages
* Paul Wise , 2014-09-07, 17:38: We should probably also monitor package conflicts. We made a big fuss about node vs nodejs (and rightly so); but I bet that we have lots of other package pairs in the archive that can't be co-installed for no good reason. We have this already: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=edos-file-overwrite;users=trei...@debian.org https://qa.debian.org/dose/file-overwrites.html Nah, I meant packages that do declare that they can't be co-installed. -- 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/20140907105153.ga5...@jwilk.net
Bug#760615: general: Shell scripts do not execute in gui.
* Tomas Pospisek , 2014-09-06, 21:06: Open a terminal and in the terminal write the following: cd /tmp echo "#!/bin/sh" > foobar echo "touch foobar.touched" >> foobar chmod +x foobar This is not a secure way to use /tmp. -- 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/20140908094258.ga8...@jwilk.net
Re: systemd, again (Re: Cinnamon environment now available in testing)
* Josselin Mouette , 2014-09-08, 10:58: Excuse me? Are you trying to use the fact that you and your stupid friends are trolling about systemd all day long in order to justify your own rants? And I thought you couldn’t get any lower. You have a very good shovel. OTOH, a hydraulic excavator must have been involved in writing your mail. Can we now all go back to the ground level? (Or higher?!) -- 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/20140908101219.ga...@jwilk.net
Re: Trimming priority:standard
* Josh Triplett , 2014-09-12, 00:55: - gettext-base. Supports internationalized shell scripts; anything using this depends on it, and nothing in standard or above does. select-editor uses it: #728612 (I can't fathom why this tool exists in the first place.) -- 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/20140912081115.ga7...@jwilk.net
Re: ppc64 not in any-powerpc ?
* Mathieu Malaterre , 2014-09-12, 14:03: I could not find the answer anywhere. Why is arch:ppc64 not in the `any-powerpc` definition ? I would have guessed arch:ppc64 to be very close to arch:powerpc... any means "any OS", not "any arches for this hardware" https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec No, "any" means "it's confusing". :-P Thanks all. I got confused with `wine` package which was built on x32 Because any-amd64 matches x32. (I kid you not.) and powerpcspe, Because any-powerpc matches powerpc. I guess those were forced by the uploaders. I don't think so. -- 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/20140912121708.ga2...@jwilk.net
Re: Trimming priority:standard
* Theodore Ts'o , 2014-09-12, 13:12: It's inevitable that systemd will subsume cron, with an incompatible configuration file format. :-) I'm looking forward for systemd-mta. -- 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/20140912171850.ga8...@jwilk.net
