Bug#785703: ITP: python-oath -- implementation of the three main OATH specifications
Package: wnpp Severity: wishlist Owner: Goswin von Brederlow brede...@q-leap.de * Package name: python-oath Version : 1.4.0 Upstream Author : Benjamin Dauvergne benjamin.dauver...@gmail.com * URL : https://github.com/bdauvergne/python-oath * License : BSD Programming Lang: Python Description : implementation of the three main OATH specifications Oath includes 3 modules implementing the three main OATH specifications: - HOTP, an event based one-time password standard using HMAC signatures, - TOTP, a time based OTP, - OCRA, a mixed OTP / signature system based on HOTP for complex use cases. Supports python 2.x and python 3.x. -- 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/20150519102531.25364.96889.reportbug@qlu-dev
Bug#777043: ITP: libshark -- Shark Machine Learning Library
Package: wnpp Severity: wishlist Owner: Goswin von Brederlow goswin-...@web.de * Package name: libshark Version : 3.0.11 Upstream Author : Institut fuer Neuroinformatik, Ruhr-Universitaet Bochum * URL : http://image.diku.dk/shark/ * License : GPL-3.0+ Programming Lang: C++ Description : Shark Machine Learning Library SHARK is a modular C++ library for the design and optimization of adaptive systems. It provides methods for linear and nonlinear optimization, in particular evolutionary and gradient-based algorithms, kernel-based learning algorithms and neural networks, and various other machine learning techniques. SHARK serves as a toolbox to support real world applications as well as research indifferent domains of computational intelligence and machine learning. The sources are compatible with the following platforms: Windows, Solaris, MacOS X, and Linux. - libshark is a dependency of sailfish - the package will be maintained under the Debian-Med team -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204123715.23837.14254.reportbug@frosties.localnet
Re: On accepting pre-generated doc from upstream
On Thu, Jul 18, 2013 at 12:07:59PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
On Thursday 18 July 2013 14:45:38 Goswin von Brederlow wrote:
[snip]
- Option 3:
(Note: I'm assuming you are generating API docs directly fromt the
source files. So the input for the doc building is not seperable from
the actual source.)
For packages 1 and 2 build without docs but also build a
package{1,2}-src package.
Have another source package{1,2}-doc that Build-Depends:
tools-for-doc-building, package{1,2}-src and sets Build-Using:
package{1,2}-src. This would then generate the API docs from the
source files using the tools and sources from the package{1,2} builds.
On update you would usualy only need to bump the version for this
package.
Pino also suggested me this approach. I looked into it and also at how the
original build system builds the doc. Saddly, I think the amount of time I
will need to put in this is simply insane.
I think I'll just drop the documentation.
Would it be so much time to
1) build-arch / binary-arch build without docs
2) Build-Depends-Indep: depend on the binary-arch packages
3) build-indep / binary-indep build with docs
On each new release you would then need to
1) debuild -us -uc -b package1
2) debuild -us -uc -b package2
2) dpkg -i debs
3) debuild package1
4) debuild package2
5) upload
That doesn't seem like too much of a problem.
MfG
Goswin
--
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/20130723120541.GB23436@frosties
Re: On accepting pre-generated doc from upstream
On Thu, Jun 06, 2013 at 11:35:46PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
Hi everyone. First of all, I'm cross-posting this between legal and devel
because I really don't know to which of them belongs (or maybe it does in
both).
The issue is this: Qt 5 has grown so large (850+MB unpacked in the single-
source tarball, will continue growing) that upstream also provides it as
submodules. 15 of them in 5.0.2.
Of course, in terms of maintainance, we have opted for the submodules choice.
Building the full doc could be done in two ways:
- Using the full source tarball. Saddly this means having to compile most of
it in order to get the tools for building the doc, or hacking far too much
the
build system to do something else.
- Build each submodule's doc.
While the second option seems the clear winner, there is a gotcha: you need
packages 1 and 2 built and in the archive to build the documentation.
Including their documentation. Packages 3 to 15 should not present further
problems.
So this can be solved by packaging 1 and 2 without docs and pushing them to
the archive. Then, once 1 and 2 have been built on *every* arch, repackage 1
and 2 with the documentation and upload them.
This means that we need to bootstrap the packages. And we may need to do it
for every major release (5.1, 5.2,...), although it's not confirmed.
As a possible workaround, upstream has suggested to provide the documentation
already generated (could be for the submodules and/or the full doc, this has
not been discussed yet). My first reaction has been to think that this will
not be allowed in Debian, but giving it some more thought,:
- We do have the source code for generating it (preferred form of
modification).
- We can build it, but it requires lot of work... and avoid FTBFSs while
bootstrapping ;)
So, could we accept pre-generated documentation in this case?
Kinds regards, and thanks in advance for your time, Lisandro.
- Option 3:
(Note: I'm assuming you are generating API docs directly fromt the
source files. So the input for the doc building is not seperable from
the actual source.)
For packages 1 and 2 build without docs but also build a
package{1,2}-src package.
Have another source package{1,2}-doc that Build-Depends:
tools-for-doc-building, package{1,2}-src and sets Build-Using:
package{1,2}-src. This would then generate the API docs from the
source files using the tools and sources from the package{1,2} builds.
On update you would usualy only need to bump the version for this
package.
MfG
Goswin
--
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/20130718124538.GD23957@frosties
Re: ITP: vmdebootstrap -- Bootstrap Debian into a (virtual machine) disk image
On Sun, Jun 09, 2013 at 10:22:27PM +0100, Neil Williams wrote: Package: wnpp Severity: wishlist Owner: Neil Williams codeh...@debian.org * Package name: vmdebootstrap Version : 0.1.0 Upstream Author : Lars Wirzenius l...@debian.org * URL : https://gitorious.org/vmdebootstrap * License : GPL3 Programming Lang: Python Description : Bootstrap Debian into a (virtual machine) disk image vmdebootstrap is a wrapper around debootstrap to install Debian into a disk image, which can be used with a virtual machine (such as KVM). Isn't there some VM-tools package already which this could be added to? Sounds like it would be smaller on its own than the packaging overhead. MfG Goswin -- 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/20130718125050.GE23957@frosties
Re: Why not to let all DDs to execute gb-command
On Tue, Jun 11, 2013 at 09:15:48AM +0800, Chow Loong Jin wrote: On Mon, Jun 10, 2013 at 10:43:57PM +0200, Philipp Kern wrote: Hi, On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote: So, I think the developer should have a set of tools (including gb and even slight removal commands), which allow him to do the most of packaging work without worrying other teams/developers. And, of course, those tools should be relatively secure not to break others work and the whole archive. gb is a harmless in this case. it is not. If you rely on random successes of your build this is worse than not providing a build at all. If there's a security issue, people will be forced to spend time on the issue. Either the Security Team or by extension the Stable Release Team, to get it built to finally include it into a point release or leave it lingering forever in p-u-new because a test case fails. It's not always the case of relying on random successes of your build. There are valid cases -- for example, if a build-dep, or a dep of a build-dep had a bug that prevented installation, and has just been fixed. -- Kind regards, Loong Jin I wonder if in that case it wouldn't make more sense to allow setting an additional Build-Depends / Build-Conflicts instead of give-back once the problematic deb was fixed. So instead of: - wait for problem to be fixed or foobar to be build on that arch - gb package you would do: - extra-build-hint --conflicts foobar 1.2-3 [ - wait for foobar to get fixed or newer foobar to be build on that arch - watch the buildd retry your package automatically - throw a party ] MfG Goswin PS: replace extra-build-hint with whatever wb command does this -- 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/20130718130303.GF23957@frosties
Re: Updating /etc/hosts automatically / behavior of sed command
On Fri, Jul 05, 2013 at 10:14:54AM +0200, Thomas Hood wrote: Tad Frank wrote: Your issue lies in the line: sed -e s/$REGISTERED_IP/$CURRENT_IP/g /etc/hosts /etc/hosts.new I searched debian-devel for the message to which you are responding; the most recent message with that subject header dates from December 1999. Yes, people were dynamically updating /etc/hosts in 1999 but I hope that no one has to do that any longer. :) -- Thomas Hood And policy allows for /etc to be read-only so the code would be a policy violation. MfG Goswin -- 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/20130718133936.GG23957@frosties
Re: Forming a Debian bugsquad team (Was: Blacklists in BTS (stopping the trolls and bug machines))
On Mon, May 27, 2013 at 09:01:40PM +0200, Ond??ej Surý wrote: If we are to form the Debian bugsquad team similar to Ubuntu bugsquad team, the main two questions would be: 1. As a Debian Developer/Maintainer would you be thankful for other people to come and help with bugs in your package. 2. Can we find enough volunteers to form such team? The idea would be to have a team of pasionate people who would constantly try to improve Debian as a whole and they would help the maintainers to triage bugs. The criteria for choosing bugs to help with might be: 1. the 'help' tag 2. the 'moreinfo' tag 3. the age of the bug 4. bugs without an answer 5. special user-tag, f.e. 'bugsq...@lists.alioth.debian.org' Well, we already all do that with our plentifull spare time, don't we? At least I see nothing about the bugsquad team having (or needing) any special power any DD (and non DD with a sponsor) already has. But that is on the bug side. More importantly is probably: What is the benefit for someone joining the bugsquad team? For example: Will there be some organization and sharing of skills that make it easier to fix bugs? Like for someone with knowledge in C to join up with someone with knowledge of maintainer scripts to fix a bug that involves both (sorry, it's hard to think of examples). I think finding volunteers will be the problem so you need to create some incentive for people to join the team instead of going at it alone. MfG Goswin PS: Another thing the bugsquad team might do is help with organizing bugsquash parties. Collect instructions on how best to organize such an event. Help with getting sponsors and how to give feedback to sponsors so they feel like their money is well spend and such. -- 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/20130604111916.GB17877@frosties
Re: Blacklists in BTS (stopping the trolls and bug machines)
On Sat, May 25, 2013 at 10:41:10AM +0200, Ond??ej Surý wrote: examples would be useful I have no big problem pointing fingers on d-d. Example 1: Dan Jacobson jida...@jidanni.org This: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707759 Or this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709568 I think that is a bad example. The reported error does appear when unpakcing php5-common even if it is not caused by the package directly but by something (ucf) it uses. It is often not clear for users if the bug is caused by passing the wrong arguments or by a bug in the tool being used or that a tool from another package is used at all. As maintainer you tend to have a better understanding and can more esily spot the right package to blame. I don't think you handled that bug correctly. It was a valid bug and you just closed it without fix. A simple bts reassign 709568 ucf would have sufficed. Or this duplicate bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707131 Wrong bug number? Did you mean #707237, which was filed a day after 707131? MfG Goswin -- 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/20130604113943.GC17877@frosties
Re: GNU config (config.sub/guess) is now GPLv3 with additional permission
On Fri, May 31, 2013 at 03:08:59PM -0700, Josh Triplett wrote: On Fri, May 31, 2013 at 06:44:00PM -0300, Henrique de Moraes Holschuh wrote: Upstream has changed the license to GPLv3. It has an additional permission to negate any viral effects, but it only applies to packages that include a configuration script generated by GNU autoconf. [...] Here is the new license text for config.sub and config.guess: [...] As a special exception to the GNU General Public License, if you distribute this file as part of a program that contains a configuration script generated by Autoconf, you may include it under the same distribution terms that you use for the rest of that program. This Exception is an additional permission under section 7 of the GNU General Public License, version 3 (GPLv3). Interesting choice of wording. Read literally (generated by Autoconf), this would mean that the exception only applies when you distribute config.guess or config.sub as part of a source distribution that includes the generated configure, not just the input configure.ac. Which should be the case for most source distributions, but it still seems interesting. And on the flip side, you could also trivially satisfy this by including a generated configure script that doesn't actually get used. In any case, this seems like something we could easily scan for with lintian or with any of the automatic whole-archive source scanning tools: just look for a source package that contains config.sub or config.guess but does *not* contain a configure script (or whose configure script does not contain Generated by GNU Autoconf in its first few lines). - Josh Triplett When the source does not come with a configure script, which usualy means debain/rules then runs autoreconf or the like, doesn't it make sense to also rely on autotools-dev and NOT ship the config.sub/geuss at all? The choice to ship one but not the other seems to me to be a bit stupid. Esspecially since config.sub/guess are much easier replacable. So yes, please do scan for this. Seems worthwile even without the legal mubo jumbo. MfG Goswin -- 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/20130604123009.GD17877@frosties
Re: Temporary solution for changelog problem in binNMUs
On Fri, May 17, 2013 at 03:42:06PM +0200, Thomas Preud'homme wrote: Le vendredi 17 mai 2013 15:36:02, Julien Cristau a écrit : On Fri, May 17, 2013 at 14:14:20 +0200, Thomas Preud'homme wrote: Also, it wouldn't help for the case of a binNMU on a subset of all arches since only some of them would have the entry. The solution proposed by ansgar cover this case. No it doesn't. dpkg will still refuse to install a m-a same package at different versions. Yeah, right. Thanks for correcting me. The sentence should instead be it would automatically cover this case if dpkg behavior was changed in this regards. But if I remember well there was some opposition to this idea. Cheers, Julien There are 2 issues: 1) the changelog differs 2) the version differs (1) would be fixed by the changelog being identical across all binNMUs. (2) would be fixed if dpkg ignores the binNMU part of versions. Although that has pitfals too. But there is a 3rd issue that would remain: 1.2-3 and 1.2-3+b1 have different changelogs. Making the binNMU changelog identical across archs would be a quick fix for part of the problem. But only a part. MfG Goswin -- 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/20130521081724.GA19040@frosties
Re: /bin/sh
On Fri, May 17, 2013 at 11:36:53AM -0500, Steve Langasek wrote: On Thu, May 16, 2013 at 01:10:06PM +0200, Goswin von Brederlow wrote: On Tue, May 14, 2013 at 12:21:33PM -0500, Steve Langasek wrote: On Tue, May 14, 2013 at 10:03:34AM -0700, Russ Allbery wrote: I think that, to convince people that flexibility won't cause stability and complexity problems, you're going to need to present a complete and fairly bulletproof implementation plan. Given how difficult the bash to dash transition was, I think it's going to have a fairly high bar to meet. dash still has two outstanding multiply-release-ignored grave bugs as a result of the last transition. A minimum demonstration of competence on the part of anyone proposing to change the shell again is to fix those RC bugs without introducing new ones. The system-shell idea fixes axactly those two bugs: # dash fails to upgrade if /bin/sh is locally diverted # dash upgrade breaks mksh-as-/bin/sh It does so in a way that there is not a consensus that we should adopt. I'm saying you need to demonstrate that you can fix these bugs in such a way that dash *exclusively* owns /bin/sh; and once this has been demonstrated, which can only be done conclusively by an upload to unstable that puts the solution in contact with real-world users, we can consider adopting a more complicated scheme that adds the flexibility being discussed. Sorry, but that is just stupid. You want others to do implement your solution that has no consensus too and is a regression from past stable releases to demonstrate that they are capable to implementing the actual solution that then restores the past behaviour? Sorry, but that is not the only way to show competence and you don't demonstrate a potentially desasterous solution in unstable. You proove its effectiveness in experimental first. And you proove your competence to do A by doing A and not by doing B. Note: Dash currently *exclusively* owns /bin/sh. Done. Prooven. Even made it into a stable release already. Maybe you aren't as competent in this matter as you thought yourself? The remaining problem is that dash also diverts /bin/sh. MfG Goswin -- 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/20130521090318.GB19040@frosties
Re: jessie release goals
On Sun, May 12, 2013 at 05:06:26PM +0200, Matthias Klose wrote: Am 12.05.2013 16:18, schrieb Daniel Schepler: Maybe we could have a release goal of dropping as many lib32* and lib64* packages as possible in favor of multi-arch. (And also as many package dependencies on libc6-[i386|amd64] as possible, which would in addition mean limiting some packages to arch:i386 if they currently provide a fake arch:amd64 package with an i386 binary.) Of course, to completely get rid of everything including libc6-* and lib32gcc1, etc., we'd need special configuration on the buildds to continue building gcc with multilib support; and the GCC maintainer has expressed resistance to being that radical even if we could get this buildd support. Well, GCC should keep building with a sane amount of effort. And that currently means not depending on a foreign architecture on the buildds. So before this can happen: - get dpkg ready to accept b-d's on foreign architectures. - get GCC ready to search for gcc_lib_dir for foreign multilibs. and get this submitted upstream before getting it to the Debian packages. - find a solution for multilibs which are not fully supported architectures, but only partial ports, or ports maintained outside the archive. - get the buildd infrastructure ready. - find a solution that GCC's b-d's may not be installable anymore with the current approach to binNMUs. It is wrong to drop the current multilib support before these are implemented and in place. So what do you commit to work on? I don't think that there are that many packages where you can or should drop multilib support. So it would be wrong to drop multilib support for zlib (GCC, gdb), ncurses, readline, expat (gdb) now. And there are not that many more packages providing multilib support. Matthias Is multilib realy the way to keep doing things? Gcc supports cross-compiling and I see multilib as just some hack to cross-compile for a foreign arch that you can also execute natively on the target. So why not in the future promote using i486-linux-gnu-gcc instead of gcc -m32? Yes, I know there is still some way to go to get cross-compiling working flawlessly with multiarch. But that was always planed as second step and with jessie we can do that step. So maybe after jessie multilib could be dropped and then the problem of uninstallable foreign B-Ds wouldn't occur. Gcc build times would also improve substancialy. MfG Goswin PS: gcc-defaults could provide a gcc wrapper that picks the right triplet-gcc-x.y depending on -mXX for backward compatibility. -- 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/20130516095710.GB2181@frosties
Re: jessie release goals
On Sun, May 12, 2013 at 12:17:06PM +0200, Vincent Lefevre wrote: On 2013-05-07 23:53:07 +0800, Thomas Goirand wrote: Now please, do the same reasoning with some other services, like Apache, pure-ftpd, or bind, and explain to me why you would like to have these installed, but not working. I agree for these services (though Apache is useless after just being installed, as one just has a dummy web page). But not for I've installed apache a bunch of times with the default configuration. After that the webpages are placed in /var/www and everything works. So I wouldn't say a apache default installation is useless. It works just fine and if the default config is not what one intends to use then it does no harm between being installed and being fully configured. At least I don't consider serving that single it works page as harmfull. MfG Goswin -- 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/20130516100729.GC2181@frosties
Re: jessie release goals
On Wed, May 15, 2013 at 09:43:02PM +0200, Christoph Biedl wrote: Christoph Anton Mitterer wrote... 2) No more packages that bypass the package management system and secure apt: a) There are still several (typically non-free) packages which download stuff from the web, install or at least un-tar it somwhere without checking any integrity information that would be hardcoded in that package. b) Another problem are IMHO plugins like Firefox extensions, kinda bypassing APT. I think at least those that are installed via a package, shouldn't be upgradable/overwritable anymore with online versions. I'd like to enhance that topic to the question under which circumstances a package is allowed to phone home, i.e. to contact a service provided by upstream without the consent of the user. For the records, I wouldn't mind much if the rule is never. Still an answer might be not as easy as it seems, a few situations: * Automatic update checks don't make sense, mostly they confuse users. * As an example, nagios3 upstream embedded several requests to the nagios homepage on the start page of any local installation. That I consider both annoying and a privacy breach, so I patched that away locally. But perhaps such behaviour should be banned entirely. * On the other hand, there are packages that do need frequent updates, virus scanners to start with, also ad blockers. Not sure whether these should be granted an exception. If not, somebody would have to take the task to provide these updates in an APT way. Just sharing a few thoughts on that ... Christoph I wouldn't mind never. An absolute requirement I think is a don't do it again option (for the user). For example every time I start eric it tells me there is an update. I know there is an update. It told me so the last 1000 times I started it. And I still don't want to break my stable system. I also wouldn't mind a debconf question in cases where the apt way is not practicable but security can still be maintained. Which would be for the *-installer packages that download the actual thing from the internet. I would rather not have them but sometimes they are unavoidable. Phoning home at runtime without explicit admin/user permission is never OK though. MfG Goswin -- 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/20130516101829.GD2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 05:29:45PM +0200, Sven Joachim wrote: On 2013-05-11 11:22 +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. I think that dash could probably stop diverting /bin/sh, now that bash no longer ships it (as of version 4.2-1). That would make it possible to locally divert /bin/sh for those who want it (#538822, #540512). Double that for multiarch on amd64/i386 because there is bash:i386 and bash:amd64 that both work just fine as /bin/sh. Trying to install a foreign bash or dash fails horribly though with the current diversion hack. Huh? No it doesn't, dpkg handles this just fine (apt doesn't because it does not support crossgrades, but that is another story). Make sure you have dpkg = 1.16.2, though. When I checked that last the mainatienr scripts would fail horribly because you can't have a thrid package doing a diversion. Dpkg never was a problem in itself. Proposed solution: - New virtual package system-shell with something essential depending on it (base-files?) Would probably need pre-depends so that system-shell cannot be removed temporarily (similar situation as with awk). Yes, verry similar. I actualy would like the same solution for awk to fix the problem that during bootstrap there is no awk link. - bash, dash pre-depend on system-shell for the transition - new packages system-shell-name Provides, Replaces, Conflicts: system-shell contains /bin/sh - /bin/name symlink None of system-shell-* would be essential but through the dependency of something essential at least one would always be installed (pseudo-essential). One of them (system-shell-dash) should have a higher priority than the rest to be singled out as the default and the essential package would depend system-shell-dash | system-shell. Choosing /bin/sh is then simply done by installing the right package and dpkg does the change atomically. Only if the packages declare Conflicts/Replaces on every real provider of system-shell, and with apt you lose outright because it insists on removing the conflicting package(s) first. We worked out the system during the second last Debconf, so nearly two years ago. I would have to look up my notes at home but that wasn't a problem. The virtual package works just fine as placeholder for all real packages since they all provide it. And about the removing the conflicting package(s) first I'm not sure if that wasn't an issue because system-shell is a virtual package or if the solution was to use Break/Replaces. But it worked in the right order with a set of dummy packages we made to test the solution. No messing around in pre/postinst/rm scripts or race conditions where the link might disapear for a while. No artificial limit on how many system-shell-* packages there could be. I'm afraid your plan as outlined is not going to work. Cheers, Sven This was just a loose summary of the general idea from memory. I might not have expressed all the finer details (correctly) but the solution we came up with worked. The details also include a bunch of tricky hacks to reassign the diversion during the initial upgrade so that at no time the /bin/sh link disapears. That was actualy the hardest part to figure out. MfG Goswin -- 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/20130516103544.GE2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sun, May 12, 2013 at 02:40:39AM +0100, Wookey wrote: +++ Steve Langasek [2013-05-11 09:33 -0700]: On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. See also: Linux is not about choice. All this added complexity to provide users a choice about something that doesn't matter undermines the robustness of the base system. Please stop. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package, and the rest of this pointless complexity should be jettisoned. I'm very keen to lose the diversion hack. It causes pain for cross-debootstrapping, especially on embedded images. If /bin/sh is no longer a diversion by dash/bash then that frees up the use of diversions for the admin or other packages. So that works too. Someone would need to make a case for replacing dash as /bin/sh. What do we get for enabling /bin/mksh fill that role too, for example? If it really is just better then why not just swap from dash to mksh and everyone can benefit? So lets say I'm convinced mksh is the better /bin/sh for everyone. How do I test that it actualy works at all? How do I get other people to test? Currenlty there is no way to say: Here, try installing this packages and report if anything breaks. Swappable system shells is a nice idea, but Steve is right that it's a critical thing that really does need to work so there has to be some real gain from futzing with it. If it can be done cleanly then great. If not then lets see if we can't just pick one (almost) everyone can live with. Wookey Problem is Debian picked *2* and both created a diversion on /bin/sh and play ping-pong with that. At the time the system-shell-* solution was considered there was no way for e.g. bash to not ship /bin/sh. It seems now that has changed so yeah, maybe we can go to just simply a plain /bin/sh. Then people that want a different /bin/sh, and there are those, are free to use diversions again. MfG Goswin -- 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/20130516104405.GF2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 08:44:30PM +0100, Roger Leigh wrote: On Sat, May 11, 2013 at 08:52:29PM +0200, Josselin Mouette wrote: Being able to choose between two entirely different desktop environments, with different user experiences, is a good thing. Being able to choose between two /bin/sh shells or two /sbin/init implementations is not. The shell I can agree with. It is required to provide a POSIX shell, so as long as it is fully functional and performs well, just picking one and sticking with it is absolutely fine. You are disagreeing with yourself, kind of. If there is only exactly one system shell and everything is tuned to work with only that one system shell then the system will no be for a POSIX shell but for THAT shell. The history with bash as /bin/sh has proven that. The only realistic way to keep scripts compatible with a POSIX shell is to have multiple shells that have POSIX as common base. So be truthfull and say you are fine with picking XYZ as system shell and have everything rely on sh being XYZ. I also disagree with the assumption that being able to choose a system shell is a bad thing. I actualy find it kind of important. By picking dash as /bin/sh (and it isn't going to go back to bash, right?) you are forcing dash to be installed. Also bash practically has to be installed simply because dash as interactive shell for users sucks. For a Debian derivativ aimed at some embedded platform it might be far better to simply have one shell that works for both /bin/sh and interactive user shells. This would be greatly simplified by having more than one choice for the system shell in Debian. Support for other shells would be better tested and easier to maintain over time. MfG Goswin -- 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/20130516110324.GG2181@frosties
Re: /bin/sh
On Tue, May 14, 2013 at 12:21:33PM -0500, Steve Langasek wrote: On Tue, May 14, 2013 at 10:03:34AM -0700, Russ Allbery wrote: I think that, to convince people that flexibility won't cause stability and complexity problems, you're going to need to present a complete and fairly bulletproof implementation plan. Given how difficult the bash to dash transition was, I think it's going to have a fairly high bar to meet. dash still has two outstanding multiply-release-ignored grave bugs as a result of the last transition. A minimum demonstration of competence on the part of anyone proposing to change the shell again is to fix those RC bugs without introducing new ones. The system-shell idea fixes axactly those two bugs: # dash fails to upgrade if /bin/sh is locally diverted # dash upgrade breaks mksh-as-/bin/sh You could say the whole reason for the idea were those 2 bugs. That being said, I think removing the use of diversions for handling the default shell and simplifying the current situation would remove complexity, and therefore should be strongly considered. Once that's done, if you really want to change the root shell on your own system, it should again be possible to use a simple local diversion to do so. Yes. MfG Goswin PS: I never advocated changing the default /bin/sh. -- 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/20130516111006.GH2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sun, May 12, 2013 at 02:40:39AM +0100, Wookey wrote: +++ Steve Langasek [2013-05-11 09:33 -0700]: On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. See also: Linux is not about choice. All this added complexity to provide users a choice about something that doesn't matter undermines the robustness of the base system. Please stop. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package, and the rest of this pointless complexity should be jettisoned. I'm very keen to lose the diversion hack. It causes pain for cross-debootstrapping, especially on embedded images. Someone would need to make a case for replacing dash as /bin/sh. What do we get for enabling /bin/mksh fill that role too, for example? If it really is just better then why not just swap from dash to mksh and everyone can benefit? Nobody wan't to mess with the default (yet). Swappable system shells is a nice idea, but Steve is right that it's a critical thing that really does need to work so there has to be some real gain from futzing with it. If it can be done cleanly then great. If not then lets see if we can't just pick one (almost) everyone can live with. Wookey The current diversion hack is insane. That certainly needs to go. I hope everyone can agree on that. The system-shell idea is a way out of that without loosing the choice what /bin/sh shall be. Currently that choice is between bash and dash. Picking just dash as /bin/sh would be an (acceptable) regression since it would open back the possibility to diver the shell locally (or by other packages). I like the system-shell idea better because it is cleaner (less likely to break) than diverting /bin/sh (both locally and by packages). Note: it would also allow changing the shell (in debian or in derivatives) in the future without running into the same diversion problems again. MfG Goswin -- 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/20130516112005.GI2181@frosties
Re: detailed lists with archive contents - more than just Contents
On Mon, May 13, 2013 at 03:21:35PM +0200, Helmut Grohne wrote: On Mon, May 13, 2013 at 11:48:06AM +0200, Goswin von Brederlow wrote: Both cases would need data for multiple archs. For the second case if identical files are in all foo_arch.deb then those should be in foo-common_all.deb. A dedup across archs instead of across packages. Thanks for explaining. Still this task is quite different from the task dedup.d.n is solving, since it requires to look at one package instead of looking at one architecture (+ all). Adding support for this to dedup.d.n would vastly increase resource usage beyond the currently available hardware. In addition the scalability issues differ, since the number of architectures is comparatively small to the number of packages. Maybe a different tool can solve these two useful tasks you proposed? Helmut Well, generating a list of all files in all packages with size and hash would be a common subtask for both. But you mentioned dedup.d.n only looks at amd64 so far. That certainly reduces the amount of work. MfG Goswin -- 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/20130514131649.GF27079@frosties
Re: Depends: libfoo:foreign ???
On Mon, May 13, 2013 at 07:55:30AM -0400, The Wanderer wrote: On 05/09/2013 11:59 AM, Wookey wrote: +++ Goswin von Brederlow [2013-05-09 11:39 +0200]: I would say that a foreign dependency on a library is never right. That's too strong. It can make sense for cross-tools, or maybe emulators, which genuinely need a foreign-arch library to operate. But I'm not aware of other sensible usages. If I'm correctly understanding what's being described here, I would think that the full-functionality 64+32 Wine would probably be another exception (unless it falls under emulators, in which case another doesn't apply); the 64-bit side is built against and depends on 64-bit libraries, and the 32-bit side is built against and depends on both 32-bit libraries and the already-built 64-bit side, and both sides are needed for an install capable of handling both 32-bit and 64-bit Windows programs. I don't see any practical way to let a package providing the full-functionality 64+32 Wine work without depending on both the 64-bit (native) and the 32-bit (foreign) libraries. Wouldn't that be 64-bit + 32-bit binaries? I thought wine had seperate binaries and a wrapper that picks the right one to start. Wine depends on wine-bin:i386 or wine64-bin:amd64 (similar for kfreebsd). The arch qualifier is not needed since the right thing already happens (normaly). Except there is wine-bin:powerpc. That kind of ruins that. A system with amd64, i386 and powerpc configured would hapily use wine-bin:powerpc instead of wine-bin:i386. Or wine-bin:i386 can be used instead of wine-bin:kfreebsd-i386. But that is a matter of pining the architectures corectly. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Apart from the above exceptions, I agree. For the full 64+32 Wine, I don't believe this is possible - or if it is possible, no way of doing it has yet been documented that I know of. The official Wine documentation of how to build that configuration involves compiling the 32-bit side on the same 64-bit host as the 64-bit side - and, importantly, compiling it against the already-built but not-yet-installed 64-bit build tree. Theoretically it might be possible to build the 64-bit side on an amd64 machine, make the resulting tree available to an i386 machine, let the i386 machine compile the 32-bit side against the 64-bit tree, make the resulting tree available to the amd64 machine again, and let the amd64 machine do the final 'make install' or equivalent process. I wouldn't expect that to actually work, though, given that it looks like the Wine tools built on the 64-bit side may get run during the 32-bit side of the build - and even if it does work, that seems like far more trouble than should be justifiable for what is otherwise a straightforwardly scriptable build process. That seems to be a problem in the wine build system though. It should already be possible to build a 32bit only wine and a 64bit only wine. And then you just need something to build the extra tools that chose between 32bit and 64bit. Or not? I don't know the wine build system so I can't say how much pain that would cause. But it would be the most logical way. (This is the main use case I have for multi-arch -dev packages; without them, the only way I can think of to potentially accomplish a full 64+32 Wine build which I would expect to result in full functionality is to identify all -dev packages needed for the desired Wine library support, then pause in between build stages to manually swap which architecture of each of those -dev packages is installed - and swap back afterwards for normal compilation of other things.) Shifting the build tree around between amd64 and i386 and back to amd64 is no solution. That will never fly. If the two archs can't be build seperately then I guess you will have to encourage maintainers to make their -dev packages coinstallable quickly for jessie. And get support for Build-Depends: libfoo-dev:i386 [amd64] added. MfG Goswin -- 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/20130514133439.GG27079@frosties
Re: Depends: libfoo:foreign ???
On Mon, May 13, 2013 at 10:31:54AM -0400, The Wanderer wrote: On 05/13/2013 10:22 AM, The Wanderer wrote: On 05/13/2013 09:46 AM, Wookey wrote: Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles against end up installed in a final installation (as libraries?) or are they really just intermediate 'during build' items? They do end up getting installed, though whether as libraries or not I don't recall offhand. I think I may have misunderstood this question. Some of the 64-bit components which would ordinarily get installed in a 64-bit-only build get omitted from the final install (and possibly from compilation) in a combined build, because the 32-bit components replace them. Not all do, however, and some - I think most - do get installed as both in parallel. I would have to investigate the build process more closely in order to say much more with any certainty. Could you build a 32bit only, a 64bit only and a 32+64bit wine, run make install for each case and generate a file list for each? Including file output so it shows what is 32bit and what 64bit in the mixed case. Also what happens if you take the list for 32+64bit and then manually pick the respective files from the 32bit only and 64bit only tree according to bitness of the files? Does that produce something functional? Equal to the 32+64bit build? MfG Goswin -- 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/20130514134017.GH27079@frosties
Re: Temporary solution for changelog problem in binNMUs
On Mon, May 13, 2013 at 06:04:58PM +0200, Holger Levsen wrote: Hi, On Montag, 13. Mai 2013, Guillem Jover wrote: The only thing the metadata solution would need now, is changing packaging helper, all packages not using a helper, and changelog and copyright extractors to look first in the new place, and fallback to the old one for backwards compatibility. that will only take four years or so. cheers, Holger If it is going to take 4 years then it is going to take 4 years. So what? Only the packages being binNMUed need to be fixed already. So when you want to binNMU something that isn't yet changed you change it, if it isn't using dh_changelog, and do a sourcefull upload. I find it more important to get a solution and to start adapting it. Because if it takes 4 years just to decide we will make changelogs metadata like propoased then it will take 8 years combined and not 4. MfG Goswin PS: If it gets decided that binNMUs changelogs will be generated as split-of files then that is OK too. But make an informed decision. Don't pick something as temporary solution just because it would be quick to hack together and leave the problem open. -- 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/20130514141154.GI27079@frosties
Re: Temporary solution for changelog problem in binNMUs
On Mon, May 13, 2013 at 11:09:53PM +0200, Ansgar Burchardt wrote: Hi, [ dropped -release and -wb-team ] Jonathan Nieder jrnie...@gmail.com writes: One problem that that doesn't solve is what to do when a package would be able to borrow its /doc/package directory from another package (using a symlink) but for the changelog and copyright (which gets even harder when binnmus are involved). See http://bugs.debian.org/556015 Right, that would need looking into. A random idea: if doc/package is a symlink to doc/other-package, then copy the binNMU part of the changelog to doc/other-package/changelog.Debian.arch.gz, but do not generate doc/other-package/changelog.Debian.gz. Ansgar Huh? If the changelog is symlinked and the package is binNMUed don't you end up with something like in the deb? foo-common: /usr/share/doc/package/changelog.Debian.gz libfoo (binNMU): /usr/share/doc/package - other-package /usr/share/doc/other-package/changelog.Debian.binNMU-arch.gz (binNMU stanza) The split off binNMU part needs to be arch qualified for multiarch or you have the same problem as before in case binNMUs for multiple archs are done independently (e.g. not the same reason). I wouldn't want the original changelog to be modified at all at install time and the other file causes no problem if it is arch qualified. MfG Goswin -- 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/20130514142258.GJ27079@frosties
Re: jessie release goals
On Mon, May 13, 2013 at 07:26:15PM +0200, Stephen Kitt wrote: On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow goswin-...@web.de wrote: On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote: The big issue which crops up then isn't so much the directory structure's impact on the build process, but rather its impact on the packaging process. If the target directory structure depends on whether we're building for a full Debian architecture or for a partial architecture or just some cross-compiler target, that means ad-hoc changes in the packaging for the various cases and that much more friction (see for example http://bugs.debian.org/671437 - although in zlib's case packaging changes are necessary to build for Windows). But it wouldn't. The target directory structure would be the same across all builds. It would always be /usr/include/[$(DEB_HOST_MULTIARCH)] and /usr/lib/[$(DEB_HOST_MULTIARCH)]. The effect of partial architecture is simply that not everything needs to be build for that architecture and the partial architecture might not be self hosting. E.g. we can cross build for mingw but we wouldn't be including windows in Debian nor run a buildd on windows. Yes, but that's not the problem. Take the premise that the target directory structure is as described above, so most library development packages ship as many headers as possible in /usr/include. For now we'll assume all mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; but to use mingw-targeted libraries other than mingw-w64-...-dev (libgtk for example), the mingw toolchain needs to look in /usr/include as well. Every compile has to look in /usr/inlclude/triplet and /usr/include/. mingw is no special case there. This is all fine as long as libc6-dev is not installed (say perhaps with sbuild and cross-build-essential). But in a typical work environment, libc6-dev will be installed, and because we'll always be cross-compiling on the buildds, packages which need to build stuff for the host to run during the build (wine-gecko does this) need build-essential too, so libc6-dev headers end up in /usr/include and are picked up by the mingw toolchain. Only architecture independent header are in /usr/include. Now in the case of w32/w64 as architectures those headers must also be suitable for windows or they are no longer architecture independent. I guess that is the problem you see. I don't see that anything changes for the layout. You just added a rather strange arch which breaks the architecture independency of libc6-dev stuff. Is that any different from building for a uclibc system? I think you have the same problem there. How much of libc6-dev and other libs are we talking about here? Packages could also have: foo-dev-common:all (or all foo-dev): /usr/include/foo.h foo-dev:w32: /usr/include/w32/foo.h - ../foo.h foo-dev:w64: /usr/include/w64/foo.h - ../foo.h Then mingw would only need to look there. This would be special casing those archs. So not an ideal solution. Likewise for other -dev packages which may be available for the host architecture but not the target architecture. Imagine the confusion then for configure scripts! Yes, that is a big problem. Luckily we have Build-Depends/Conflicts so all the right packages are there and all the wrong packages are not. For buildds that shouldn't be a problem. Also any link test for libs will fail if the -dev is not installed for the right arch. As far as I can see there are three solutions to this: * split headers completely Possible without any toolchain changes. Just move the files in every -dev package. * drop the idea of building mingw packages using the existing Debian packaging I don't think mingw is overly special there. Cross-compiling, esspecially for a different libc, will be verry similar. * add patches to all supported packages so that they build differently when targeting mingw (and any other partial architecture which can't share /usr/include) * install w32/w64 packages in a sysroot, i.e. prefix every file on unpack. Not sure how well that would work with maintainer scripts though. For other cross-compiles one can use chroot but you probably don't want / can't use that for w32/w64. This could be done during build. Sort of like option 3. A small patch to move debian/package/* to debian/package/usr/lib/mingw/ before building the deb. Fedora went with the second solution; they have mingw-specific packages for everything they build targeting Windows. If we could build-depend on source packages (which has been mentioned elsewhere in this thread) this would be possible on Debian too, although it would be a bit of a chore for me (and whoever else wants to chip in). But I wouldn't want supporting a non-free operating system to become a chore for more Debian developers than necessary! (The aim of all the mingw work as far as Debian is concerned, apart from
Re: Source build-dependencies
On Sat, May 11, 2013 at 06:03:30PM +0100, Wookey wrote: +++ Stephen Kitt [2013-05-09 10:46 +0200]: On Thu, 9 May 2013 10:10:01 +0200, Mike Hommey m...@glandium.org wrote: * source build dependencies (such that e.g binutils-mingw-w64 build depends on src:binutils instead of binutils-source) Yes! That was on my list as well ;-). The Built-Using stanza could even be filled in automatically in such cases... I'd vote for that too, as it would be very helpful for cross-toolchain building. I hadn't realised that source build-deps was a possibility. Is it? Does anyone have a proposal for how it might work? Wookey 1) dpkg: support dpkg -i foo.dsc, which unpacks the source to /usr/src/ or something 2) apt: parse Sources.gz and add them to architecture src, apt-get install binutils:src downloads the dsc, orig.tar, debian.tar, ... and then passes the dsc file to dpkg for installing 2b) fix other tools like pbuilder-satify-depends, sbuild, ... 3) Sources can use Build-Depends: binutils:src using the multiarch syntax to qualify archs MfG Goswin -- 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/20130514145731.GL27079@frosties
Re: detailed lists with archive contents - more than just Contents
On Tue, Apr 16, 2013 at 09:09:06PM +0200, Helmut Grohne wrote: On Tue, Apr 16, 2013 at 03:04:20PM +0200, Goswin von Brederlow wrote: Will that also detect files in multiarch packages that are not identical? No, it does not do this at the moment. The main reason here is that currently only amd64 is processed. Support for multiple architectures would take a bit more to implement and vastly more resources on the machine hosting dedup.d.n. Or files in foo_arch.deb that should be in foo-common_all.deb? I do not yet understand what kind of algorithm you imagine here. In any case dedup.d.n does not do such a thing at the moment. In addition a task that operates one one binary package is likely better suited for lintian. Helmut Both cases would need data for multiple archs. For the second case if identical files are in all foo_arch.deb then those should be in foo-common_all.deb. A dedup across archs instead of across packages. MfG Goswin -- 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/20130513094805.GC8366@frosties
Re: Depends: libfoo:foreign ???
On Thu, May 09, 2013 at 04:59:28PM +0100, Wookey wrote: +++ Goswin von Brederlow [2013-05-09 11:39 +0200]: On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client A Depends like in this case is never right since it mixes biarch (libc6-i386) packages with multiarch (libfoo:i386). This does seem wrong, especially in this case. I can't think of a case where it makes sense offhand, but there might be one. It should be libc6:i386, libfoo:i386 at least. I would say that a foreign dependency on a library is never right. That's too strong. It can make sense for cross-tools, or maybe emulators, which genuinely need a foreign-arch library to operate. But I'm not aware of other sensible usages. Right. cross-tools are probably the exception there. Forgot about them for a minute. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Apart from the above exceptions, I agree. We haven't yet formulated any policy on what is/isn't going to be allowed/deemed sensible. Also, iirc, the use of foreign dependencies is only supposed to be on packages with Multi-Arch: allowed. I don't think that's relevant/correct. A foreign-arch dep is appropriate when the binary is linked against/uses said library, and a same-arch libfoo-arch-cross isn't used instead. Said library could be a perfectly normal M-A:same package. I guess it's time to have a think about this stuff and write down some guidelines/policy. Wookey Should that include binaries linked against libraries? Imho any foreign arch binary or library should come from a foreign arch package. So even for cross-tools if they need a foreign binary or library they should depend on the foreign package containing them. [And how will they run the foreign binary? seems like the foreign binaries case shouldn't happen at all.] That should only leave the uses foreign library case. Like a gcc cross-compiler uses the foreign libgcc. The gcc cross-compiler itself is not linked against the foreign libgcc though. But that destroys the idea of DAK catching it. I don't see how teamspeak-client depending on libfoo:i386 would be cought but i486-linux-gnu-gcc depending on libfoo:i386 would pass. Unless we add a specific tag for cross-tools to excempt them from the check. Looks like we have to keep catching those bugs by hand. MfG Goswin -- 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/20130513102146.GD8366@frosties
Re: wheezy postmortem re rc bugfixing
On Wed, May 08, 2013 at 04:51:14PM +0100, Ian Jackson wrote: * Consider other ways in which our RC-bug-fixing efforts can be improved, especially during the latter part of the freeze. I think one way to improve hard to reproduce bugs or bugs in uncommon package would be to get more users involved. I think the way to go there is to get users better informed about the problem. This could come in two parts: 1) A developer (maintainer or random person doing triage) tags the bug RFUH (request for user help) in some way. Helpfull would be a short summary of the problem and what help is needed. E.g. needs hardware XYZ, look for XYZ to happen and then run FOO and send the output. 2) A tool for users to run that checks the installed packages against RFUH tags and points out matches. Maybe requirements could be checked automatically too. So only users with hardware XYZ see the RFUH that requires XYZ. Or RFUH could be for combinarions of packages: users of foo + bar + baz. The goal would be to limit message to only those users that can help. This (2) could also be helpfull before removing packages. The tool could warn stable users about their favourite package being in danger of removal and get them to test out the alternatives or scream bloody murder before it is too late. Is there already something for that? Then it needs to be advertised more. MfG Goswin -- 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/20130513104528.GE8366@frosties
Re: epoch fix?
On Sun, May 12, 2013 at 11:53:46AM +0200, Vincent Lefevre wrote: On 2013-05-10 02:01:15 +0800, Thomas Goirand wrote: Seems nobody is picking-up on the topic, so I'll try once more, because I'm convince there's something we could do here. How about replacing epoch separator char : by @ in the filenames for example? Why not keep the usual : escaping as in URLs? It may be less readable (for the few people who need to read it), but it may be better if other characters need to be introduced and escaped in the future. Because that needs to be escaped (again) when downloading the file via e.g. http. And if you need to escape things then we might as well use : directly and remain readable. MfG Goswin -- 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/20130513104956.GF8366@frosties
Re: Temporary solution for changelog problem in binNMUs
On Mon, May 13, 2013 at 11:14:07AM +0200, Ansgar Burchardt wrote: Hi, with wheezy released and development on jessie started the problem with binNMUs for multiarch-enabled packages is back: binNMU'ed packages have different changelog entries and upgrades fail (for example [1]). [1] http://bugs.debian.org/708097 It's quite annoying as the problem is only detected when dpkg tries to extract the package. There have been previous discussions how to fix this[2]. The dpkg maintainers would like to treat changelogs and copyright files as metadata and move them out of /usr/share/doc[3]. [2] https://lists.debian.org/debian-dpkg/2012/07/msg00017.html [3] http://bugs.debian.org/681289 I believe it will still take a while to reach a consensus and implement it. So I would like to propose a temporary solution until this is sorted out: Let dh_installchangelogs split out the binNMU changelog entry into a changelog(.Debian).$arch.gz file for now. Yes, this might not be the final solution, but at least binNMUs shouldn't break any longer, at least as long as they have the same version across all architectures. For this sbuild should add binary-only=yes to the changelog[4] and dh_installchangelogs split such entries into a separate file (will file a bug soon). [4] http://bugs.debian.org/681292 Ansgar Please don't. That just eats up developer time to implement, more time to un-implement when the real solution comes and probably delays the real solution because nobody wants to break the temporary fix. Sometimes a bit of pain is a good motivator. Isn't the reason this was on hold the wheezy release and now that is out work on this can continue? Guillem sayd he already has a working solution for changelog / copyright as metadata at home. And despide the discussion about what it is all usefull for there doesn't seem to be any real (unsolvable) objections to that solution. So I would rather see that solution in experimental NOW and get people to try it than divert resources to temporary fixes. MfG Goswin -- 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/20130513121214.GG8366@frosties
Re: Merging / and /usr (was: jessie release goals)
On Fri, May 10, 2013 at 10:07:18AM +0200, Marc Haber wrote:
On Thu, 9 May 2013 18:17:29 +0200, m...@linux.it (Marco d'Itri) wrote:
On May 09, Bernhard R. Link brl...@debian.org wrote:
Or in other words: to make essential functionality not available if
/usr is broken.
Again: this is not we are discussing. Essential functionality is moving
to /usr anyway
Which is a really really bad thing. Some anonymous upstream is forcing
us to decrease the reliability of our systems. I really hate that
idea.
Don't we all. But it has already hapened.
Having a seperate / means you have an instant rescue image that has
just the right kernel and tools you need to repair the rest of your
system.
OK, so you could have an even *smaller* / with a *real* independent
rescue image like grml in /boot.
Having the rescue image _this_ independent is not really desireable
since one would probably have to deal with outdated or non-existing
rescue tools in the independent image while the correct software in
the correct version is on the system's own / file system.
Or you would have a known working and good version of tools while the
system (being unstable) might have any number of bugs in them.
Note: The rescue image could be dynamically generated on updates or
come as prebuild images. Or you could have both. And a stable and
latest flavour on top. The rescue image will be no more out of date
than any other package in debian.
You also have one small filesystem with all the important
stuff like /etc in it while the boring large distro stuff is in
another partition. You also have a partition border between
most of the random stuff and the important stuff.
Indeed, if the content of /{bin,sbin,lib} is moved to /usr you can have
a small filesystem with all the important stuff like /etc in it and the
boring large distro stuff (like 100 MB of kernel modules for each
kernel, currently in /lib) in another partition.
But I'll have the fsck version that is guaranteed to fit my /usr file
system in the big /usr file system, so I'll be forced to use an fsck
from a rescue image which might not be the current one, possibly
causing even more damage.
Greetings
Marc
Fsck is in the initramfs (added combined with the mnount /usr patches)
so you can fix your /usr and even your / from there already.
Has anyone actualy compiled data about fsck problems respective to
filesystem size? I can't remember EVER having a fsck problem with /usr
ever since I switched to keeping it read-only. And that was somewhere
in early 2.4.x times.
MfG
Goswin
--
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/20130513123820.GH8366@frosties
Re: Merging / and /usr (was: jessie release goals)
On Thu, May 09, 2013 at 12:03:43PM +0100, Roger Leigh wrote: On Thu, May 09, 2013 at 11:50:31AM +0200, Goswin von Brederlow wrote: If you make /usr a symlink to / then there will be to distinct paths to each file and that will confuse dpkg. The first problem that comes to mind is package A containing /bin/foo and package B containing /usr/bin/foo. Dpkg will happily install both without noticing the file overwrite conflict. Or package A 1.0 contains /bin/foo and package A 1.1 contains /usr/bin/foo. IIrc then dpkg will unpack A 1.1 (overwrite /bin/foo with /usr/bin/foo) and then remove /bin/foo. Leaving you without /usr/bin/foo. This is all very true. Once we have /usr mounted in the initramfs, we can correct such duplicate paths to prevent this; packages which provide a binary in /bin and a symlink in /usr/bin to make the binary available in early boot can simply move the binary back to /usr--it will be guaranteed to be available in early boot. Since two different paths would then be effectively equivalent, maybe we might also need dpkg itself to be aware of this so that it will refuse to overwrite, in addition to a manual audit of the existing paths. My current work on this is at http://anonscm.debian.org/gitweb/?p=users/rleigh/initramfs-tools.git;a=shortlog;h=refs/heads/usrmount It works for mounting a local /usr; testing NFS and NFS/local combinations is on my TODO list for tonight. This still needs further cleanup and testing. It will be ready for wider testing in a few days. It also needs a patch to util-linux so it doesn't try to fsck a mounted /usr at boot. Regards, Roger I totaly support your initramfs patches to mount /usr. But that is a long way away from the merge / + /usr. Which I don't feel has a good solution yet. All the proposals so far have major faults leading to corrupted and even unbootable systems. As I see it the way to go is: 1) mount /usr in initramfs now so we simply don't have to care wether it is seperate or not. You are well on the way there. 2) possibly remove patches that put stuff in / with compat symlinks in /usr/ provided they conflict with an older initramfs. Might be good to wait a release before doing that so we don't add tons of dependencies on the intramfs version. 3) wait a release (unless we do that for 2) 4) remove all / instead of /usr patches, remove / + /usr duplicates 5) wait a release 6) consider the / + /usr situation again That would give at least 4 years before merging / and /usr becomes an issue. I think talk about doing this for jessie is seriously premature given the solutions for merging proposed so far. MfG Goswin -- 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/20130513125102.GI8366@frosties
Re: jessie release goals
On Tue, May 07, 2013 at 09:34:09PM +0100, Noel David Torres Taño wrote: On Lunes, 6 de mayo de 2013 13:49:57 Andreas Beckmann wrote: Hi, now might be the right time to start a discussion about release goals for jessie. Here are some points that come into my mind right now (and some were already discussed very recently): * multiarch compatible binNMUs * discarding maintainer uploaded binary packages [!arch:all] * discarding maintainer uploaded binary packages [incl. arch:all] * extending binNMUs to allow rebuilding arch:all packages (so it's no longer a binary only but a sourceful no-change rebuild - the classic binNMU should stay of course) Andreas ... looking forward to have PPAs in the future :-) I would like to see multiarch fully working (it is not, see #705834) What does that have to do with multiarch. The actual problem there seems to be: update-alternatives: error: alternative path /usr/bin/wine32-unstable doesn't exist dpkg: error processing wine-bin-unstable (--install): subprocess installed post-installation script returned error exit status 2 That is just a single packaging bug. Nothing worth a release goal. MfG Goswin -- 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/20130511084450.GB3334@frosties
Re: /bin/sh (was Re: jessie release goals)
On Tue, May 07, 2013 at 07:46:43PM +0200, Marc Haber wrote: On Tue, 7 May 2013 16:46:46 +0200, m...@linux.it (Marco d'Itri) wrote: On May 07, Thorsten Glaser t...@debian.org wrote: My stated goal here is, indeed, to be able to run at least some useful configurations of a Debian installation without *both* bash and dash installed. What is the point? A smaller footprint of the intalled system? This may be interesting for embedded things. Greetings Marc While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. But we already have 4 working candidates for /bin/sh: bash, bash-static, dash, mksh Add 2 more if dash and mksh build static flavours too. posh, ksh93, (yash or zsh) could also become candidates with a little work it seems. Double that for multiarch on amd64/i386 because there is bash:i386 and bash:amd64 that both work just fine as /bin/sh. Trying to install a foreign bash or dash fails horribly though with the current diversion hack. Double that for kfreebsd with multiarch. kfreebsd-amd64 currently has 16 /bin/sh candidates. The current implementation of /bin/sh handling simply restricts the freedom to choose a /bin/sh. Not because only 2 shells are suitable and maintainable but simply because of the way the /bin/sh link is managed with diversions. Debian is about freedom and choice, right? Proposed solution: - New virtual package system-shell with something essential depending on it (base-files?) - bash, dash pre-depend on system-shell for the transition - new packages system-shell-name Provides, Replaces, Conflicts: system-shell contains /bin/sh - /bin/name symlink None of system-shell-* would be essential but through the dependency of something essential at least one would always be installed (pseudo-essential). One of them (system-shell-dash) should have a higher priority than the rest to be singled out as the default and the essential package would depend system-shell-dash | system-shell. Choosing /bin/sh is then simply done by installing the right package and dpkg does the change atomically. No messing around in pre/postinst/rm scripts or race conditions where the link might disapear for a while. No artificial limit on how many system-shell-* packages there could be. MfG Goswin -- 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/20130511092210.GC3334@frosties
Re: jessie release goals
On Tue, May 07, 2013 at 10:31:10PM +0100, Wookey wrote:
+++ Stephen Kitt [2013-05-07 14:38 +0200]:
Hi Wookey,
On Tue, 7 May 2013 03:04:50 +0100, Wookey woo...@wookware.org wrote:
(just a decision to leave arch-independent headers in /usr/include and
move arch-dependent headers to /usr/include/triplet).
Doesn't this limit us to cross-compiling only across Debian architectures?
If
we go for a full /usr/include/triplet split (in the same way as for
libraries)
Libraries are always different for different architectures. Only a
fairly small subset of headers is, so you could say we are doing
exactly the same thing for both libaries and headers:
arch-indep stuff goes in /usr/{lib,include}
arch-dependent stuff goes in /usr/{lib,include}/triplet
But your point is taken.
The tradeoff is:
1) (Move _all_ headers to /usr/include/triplet)
* Much duplication of installed headers
* Only one system include dir, which fits current build-system
expectations
2) (Move only arch-dependent headers to /usr/include/triplet)
* No duplication of headers
* Two system include dirs, which may confuse/break some builds
In both cases things which manage to explictly look only in '/usr/include'
may fail to build, but much more likely for 2. I have no idea how
much a problem this would be in practice.
'1)', above has been reasonably well tested in Ubuntu raring, and telling the
compiler to look in both dirs for system headers by default works
well, but there could be issues when given paths to subdirs.
Note: #include foo.h will implicitly look in /usr/include/triplet
and /usr/include. You have to do something strange to fail to build.
E.g. grep SOMETHING $dir/foo.h in configure instead of test
compiling like macros usualy do.
So this is less of an issue than it sounds. It realy needs to be
explicitly broken to fail.
we could support cross-compiling to anything with the same
structure - I'm thinking MinGW-w64 here of course, but I imagine it would
apply to other targets too, some of which are supported in Debian already
using the /usr/triplet/include directories.
The above issue is independent of the need for dpkg-architecture to know
about an arch to use multiarch mechanism for cross-building to it. But
that's very easy to do (An easy way to add arches in a local config
file is something that's been mentioned before). Having mingw as an
arch is a good idea if it isn't already.
And you can still use a sysroot and non-multiarch ways of filling it
if you prefer. I haven't really experimented with mulitarch and
sysroot at the same time but SFAIK it should work.
Wookey
MfG
Goswin
--
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/20130511092922.GD3334@frosties
Re: jessie release goals
On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote: Let me explain where I'm coming from... With MinGW-w64, we have a set of compilers, headers and libraries which allow building software targeting native Windows, without Cygwin or much in the way of wrappers at all. This is definitely non-POSIX and not much like Debian; but I imagine similar problems crop up when targeting a different libc. Despite the differences, and thanks to a lot of work by upstream developers, a lot of the libraries in Debian build fine when targeting Windows, and most of the time the only change required is to pass the correct target triplet to the configure script. This makes it sorely tempting to add mingw (i386, amd64 and arm as Dmitrijs mentions) as partial architectures in Debian and use all the existing packaging as much as possible to provide at least -dev packages and DLLs for as many libraries as possible; this would greatly simplify the lives of people working on building stuff for Windows (currently they basically have to produce Makefiles which build all their dependencies - and then you end up with things like the Firefox source packages which include all their dependencies on all platforms). The big issue which crops up then isn't so much the directory structure's impact on the build process, but rather its impact on the packaging process. If the target directory structure depends on whether we're building for a full Debian architecture or for a partial architecture or just some cross-compiler target, that means ad-hoc changes in the packaging for the various cases and that much more friction (see for example http://bugs.debian.org/671437 - although in zlib's case packaging changes are necessary to build for Windows). But it wouldn't. The target directory structure would be the same across all builds. It would always be /usr/include/[$(DEB_HOST_MULTIARCH)] and /usr/lib/[$(DEB_HOST_MULTIARCH)]. The effect of partial architecture is simply that not everything needs to be build for that architecture and the partial architecture might not be self hosting. E.g. we can cross build for mingw but we wouldn't be including windows in Debian nor run a buildd on windows. I know (2) is well-tested, and it reduces duplication drastically. Does this outweigh being able to use multiarch and Debian's existing packaging work as a generic means of supporting cross-compilers? we could support cross-compiling to anything with the same structure - I'm thinking MinGW-w64 here of course, but I imagine it would apply to other targets too, some of which are supported in Debian already using the /usr/triplet/include directories. The header-layout issue is independent of the need for dpkg-architecture to know about an arch to use multiarch mechanisms for cross-building to it. But that's very easy to do (An easy way to add arches in a local config file is something that's been mentioned before). Having mingw as an arch is a good idea if it isn't already. And you can still use a sysroot and non-multiarch ways of filling it if you prefer. I haven't really experimented with multiarch and sysroot at the same time but SFAICS it should work. Indeed, but when I first saw multiarch I couldn't help but think this was a really nice way to support cross-compilation too; at the time I was told it was too early to consider that, it would appear now is the right time before things become set in stone. Unless I'm mistaken, if we go down the (2) route we could still have a mingw (partial) architecture, but every single package we'd want to build on it would need to handle it specifically... Regards, Stephen I think you are mistaken. mingw should handle just like any other architecture. Only difference being that you can't build natively, you have to cross-build. But let us know if you tried it. MfG Goswin -- 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/20130511093928.GE3334@frosties
Re: [Popcon-developers] encrypted popcon submissions
On Sat, May 11, 2013 at 11:43:25AM +0200, Bill Allombert wrote: On Fri, May 10, 2013 at 10:44:25PM +0200, Peter Palfrader wrote: On Fri, 10 May 2013, Bill Allombert wrote: I am considering activating encryption of popularity-contest submissions using public key cryptography to protect popcon submission while in transit. Do you think the benefits outweight the drawback that the admin no longer can be certain we don't send anything we shouldn't? I do not think it makes much difference. The report is sent by a simple shell script which you can easily audit. Even if you use a network scanner, you can check that what is sent is the encrypted file since you have a copy of it. And in any case, there will be an option do deactivate encryption if you so chose. - The popcon.debian.org server will know the matching private key and use it to decrypt report before storing them. The drawback is the computing cost on the server. Currently we are processing about 25000 report each days, which would require about 2 hours of 'real' CPU time to decrypt, which is too much for popov.debian.org. On the other hand this is easily parallelisable. Why do you think this is too much for popov to handle? I did some benchmark. Currently popov CPU has about 20% of a real CPU. Currently processing the popcon data takes between 6h30 and 8h30. At this rate decrypting the report would take an additional 7h. And if it really is, adding vCPUs is easy. Excellent. Why is transport encryption (ala https) not sufficient? I do not see why https would be faster than gpg for the same level of security. There are some issues with https: 1) https does not handle email submissions. gpg is transport agnostic. 2) https requires more client-side support than what perl-base provide. On the other hand, apt already depends on gpg, so we can assume that gpg is available. 3) managing https certificate is harder. A gpg public key can easily be included in the popularity-contest package On the other hand it can not as easily be changed when the private key is compromised. The window between the hack being detected and data being secure again would be far greater with a gpg key in the package. 4) https allows the web server to see the decrypted content. gpg encryption only allow the popcon user to read it. 5) https require CPU time when the reports is received. At time where a lot of reports are received at the same time, this can overload the CPU. By contrast, gpg provides much flexibility in CPU time allocations. Cheers, MfG Goswin -- 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/20130511095535.GF3334@frosties
Re: Depends: libfoo:foreign ???
On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client It appears that will block it from reaching testing: Indeed, Britney does not support those annotations (at the moment?). To avoid issues with this kind of thing, we made her consider such dependencies for unsatisfiable[1]. So for now anything using that form in Depends or Pre-Depends will not reach testing (without manual intervention from the Release team and I am not sure how likely we are to do that). http://packages.qa.debian.org/t/teamspeak-client.html The proper thing to do would be to remove the amd64 package entirely and have users install the i386 version. Indeed, I believe that should work. It is the indended solution. If it doesn't work then that is a bug and needs to be fixed. ~Niels [1] Though she ignores them in Recommends/Suggests and possibly also in Breaks/Conflicts. A Depends like in this case is never right since it mixes biarch (libc6-i386) packages with multiarch (libfoo:i386). I would say that a foreign dependency on a library is never right. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Also, iirc, the use of foreign dependencies is only supposed to be on packages with Multi-Arch: allowed. This is for interpreters and plugins/lib bindings where the normal automatic method can't work. So maybe DAK could be made more restrictive here. MfG Goswin -- 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/20130509093918.GA31432@frosties
Re: Merging / and /usr (was: jessie release goals)
On Tue, May 07, 2013 at 04:56:04PM +0100, Roger Leigh wrote: On Tue, May 07, 2013 at 05:35:11PM +0200, Marco d'Itri wrote: On May 07, ?? ?? pashev.i...@gmail.com wrote: What about merging / and /usr ? An ambitious plan. I strongly support the everything in /usr scheme, but let's first consolidate support for standalone /usr must be mounted by the initramfs. I'm working on this at the present (I'm re-doing the proof of concept patches I made a few months back, to clean it all up and make it work in a wider number of cases). I hope to have something by the end of the week, time permitting. That said, I'm not in support of moving things to /usr; it's completely backward. Once we have / and /usr mounted in the initramfs, then we can work on deduplicating shared paths on / and /usr. This will give us the option of migrating either way in the future (if ever). If we do this, I'd prefer to make /usr a symlink to / on new installs, while retaining full backward compatibility for existing users, and requiring zero packaging changes. But the other way would also be possible--it would just be a matter of d-i setting up the links. But none of this is the primary reason for doing this initially. Regards, Roger If you make /usr a symlink to / then there will be to distinct paths to each file and that will confuse dpkg. The first problem that comes to mind is package A containing /bin/foo and package B containing /usr/bin/foo. Dpkg will happily install both without noticing the file overwrite conflict. Or package A 1.0 contains /bin/foo and package A 1.1 contains /usr/bin/foo. IIrc then dpkg will unpack A 1.1 (overwrite /bin/foo with /usr/bin/foo) and then remove /bin/foo. Leaving you without /usr/bin/foo. MfG Goswin -- 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/20130509095031.GB31432@frosties
Re: Merging / and /usr (was: jessie release goals)
On Wed, May 08, 2013 at 09:12:12AM -0400, The Wanderer wrote: On 05/07/2013 11:41 AM, Paul Tagliamonte wrote: On Tue, May 07, 2013 at 05:36:41PM +0200, Marco d'Itri wrote: On May 07, Paul Tagliamonte paul...@debian.org wrote: No please. We are good about making sure they each mean something important, and there's no good reason. Not really nowadays: more and more things needed at boot time are in /usr and there are no plans to fix them. We also support setups that might need this split due to low storage, such as arm devices. everything in /usr actually means that supporting these devices is much easier. Not when you have a 500 meg internal storage that the firmware boots off of, and using a multi-gig CF card to store the mega-awesome-app you're using it for. This seems to point to what I think may be a key question in the ongoing/recurring '/usr'-related discussions, which I don't think I've seen addressed in the iterations I've seen. If it has been addressed well, please point me to past iterations which have so addressed it, rather than rehashing the whole thing here just for my benefit. The question, expressed in a number of different ways to provide a type of clarity by triangulation, is: Why does /usr exist in the first place? Why was it created, way back in the day? What is its purpose, what is it for? My understanding, to the extent that I've had one, has always been that - to oversimplify it a bit - / is for installs of things which are system-essential, and /usr is for installs of things which are not. The definition of system-essential can be debated, but again, my understanding of it has been that it incorporates A: boot-essential (things required for boot) plus B: emergency tools (things you want to try to guarantee will be available in an emergency, things-are-broken-and-we-have-to-fix-them scenario, such as might leave you needing to rely on single-user mode). The initial problem was that the harddisk was too small. So you had to split things up into 2 harddisks somewhere. / was the first disk, /usr the second. We have long since past this problem. Except it is comming back. With embedded systems that boot from a small flash that contains / and then have /usr on a non-bootable drive. But those systems can put an initrd on flash to boot. I'm not aware of any situation where an initrd can't be used (can't, not don't want to). For Debian the problem has become that / must contain everything needed to be able to mount /usr. And that includes such odd cases as /usr on NFS over wlan and a million other permutations of any possible way to hide /usr somewhere. The problem in recent years has been twofold: 1) some people have become more creative and used new things to put /usr on. Like iscsi or nfs over wlan. So more tools are needed in / to make this possible. 2) most people don't have a seperate /usr or /usr on the same medium as / and upstreams have been ignorant or neglient about ensuring the right things end up in / and only things from / are used before mounting /usr. The less people have a seperate (and complicated) /usr the less this is tested and more bit-rot creaps in. We have reached a point where other distributions have given up and upstreams are saying they don't care for a seperate /usr anymore. The real-world scenario is obviously far more complicated than that - dragging in definitions for what goes in /etc and /var and /home, and further defining a distinction between /usr and /usr/local, and so forth. But the basic concept seems simple enough as far as it goes. Now, the next question is: does that distinction, that defining purpose for the existence of /usr, still make sense in the modern world? Almost everyone boots via an initrd nowadays AFAIK, which would seem to more or less negate the advantages of keeping boot-essential things separate that way - but almost still isn't everyone, and I don't know whether we want to explicitly step away from support for non-initrd boot configurations. The emergency tools side of it I'm less clear on. It's relatively unimportant for cases where you have physical access to the system in the emergency scenario, assuming you can take the machine down long enough to boot into a rescue environment on removable storage (LiveCD or USB drive, et cetera), but there may not be any analogous alternate fallback for cases where you only have remote access to a machine, or where taking the machine down that way may not be an option. There's also the question of what scenarios this could actually help in, which may be limited enough to make the entire thing negligible. On most (numerically) systems you have a bootloader that lets you choose what to boot and it is trivial to add an emergency initrd with all the repair tools you would ever want. That is actualy much better than using / for emergencies since then / will not be mounted and can be safely repaired too.
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On Fri, May 03, 2013 at 04:38:40PM +0200, Josselin Mouette wrote: Le vendredi 03 mai 2013 à 09:18 +0800, Chow Loong Jin a écrit : While we're at it, can we also have source-only uploads? Uploading potentially huge binary packages that just go to /dev/null seems like a pointless waste of bandwidth to me, and the only for argument I've heard (which I don't buy) is so that we know maintainers have test-built their packages. There is a solution to both the upload bandwidth problem and the the problem that buildd binaries are untested, but I???m afraid it implies changes to dak. This means configuring dak to accepting only two types of uploads: - source-only uploads They are pushed to the buildds, and the produced binaries (including arch:all) are put in a staging area (much like incoming.d.o). These binaries can be downloaded, but the .changes cannot (to forbid skipping the second step). - binary-changes-only uploads, without binaries The developer uploads a sole .changes referencing the set of binaries he has downloaded (and tested, although it is hard to force that step). Anything referencing binaries not built on the buildds is ditched. This way, you ensure that the actual binaries ending up in the archive have been tested, which is neither the case with just source-only uploads (no binaries tested) nor with ditched-binary uploads (the binary might be built in a different environment). Cheers, Firstly: We already know we can't trust all maintainers to build binaries in a clean chroot. Nor can we trust them to test binaries they upload. What makes you think maintainers will not simply blindly create changes files for buildd build binaries and upload them? Secondly: Maintainers will only test binaries for their own arch. Most archs won't get this extra test step so most uploaded debs will still remain untested. Overall it seems like that extra step will just create extra work for the maintainer at a time (hours, days, weeks after the upload) not of his choosing with little benefit to the user. Those maintainers that do properly test stuff will test the packages before doing the source only upload. And I have enough confidence in the autobuilders to produce working debs from a well tested source. It's not 100% but close enough. The rest will be cought in unstable quickly enough. Those maintainers that skip or even circumvent testing will always do so. And I would rather have buildd build debs there than whatever those maintainer manage to hack together to produce a deb. I've seen uploads with debs where the source had a make error in debian/rules. There is no way that source package could ever have produced the uploaded deb. At least those kind of errors would be eliminated. MfG Goswin -- 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/20130508095359.GD13185@frosties
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On Fri, May 03, 2013 at 07:11:35PM +0200, Bernhard R. Link wrote: * Holger Levsen hol...@layer-acht.org [130502 12:28]: People do this all the time: upload packages built against local packages, experimental or even on Ubuntu to Debian sid. /me shivers. This hurts. There is no reason not to rebuild in sane environments. Can we please fix this for the next release?! I'm not sure the cure is not worse than the problem. Apart from the big problem of making it even easier for people to upload trash without testing it (both wasting buildd resources and lettings users install broken packages which any trivial testing would have catched, from which I've seen far too many), reducing the buildability of packages is a cruical problem for freedom. Having to upload binary debs is not preventing that. If we step towards rebuilding everything in a highly artifical environment, it should be made clear that a package having missing build-conflicts or any other bug preventing it from being built on a real system should still be important bugs afterwards. Once we drop that and only give people the right to modify the software we distribute but no longer the possiblity to do so on their own, the Free we are so proud on gets mood. How does always building in a clean chroot impact the freedom in any way? The build tools are free and any user can set up their own clean chroot to build the source. So even if Build-Conflicts were to bit-rot completly I don't see how that affects freedom in any way. Also build systems tend to degrade quite heavily over time and get more and more specific. In some years we might not be able to switch to some other builder tools as too many packages depend on the specifics of the ones we currently have. I don't see how that can be true. We have been using sbuild for ages and we have pbuilder and other alternatives working just as well. I don't see any degradation and reliance on sbuild hapening so far. And mainatiners will still be expected to build and test their packages at home, which tend to not to use sbuild. So I think the fear that sources will rely on specific sbuild behaviour is unfounded. MfG Goswin -- 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/20130508100438.GE13185@frosties
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On Sun, May 05, 2013 at 12:18:44AM +0100, Wookey wrote: The harder question is how/when to do that QA. The time to do QA is now and always. Otherwise it just collects and becomes too much. I resisted making the suggestion of doing it by default on all builds as that seemed a step too far, although I see someone else did :-). In fact, given the significant overhead of build-dep installation, build-twice would actually be quite a small overhead for many smaller packages (and only needs to be done on one fast arch, not all of them). It would clearly be annoying for builds that are large/slow anyway, which implies some kind of exception list, which was kind of the point where I decided this wasn't going to fly. If one arch tests it that should be enough for 99% of cases. So limiting it to fast archs should be fine. This could even be done dynamically. Use --build-twice only if there are less than X source in needs-build. In times of stress and on slower archs the option would be droped automatically. From time to time archive wide rebuilds are done. Those could certainly do --build-twice if buildds don't. MfG Goswin -- 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/20130508102045.GF13185@frosties
Re: git as a source package format?
On Sat, May 04, 2013 at 12:11:23PM +0800, Paul Wise wrote: On Sat, May 4, 2013 at 10:41 AM, Charles Plessy wrote: The fact is that Debian does not make much effort to ensure that we do not distribute unredistributable files in our mirrors and installation media, once a package has passed its first copyright and license review. That is simply not true, every developer is responsible for checking this before every upload, to NEW or directly to unstable. I don't know about you or the rest of Debian but I certainly take this responsibility seriously and perform this very necessary action. And even if it were true then how should that first copyright and license review work with git format? Do you expect ftp-master to audit every single commit? After the initial upload subsequent uploads are easier to check since only the diff to the previous one needs to be considered. Still with git format that could be a lot of commits. MfG Goswin PS: For me a debian source package is the compact snapshot of the VCS repository that was used to build a binary. If I want history I checkout the VCS. -- 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/20130506144644.GA21910@frosties
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On Sat, May 04, 2013 at 09:33:14PM +0200, Helmut Grohne wrote: On Fri, May 03, 2013 at 04:53:59PM +0800, Thomas Goirand wrote: I think there's a consensus, the problem is who's going to do the work for automating dropping of binaries and rebuild. Not implying that I am the one doing this work, I would like to learn more about what needs to be touched to achieve aspects of the following features: (Again not implying that they are all desired.) * Throwing away binaries and rebuilding everything. * Permitting source-only uploads. * arch:all binNMUs. Pointers to relevant documentation appreciated. Specific questions: * Which tools/infrastructure needs changes? * What are the general changes needed? * How can those changes be split in independent pieces and applied without interfering badly? Helmut Maybe as an intermediate and imediate step we could switch to uploading only arch:all debs for mixed packages. That is already supported by DAK and the buildds and would drop a lot of locally build debs. MfG Goswin -- 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/20130506145729.GB21910@frosties
Re: NEW processing during freezes
On Thu, Apr 25, 2013 at 09:44:58AM +0800, Chow Loong Jin wrote: On 23/04/2013 23:15, Thorsten Glaser wrote: Joachim Breitner nomeata at debian.org writes: The (luxury) problem is that I got used to it and began uploading the new (and NEW) dependency bar of package foo along with the new version of foo (instead of uploading bar first, wait for NEW processing and only I think you shouldn???t do that anyway. After all, to do that, you???d have to manually install the new version of bar in the chroot you used to build foo, which is a violation of the ???clean, minimal chroot??? rule if read strictly (and, from experience with bad non-buildd uploads, I tend to read it strictly). If you use a local APT repository containing bar, then it still fulfils the clean, minimal chroot rule, since the debs you have uploaded aren't rebuilt for the particular architecture you're building foo on anyway (assuming that you use the same debs you uploaded to the Debian archive). By uploading foo with a dependency on a NEW package you make foo uninstallable for a time. Which on its own is already a bad thing. Worse it only works if bar is a new source package or you have a versioned Build-Depends on the new version. Otherwise all buildds will simply compile the new foo against the old bar and then you have one arch where foo is uninstallable while all others work. Maybe this calls for an upload manager or a dependency based delayed upload queue. You can prepare and sign the upload at any time after all. Only the upload itself needs to be timed to the NEW processing. MfG Goswin -- 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/20130502090646.GC29888@frosties
Re: Bug#706159: ITP: libzmq-libzmq2-perl -- Perl bindings to the libzmq 2.x library
On Thu, Apr 25, 2013 at 07:09:04PM +0200, Alessandro Ghedini wrote: On gio, apr 25, 2013 at 06:36:39 +0200, Julian Taylor wrote: On 25.04.2013 18:01, Alessandro Ghedini wrote: * Package name: libzmq-libzmq2-perl Version : 1.07 Upstream Author : Daisuke Maki dais...@endeworks.jp * URL : https://metacpan.org/release/ZMQ-LibZMQ2/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl bindings to the libzmq 2.x library [...] what is the difference to libzeromq-perl that we already have in unstable? The ZeroMQ module (libzeromq-perl) is deprecated in favour of ZMQ::LibZMQ2 (libzmq-libzmq2-perl), ZMQ::LibZMQ3 and ZMQ. My intention would be to have libzeromq-perl removed at some point soon (this is why it's not in wheezy, also see #690680) but it's been taking me a long time (mostly because of a lack of free time from my part). Cheers So is this a rename of the old package, a fork using the new namespace or a rewrite? MfG Goswin -- 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/20130502090905.GD29888@frosties
Re: Bug#706458: ITP: inotify-hookable -- blocking command-line interface to inotify
On Tue, Apr 30, 2013 at 01:58:58PM +0200, Dominique Dumont wrote: Package: wnpp Owner: Dominique Dumont d...@debian.org Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: inotify-hookable Version : 0.7 Upstream Author : ???var Arnfj???r??? Bjarmason a...@cpan.org * URL : http://search.cpan.org/dist/App-Inotify-Hookable/ * License : Artistic or GPL-1+ Programming Lang: FIXME Description : blocking command-line interface to inotify inotify-hookable is a program that monitor files with Linux inotify. This program accepts options to specify the files to be monitored and the command to run when a file has changed (based in kernel inotify) Example: inotify-hookable -f foo.c -c 'gcc -o foo foo.c' How is that better than the existing inotify shell tools? What do they lack and why not improve them instead of writing a new one? MfG Goswin -- 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/20130502092958.GE29888@frosties
Re: NEW processing during freezes
On Thu, May 02, 2013 at 11:31:54AM +0200, Andreas Beckmann wrote: On 2013-05-02 11:06, Goswin von Brederlow wrote: versioned Build-Depends on the new version. Otherwise all buildds will simply compile the new foo against the old bar and then you have one arch where foo is uninstallable while all others work. This is quickly fixed by doing a binNMU on the uploaded-arch. People do this all the time: upload packages built against local packages, experimental or even on Ubuntu to Debian sid. Rebuilding against the NEW package can be done by binNMUs (with proper dep-waits), but that very much smells like a transition that is to be handled by the release team. *shiver* Some people are realy broken. Maybe this calls for an upload manager or a dependency based delayed upload queue. You can prepare and sign the upload at any time after all. Only the upload itself needs to be timed to the NEW processing. That will only work if the delayed package adds a versioned B-D on the NEW package (so it comes with an explicit dep-wait), otherwise it will be uploaded after NEW processing, but before the NEW package was built everywhere. And rebuilding the old package may have higher precedence than building something completely NEW on architecture $slow. Andreas No, if the package has a versioned B-D then the buildds already do the right thing and the delayed queue would be pointless. I was thinking more of something that detects the depends on the uploaded binary and figures out you build against a too new version of a lib or of uploading a command file along with the package that says what to wait for. The queue would have to scan the Packages.gz files (hopefully including incoming to minimize delays) to decide when to upload a package. Going just by Sources.gz would defeat the purpose again. Another usefull feature would then be for the queue to notify the uploader when a package being waited on failed to build. Otherwise the upload would wait forever. MfG Goswin -- 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/20130502145926.GA2080@frosties
Re: Bug#706458: ITP: inotify-hookable -- blocking command-line interface to inotify
On Thu, May 02, 2013 at 04:05:45PM +0200, Dominique Dumont wrote: On Thursday 02 May 2013 11:29:58 Goswin von Brederlow wrote: How is that better than the existing inotify shell tools? What do they lack and why not improve them instead of writing a new one? inotify-hookable main advantage over inotywait are: - you can specify command to run after watch as option. - watch are restarted - when watching a directory, inotify-hookable ignore emacs and backup files by default. - you can specify different commands to run depending on which files was changed inotifywait is better suited to be used within a shell script. inotify-hookable is better when you just want to run something on the command line. I currently use the following command to compile a bunch of less files into a css file. The css file and the less file are located in the same directory: inotify-hookable -w . -i '.*css$' -c '../../enyo/tools/lessc.sh ./package.js' Still no argument to have 2 source packages. The inotify-tools source could provide both interfaces if they can't be merged into a single one. Inotify-tools already has inotifywait and inotifywatch. I don't see a reason why inotifyhook couldn't be added as 3rd tool. They could probably share a lot of code too. Just my 2c, Goswin -- 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/20130502150720.GB2080@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Fri, Apr 19, 2013 at 12:16:11PM +0300, Niko Tyni wrote: On Thu, Apr 18, 2013 at 10:56:34AM +0200, Goswin von Brederlow wrote: On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote: Niko Tyni nt...@debian.org writes: FWIW, I've done ABI-incompatible uploads of perl to experimental in the past without changing the perlapi-* virtual package name or the libperl SONAME. The aim was to experiment with different configuration options, particularly 64-bit integers and 128-bit long doubles. I certainly didn't support upgrades from those versions to the same extent as I'd have done for unstable. OTOH, the packages were pretty close to uninstallable on any non-minimal systems anyway, as we didn't offer corresponding rebuilt XS modules in experimental. Oh, that's a good point. Yes, I hadn't thought about that specific case for testing ABI breakage in experimental. But then that simply is a broken upload. It will break horribly if you install the experimental perl but keep other perl packages from sid. Well, it wasn't installable with perl packages in sid at the time due to a major version upgrade, which is why I was experimenting with incompatible ABI changes in the first place. (This was around perl/5.12.0-1 or so.) That was OK then. Just in general one should think about such things. Note: This isn't an attack of you or that upload. You/perl just have the horrible luck of being used as an example. You should have set the perlapi-* to include -experimental or something to make it differ from sid. Having the perlapi-* provides and depends makes this simple. First, this was against the policy at the time (since fixed with #579457.) Second, the ABI changes would also have required an extra libperl SONAME change with the implied NEW processing. That's too much overhead IMO. Yeah, NEW queue processing can be bad. But if it realy is just experimenting and the dependencies prevent mixed setups then I wouldn't take the SONAME so serious. The SONAME change is there so old and new stuff can coexist and migrate over time. That isn't applicable to such an experimental situation. Imho experimental packages should be made with the hope that they could enter sid in the future. Sure they are for experimenting. But say the experiment is successfull shouldn't the package go to sid? If you have to redesign them at that point you will just introduce new bugs at that point and restart the testing process again. The experiment in this case was seeing if the test suite passes on all architectures or not. It did not because long doubles are weird on powerpc, so I reverted the change. I then uploaded the next try (again, to experimental of course) without changing the perlapi-* or the SONAME. I still think that expecting full-blown ABI change handling for iterations like this in experimental is too much. Totaly. Not for every iteration anyway. As long as mixing/breaking sid is prevented with an SONAME change or dependencies that is fine. I think ftp-master would kill you if every experimental upload had to go through NEW. As a side note: What you did probably shouldn't have been using experimental at all. This should have gone to the long proposed build me this package buildd extension. All you wanted (it sounds like) was to compile the package and see the results of the built time test suite. It would be nice if someone would work on implementing this idea. That way maintainers could upload sources for test builds on selective archs. MfG Goswin -- 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/20130423122218.GA26534@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote: On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote: Oh, that's a good point. Yes, I hadn't thought about that specific case for testing ABI breakage in experimental. But then that simply is a broken upload. It will break horribly if you install the experimental perl but keep other perl packages from sid. Welcome to experimental. Stuff might break, stuff might be deliberately broken, ... I might also not properly manage abi changes in libraries in experimental, especially when it is me packaging snapshots. /Sune I sure hope you mean breakages between different experimental versions. Not breakages compared to stable/testing/unstable versions. MfG Goswin -- 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/20130423122357.GB26534@frosties
Re: alternative debian/rules
On Mon, Apr 22, 2013 at 11:23:51AM +0100, Jonathan Dowland wrote: On Tue, Apr 16, 2013 at 01:46:20PM -0700, Steve Langasek wrote: On Tue, Apr 16, 2013 at 02:28:18PM +0200, Goswin von Brederlow wrote: % ls -lh debian/rules lrwxrwxrwx 1 mrvn users 1 Apr 16 12:27 debian/rules - /usr/bin/dh I don't understand your point, other than to demonstrate that you're doing something which doesn't conform to policy? And running something like csh. Both seem like bad ideas! Huh? That's zsh and there was no point besides the comedic value. MfG Goswin -- 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/20130423124935.GC26534@frosties
Re: Bug#705879: moreinfo
On Tue, Apr 23, 2013 at 12:09:49AM +1000, Dmitry Smirnov wrote: On Mon, 22 Apr 2013 17:50:37 Holger Levsen wrote: ah! thanks for summarizing why this is not a bug, but rather a feature (UUIDs for partitions) made for this situation not being used! For the record about a year ago when I tried to use UUID for external journal on ext4 it didn't work because (I think) it was not implemented. Probably it still doesn't work although I could miss something in recent changelogs. Although UUID is very useful for partitions I didn't mention UUID because I knew it wouldn't work for ext4 external journal. see eg http://wiki.debian.org/Part-UUID or debian-u...@lists.debian.org for more info. Thanks for the link. Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B If UUID doesn't work then I think you are left with LVM as the only option to get a reliable device name. MfG Goswin -- 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/20130423125219.GD26534@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote: On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? Thomas Why wait? Well, ok, better not add changes to dpkg right now. :) Has anyone tried patching dpkg to keep the epoch in the deb filename? Anything break? MfG Goswin -- 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/20130418084850.GB24658@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote: Niko Tyni nt...@debian.org writes: FWIW, I've done ABI-incompatible uploads of perl to experimental in the past without changing the perlapi-* virtual package name or the libperl SONAME. The aim was to experiment with different configuration options, particularly 64-bit integers and 128-bit long doubles. I certainly didn't support upgrades from those versions to the same extent as I'd have done for unstable. OTOH, the packages were pretty close to uninstallable on any non-minimal systems anyway, as we didn't offer corresponding rebuilt XS modules in experimental. Oh, that's a good point. Yes, I hadn't thought about that specific case for testing ABI breakage in experimental. But then that simply is a broken upload. It will break horribly if you install the experimental perl but keep other perl packages from sid. You should have set the perlapi-* to include -experimental or something to make it differ from sid. Having the perlapi-* provides and depends makes this simple. Imho experimental packages should be made with the hope that they could enter sid in the future. Sure they are for experimenting. But say the experiment is successfull shouldn't the package go to sid? If you have to redesign them at that point you will just introduce new bugs at that point and restart the testing process again. But that might just be me. MfG Goswin -- 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/20130418085634.GC24658@frosties
Re: epoch in filenames for packages (was: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Thu, Apr 18, 2013 at 11:04:11AM +0200, Ansgar Burchardt wrote: On 04/18/2013 10:48, Goswin von Brederlow wrote: On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote: On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. It handles it by rejecting the later upload. I wonder what would happen if one uploaded a foo_1.2.3-1_amd64.deb with a new epoch but same hash. :) The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? [...] Has anyone tried patching dpkg to keep the epoch in the deb filename? Anything break? [1] and [2] include at least dpkg-genchanges and dpkg-source breaking. [1] http://bugs.debian.org/551323 [2] http://bugs.debian.org/645895 Ansgar Both of those are part of dpkg so they should have been patched too. I ment does anything outside of dpkg break. But that is probably covered in the thread mentioned in the last mail. MfG Goswin -- 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/20130418144535.GD21076@frosties
Re: Automatically satisfying Build-Depends from local control file
On Tue, Apr 16, 2013 at 09:19:27PM -0700, Nikolaus Rath wrote: Hello, When downloading a source package from somewhere else, I often find myself in the situation that after.. If by downloading you mean apt-get source foo then the answere is: apt-get build-dep foo Otherwise there isn't a general solution, lots of suggestion in the other mails. MfG Goswin -- 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/20130418144746.GE21076@frosties
Re: multiarch and interpreters/runtimes
On Thu, Apr 18, 2013 at 04:41:35PM +0200, Matthias Klose wrote: There are maybe not many use cases where you do want to install an interpreter like python or perl for a foreign architecture, but there are some use case where such a setup makes sense. For now I see this limited for architecture pairs like amd64/i386, armel/armhf, ia64/i386, i.e. for architectures where the foreign interpreter can be run (without qemu). Use cases are - running the OpenJDK hotspot JIT for i386 on ia64, an implementation which is much faster than the OpenJDK Zero interpreter on ia64. This can be done today in wheezy. The OpenJDK packages do use different prefixes and are co-installable. While the packages come with binaries, these are all installed using alternatives, so the packages can even be installed for more than architecture (no, I don't like this alternatives schema much). Ia64 does no longer (for a while now) support i386. The support has been removed from hardware years ago and from the kernel too. You have to use qemu there. Is that still faster then the ia64 interpreter? So what is the status for some runtimes/interpreters (would like to see some follow-up/corrections from package maintainers)? - OpenJDK: runtime and development files are co-installable, the package itself is not cross-buildable, and afaik nobody did try to cross build any bindings. - Perl: Afaik, Neil did prepare the interpreter to cross-build, and to co-install the runtime and development files. What about cross-building third party modules? - Python: co-installable runtime and development files, cross-buildability upstreamed for 2.7.4 and 3.3.1. There is a way to cross-build third party modules using distutils/setuptools. Packages are available in experimental, but because I didn't backport this to 2.6 and 3.2, not much useful. Install an Ubuntu raring (13.04) chroot to experiment with these. Details at http://wiki.debian.org/Python/MultiArch - Ruby: Afaik, not yet started on multiarch. - Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches are available in Debian bug reports. Currently the shared libraries are split out into separate packages, and are co-installable. Not yet tested if this enough to run an embedded interpreter. - Lua, Ocaml, Haskell, Guile, ... ? Matthias The support for this comes with Multiarch: allowed, which will only be allowed after wheezy. The interpreter declares itself Multiarch: allowed and then depending packages can specify wether they must match the abi (loadable binary plugins) or can work with any arch (binary packages that also contains some perl scripts). Co-installability of interpreters is generally not planed and would have to be made as custom solutions, i.e. place the interpreter in /usr/lib/x86_64-linux-gnu/perl/ and provide /usr/bin/perl as alternative. Also cross-building is not relevant for this issue. Normaly you would build it native (e.g. i386 chroot) and then install it on some other arch (amd64). But I think multiarch support for interpreters will be slow. There aren't many use cases so not a lot of pressure to implement it. Anyway, all of this has to wait till after wheezy. So get that out first. MfG Goswin -- 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/20130418145645.GF21076@frosties
Re: multiarch and interpreters/runtimes
On Thu, Apr 18, 2013 at 06:15:26PM +0100, Ian Jackson wrote: Goswin von Brederlow writes (Re: multiarch and interpreters/runtimes): Co-installability of interpreters is generally not planed and would have to be made as custom solutions, i.e. place the interpreter in /usr/lib/x86_64-linux-gnu/perl/ and provide /usr/bin/perl as alternative. I think it's important to distinguish between (a) coinstallability of interpreter executables for use in #!, or explicit invocation and (b) coinstallability of the interpreter code as a library which can be embedded in other applications. So for example, you are saying that coinstalling i386 and amd64 versions of tclsh (which is normally found in /usr/bin) is not generally planned. But coinstalling i386 and amd64 versions of libtcl.so _is_ intended and supported by multiarch, and presumably also of tcl extensions. Please correct me if I'm wrong. You are fully correct there. Having dynamic libraries in /usr/lib/ coinstallable is a simple matter of moving them to the multiarch dir. The problem is indeed only the binary and its #! invocation. I'm not sure what the situation is for plugins with such interpreter libs. If the plugin is a libPlugin.so that is linked against libInterpreter.so then this should just work automatically like any library dependency with a simple Multiarch: same. If it is not linked a simple Depends should do. But don't nail me on it. A specific example might turn out to be more complex and need M-A: allow. So split second thought, suboptimal solution looks like this: Package: interpreter Architecture: any Depends: libinterpreter Multi-Arch: foreign Package: libinterpreter Architecture: any Multi-Arch: same Package: plugin (metapackage) Architecture: any Depends: interpreter, libplugin Multi-Arch: foreign Package: libplugin Architecture: any Depends: libinterpreter Multi-Arch: same Package: app-with-lib Architecture: any Depends: libinterpreter, libplugin Multi-Arch: foreign (optional) Package: app-with-script Architecture: any/all Depends: interpreter, plugin Multi-Arch: foreign (optional) Package: script Architecture: all Depends: interpreter Multi-Arch: foreign (optional) Note: This uses an extra package (plugin) to work around Multi-Arch: allowed not being allowed. Anyway, all of this has to wait till after wheezy. So get that out first. Right. Thanks for the explanation, anyway. Ian. MfG Goswin -- 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/20130418183535.GA16749@frosties
Re: alternative debian/rules
On Fri, Apr 05, 2013 at 10:47:39AM -0700, Russ Allbery wrote: ?? ?? pashev.i...@gmail.com writes: Indeed. So, in any case one can use its own tool just like dh: %: debian/megatool $@ Yes, from a Policy perspective. Although please consider using dh and its framework instead to make life easier for everyone else in the project who may have to help out with maintaining the package, such as the security team. It has a nice plugin module system that lets you add custom infrastructure for particular types of projects without changing the basic framework. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ % ls -lh debian/rules lrwxrwxrwx 1 mrvn users 1 Apr 16 12:27 debian/rules - /usr/bin/dh MfG Goswin -- 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/20130416122818.GA21076@frosties
Re: detailed lists with archive contents - more than just Contents
On Sun, Apr 14, 2013 at 04:48:20PM +0800, Paul Wise wrote: On Thu, Feb 21, 2013 at 9:54 PM, Paul Wise wrote: For duplicate file detection, there is now the Debian duplication detector (still importing the archive): http://dedup.debian.net/ This will soon be linked to from the PTS for packages that share a significant amount of data. Here is an example of what to expect: http://packages.qa.debian.org/a/a2ps.html Will that also detect files in multiarch packages that are not identical? Or files in foo_arch.deb that should be in foo-common_all.deb? MfG Goswin -- 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/20130416130420.GB21076@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sat, Apr 06, 2013 at 01:08:49PM +0900, Charles Plessy wrote: Le Sun, Mar 31, 2013 at 07:02:15PM -0400, Scott Kitterman a écrit : Depends: r-base-core (= 3.0.0~20130327) , r-base-core ( 4) or you could have an API virtual package: r-base-api-3.0 Hi Dirk and everybody, since we already have a substitution variable in most of the R packages (R:Depends), I think that we can use it to address the problem. First, let's define the problem: R broke backwards compatibility a couple of times since it has been packaged. Rebuilding packages is usually done swiftly, but there remains the problem of transitions to Testing and updates on the users computers. There is usually a gap of some years between breakages, so we do not want an over-engeneered solution. I like the idea of an api virtual package, as it requires little work from the parties involved and solves most of the problem. (The exception being that partial upgrades from Wheezy to Jessie will not be supported, but this is also the case in the current situation). In short: That is not an exception but THE intention. It's the whole point of having an api virtual package. In long: The R package breaks compatibility in such a way that a partial upgrade simply won't be functional. You either update them all or none. Till now installing any package compiles against a newer R API would pull in the newer r-base-core package to fullfill its version requirement but would not force old R packages already installed to also be updated. This leads to procken packages on partial update. Introducing the api virtual package will enforce that all R packages will be compiled against the same R API, against a compatible r-base-core. Installing one package compiled against the new R will force apt/aptitude to also update all the already installed R packages, which is what is required. - /usr/share/R/debian/r-cran.mk, which is used in most R packages and produces the R:Depends substitution variable, would make packages depend on the r-api virtual package instead of requiring a version equal or superior to the version of r-base-core used at build time. It might be enough to only depend on the api or you might need both, the api virtual package and a versioned depends for a minimum version. But that depends on the circumstances. Design it so that it is easy to have both and so that you don't miss updating the minimum version when required. - Next time R breaks backwards compatibility, Dirk would need to modify the Provides: line in debian/control and voilà, the new R core package can not be installed on a system without removing or upgrading the R library packages that were built with the old API. It might make sense to have a single file r-api-virtual-version (or so) in the source and generate the Provides: field and /usr/share/R/debian/r-cran.mk from that single source. Let's discuss the details on #704805 Have a nice week-end, MfG Goswin -- 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/20130416131604.GC21076@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 01:13:29PM +0100, Neil Williams wrote: On Mon, 1 Apr 2013 17:42:29 +0600 Andrey Rahmatullin w...@wrar.name wrote: On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote: Thanks for trading the R release cycle with Debian's and for delaying the release. The harm has already been done, so somebody should probably go and create a transition tracker for it? Rather than accept the harm, surely the release team could simply roll back the upload in some manner? Only by uploading older versions with bumped version numbers, and that still will cause testing and unstable to have different binaries. That is why we have epochs - an epoch is ignored for the purposes of the binary packages, see zlib1g and other packages using epochs. The existing tools have sane support for epochs, exactly to avoid these problems. http://packages.debian.org/sid/zlib1g 1:1.2.7.dfsg-13 http://ftp.uk.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.7.dfsg-13_amd64.deb dpkg -l | grep ':' The version currently in wheezy could be re-uploaded with a single change to the changelog to start using an epoch and using the version string currently in wheezy for the post-epoch string of the new version. If wheezy had foo 1.2.3-1 and unstable 2.0.0-1, the epoch version of 1.2.3 would be 1:1.2.3-1 which is newer than 2.0.0-1 but be compatible with 1.2.3-1 already in wheezy. Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. You would have to upload foo 1:1.2.3-2 to avoid the name clash. And not, we do not have epochs to temporarily downgrade a package after a botched upload. Esspecially when the package doesn't yet have a epoch. MfG Goswin -- 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/20130402131824.GA10316@frosties
Re: multi-tarball packages in version control
On Tue, Mar 05, 2013 at 03:37:07PM +0100, Tzafrir Cohen wrote: On Tue, Mar 05, 2013 at 02:03:48PM +0100, Goswin von Brederlow wrote: On Sat, Feb 16, 2013 at 09:57:16AM +0100, Tzafrir Cohen wrote: ... I mentioned, I would prefer to keep those files out of my packaging archive: they hardly change, anyway. So, what do you do with multi-tarball packages? I keep a patched svn-buildpackage, for now. You don't want the extra tarballs in your version control system and they hardly change. Then why have them as extra tarballs? Upstream has. Extra tarballs is for software that is released in multiple components where the components are being released in lock step with each other. It sounds to me like in your case each component is released separately on their own schedule. In that case separate source packages would be better. That way you only need to upload the parts that have changed, buildds only need to build the parts that have changed, users only need to update the parts that have changed and so on. All around better for everyone. They are all released together and have the same version number. You said they rarely change. Does that mean upstream releases the same (apart from the version number) tarball again and again? I don't include all of them. I would like to keep an option to add a format in rev. 2 without uploading the equivalent of all the existing tarballs. Can one add additional tarballs to an existing binary or does the source have to be recompiled for the extra tarball? Can one use last versions extra tarballs with the current versions binary and vice versa? If the answere is yes to both then seriously consider making the tarballs seperate source packages. MfG Goswin -- 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/20130307120533.GC632@frosties
Re: multi-tarball packages in version control
On Sat, Feb 16, 2013 at 09:57:16AM +0100, Tzafrir Cohen wrote: ... I mentioned, I would prefer to keep those files out of my packaging archive: they hardly change, anyway. So, what do you do with multi-tarball packages? I keep a patched svn-buildpackage, for now. You don't want the extra tarballs in your version control system and they hardly change. Then why have them as extra tarballs? Extra tarballs is for software that is released in multiple components where the components are being released in lock step with each other. It sounds to me like in your case each component is released separately on their own schedule. In that case separate source packages would be better. That way you only need to upload the parts that have changed, buildds only need to build the parts that have changed, users only need to update the parts that have changed and so on. All around better for everyone. MfG Goswin -- 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/20130305130347.GB345@frosties
Re: RFC declarative built-using field generation
On Thu, Feb 07, 2013 at 11:11:22PM -0400, Joey Hess wrote: Ben Hutchings wrote: What I mean is that a changes file for a sourceful upload has 'source' (and maybe some real architecture names) in the Architecture field. Therefore 'source' cannot be assigned as the name of a real architecture. Ah, sure. However, source in Build-Depends could be taken to mean that it Build-Depends on the source of the package. Which is not currently supported, but I'm sure everyone stuck maintaining foo-source binary packages would be happy if it were one day. So perhaps best not to overload it. But isn't that exactly what you specify? You do depend on the source of the package. It would be greate to have a policy for foo-source package, if that doesn't already exist, where to place the source in such a way that a future support for Build-Depends on source packages would also put it. That way Build-Depend: foo-source [any source] would currently install foo-source but in the future it would unpack the foo source instead. This also assumes that foo source will have Provides: foo-source. MfG Goswin -- 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/20130305131313.GC345@frosties
Accepted ia32-libs 1:0.4 (amd64 i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 25 Nov 2012 19:31:10 +0100 Source: ia32-libs Binary: ia32-libs ia32-libs-i386 Architecture: amd64 i386 source Version: 1:0.4 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Closes: 684029 Description: ia32-libs - Transitional package to migrate ia32-libs to multiarch ia32-libs-i386 - Transitional package to migrate ia32-libs to multiarch Changes: ia32-libs (1:0.4) unstable; urgency=low . * Removing libldap-2.4-2, libnss-ldap, libpam-ldap from dependences: + recommends causes debconf questions for those not having LDAP. + suggests doesn't cause them to be installed on upgrade. + if you need them you should know about them anyway. + if something needs them it should depend on it itself. (Closes: #684029) Checksums-Sha1: 04dea69c28085c82097cd8bcd123ddfd7ee714dd 1745 ia32-libs_0.4.dsc 96f1ba5aa2da19e29c5ce657e8de53ca56fe6522 115949 ia32-libs_0.4.tar.gz 1bb07c1a9958cb6edd2a5c0bfd5b535082d9361a 114232 ia32-libs_0.4_amd64.deb 9c43706623eff17477bfe5145b2baabf1cda655f 115088 ia32-libs-i386_0.4_i386.deb Checksums-Sha256: 4e3bea235c1ed7239f5fc55159a7c3d4b29cdd970b7a2874eef24534d6d56b0b 1745 ia32-libs_0.4.dsc 9839f8e96b05367bed0d87c1264892186fad2e0e03ef9694903642659a152060 115949 ia32-libs_0.4.tar.gz ce6cd0356aa7b166b3b1765f97c3fa6ee188c04cdddae50e5733f043a55da746 114232 ia32-libs_0.4_amd64.deb 2a0f3a2781245e5fd48b5e99c064f531d829feffd2a702afe2654992bc494fcb 115088 ia32-libs-i386_0.4_i386.deb Files: 5d700d72d8d26a421632d196a2c603de 1745 oldlibs extra ia32-libs_0.4.dsc 8da4860de356806f84dd321ac03a2395 115949 oldlibs extra ia32-libs_0.4.tar.gz 54275d3503faae1b697880f5ae860a82 114232 oldlibs extra ia32-libs_0.4_amd64.deb c1636dae9cbe9bc90e832445a0f28e24 115088 oldlibs extra ia32-libs-i386_0.4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJQtUBgAAoJEIATJTTdNH3IEDcP/1giwSe8j50hWLzQVvnl0lwg c1QmZYFVdvFshswdDMxQKRRRPkxQVgrG+rGnNQDBx22mdazA39CFD10eRa/tFSUR ipWrmAg1wf0NawPIvi6O6Ip0ZSS+2Qmfps8DZvxR1qHtX6GVoibwQ9Pel+ES/hl4 wcnkrl/Q+1DqfpDS5KlCtpEYyjAG7Y9RUP6AjzRLHMnEmmp5YeLhzMNCLRnX6gX7 5QK+dDKL18PFxE4BSiVLFSlBAoDuw7oavO/JMP1dY1HjticiFgjegPXmnmilIKWY sHgoP8ZDcg87Ntec9GgTcMepgdraPSvAD9Hys/iU85N0UCMJQ9CxU3SXjLMD1lRR 9oJvcEHuyZYK1J1dj3vHJ6+7yKfYMsaP32pHr8OlA0MAK48ek1w1c13xeGyeAE+c MI0QzQDZQERRDgvZBN1DwonFIlAD5RxiT1yVlB4RO85CbUMF31koLX9RBWM6cR2p vOWocgi3ktVRFGEr0tMQEabj8hPg8zb9SVCVgOnbCnxyLcQ8pd+3v9IzpHWkctNU X1hhaWi1C1nYez7p3XUciWRGHsNsuMHh2guMIkRSi8IYyrbjAWUFbMfwv1ZJi52b 4qwg/SrkSLf53yyIz+ND2T8tfAbDvT2jnpB5J6TODw2GSVQkfMCDX6naS+2EKvih m4n7VVw46Kh8pKTURtwB =vYLT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tdtwp-0008di...@franck.debian.org
Accepted ia32-libs-gtk 20120709 (amd64 i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 06 Jul 2012 10:20:41 +0200 Source: ia32-libs-gtk Binary: ia32-libs-gtk ia32-libs-gtk-i386 Architecture: amd64 i386 source Version: 20120709 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Closes: 679145 Description: ia32-libs-gtk-i386 - Transitional package to migrate ia32-libs-gtk to multiarch ia32-libs-gtk - Transitional package to migrate ia32-libs-gtk to multiarch Changes: ia32-libs-gtk (20120709) unstable; urgency=low . * Remove dependency on at-spi and libatspi1.0-0 (Closes: #679145). * Move Multi-Arch buggy packages to recommends for the time being to make package installable: + libbonobo2-0 #68 + libglade2-0 #650787 + libgnomecanvas2-0 #650777 + libidl0 #641614 + liborbit2 #641615 + libwmf0.2-7 #677786 Checksums-Sha1: a9210c3b51e7d0de301bd80c05c259a8d84dcb6f 1224 ia32-libs-gtk_20120709.dsc 6edd57730e05e8121d5abd7bf78266da0f36b32b 19564 ia32-libs-gtk_20120709.tar.gz 5c87f261aca1df6d663c7fb0f179da345a96f54f 19626 ia32-libs-gtk_20120709_amd64.deb f422d5f4dce5025b3bd21c2d87c50e4cf50c3ae8 20026 ia32-libs-gtk-i386_20120709_i386.deb Checksums-Sha256: d4944f3df3ba368399b1687d1f7982451388291f28c54612c30d90d929a94d85 1224 ia32-libs-gtk_20120709.dsc d38047eedcef4947323b6b0edbb03cf3da0eb70002e0e859cf91246e0c26447d 19564 ia32-libs-gtk_20120709.tar.gz 262ed475917bbd69586d7e95a9e6ad6cc11b97f25987a4927601517786ceab30 19626 ia32-libs-gtk_20120709_amd64.deb 195e65a265ee0e7a0588ecfda19695b3ec493ba2678d1ac55c4ec598869c36f8 20026 ia32-libs-gtk-i386_20120709_i386.deb Files: 2740f47e430d164d81029ae2682b59fb 1224 oldlibs extra ia32-libs-gtk_20120709.dsc 04c16ae316bcdae2df3a58721f91ff14 19564 oldlibs extra ia32-libs-gtk_20120709.tar.gz 18852512a460c970120c07afe96cb4ed 19626 oldlibs extra ia32-libs-gtk_20120709_amd64.deb 58b30b5b7ec1568d21624289a14ac558 20026 oldlibs extra ia32-libs-gtk-i386_20120709_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAk/6+58ACgkQ3VcITofi8rvHwQD/VktW6s5LMb5wEQo4AGgI1SV2 0LWkYHQiEUNTOQlhXkkA/2O6b+Oq7FBOYLiYPJ/rUN2hbHAt7oGzapXQYr0PNpCR =4j9x -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tlguk-0007k3...@franck.debian.org
Bug#637232: Multiarch breaks support for non-multiarch toolchain
On Mon, Jul 23, 2012 at 06:44:58AM -0500, Jonathan Nieder wrote: Hi, Goswin von Brederlow wrote: On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote: c) Compatibility wrapper. If someone needs this, feel free to email me and I'll help out however I can. If you write one of those then please make sure it works with gcc, gcc -m32, gcc -m64 and uclibc [...] Let's not get ahead of ourselves. I'm not aware of a wrapper having been written, and I certainly wouldn't want to impose additional requirements on someone trying unless someone interested is providing the patches to support those. If someone writes a wrapper then he has to make sure it doesn't break things that used to work. MfG Goswin -- 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/20120725135202.GA4229@frosties
Bug#637232: Multiarch breaks support for non-multiarch toolchain
On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote: affects 637232 + release-notes quit Hi, Matthias Klose wrote: On 08/09/2011 07:31 PM, Aurelien Jarno wrote: I got fed up by people reporting bug on libc6, while this problem results from a decision Debian to implement multiarch. People should work on implementing a compatibility wrapper and to make upstream toolchain multiarch aware. Until this is done, this bug should be kept opened. just do it. To be realistic, is anyone actually going to do this? Avenues forward: a) Help upstream authors of toolchain components with hardcoded header and library search paths to implement multiarch. gcc: in progress - http://gcc.gnu.org/PR53468 (thanks, Matthias!) clang: fixed? - http://llvm.org/bugs/show_bug.cgi?id=6541 icc (Intel C++): status? pathcc (PathScale ekopath): status? tcc (Tiny C compiler): fixed - b56edc7b, 2012-05-22 pcc (Portable C compiler): unfixed - http://bugs.debian.org/638309 cmake: fixed - http://public.kitware.com/Bug/view.php?id=12037 What I don't understand is why compilers (which probably means ld from binutils in all cases) won't use ld.so.conf to find the libs. It only does so to find libs linked into libs you link against. So it is used execpt for the verry first level of recursion. Maybe this could be fixed better in a single common point. b) There is a workaround described in libc6/NEWS.Debian.gz which works fine: LIBRARY_PATH=/usr/lib/triplet CPATH=/usr/include/triplet export CPATH LIBRARY_PATH It's probably worth advertising that more widely, for example in the release notes. I find it a bit hard to believe CPATH is needed. That directory has been in use for years and years way before multiarch. Anyone know which compiler needs it? c) Compatibility wrapper. If someone needs this, feel free to email me and I'll help out however I can. If you write one of those then please make sure it works with gcc, gcc -m32, gcc -m64 and uclibc (which brings some wrappers already I believe). It would also be nice to include i486-linux-gnu-* on amd64 and amd64-linux-gnu-* on i386 and similar for other archs. MfG Goswin -- 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/20120723083604.GA10263@frosties
Re: Finding missing epochs
On Thu, Jul 05, 2012 at 11:34:28PM +0200, Jakub Wilk wrote: I wrote a tool to detect versioned (build-)dependencies with possible missing (or insufficient) epochs. The results for unstable and a DD-list are attached. The source code is available at: svn://svn.debian.org/svn/collab-qa/epoch-mismatch-finder Could you rewrite this as lintian check or maybe just file a wishlist bug against lintian to include such a check please? MfG Goswin -- 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/20120717125110.GA23876@frosties
Re: Audit of Debian/Ubuntu for unfixed vulnerabilities because of embedded code copies
On Mon, Jul 02, 2012 at 12:27:06PM +0200, Bernd Zeimetz wrote: On 07/02/2012 10:53 AM, Silvio Cesare wrote: Hi, [ ... ] Now some of these cases are going to be false positives. From looking at the results, many of the vulns were probably fixed but have not been reported in the security tracker. The report tries to be self explanatory and justify why it thinks it's found a code copy based on the source code being similar. It also tells you which source file has the vuln based on the CVE summary. The ia32-libs stuff are all false positives (assuming the package was updated after the security fixes came out, I'm not 100% sure about that :) And the openssl source is expected to contain the openssl source. Otherwise I think it might be worth to integraet such a check into the qa tools Debian runs regularity. Thanks for your work! Cheers, Bernd Just FYI: the ia32-libs nightmare for security will end in wheezy. I'm afraid till then ia32-libs remain (security) buggy a lot of the time. Updates are done rarely, and only before a point release and fixing 50 security bugs all together at that time in such an update isn't unheard of. The changelog contains the relevant parts of the included sources changelogs including BTS bug number and CVE numbers if you want to check. It also contains a list of soruce packages + versions for easier comparison of open issues. Unfortunatley the existing code duplication automatism the security team has is not up to the task of handling ia32-libs so the package never got the automated tracking of issues other code duplication has. Anyway, it will soon be gone... any second now... only took 10+ years... :) MfG Goswin -- 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/20120717131424.GC23876@frosties
Bug#679853: general: Too much downtime during a big dist-upgrade - avoidable with snapshots
On Mon, Jul 02, 2012 at 08:27:05PM +0600, Alexander E. Patrakov wrote: While it might work for some, there's a much simpler way to minimize daemon downtime: Avoid stopping a daemon in the prerm, and instead restart it in the postinst. Downtime then becomes 1 second per daemon (less than a kexec reboot). However, the daemon then needs to be audited to ensure that it will continue to work while its foundation is being upgraded underneath it. Yes, you seem to be right here. That's what I did for my own proprietary daemon that also runs on my debian servers, and it works well enough (except that I need to restart it manually when the shared libraries it uses receive security updates - but that's OK for me). So in reality, I am on the fence. The quoted solution is easier and it seems to work well enough. But for some reason, freedesktop folks invented this for desktop systems: http://fedoraproject.org/wiki/Features/OfflineSystemUpdates . From what I have understood, the motivation is that there is no way to get a consistent state except by rebooting - which partially corresponds to your case of non-audited daemons. Basically, it looks like they gave up, that's why I proposed a complicated solution based on the same shaky (at least for servers) assumption that it is the best to avoid updating packages on a live system. As for the issue of merging files e.g. in /etc - the objection is valid if there is a valid source of such changes (and IMHO indeed, it would be too radical to ban any manual changes in /etc between the upgrade and the reboot). Also, for anyone reading this bug, I would like to stress that I consider it an issue only for systems running the testing distribution, because big dist-upgrades are not frequent in stable. -- Alexander E. Patrakov I think that goes along with There is no way to update but to reinstall. for most non-Debian based distributions. Debian has always allowed updating instead of reinstalling and updating without rebooting. Any system to prepare an update system in the background and then reboot into the new state will at most be an alternative. Certainly something nice to have but the it will probably be like vi/emacs. Half the people like one way, the other the other way. And the two shall never meet. MfG Goswin -- 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/20120717130054.GB23876@frosties
Re: Moving changelog and copyright files to control tarball, or merging control and data tarballs ?
On Sat, Jul 14, 2012 at 09:00:29AM +0200, Guillem Jover wrote: Hi! Just to give some context and background, this started with the discussion of binNMUs and multi-arch [0], related to file conflicts due to the coinstallability of multiple M-A:same instances, and while initially a wild idea to possibly fix that specific case, it seemed to me it was generic enough and which would make other parts of the system easier and more structured. [0] http://lists.debian.org/debian-dpkg/2011/09/msg00029.html On Sat, 2012-07-14 at 09:48:35 +0900, Charles Plessy wrote: Pushing the logic further, I wonder if that suggests that the Debian binary package format could be simplified to be a simple tarball with the metadata in /var/lib/dpkg, instead of the current format with a data and a control tarballs joined together in the 'ar' format. One thing that is being done with package metadata is that it is extracted before the package proper into a temporary location and used there. As such as a minimum the /var/lib/dpkg/ you propse should be first in the tarball so only a minimum of data needs to be uncompressed to extract the metadata. And you would have to always intercept those files all the time since they need to go to a temporary place. So as Guillem says: That would not simplify it at all, in fact it would make it way more complex, not to mention it would require bumping the .deb version format to 3.0. But what I wanted to say is that one thing that is being done with package metadata is that it is extracted before the package proper into a temporary location and used there. Dpkg uses the control file and maintainer scripts (preinst, prerm sometimes). But other tools need access to data too, like apt-listchanges. In that light I too think it makes sense to move the NEWS.Debian and changelog files to the control tarball so they can be accessed easier and faster. This would not prevent dpkg to store the metadata somewhere else than /var/lib/dpkg later, as it would be easy to intercept the files and treat them appropriately, similar to what is being done with files in usr/share/doc with multi-arch packages. Also, once using a simple tarball as binary package, arbitrary files become trivial to extract quickly, or perhaps even to update (like for translations). This would require to hardcode several path locations in dpkg just to make them generic again internally, which does not make any sense to me. Also dpkg does not currently have any internal knowledge about magic paths, and there's no special handling of multi-arch paths for «/usr/share/doc/». regards, guillem I'm not opposed to merging the control and data tarballs, neigther am I for it. I don't quite see a reason for it. But putting the metadata into /var/lib/dpkg is indeed a bad idea, esspecially with the idea/plans to change the internal storage of those files in dpkg. By having the files in the package already in place you put knowledge of the dpkg internal DB into each and every deb and any change will be a nightmare. Instead, if you want to play more with the idea of a single tarball, think about having the metadata in /DEBIAN/ instead. That is where they are already during building of debs so build tools would not need changes (other than dpkg itself) And you would have a single hardcoded path location to work from. Just my 2c. MfG Goswin -- 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/20120717135508.GD23876@frosties
Accepted ia32-libs-gtk 20120616 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 16 Jun 2012 15:32:03 +0200 Source: ia32-libs-gtk Binary: ia32-libs-gtk ia32-libs-gtk-i386 Architecture: source amd64 Version: 20120616 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Description: ia32-libs-gtk - Transitional package to migrate ia32-libs-gtk to multiarch ia32-libs-gtk-i386 - Transitional package to migrate ia32-libs-gtk to multiarch Changes: ia32-libs-gtk (20120616) unstable; urgency=low . * Transition ia32-libs-gtk to multiarch. + ia32-libs-gtk:amd64 becomes transitional package depending on ia32-libs-gtk-i386. + New transitional package ia32-libs-gtk-i386:i386 that depends on all libraries previously in ia32-libs-gtk. * Removed ia32-libs-gtk-dev + building complex 32bit packages on amd64 is no longer supported + build i386 packages and install via multiarch instead * Removed support for ia64, kernel no longer supports 32bit. * Drop gtk2-engines-xfce, leaf package and not multiarch. Checksums-Sha1: 4dd8772c2e549dd8d44835b03b200ef39c88badb 1482 ia32-libs-gtk_20120616.dsc 1e9240ad1df62522a4b917e3ed44cf118887b440 19440 ia32-libs-gtk_20120616.tar.gz 81d31d58dc9550663c1fa0cd1b1d5c5dc8d5a311 19440 ia32-libs-gtk_20120616_amd64.deb Checksums-Sha256: aea0ef0537d8e1e93a6fb633caff4a9c29cc30d3440d3c4b3282453731275781 1482 ia32-libs-gtk_20120616.dsc d1ea37f83f6d5d6ee2adb5269eb3c537b77513e4b1062e2b820b23ea8fa20279 19440 ia32-libs-gtk_20120616.tar.gz ca603d64095ffe172a6ac11a9dad25a51d0113c2bd42c82f512bffaead92cbdd 19440 ia32-libs-gtk_20120616_amd64.deb Files: f884be1c76673971da460545fc002614 1482 oldlibs extra ia32-libs-gtk_20120616.dsc 31ca05d012e51af8f75c9fe516b83833 19440 oldlibs extra ia32-libs-gtk_20120616.tar.gz bd23f2d8e4eb8ce92a01024dd7713e71 19440 oldlibs extra ia32-libs-gtk_20120616_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJP9A9xAAoJEFb2GnlAHawEMHQH/1SWfaC2p2NIUNe0yE89ngND sly+36pZ5fUW1Py7ByyfxL0RSty1cvR0WqOQfCbnGgMbAJoNVVSZcrdX4qJmWo0n ikDlbn7K+hf2mKakQr1S8DqQnwKtyPBOUM8a8Z26M4D0s0IE4UoCO5qq3oIeWjUT xA5yQjt45B+jyvqv88qcBizpNdEpELVzJb1BnaZpZmToD9tTWrOOavy8yu5IKlVo jZn5Ybr9AQIdfO82f1N7wyc4oB90qaqRoaxImQIXhLh5jm/RkLpBdPe8lrwnGR8y bngdKSsQUqrBT7V1uu0hQkw6SnYpnIyUPucnVexaYMWIKBOF7ijYCRU6skO+y7k= =E8Sl -END PGP SIGNATURE- Accepted: ia32-libs-gtk_20120616.dsc to main/i/ia32-libs-gtk/ia32-libs-gtk_20120616.dsc ia32-libs-gtk_20120616.tar.gz to main/i/ia32-libs-gtk/ia32-libs-gtk_20120616.tar.gz ia32-libs-gtk_20120616_amd64.deb to main/i/ia32-libs-gtk/ia32-libs-gtk_20120616_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1smmbj-0006p3...@franck.debian.org
Accepted ia32-libs 20120701 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 01 Jul 2012 10:54:33 +0200 Source: ia32-libs Binary: ia32-libs ia32-libs-i386 Architecture: source amd64 Version: 20120701 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Description: ia32-libs - Transitional package to migrate ia32-libs to multiarch ia32-libs-i386 - Transitional package to migrate ia32-libs to multiarch Closes: 679671 Changes: ia32-libs (20120701) unstable; urgency=low . * Drop dependency on removed libdb4.8 [ROM] (Closes: #679671) Checksums-Sha1: eb25b0dcbc430956643a00be2850ba5a4fc6d849 1415 ia32-libs_20120701.dsc c33dc43cf946de5b737764425c77c4b4351b706e 115367 ia32-libs_20120701.tar.gz 4578b072cc2d7350b6bf3d47117ebbb4cb0e0ece 113256 ia32-libs_20120701_amd64.deb Checksums-Sha256: 455f46cc2025a16c62ec0a578bb21b36e6b29bb92d1426810e082d3dccb1acbd 1415 ia32-libs_20120701.dsc c4c4f80ec438dc5fc64c7c880de42c31447b4c988cc8b4ae6744ca3cda8f30d7 115367 ia32-libs_20120701.tar.gz 93dd495fdb255b11621f87fb95305506e8f2877f881905c71ff5678cc8793fe4 113256 ia32-libs_20120701_amd64.deb Files: 1af3649c44f7f16bf90cc2c9554d62ff 1415 oldlibs extra ia32-libs_20120701.dsc 40f50293572b8705627bbd02c1a35058 115367 oldlibs extra ia32-libs_20120701.tar.gz 869302a1fa9e9ec8bd0b3a0dbbd3f4ff 113256 oldlibs extra ia32-libs_20120701_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJP9BdxAAoJEFb2GnlAHawEphEH/3NKOeUssTy71xX3Fo82znve bqrepbVtWXzKZvTiAbRCoT0xs5gIaIU+OW24mK5aFZi8CYiR02whMjKEfUdfHHzy C0DdkvLhKlRl5FvFYNA4zclJi2Bg6qNtPJulLAGEQu7S2uGl8clqK1HhVu3/sxHo TEdb+1JmTAPC/e2Wd63lDgXUhn8nRonG9QyUAUp4gpUZ6LhCkEvfx62ciN8v4q0e 9k6X9TvamI2yhY4fWlsBZMAMyUBdeorlX5UXO99FcJKWBEBv9KibNoKcAl2RiMpN dZmvEK5x/j7L6TC4iQfjk8Y3UcGv+o/G2ffS96ouTDZ+TlKBDQ5gOTvMI4VrN0I= =gw6x -END PGP SIGNATURE- Accepted: ia32-libs_20120701.dsc to main/i/ia32-libs/ia32-libs_20120701.dsc ia32-libs_20120701.tar.gz to main/i/ia32-libs/ia32-libs_20120701.tar.gz ia32-libs_20120701_amd64.deb to main/i/ia32-libs/ia32-libs_20120701_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1smmst-0006qv...@franck.debian.org
Accepted ia32-libs 20120616 (source i386 amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 16 Jun 2012 15:32:03 +0200 Source: ia32-libs Binary: ia32-libs ia32-libs-i386 Architecture: amd64 i386 source Version: 20120616 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Description: ia32-libs-i386 - Transitional package to migrate ia32-libs to multiarch ia32-libs - Transitional package to migrate ia32-libs to multiarch Changes: ia32-libs (20120616) unstable; urgency=low . * Transition ia32-libs to multiarch. + ia32-libs:amd64 becomes transitional package depending on ia32-libs-i386. + New transitional package ia32-libs-i386:i386 that depends on all libraries previously in ia32-libs. * Drop libhal1 dependency since it is to be removed from wheezy. * Drop libcapi20-3 dependency since isdnutils is dead and not multiarch. * Removed ia32-libs-dev + building complex 32bit packages on amd64 is no longer supported + build i386 packages and install via multiarch instead * Removed support for ia64, kernel no longer supports 32bit. Checksums-Sha1: 9b66b612cb75c3b7d07c997e5b66250981655397 113222 ia32-libs_20120616_amd64.deb 7ecd1ace9e58543a03406c4f0ce6aba7015f414b 1123 ia32-libs_20120616.dsc 5cfc84e64f61dc7876d289166fc58d8d691f8e58 228030 ia32-libs_20120616.tar.gz 0217000ffae75b816950f82aa189e17deaf1d69e 114720 ia32-libs-i386_20120616_i386.deb Checksums-Sha256: 485f44c6fa329a6e4ce9ad1fc1cb7046d914a0ff384c38fe3c9157b8b4c6f12b 113222 ia32-libs_20120616_amd64.deb 97cc3d72216f5fc726bacb3a40b5e5ea25d6a33190a3e8cdac52ff9b1423c003 1123 ia32-libs_20120616.dsc 6bc652e5566f3bc9eae33fa00a00c9a8f7de13c6922ab0ed4adff62e26e3e7cc 228030 ia32-libs_20120616.tar.gz fbf356bd7e9f71ec42f31e979c533071893bc52f2a702de6eb5edaf82dec9f4e 114720 ia32-libs-i386_20120616_i386.deb Files: b4c7621d13fe835018cd6c3a3a767368 113222 oldlibs extra ia32-libs_20120616_amd64.deb 3ff2f4a5e4b1ea3ba42a62031aa03f0a 1123 oldlibs extra ia32-libs_20120616.dsc 75b0629e9a14486f61bb2b51fce439e1 228030 oldlibs extra ia32-libs_20120616.tar.gz b336e176d219f85a074fac00f8052af7 114720 oldlibs extra ia32-libs-i386_20120616_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk/dpv4ACgkQLkAIIn9ODhHT1ACeLoM2wAe712bZGw/DE9P2iy8y 9ukAoNPuNnQXNDvSf9KhQaXknLVvPXYr =8+lK -END PGP SIGNATURE- Accepted: ia32-libs-i386_20120616_i386.deb to main/i/ia32-libs/ia32-libs-i386_20120616_i386.deb ia32-libs_20120616.dsc to main/i/ia32-libs/ia32-libs_20120616.dsc ia32-libs_20120616.tar.gz to main/i/ia32-libs/ia32-libs_20120616.tar.gz ia32-libs_20120616_amd64.deb to main/i/ia32-libs/ia32-libs_20120616_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1skuh8-0001ql...@franck.debian.org
Re: cross-build-essential
Simon McVittie s...@debian.org writes: On 28/06/12 10:17, Goswin von Brederlow wrote: Say I want to have the build-essential for i386 installed on amd64. I could install build-essential:i386, replacing gcc/g++:amd64 with gcc/g++:i386. Wouldn't that give me everything needed to cross-compile for i386? For evolutions of the same CPU family (i386 vs amd64, powerpc vs powerpc64) this sort of works, but after you've installed gcc:i386, you can't compile 64-bit code any more (until you reinstall gcc:amd64). That means that in practice you use a chroot for 32-bit compilation, and if you're doing that, it might as well be a purely i386 chroot that doesn't use multiarch. For real cross-compiling - amd64 vs armel, say - you don't really want to be running an armel gcc binary that emits armel machine code (which is what gcc:armel is) under qemu emulation: it's technically possible, but your build will be rather slow. What you want is an amd64 gcc binary that emits armel machine code, which is what gcc-cross-armel:amd64 contains. S Obviously. That's why I refined the idea in the next lines. MfG Goswin -- 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/87395e5bwl.fsf@frosties.localnet
Re: Future of update-rc.d in wheezy+1
Roger Leigh rle...@codelibre.net writes: Hi folks, I'd just like to briefly discuss potential plans for update-rc.d in wheezy+1, and how this might impact on file-rc and sysv-rc. sysv-rc has defaulted to using LSB header dependencies and insserv for a few years now. The last few releases require you to enable insserv to upgrade, and the pending upload just does this automatically. The result is that all wheezy users of sysv-rc will be using dependency-based boot. This means that the runlevels and sequence numbers passed as arguments to update-rc.d will never be used; they will just get silently discarded. The main problem as I see it is that these numbers are going to bitrot badly--they aren't being tested, while the dependency information in the header is being used by everyone. I'd like to suggest that we do the following in sysv-rc update-rc.d: - wheezy: silently drop start|stop sequence numbers and runlevels (this is already the case when using insserv, and we can remove the non-insserv codepaths) - wheezy+1: warn if these options are used - wheezy+2: remove support for the options and error out if used And additionally, to add lintian warnings for use of these options, including when using dh_installinit. The main problem that I can see is file-rc is currently still dependent upon the sequence numbers and runlevel information. Would it be possible for file-rc to also add support for dependencies? Given that the static boot ordering is quite dead at this point, it would be very helpful to know what's possible here. Could it use insserv to do the dependency graph and then just consume the makefile-style dependency list? Regards, Roger You say the numbers are going to bitrot, which I totaly agree. But that could be prevented. The numbers specified for update-rc.d must be well ordered according to the dependencies specified in the LSB headers. That means that that update-rc.d could keep a record of the numbers specified and check that the numbers are valid even though sysv-rc/insserv then ignore them. This check could also be done as archive wide check using piuparts or something. Doesn't have to be done on every users systems. MfG Goswin -- 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/871ukzn7ui.fsf@frosties.localnet
Re: cross-build-essential
Wookey woo...@wookware.org writes: +++ Wookey [2012-01-19 14:32 +]: +++ Neil Williams [2012-01-19 13:02 +]: On Thu, 19 Jan 2012 12:10:28 + Wookey woo...@wookware.org wrote: I've thought for a long time that a package like build-essential for cross-building would be a really good idea. +1 It should probably depend on build-essential itself as a starting point. I suppose so. You won't get far without that. OK, there has been progress in this area. Thanks to Patrick McDermmot (GSOC student) we have a patch to add support to build-essential for a crossbuild-essential-arch packages. http://odin1.pehjota.net/~pj/debian-bootstrap/build-essential/ The initial patches there add crossbuild-essential packages to the build-essential source, which is easy to do but leads to some questions. 1) Some of the packages that cross-build-essential depends on (cross-compiler packages) are not yet in the archive, and won't be in wheezy. That means that these packages will not be installable and thus will not migrate from unstable until the cross-compiler packages do arrive. That seems like a very good reason to keep cross-build-essential as a separate source package for now, available from emdebian.org, along with the toolchains. Anyone disagree? I wonder what the difference is between cross-build-essential and build-essential in terms of packages and wether we need a seperate package at all. Say I want to have the build-essential for i386 installed on amd64. I could install build-essential:i386, replacing gcc/g++:amd64 with gcc/g++:i386. Wouldn't that give me everything needed to cross-compile for i386? That said wouldn't it make sense to have build-essential use Depends: g++:arch (= ver) | g++-cross-arch (= ver) Since build-essential is architecture any it already pulls in the foreign libraries needed for that arch. Only difference would be that since g++:foreign conflicts with the g++:native frontends would choose g++-cross-arch instead. MfG Goswin -- 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/87wr2rlrs2.fsf@frosties.localnet
Anyone using pristine-tar with multiple upstream tarballs?
Hi, I'm wondering if anyone is using pristine-tar with multiple upstream tarballs. It seems git-import-orig still doesn't support that. Do you import the tarballs manually or is there another wrapper around pristine-tar to do the work? MfG Goswin -- 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/87sjdflq6q.fsf@frosties.localnet
Re: Summary: Moving /tmp to tmpfs makes it useless
Wouter Verhelst wou...@debian.org writes: On Sun, Jun 24, 2012 at 09:54:22PM +0200, Stephan Seitz wrote: On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote: Meanwhile, you've got a non-FHS directory on your system that is of no immediate use. Your later suggested /store as a user /tmp replacement is a non-FHS directory as well. No, you misunderstand. As a local sysadmin, I've installed systems with a large scratch space for users to use under a non-FHS directory. The FHS explicitly allows that. We have /scratch for that. Unlike /tmp the /scratch is not going to be cleaned on reboot. So it is more like /var/tmp. But I never said Debian should do the same. MfG Goswin -- 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/87y5nb20bx.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
Steve Langasek vor...@debian.org writes: On Sun, Jun 24, 2012 at 03:57:29PM +0800, Thomas Goirand wrote: Release notes are meant to be read once, not every time you upgrade a system. Having a debconf note once might be appropriate. The second time, you'll go right, I've seen that before. The third time you go sigh, yes, I know, fuck off. The fourth time, you hit ctrl-C, and run DEBIAN_FRONTEND=noninteractive apt-get upgrade -- and then miss something that was actually important and didn't occur on previous installs. Please, let's keep upgrade information in the release notes. If some people don't read them, that's something we should try to fix; not by trying to work around the release notes, but by making them more accessible, easier to find, and more obvious instead. Well, if you update apt + dpkg first, then --add-architecture i386, and *then only* dist-upgrade (or if we manage to update apt / dpkg in stable, so that it does that automatically), it wouldn't display the debconf. So if you were doing lots of upgrades, it would display the debconf screen only if you do the mistake to forget about the --add-architecture i386. So I don't think that my proposal is an abuse of debconf as you describe. It's an abuse of debconf because if you know the system is broken, we should do better than just to tell the user that the system is broken. We should either give them the option to automatically fix it on upgrade, or - better by far - we should automatically fix it for them on upgrade. Why would anyone who has the ia32-libs package installed want anything *but* to have 'dpkg --add-architecture i386' on upgrade? That said, I'm not sure I wouldn't also consider it an abuse of base-files to make that package do this on upgrade. If you're going to task some package with transitioning to multiarch, it probably makes more sense to do it in dpkg itself. As long as we don't have a arch X packages for arch Y partial architecture I don't think anything should silently add a foreign arch automatically. Also adding the architecture requires an apt-get/aptitude update and restarting the upgrade/dist-ugrade so that can't be done from maintainer scripts cleanly. I think the place where it makes sense to add a foreign architecture is in Debian-Installer. I think people who upgrade will have to read the release notes. MfG Goswin -- 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/87txxz1zz0.fsf@frosties.localnet
Re: Summary: Moving /tmp to tmpfs makes it useless
Henrique de Moraes Holschuh h...@debian.org writes: On Sun, 24 Jun 2012, Goswin von Brederlow wrote: Henrique de Moraes Holschuh h...@debian.org writes: I've read that some SSDs really *dislike* the way Linux does TRIM batching (or doesn't :p), so yes, it may well be that on most SSDs regular fstrim will do much better. I'm assuming this is due to fragmentation. With TRIM you get lots of small free chunks. With fstrim you get huge batches. AFAIK, it is related to trim requests not being of the same type as write/read requests (so you have to drain the queue of all in-flight commands or something), some SSDs being allergic to large batched trim requests while others are allergic to unbatched small trim requests, übershitty implementation of said command in SSDs (high latency, synchronous), etc. On top of whatever performance issues the Linux support for TRIM at the storage stack and filesystems might have. It may well have no fix. fstrim is not performance sensitive (people will run it when they have the time to wait for it to complete), so it doesn't matter if the SSD is very bad at TRIM and goes out for lunch for several seconds per trim request... Ahh, that makes more sense. I thought you ment normal read/write (without interleaved TRIM) would become slower. But if the disk doesn't defrag then won't it just be a matter of time for it to get slow with fstrim too? Any SSD worth its price has both the reserved flash and the background garbage collection systems required to defrag itself if left idle for long enough. But regular TRIMming lets it do a much better job. MfG Goswin -- 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/87hatz1z5c.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
Adam Borowski kilob...@angband.pl writes: On Sat, Jun 23, 2012 at 01:07:56PM +0200, Goswin von Brederlow wrote: It has to be held back. But apt-get/aptitude might select a solution where they do get removed rather then hold back many other packages. I'm hoping it will be held back automatically without user intervention but that might not happen. I'm not aware that this will happen but I also haven't tested a squeeze - wheezy upgrade with 32bit stuff installed. Experiece has just shown that on large upgrades packages are easily removed instead of held back and given the large number of updates involved users often miss a specific one being listed. You don't need to go between releases: every time gcc-4.7 or eglibc get updated, apt wants to remove whole architectures which didn't build these packages yet. Having it hold in such a case would be nice. That is a different situation though. There you have libfoo:amd64 and libfoo:i386 in different versions. Here you have ia32-libs depending on something that doesn't (yet) exist. MfG Goswin -- 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/87k3yx80ap.fsf@frosties.localnet
Re: Summary: Moving /tmp to tmpfs makes it useless
Henrique de Moraes Holschuh h...@debian.org writes: On Sun, 24 Jun 2012, Osamu Aoki wrote: On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote: Tollef Fog Heen wrote: On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote: On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: ]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. This was what I read elsewhere too. For now you shouldn't use discard option with SSDs, it's bad for performance. Better is to run fstrim periodically. Could you care to give us pointer to the rational behind your assertion? Better yet: just tell people to get their own answer, using bonie++. This is likely to be filesystem-specific, kernel version specific, storage-stack specific AND device-specific after all. I've read that some SSDs really *dislike* the way Linux does TRIM batching (or doesn't :p), so yes, it may well be that on most SSDs regular fstrim will do much better. I'm assuming this is due to fragmentation. With TRIM you get lots of small free chunks. With fstrim you get huge batches. But if the disk doesn't defrag then won't it just be a matter of time for it to get slow with fstrim too? MfG Goswin -- 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/87fw9l7zyr.fsf@frosties.localnet
Re: Fwd: ITP: e2defrag -- ext[234] filesystem defragmenter
Phillip Susi ps...@ubuntu.com writes: Package: wnpp Severity: wishlist Owner: Phillip Susi ps...@ubuntu.com * Package name: e2defrag Version : 0.79 Upstream Author : Phillip Susi ps...@ubuntu.com * URL : http://launchpad.net/e2defrag * License : GPL Programming Lang: C Description : ext[234] filesystem defragmenter As a file system is used, data tends to become more and more scattered across the disk, degrading performance. A disk defragmenter simply re-organises the data on the disk, so that individual files occupy a single sequential set of disk blocks, and all the free space on the disk is collected together in a single region. This generally means that reading a whole file is faster, and disk accesses in general are more efficient. To use, the filesystem must not be mounted, and you need to back up your data first because if anything goes wrong ( power failure, system crash, bug in the program ) your filesystem is likely to be unrecoverable. I've maintained this package in the past for a while and I stoped because there was no upstream developement to support ext3/4 filesystems. It looks like you now took over upstream developement and added implemented ext3/4 support. Could I suggest coordinating with xfs_fsr (and whatever other defrag tool is out there) to develope a common nameing scheme and interface. I think it would be good to have a generic defrag, analog to fsck, that then calls defrag.ext2/3/4 or defrag.xfs as appropriate. Have a single cron job that can defrag one filesystem after another and so on. MfG Goswin -- 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/878vfd7yfy.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
Wouter Verhelst wou...@debian.org writes: On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote: On 06/22/2012 05:34 PM, Goswin von Brederlow wrote: Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back Step 2: dpkg --add-architecture i386 apt-get update Step 3: dist-upgrade (ia32-libs, wine, ... is now installable) May I suggest that upon upgrade, we have a debconf message telling about it? We could add this in base-files or any essential package, probably one with some debconf messages already in would be a better pick. Instructions would show, IF ia32-libs old version is currently installed AND the --add-architecture i386 hasn't bee done. I know we have release notes, but some don't know about them or would simply not read them. A debconf message seem really appropriate IMO. No, debconf messages are the wrong tool for the job. Release notes are meant to be read once, not every time you upgrade a system. Having a debconf note once might be appropriate. The second time, you'll go right, I've seen that before. The third time you go sigh, yes, I know, fuck off. The fourth time, you hit ctrl-C, and run DEBIAN_FRONTEND=noninteractive apt-get upgrade -- and then miss something that was actually important and didn't occur on previous installs. Please, let's keep upgrade information in the release notes. If some people don't read them, that's something we should try to fix; not by trying to work around the release notes, but by making them more accessible, easier to find, and more obvious instead. +1. MfG Goswin -- 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/87pq8o7wmn.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
Thomas Goirand z...@debian.org writes: On 06/23/2012 02:18 AM, Goswin von Brederlow wrote: Problem is that frontends will complain about ia32-libs being not upgradable and might suggest removing it instead of keeping it back way before that. At the time base-file is upgraded ia32-libs and all other 32bit stuff might already have been removed. Well, you wrote it would be held back, so I reacted upon the information you gave... It has to be held back. But apt-get/aptitude might select a solution where they do get removed rather then hold back many other packages. I'm hoping it will be held back automatically without user intervention but that might not happen. What mechanism would remove it? Is there any break / conflict somewhere that would do that? Thomas No relevant breaks / conflicts in ia32-libs. But there might be breaks / conflicts in other packages or simply versioned depends that make upgrading foo impossible as long as the squeeze ia32-libs is installed. I'm not aware that this will happen but I also haven't tested a squeeze - wheezy upgrade with 32bit stuff installed. Experiece has just shown that on large upgrades packages are easily removed instead of held back and given the large number of updates involved users often miss a specific one being listed. MfG Goswin -- 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/87pq8qqoab.fsf@frosties.localnet
RFC: Event based initramfs
Hi, a short while ago we had a lively discussion about the problems in initramfs with devices apearing too late (especially USB devices) or crypto/md/lvm/multipath devices being stacked in a way the initramfs scripts wouldn't handle. A simple solution for this problem is to use udev to watch out for new block devices apearing and creating a trigger file and to watch for the trigger file in the init script in a simple busy loop. Then whenever new block devices appear the crypto/md/lvm/multipath scripts are run again to configure the new devices. Since that can create new block devices the init script loops until the devices for $ROOT and $resume appear or a timeout is reached (20s without a new block device appearing). A patch implementing this simple solution is now available in the BTS (#678696). If you had to configure rootdelay= in the past or generally have a non-trivial device setup please do test this patch. You can also try to install a new system with some insane stackings of the 4 components, e.g. lvm on raid on lvm on raid, and then try if a patched initramfs can boot it. MfG Goswin PS: don't forget to include the scripts/local-block/* sniplets from the bugreport till the respective packages themself provide scripts. -- 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/87hau1bwrh.fsf@frosties.localnet
Re: Announce: script to automatically restart services after update of dependencies
Ben Hutchings b...@decadent.org.uk writes: On Thu, Jun 21, 2012 at 11:16:51AM +0200, Goswin von Brederlow wrote: Ben Hutchings b...@decadent.org.uk writes: On Tue, 2012-06-19 at 15:29 +0300, Eugene V. Lyubimkin wrote: Hello, On 2012-06-19 13:59, Tomas Pospisek wrote: This implies that an apt-get install library needs to trigger that restart. Which means that apt-get needs to depend on restart-services. So either restart-services and checkrestart should go into the apt package, or apt needs to depend on/recommend debian-goodies, which would currently pull in python, perl, curl, dialog and their respective dependencies. The later may be a technically working solution, but from a conceptual and a KISS point of view doesn't make sense to me. Is my conclusion correct so far? So if we want a clean solution, then checkrestart/restart-services would need to move into apt and get rid of the non-essential dependencies (get rewritten in shell or C). I believe this is a wrong layer for proposed functionality -- apt-get (libapt) is not the only high-level package manager for Debian. If I were you, I'd look into dpkg file triggers instead. Triggers will by the way automatically solve the problem that you don't restart a service 5 times if 5 libraries were upgraded. But we still need one trigger per service? I don't think that's a good idea. Ben. Do you? Why not a trigger that calls checkrestart? I was thinking we would need a file trigger per service, which is activated automatically (requires changing all service packages); or an explicit trigger, which is activated by each library postinst (requires changing all library packages). Are you suggesting a file trigger on /lib and /usr/lib? It seems inefficient as I think the triggered postinst would have to check *all* libraries, but I suppose it would work. And presumably this is no worse than what checkrestart does now. Ben. Yes, a single file trigger for /lib and /usr/lib. Unfortunately dpkg does not tell the trigger what files have changed so indeed it would have to check all libraries if you go that way. If we go with an opt-in model then I would have services drop a file in /usr/share/checkrestart/ listing the binaries (or pidfiles) that need to be checked, look up the pid of any running instance and then check if it has any deleted libraries in use. This could also be part of the LSB header of init scripts or a comment in the upstart/systemd config instead of /usr/share/checkrestart/service. Another idea would be to extend start-stop-daemon (upsstart / systemd) to have a new option --respawn. This would do two things: 1) monitor the child and restart a service that dies unexpectadly. 2) register the daemon for checkrestart. In that case start-stop-daemon would come with an dpkg trigger to check and do the restarts. This would be an opt-in though. Using checkrestart + blacklist would be opt-out and would give more imediate results. MfG Goswin -- 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/87ipejloxp.fsf@frosties.localnet
Re: build-time testing of pure arch:all packages
Stefano Zacchiroli z...@debian.org writes: On Fri, Jun 22, 2012 at 12:29:48AM -0400, Yaroslav Halchenko wrote: I was thinking about a bit more automated way... ideally (in the long run) even that FTBFS (e.g. due to failed tests or some other arch specific quirks) would forbid automatic migration to wheezy etc -- kinda full blown benefits from the Debian infrastructure without much of work from my side ;) You can do this in a not so nice way like this: 1) if you have no Architecture: any package then add a package-test-logs package. 2) build-arch depends on build-indep (i.e. always compile the arch:all stuff) 3) in build-arch run the tests and include the log in the Architecture:any package This adds a stupid dummy package to the archive that nobody but you need or fattens up an existing one with a logfile nobody but you need. That is the not so nice part. But it would do what you want now. Note: Consider carefully if it wouldn't make more sense to help build a real automatic testing infrastructure (which could reuse idle buildd). How urgently do you need those tests to be run? Did you check if the QA rebuilds try to, or could be asked to, build arch:all packages? If so, it'd be a good start to routinely do archive-wide rebuilds of arch:all packages as we routinely do rebuilds of arch:any packages. (Cc:-ing Lucas, for his great work on QA rebuilds.) Are archive wide rebuilds done on anythiong but i386/amd64? MfG Goswin -- 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/87bokblo6o.fsf@frosties.localnet
Re: Is it possible to run autopkgtest without a virtual machine ?
Charles Plessy ple...@debian.org writes: Dear all, I think that the idea behind autopkgtest (DEP 8) is very interesting, and could eventually replace build-time regression tests. To train myself, I tried to implement simple tests for the tabix package. However, adt-run needs a virtual machine. I know that some developers have some workarounds, but couldn't autopkgtest also support running tests on the local system ? This would be tremendously useful when the tests can be contained in the binary packages, as it would make it very easy for our users and ourselves to test the packages. Have a nice day, I think test should be run in a container (or VM) but never the local system itself. The absolute minimum would be a chroot but a container would give better control over things like networking. MfG Goswin -- 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/877guzlnxv.fsf@frosties.localnet
The future (or non-future) of ia32-libs
Hi, two weeks ago we hit a huge milestone with multiarch and wine:i386 became installable on amd64. Last week we hit another milestone so that ia32-libs became mostly installable (it might still want to remove some amd64 packages in the process depending on what you have installed). As a consequence I've already uploaded an ia32-libs transitional package [1], currently in NEW, that will allow ia32-libs users to easily switch to multiarch. The transitional package can be removed when nothing depends on it anymore and ends the nightmare of ia32-libs for good. But the work is not done yet. There are still some bugs left to fix for the full multiarch experience: #677741 ia32-libs: Multiarch issues --- #677735 freeglut: Please add multiarch support #675797 sane-utils: should be Multi-Arch: foreign #651475 isdnutils: support Multi-Arch #677733 xcb-util-renderutil: Please add multiarch support And then there is also ia32-libs-gtk [2], which is not yet installable as multiarch: #677762 ia32-libs-gtk: Multiarch issues --- #677787 gtk2-engines-xfce: Please add multiarch support #677788 lesstif2: Please add multiarch support #650777 libgnomecanvas: Please mark libgnomecanvas-common Multi-Arch: foreign #676914 libsasl2-2: binNMU broke multi-arch installability #650787 libglade2: Please transition libglade2 for multiarch #676918 libsasl2-2:amd64: Package is MA-same, but changelog differs between architectures after binNMU #641614 libidl: please convert to multiarch #641615 orbit2: Please convert to multiarch #677786 libwmf: Please add multiarch support #68 libbonobo: Please add multiarch support #69 at-spi: Please add multiarch support Any help NMUing (if not already in delayed) those package would be apreciated. If we can get those bugs fixed in the next week then 99% of the multiarch needs for amd64 will be covered. If you do test those packages and find other bugs then please report them set them as blocking the respective meta bug (#677741 or #677762). Those bugs should also be usertagged with: user: multiarch-de...@lists.alioth.debian.org usertags: multiarch That way they count towards the multiarch release goal [3] and show up on the QA page of the relevant package as blocking that goal. Dear Release Team, ia32-libs now builds 2 transitional packages: ia32-libs:amd64 and ia32-libs-i386:i386. The former depends on the later and the later depends on all the 32bit libraries that ia32-libs used to contain. This means that the dependencies of ia32-libs:amd64 are not fullfillable in amd64 and the package will need some big hammer to get it past britney into testing, as previosuly discussed. Upgrading from squeeze to wheezy also needs 3 steps and should be documented in the release notes. This applies to ia32-libs, ia32-libs-gtk, wine, any other 32bit stuff for amd64 that switches to multiarch. Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back Step 2: dpkg --add-architecture i386 apt-get update Step 3: dist-upgrade (ia32-libs, wine, ... is now installable) Help from some native english speaker to write something for the release notes would be welcome. MfG Goswin [1] http://mentors.debian.net/debian/pool/main/i/ia32-libs/ia32-libs_20120616.dsc [2] http://mentors.debian.net/debian/pool/main/i/ia32-libs-gtk/ia32-libs-gtk_20120616.dsc [3] http://wiki.debian.org/ReleaseGoals/MultiArch -- 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/87395nlmgb.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
Thomas Goirand z...@debian.org writes: On 06/22/2012 05:34 PM, Goswin von Brederlow wrote: Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back Step 2: dpkg --add-architecture i386 apt-get update Step 3: dist-upgrade (ia32-libs, wine, ... is now installable) May I suggest that upon upgrade, we have a debconf message telling about it? We could add this in base-files or any essential package, probably one with some debconf messages already in would be a better pick. Instructions would show, IF ia32-libs old version is currently installed AND the --add-architecture i386 hasn't bee done. I know we have release notes, but some don't know about them or would simply not read them. A debconf message seem really appropriate IMO. Something along with: Problem is that frontends will complain about ia32-libs being not upgradable and might suggest removing it instead of keeping it back way before that. At the time base-file is upgraded ia32-libs and all other 32bit stuff might already have been removed. It appears that you have an old version of ia32-libs installed in your system. Debian now supports multi-arch, and the new version of ia32-libs (a transitional package) uses and needs this new feature. . In order to upgrade the version of ia32-libs in your system, you will need to do: dpkg --add-architecture i386 apt-get update apt-get dist-upgrade Until you do this, upgrades of ia32-libs and packages depending on it (wine, other examples, etc.) will not be possible. More information about this available at: https://wiki.debian.org/please-fill I'm ok to contribute a small patch doing this. Thoughts? Any English guy to propose a better wording? Cheers, Thomas I don't think that would be of much help but feel free to try it out with some real squeeze - wheezy upgrades and see if you see the message before ia32-libs get removed. MfG Goswin -- 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/87bokbus6c.fsf@frosties.localnet
Re: build-time testing of pure arch:all packages
Yaroslav Halchenko deb...@onerussian.com writes: On Fri, 22 Jun 2012, Goswin von Brederlow wrote: archive-wide rebuilds of arch:all packages as we routinely do rebuilds of arch:any packages. (Cc:-ing Lucas, for his great work on QA rebuilds.) Are archive wide rebuilds done on anythiong but i386/amd64? IMHO if archive-wide rebuild could be carried on at least one representative big-endian architecture (e.g. sparc) -- it might already be quite useful. Do we also have some time share on one of the top3 HPC boxes [2] + Lucas#2 to take care about it? ;-) [2] http://en.wikipedia.org/wiki/TOP500 My boss recently came back from a conference and he brought back a flyer about 2U arm server with up to 192 cores and 192 GB ram (on 12 planes a 4 quad core cpus and 4x 4GB ram each) with 10 Gbit networking. I wonder: How long would an archive wide build take with 192 armel buildds? MfG Goswin -- 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/877guzurwh.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
m...@linux.it (Marco d'Itri) writes: On Jun 22, Goswin von Brederlow goswin-...@web.de wrote: Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back Step 2: dpkg --add-architecture i386 apt-get update Step 3: dist-upgrade (ia32-libs, wine, ... is now installable) Maybe this is easier? 1: upgrade dpkg and apt 2: dpkg --add-architecture i386 apt-get update 3: dist-upgrade as usual -- ciao, Marco Sure, that would be enough for the 1. step. There are a few more packages that need to be updated by hand for other reasons. Anything between dpkg+apt and everything but ia32-libs will be fine for me. MfG Goswin -- 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/87395nurtn.fsf@frosties.localnet
