Re: problematic shlibs entry in substvars file
[Whoops, forgot to send on list]
On 15/01/2013 15:48, Paul Johnson wrote:
> To create the shlibs dependency, I think dpkg-shlibdeps is reading
> files in /var/lib/dpkg/info. I can't find any "2.7" associated with
> libc6-amd in there.
>
> And, if libc6-amd is really the i386 version of the C library supplied
> on mutiarch systems, I don't really understand why the package is
> trying to depend on it at all.
I believe that dpkg-shlibdeps checks in these places:
- /var/lib/dpkg/info/*.shlibs
- /etc/dpkg/shlibs.{default,override}
Could you grep libc6-amd64 in these places? That should provide a hint as to
where this dependency is coming from.
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signature
Bug#698209: ITP: librarian-puppet -- a bundler for your puppet infrastructure
Package: wnpp Severity: wishlist Owner: Stig Sandbeck Mathisen * Package name: librarian-puppet Version : 0.9.7 Upstream Author : Tim Sharpe * URL : https://github.com/rodjek/librarian-puppet * License : MIT Programming Lang: Ruby Description : a bundler for your puppet infrastructure Librarian-puppet is a bundler for your puppet infrastructure. You can use librarian-puppet to manage the puppet modules your infrastructure depends on. It is based on Librarian, a framework for writing bundlers, which are tools that resolve, fetch, install, and isolate a project's dependencies. Librarian-puppet manages your modules/ directory for you based on your Puppetfile. Your Puppetfile becomes the authoritative source for what modules you require and at what version, tag or branch. Once using Librarian-puppet you should not modify the contents of your modules directory. The individual modules' repos should be updated, tagged with a new release and the version bumped in your Puppetfile. -- 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/20130115082742.27214.33417.report...@dagon.fnord.no
Bug#698210: ITP: ruby-librarian -- a framework for writing bundlers
Package: wnpp Severity: wishlist Owner: Stig Sandbeck Mathisen * Package name: ruby-librarian Version : 0.0.26 Upstream Author : Jay Feldblum * URL : https://github.com/yfeldblum/librarian * License : MIT Programming Lang: Ruby Description : a framework for writing bundlers Librarian is a framework for writing bundlers, which are tools that resolve, fetch, install, and isolate a project's dependencies, in Ruby. Librarian ships with Librarian-Chef, which is a bundler for your Chef-based infrastructure repositories. In the future, Librarian-Chef will be a separate project. A bundler written with Librarian will expect you to provide a specfile listing your project's declared dependencies, including any version constraints and including the upstream sources for finding them. Librarian can resolve the spec, write a lockfile listing the full resolution, fetch the resolved dependencies, install them, and isolate them in your project. A bundler written with Librarian will be similar in kind to Bundler, the bundler for Ruby gems that many modern Rails applications use. -- 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/20130115082746.26918.11060.report...@dagon.fnord.no
Bug#698212: ITP: gnomediaicons -- network icons scheme for Dia
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: gnomediaicons Version : 0.1 Upstream Author : Thiago Ribeiro ribeiro.it at gmail * URL : http://sf.net/projects/gnomediaicons * License : GPL Programming Lang: other Description : network icons scheme for Dia gnomeDIAicons is a package with a network icons scheme based on Gnome Gorilla's theme. . The purpose of this project is generate beauty icons to Dia program and provide a raise in its utilization against MS Visio. . I hope it can be useful for many people. I'll provide others schemes too, but at first only network scheme was made. -- 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/20130115090830.21225.51659.report...@lirispat.univ-lyon1.fr
Re: Retrieving source package from repository without touching sources.list?
On 15 January 2013 04:46, Nikolaus Rath wrote: > # fancy-dget http://http.debian.net/debian/ experimental mypackage > > would download the newest mypackage source from experimental. Bonus > points if messing with the system wide sources.list is avoided entirely > and no root privileges are required. > It's called pull-debian-source $ pull-debian-source mypkg $ pull-debian-source mypkg experimental $ pull-debian-source mypkg 0.2.3-3.2 It uses the archive & snapshots to pull in historical versions. >From the ubuntu-dev-tools package available in stable and up. There is also equivalent pull-lp-source with same arguments to pull ubuntu packages instead of debian. I haven't seen similar tool for other derivatives. Regards, Dmitrijs. -- 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/canbhlugu9hxkqxbsv1+m4gqf0vcprnuph2kakrnys2mz5+i...@mail.gmail.com
Re: Packages with incomplete .md5sum files
[Holger Levsen] > Hi Andreas, > > On Donnerstag, 10. Januar 2013, Andreas Beckmann wrote: > > Hi, > > > > the following packages from wheezy ship files that are excluded from > > the .md5sums file: > > > > gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/.gacl > > gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/gridsitefoot.txt > > gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/gridsitehead.txt [...] > those I'd file with severity "important" - sure it's a policy violation, > surely it's bad, Policy violation? Where? I don't see anything about 'md5sums' in Policy. -- 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/20130115092337.gq4...@p12n.org
Re: Packages with incomplete .md5sum files
On Mon, Jan 14, 2013 at 13:10:24 +0100, Holger Levsen wrote: > this I'd probably file as serious, not having checksums for files in /usr > seems worse. But then, the same reasoning as for the above bugs applies, so > maybe important is better after all. > There's no requirement for md5sums files in the first place AFAIK. How are incomplete md5sums worse than no md5sums? If anything this stuff should be minor IMO. Cheers, Julien signature.asc Description: Digital signature
Re: Packages with incomplete .md5sum files
On 2013-01-15 10:29 +0100, Julien Cristau wrote: > There's no requirement for md5sums files in the first place AFAIK. How > are incomplete md5sums worse than no md5sums? If there is no md5sums file, dpkg (as of version 1.16.3) creates it at unpack time. Cheers, Sven -- 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/87hami22yh@turtle.gmx.de
Re: idea -- apt-based init daemon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013-01-15 10:49, hhm wrote: > Hope this helps! http://m.mediapost.com/publications/13/No-Cookies-A22.jpg (this is one of the most obvious cases of "please show the code" I have seen to date) - -- brother http://sis.bthstudent.se -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQ9S0xAAoJEJbdSEaj0jV7ob4IAKs2EOwG3DoAwbLQvPCGTbKa I6CZWYEttC2LBU3jqQicna9L+s8iXcKOuQhMNx9K6xX3m5x5x0KRFCYpqDEPhyfS 9/4CWnCUMmsuIdPsFbZgNIBnkaT0teB0zFz/+fQZdyZynlepz8EDmpzRvoePQ678 SYJsYD+Cjg85Kdx9aWOrujVVFCk2NqcflGEi9/8uk6Ssn3YMsaQw5G8C9+JikCJ2 RxZRc316ueGB6/ZEA7TMM5QH/2dbIhQGC+N/mfz2Gzm3rpIfHSXY1iHls/6CF9ED A0s5WHfMg1luq6HPOlMku2epoHEBOuEWIfNGyqTam38hFwduKZmBlzvjOMVU+qU= =17K9 -END PGP SIGNATURE- -- 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/50f52d32.4050...@bsnet.se
Re: Packages with incomplete .md5sum files
On 2013-01-15 10:29, Julien Cristau wrote: > There's no requirement for md5sums files in the first place AFAIK. How > are incomplete md5sums worse than no md5sums? If anything this stuff > should be minor IMO. If a package is shipping no .md5sum at all, it will be created by dpkg at installation time. A partial .md5sum however will not be "completed". This hides some shipped files from debsums, defeating its purpose. I'm pretty sure modifying *any* shipped files in the maintainer scripts should be forbidden, although I didn't find a policy reference for this (this is made explicit for conffiles, what about "normal" files?). Packages violating this and hiding the fact by excluding the modified files from .md5sums ... should be fixed. Andreas -- 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/50f52d38.1010...@abeckmann.de
Re: Retrieving source package from repository without touching sources.list?
On Tue, Jan 15, 2013 at 5:19 PM, Dmitrijs Ledkovs wrote: > It's called pull-debian-source Sounds like something that should be moved into devscripts. -- 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/CAKTje6G_SvHd-MHn-eE6bHcaUL4nsPqZSw43=34=13ulbcf...@mail.gmail.com
Re: package.debian.org
Hi, I still have problem with debbugs mail server, i could not test report bug via email. Any body can help me setting mail server of debbugs, please :( And how to check if the setting is succeed or not. Thank you very much and best regards, lochd On 1/9/2013 6:10 PM, Josselin Mouette wrote: Hi, Le mercredi 09 janvier 2013 à 17:33 +0700, lochd a écrit : Hi, My name is Loc. I'm investigating about debian website systems. I already could get data of bugs tracking system and webwml. But i cannot get source code of package.debian.org from any where. So, could i have it's source code? http://packages.debian.org/about/ Cheers, -- Hoang Duc Loc (Mr) Toshiba Software Development(Viet Nam) Co, Ltd Add : 16th Floor,519 Kim Ma Str , Ba Dinh Dist , Ha Noi Tel : 04-2220 8801 - Ext : 135 Fax : 04-2220 8802 Email :lo...@tsdv.com.vn Note: This e-mail message may contain personal information or confidential information. If you are not the addressee of this message, please delete this message and kindly notify the sender as soon as possible, do not copy, use, or disclose this message. -- 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/50f53030.1010...@tsdv.com.vn
Re: Retrieving source package from repository without touching sources.list?
Hi Paul (2013.01.15_12:42:54_+0200) > > It's called pull-debian-source > Sounds like something that should be moved into devscripts. It uses Launchpad to authenticate packages without having to fetch and read Packages and InRelease itself, so it probably couldn't go into devscripts as-is. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- 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/20130115104907.gh1...@bach.rivera.co.za
Re: Packages with incomplete .md5sum files
On Tue, Jan 15, 2013 at 11:19:36 +0100, Andreas Beckmann wrote: > I'm pretty sure modifying *any* shipped files in the maintainer scripts > should be forbidden, although I didn't find a policy reference for this > (this is made explicit for conffiles, what about "normal" files?). > Packages violating this and hiding the fact by excluding the modified > files from .md5sums ... should be fixed. > I'm not saying they shouldn't be fixed, just that IMO the missing md5sum is minor. Cheers, Julien signature.asc Description: Digital signature
Re: idea -- apt-based init daemon
hhm writes: > As is well known, init daemons in distros the distro-world over are > replacing sysvinit. > > As far as I can tell, among the reasons for this phenomena is: > 1) to take advantage of parallel processing > 2) to work better with event-based systems (linux kernel etc.) > > Sysvinit was created in the age of synchronous computing systems, and > it reflects this. Now systems are becoming more asynchronous. > > The way these things are addressed is often: > 1) a dependency system > 2) an event trigger system > > Well, does those two things sound familiar, by any chance :-)? > > Apt manages dependencies, and processes triggers. It was created for > managing software packages... > > ...maybe it can be augmented with functionality to manage software services > too! Is it first of April again? I haven't even noticed! This idea violates the KISS-principle. -- CYa, ⡍⠁⠗⠊⠕ -- 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/87libu5xoj@fx.delysid.org
Bootstrappable Debian - proposal of needed changes
Hi, the following is an email written by Wookey and myself. 0. Introduction === The Debian bootstrap build ordering tool Google Summer of Code project [1] was continued even after the summer ended and recently reached a new milestone by being able to create a final build order from a dependency graph [2] for Debian Sid. By now, all important tools and algorithms have been written [5] to solve the following problems: - find source packages to which build profiles (reduced build dependencies) should be added - given enough source packages annotated with build profiles, generate a final build order which produces a full Debian archive from zero, starting from cross compiling a minimal system and natively compiling the rest, breaking build dependencies as necessary (and as possible) Since Debian source packages do not (yet) contain enough meta data to decide whether or not a build dependency can be dropped, USE flags of Gentoo source packages were harvested [3] [6]. On top of that, suggestions from Thorsten Glaser, Patrick McDermott and Daniel Schepler were used. This way, our current results are hopefully not too far away from reality, While the theoretical results do look consistent, this has so far not been completed in practice due to the following open issues: 1. missing multiarch annotations prevent the multiarch cross build dependencies of some source packages from being resolved correctly 2. not all source packages of the minimal build system are cross compilable in practice yet 3. no decision has been made on the syntax of the new control fields (build profiles) which are required for automated bootstrapping 4. not enough source packages implement build profiles (this depends on 3 being solved) More details on this scheme are given at the DebianBootstrap wiki page [8]. Work has been going on for a couple of years on this, evolving as practical experience was gained, and input taken from more people. We therefore make the following proposals (field names not set in stone) in descending order of importance for us: 1. Build-Profiles = The build profile format was proposed by Guillem Jover together with other solutions he presented in this document [7] as part of bug#661538. Build profiles extend the Build-Depends format with a syntax similar to architecture restrictions but using < and > instead. Build-Depends: huge (>= 1.0) [i386 arm] , tiny The build dependency "huge" would not be required by the source package if it is built in the "embedded" or "stage1" profile. This mechanism neatly allows for removed build-deps, replaced build-deps and added build-deps, and an arbitrary number of possible 'profiles'. Besides bootstrapping, these build profiles could also be used for embedded builds, and to allow for changed buil-deps when cross-building. One could also imagine that DEB_BUILD_OPTIONS=nodocs could be replaced by a profile called "nodocs". Patches for dpkg (bug#661538) and dose3 implementing this syntax already exist. This scheme supersedes an earlier version, (referred-to as 'staged' builds), which used repeated Build-depends-StageN: lines. See the dpkg bug#661538 for the evolution of this. The profile labels are arbitrary but agreement on label usage is necessary. For bootstrap automation we have been using 'stage1', 'stage2', etc which fits with existing custom in packages which already have such internal mechanisms using DEB_STAGE (currently gcc, eglibc, libselinux, gcj, gnat, gdc, linux [9]) These seem like sensible names so we propose to stick with them. Other useful profiles can be defined in the future. The drawback of this syntax is that Build-Dep parsing tools need to be updated to read/accept it, so uploads of source containing these annotations cannot be done until the dpkg in buildds at least parses it. 2. Build-Profiles (extension 1) === When a source package is built with fewer build dependencies (cross, embedded, stage1, nodocs...), then it often happens that it does not build one or more of its binary packages at all (e.g. foo-gtk, foo-java, foo-doc). While this is a minor nuisance during a half automated bootstrap, a fully automated bootstrapping process needs to know which binary packages a source package does not build if it is compiled in one of its profiles. We therefore propose a new field for binary packages in their control file which indicates for which profiles it builds. Builds-With-Profile: !stage1 !embedded Different profile names are separated by spaces similar to the Architecture field. A binary package with the above field would not be built during the profile builds "stage1" or "embedded". Binary packages which do not have this field would default to being built by every profile. This field would mean a minor change to dpkg-gencontrol. 3. Build-profiles (extension 2) === A build profile is set either using a DEB_ environ
Bug#698233: ITP: pajeng -- visualization tool for the analysis of parallel applications
Package: wnpp Severity: wishlist Owner: Martin Quinson * Package name: pajeng Version : 1.0 Upstream Author : Lucas Schnorr * URL : https://github.com/schnorr/pajeng * License : GPL v3 Programming Lang: C++ Description : visualization tool for the analysis of parallel applications PajeNG (Paje Next Generation) is a re-implementation (in C++) and direct heir of the well-known Paje visualization tool for the analysis of execution traces (in the Paje File Format) through trace visualization (space/time view). PajeNG comprises the libpaje library, the space-time visualization tool in pajeng and a set of auxiliary tools to manage Paje trace files (such as pj_dump and pj_validate). Note that this thus a reimplementation of paje.app, that is already packaged for debian -- 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/20130115183758.11850.79121.report...@alphonse.loria.fr
Re: Bug#698212: ITP: gnomediaicons -- network icons scheme for Dia
Hi Mathieu, On Dienstag, 15. Januar 2013, Mathieu Malaterre wrote: > The purpose of this project is generate beauty icons to Dia program and > provide a raise in its utilization against MS Visio. whoot! really about time! thanks for your work on this! cheers, Holger -- 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/201301152049.45751.hol...@layer-acht.org
Re: idea -- apt-based init daemon
On Tue, Jan 15, 2013 at 11:19:30AM +0100, Martin Bagge / brother wrote: > On 2013-01-15 10:49, hhm wrote: > > Hope this helps! > http://m.mediapost.com/publications/13/No-Cookies-A22.jpg > (this is one of the most obvious cases of "please show the code" I > have seen to date) When you show the code, please make sure to preface it with a "NSFW" warning. :-P -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#698238: ITP: viva -- Trace Visualization Tool
Package: wnpp Severity: wishlist Owner: Martin Quinson * Package name: viva Version : 1.0 Upstream Author : Lucas Schnorr * URL : https://github.com/schnorr/pajeng * License : GPL v3 Programming Lang: C++ Description : Trace Visualization Tool Viva is a tool used to analyze traces recorded during the execution of parallel or distributed applications. These traces should be formatted according to the Paje file format. Viva also serves as a sandbox to the development of new visualization techniques. . Current features include: * Temporal integration using dynamic time-intervals * Spatial aggregation through hierarchical traces * Interactive Graph Visualization with a force-directed algorithm, with viva * Squarified Treemap to compare processes behavior on scale, with vv_treemap -- 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/20130115200219.12245.44818.report...@alphonse.loria.fr
Re: Packages with incomplete .md5sum files
* Andreas Beckmann [130115 11:20]: > On 2013-01-15 10:29, Julien Cristau wrote: > > There's no requirement for md5sums files in the first place AFAIK. How > > are incomplete md5sums worse than no md5sums? If anything this stuff > > should be minor IMO. > > If a package is shipping no .md5sum at all, it will be created by dpkg > at installation time. > > A partial .md5sum however will not be "completed". This hides some > shipped files from debsums, defeating its purpose. That depends what the purpose is supposed to be. Having debsums by default create fake .md5sum files for packages not shipping them defeats the purpose md5sums is most useful for: to check that the files in your filesystem are correct and where not corrupted by faulty hardware. (As in my experience almost all of those problems happen when writing to the disk (by faulty memory, faulty busses, overheated mainboards or CPUs) and not to content on the disc itself). So while incomplete .md5sums are definitely not nice and worse then complete files, I do not see how that could be worse than not having any .md5sum files. Bernhard R. Link -- 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/20130115215008.ga3...@client.brlink.eu
Re: problematic shlibs entry in substvars file
On Tue, Jan 15, 2013 at 2:08 AM, Chow Loong Jin wrote:
> [Whoops, forgot to send on list]
>
> On 15/01/2013 15:48, Paul Johnson wrote:
>> To create the shlibs dependency, I think dpkg-shlibdeps is reading
>> files in /var/lib/dpkg/info. I can't find any "2.7" associated with
>> libc6-amd in there.
>>
>> And, if libc6-amd is really the i386 version of the C library supplied
>> on mutiarch systems, I don't really understand why the package is
>> trying to depend on it at all.
>
> I believe that dpkg-shlibdeps checks in these places:
> - /var/lib/dpkg/info/*.shlibs
> - /etc/dpkg/shlibs.{default,override}
>
> Could you grep libc6-amd64 in these places? That should provide a hint as to
> where this dependency is coming from.
>
Thanks for the advice. I don't see anything in there.
pauljohn@pjlap-124:dpkg$ pwd
/etc/dpkg
pauljohn@pjlap-124:dpkg$ grep -r libc *
pauljohn@pjlap-124:dpkg$
Those files are empty
pauljohn@pjlap-124:dpkg$ cat shlibs.default
# dpkg shlibs defaults file
#
# This file contains shlibs entries that are used as a last resort when
# no matching entries are found elsewhere. For more information see the
# dpkg-shlibdeps(1) manual page.
#
#
pauljohn@pjlap-124:dpkg$ cat shlibs.override
# dpkg shlibs override file
#
# Entries in this file will override all others, only use if you
# are really sure that is what you want!
#
# For more information see the dpkg-shlibdeps(1) manual page.
#
#
> --
> Kind regards,
> Loong Jin
>
--
Paul E. Johnson
Professor, Political Science Assoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org http://quant.ku.edu
--
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/caerodj85fxorfp4yd19+nufivazdkgw7cmczrptkbz94heh...@mail.gmail.com
Re: Packages with incomplete .md5sum files
On Tue, Jan 15, 2013 at 10:46:46 +0100, Sven Joachim wrote: > On 2013-01-15 10:29 +0100, Julien Cristau wrote: > > > There's no requirement for md5sums files in the first place AFAIK. How > > are incomplete md5sums worse than no md5sums? > > If there is no md5sums file, dpkg (as of version 1.16.3) creates it at > unpack time. > That sounds like a dpkg misfeature. Cheers, Julien signature.asc Description: Digital signature
Package version numbers
Hi, Neither my AM (Christian Perrier) nor myself are sure about the answer to this one, so he suggested I ask -devel for advice (and I'm throwing -mentors into the mix too). I've prepared an update for calibre, to fix a few issues in the package which is currently in Wheezy (see #686547 for details). The update involves repacking the original tarball, which was already repacked, and is an NMU. The version of calibre in Wheezy is 0.8.51+dfsg-1; what should the update's version be? I'm purposefully not mentioning our ideas (one of them is obvious from the exchanges in the bug report, but is in all likelihood incorrect). Thanks in advance, Stephen signature.asc Description: PGP signature
Re: Package version numbers
* Stephen Kitt , 2013-01-15, 23:27: The version of calibre in Wheezy is 0.8.51+dfsg-1; what should the update's version be? I'm purposefully not mentioning our ideas (one of them is obvious from the exchanges in the bug report, but is in all likelihood incorrect). I would paint the bikeshed the following color: 0.8.51+dfsg1-0.1 -- 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/20130115224434.ga7...@jwilk.net
Re: Bootstrappable Debian - proposal of needed changes
* Johannes Schauer , 2013-01-15, 19:18: Build profiles extend the Build-Depends format with a syntax similar to architecture restrictions but using < and > instead. Build-Depends: huge (>= 1.0) [i386 arm] , tiny [...] The drawback of this syntax is that Build-Dep parsing tools need to be updated to read/accept it, so uploads of source containing these annotations cannot be done until the dpkg in buildds at least parses it. Not only dpkg, but also wanna-build, sbuild, lintian, dak, and who knows what else... We've been historically very slow at adapting our software to these kind of changes: 1) Architecture wildcards were implemented in dpkg in January 2006. pbuilder added support for them in February... 2011. 2) Support for the :any qualifiers in Build-Depends was added to apt in February 2010, and to dpkg in March 2012; AFAIK it's still not supported by wanna-build. -- 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/20130115232653.ga8...@jwilk.net
Re: Bootstrappable Debian - proposal of needed changes
Le Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer a écrit : > > The build profile format was proposed by Guillem Jover together with > other solutions he presented in this document [7] as part of bug#661538. > Build profiles extend the Build-Depends format with a syntax similar to > architecture restrictions but using < and > instead. > > Build-Depends: huge (>= 1.0) [i386 arm] , tiny Hi Johannes, It looks to me that the above is trying to implement the equivalent of Recommends for build dependancies. "The Recommends field should list packages that would be found together with this one in all but unusual installations." Are you entirely sure that you need to distinguish between profiles, instead of having the source package build rules do the right things according to which recommended packages have been installed ? In that case, your example could be reduced to: Build-Depends: tiny Build-Recommends: huge (>= 1.0) 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/20130115235806.ga24...@falafel.plessy.net
Re: Bootstrappable Debian - proposal of needed changes
Charles Plessy wrote: >Le Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer a écrit : >> >> The build profile format was proposed by Guillem Jover together with >> other solutions he presented in this document [7] as part of bug#661538. >> Build profiles extend the Build-Depends format with a syntax similar to >> architecture restrictions but using < and > instead. >> >> Build-Depends: huge (>= 1.0) [i386 arm] , tiny > >Hi Johannes, > >It looks to me that the above is trying to implement the equivalent of >Recommends for build dependancies. "The Recommends field should list packages >that would be found together with this one in all but unusual installations." > >Are you entirely sure that you need to distinguish between profiles, instead of >having the source package build rules do the right things according to which >recommended packages have been installed ? In that case, your example >could be reduced to: > >Build-Depends: tiny >Build-Recommends: huge (>= 1.0) No, not at all. This discussion has happened before, and Build-Recommends has been suggested before. It's broken, leading to non-deterministic package builds and associated insanity. Explicit sets of profiles are an alternative that (it seems) are the new preferred way to do bootstrapping, and also other optional (but fully-specified) versions of packages. It's quite possible that it may be necessary to have several stage profiles, depending on how big a potential package loop you need to break. In this case, you'll need to have through to listed for that package. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews -- 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/e1tvghz-ls...@mail.einval.com
Re: Bootstrappable Debian - proposal of needed changes
On Wed, Jan 16, 2013 at 08:58:06AM +0900, Charles Plessy wrote: > Le Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer a écrit : > > The build profile format was proposed by Guillem Jover together with > > other solutions he presented in this document [7] as part of bug#661538. > > Build profiles extend the Build-Depends format with a syntax similar to > > architecture restrictions but using < and > instead. > > Build-Depends: huge (>= 1.0) [i386 arm] , tiny > Hi Johannes, > It looks to me that the above is trying to implement the equivalent of > Recommends for build dependancies. "The Recommends field should list > packages that would be found together with this one in all but unusual > installations." Recommends are totally useless for build-dependencies and this idea is a non-starter. Builds *must* be reproducible and *must not* rely on arbitrary variations in the build environment. The fundamental requirement for these profiles is for bootstrapping; we must have a guarantee that at each stage of the bootstrap, the output is well-formed to support the next stage of the bootstrap, and that at the *end* of the bootstrap the result is a complete package and not an arbitrary subset. > Are you entirely sure that you need to distinguish between profiles, > instead of having the source package build rules do the right things > according to which recommended packages have been installed ? Yes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#698256: ITP: lz4 -- Extremely Fast Compression algorithm library
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu * Package name: lz4 Version : 0.0.0 (svn r88) Upstream Author : Yann Collet * URL : http://code.google.com/p/lz4/ * License : BSD 2-Clause License Programming Lang: C Description : Extremely Fast Compression algorithm library LZ4 is a very fast lossless compression algorithm. This uses Dictionary compression, and only supports compression and decompression unit blocks. -- 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/20130116005121.12172.61568.reportbug@chimagu
Bug#698258: ITP: python-charade -- universal encoding detector for Python 2 and Python 3
Package: wnpp Severity: wishlist Owner: Daniele Tricoli * Package name: python-charade Version : 1.0.1 Upstream Author : Ian Cordasco * URL : https://github.com/sigmavirus24/charade * License : LGPL Programming Lang: Python Description : universal encoding detector for Python 2 and Python 3 python-charade is a port of Mark Pilgrim's chardet with support for both Python 2 and Python 3. Supported encodings: - ASCII, UTF-8, UTF-16 (2 variants), UTF-32 (4 variants) - Big5, GB2312, EUC-TW, HZ-GB-2312, ISO-2022-CN (Traditional and Simplified Chinese) - EUC-JP, SHIFT_JIS, ISO-2022-JP (Japanese) - EUC-KR, ISO-2022-KR (Korean) - KOI8-R, MacCyrillic, IBM855, IBM866, ISO-8859-5, windows-1251 (Cyrillic) - ISO-8859-2, windows-1250 (Hungarian) - ISO-8859-5, windows-1251 (Bulgarian) - windows-1252 (English) - ISO-8859-7, windows-1253 (Greek) - ISO-8859-8, windows-1255 (Visual and Logical Hebrew) - TIS-620 (Thai) The package will be maintained under the umbrella of the DPMT and it's a dependency for the new version (1.1.0) of python-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/20130116022920.8843.94193.report...@mornie.home
Re: problematic shlibs entry in substvars file
The version difference is probably due to symbols stuff, read deb-symbols(5), dpkg-shlibdeps(1), dpkg-gensymbols(1) and this wiki page: http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps No idea about the other stuff, you appear to have four copies of the C library installed and are maybe attempting multiarch cross-compilation, which isn't supported properly yet. -- 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/caktje6hpnzotscnayezgfdunihvgwvz+mxpg1gaz5uq3vky...@mail.gmail.com
Re: Bug#698256: ITP: lz4 -- Extremely Fast Compression algorithm library
On Wed, Jan 16, 2013 at 8:51 AM, Nobuhiro Iwamatsu wrote: > * Package name: lz4 > Description : Extremely Fast Compression algorithm library > > LZ4 is a very fast lossless compression algorithm. Is it faster than lzop? How does it compare to lzop, gzip, lzip, xz, bzip2 in terms of compression ratio? Please include that information in the package description. -- 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/caktje6e_sutku679gx6aqxm314ak7bt3hxxhenkau9lkhkc...@mail.gmail.com
Re: Bootstrappable Debian - proposal of needed changes
Thanks a lot for your work on this! and to everyone else who worked on or shaped the proposal. On Wed, Jan 16, 2013 at 2:18 AM, Johannes Schauer wrote: > - should Debian be bootstrappable in a fully automated fashion? We >created the algorithms that can allow this to happen, we just need >more meta data and a way to encode it That sounds useful, so yes. arm64 is on the way, it would be a nice test case but I guess wookey/Sledge are onto that. The SH-5 CPU architecture apparently exists but has no port. There are also the architectures with open-source CPU designs OpenRISC and LatticeMico32 (LM32, used in the Milkymist SoC). So it is safe to say that there could be new Debian ports in the future and that your work would be very helpful in reducing the investment needed for new ports. > - do the proposals for the needed fields sound convincing? Can they be >improved? Do they have fundamental flaws? As an interested bystander, it sounds good. Agreed about using Profile rather than Build-with-profile/Built-with-profile. I imagine that most packages will be cross-buildable. Packages outside the set of bootstrap packages probably don't need to declare if they are cross-buildable or not? Cross-building is a slightly larger topic since there are things like arch:all firmware for ARM processors in the same source package as the tools that upload that firmware. There are also various packages in the archive (or potential ones) that are cross-built for non-Debian architectures (like win32, SH-2 or bionic libc). If you think this might be interesting to announce more widely (as I do), please add a paragraph to the next DeveloperNews, which will be released on debian-devel-announce when we get 5 entries. http://wiki.debian.org/DeveloperNews I'm also sending a mail to LWN and the distributions mailing list (at freedesktop), it might be interesting to developers of other distributions, especially Gentoo :) -- 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/caktje6furvgsxqfxsqlcokhr7fryf2rjz8a+kbngp4qwz0w...@mail.gmail.com
Re: Retrieving source package from repository without touching sources.list?
Paul Wise writes: > Sounds like you are looking for chdist: [...] I knew someone must have done the work already :-). Both chdist and pull-debian-source seem to do exactly what I need, thanks! Now there's just the difficult decision which one to use.. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- 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/87k3rdsslu@vostro.rath.org
Re: Bug#698256: ITP: lz4 -- Extremely Fast Compression algorithm library
Hi,
On Wed, Jan 16, 2013 at 11:50 AM, Paul Wise wrote:
> On Wed, Jan 16, 2013 at 8:51 AM, Nobuhiro Iwamatsu wrote:
>
>> * Package name: lz4
>> Description : Extremely Fast Compression algorithm library
>>
>> LZ4 is a very fast lossless compression algorithm.
>
> Is it faster than lzop? How does it compare to lzop, gzip, lzip, xz,
> bzip2 in terms of compression ratio? Please include that information
> in the package description.
OK , I wil include that.
And we can see infomation from website.
http://code.google.com/p/lz4
I copied infomation about compression ratio and speed.
NameRatio C.speed D.speed
LZ4 (r59) 2.084 330 915
LZO 2.05 1x_1 2.038 311 480
QuickLZ 1.5 -1 2.233 257 277
Snappy 1.0.52.024 227 729
LZF 2.076 197 465
FastLZ 2.030 190 420
zlib 1.2.5 -1 2.72839 195
LZ4 HC (r66)2.71218 1020
zlib 1.2.5 -6 3.09514 210
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
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/cabmqnvlo--avob2fu5ehh6adtcfubwdt2-vr8dzr1waoe3d...@mail.gmail.com
Re: Bootstrappable Debian - proposal of needed changes
+++ Paul Wise [2013-01-16 11:52 +0800]: > That sounds useful, so yes. arm64 is on the way, it would be a nice > test case but I guess wookey/Sledge are onto that. I intend to send an update mail on the state of this later this week. > If you think this might be interesting to announce more widely (as I > do), please add a paragraph to the next DeveloperNews, which will be > released on debian-devel-announce when we get 5 entries. > > http://wiki.debian.org/DeveloperNews Does asking d-devel for feedback count as news? Having this functionality available for packagers would count as news... But I agree that telling people about the concept is useful. > I'm also sending a mail to LWN and the distributions mailing list (at > freedesktop), it might be interesting to developers of other > distributions, especially Gentoo :) If doing that you might want to mention that Johannes will be talking about his/our bootstrap work in the cross-distro room at FOSDEM. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20130116044126.gm5...@stoneboat.aleph1.co.uk
Re: problematic shlibs entry in substvars file
On 16/01/2013 06:16, Paul Johnson wrote:
>> >
>> > I believe that dpkg-shlibdeps checks in these places:
>> > - /var/lib/dpkg/info/*.shlibs
>> > - /etc/dpkg/shlibs.{default,override}
>> >
>> > Could you grep libc6-amd64 in these places? That should provide a hint as
>> > to
>> > where this dependency is coming from.
>> >
> Thanks for the advice. I don't see anything in there.
>
> pauljohn@pjlap-124:dpkg$ pwd
> /etc/dpkg
> pauljohn@pjlap-124:dpkg$ grep -r libc *
> pauljohn@pjlap-124:dpkg$
>
> Those files are empty
>
> pauljohn@pjlap-124:dpkg$ cat shlibs.default
> [...]
Could you also run `grep libc6-amd64 /var/lib/dpkg/info/*.shlibs`? That's
probably where it is then.
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signature
Re: Package version numbers
Quoting Jakub Wilk (jw...@debian.org): > * Stephen Kitt , 2013-01-15, 23:27: > >The version of calibre in Wheezy is 0.8.51+dfsg-1; what should the > >update's version be? I'm purposefully not mentioning our ideas > >(one of them is obvious from the exchanges in the bug report, but > >is in all likelihood incorrect). > > I would paint the bikeshed the following color: > 0.8.51+dfsg1-0.1 Isn't that missing the fact that this is a t-p-u upload, which is indeed the start of a "wheezy" branch? So something we were naming "+wheezy" in the past and which we now name "+deb70u1". The main problem is indeed the combination of a t-p-u upload and an NMU of a Debian native package. signature.asc Description: Digital signature
Re: Bootstrappable Debian - proposal of needed changes
On Wed, Jan 16, 2013 at 12:41 PM, Wookey wrote: > I intend to send an update mail on the state of this later this week. Excellent. > Does asking d-devel for feedback count as news? Having this > functionality available for packagers would count as news... But I > agree that telling people about the concept is useful. The "news" would be milestone mentioned in the intro. > If doing that you might want to mention that Johannes will be talking > about his/our bootstrap work in the cross-distro room at FOSDEM. Sent a couple of followups, thanks for the suggestion. -- 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/caktje6feyoks3oczkn8qe11gbmp3n0xw1y3mobhonhweymo...@mail.gmail.com
Re: Bootstrappable Debian - proposal of needed changes
On Wed, 16 Jan 2013 00:26:53 +0100 Jakub Wilk wrote: > * Johannes Schauer , 2013-01-15, 19:18: > >Build profiles extend the Build-Depends format with a syntax similar to > >architecture restrictions but using < and > instead. > > > > Build-Depends: huge (>= 1.0) [i386 arm] , tiny > > > >The drawback of this syntax is that Build-Dep parsing tools need to be > >updated to read/accept it, so uploads of source containing these > >annotations cannot be done until the dpkg in buildds at least parses > >it. > > Not only dpkg, but also wanna-build, sbuild, lintian, dak, and who knows > what else... It's about which ones need to change. lintian response rates are not likely to be a problem - once this gets approved. dak doesn't necessarily need to do anything - most bootstrapping happens outside the main archive to prepare the ground for a move into debian-ports. Beyond that point, none of the bootstrapping support is required. sbuild can use a specified bootstrapping dependency resolver, e.g. the one used to test the proposal itself. (As could pbuilder.) Again, as bootstrapping doesn't happen inside the main archive (due to changed dependencies and changed functionality which would cause problems), there isn't necessarily anything wanna-build needs to do with this other than to allow the syntax & ignore it. > We've been historically very slow at adapting our software to these kind > of changes: > > 1) Architecture wildcards were implemented in dpkg in January 2006. > pbuilder added support for them in February... 2011. > > 2) Support for the :any qualifiers in Build-Depends was added to apt in > February 2010, and to dpkg in March 2012; AFAIK it's still not supported > by wanna-build. There are a lot of people willing to put a lot of time into this proposal, not just those who have joined the thread so far. Patches, patches and a few NMU's... Simply having the mechanism in place and the critical tools updated will be a major win. There will still be enough changes needed in the rest of the packages. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp3nvu6ipYEb.pgp Description: PGP signature
