Switching default dpkg-source compressor for V2+ formats to xz

Hi! I'd like to switch the default dpkg-source compressor to xz for V2+ (not for V1) source formats, as suggested by Ansgar Burchardt in [0]. [0] After having switched the default dpkg-deb compressor to xz in 1.17.0, it only makes se

Re: Switching default dpkg-source compressor for V2+ formats to xz

On Tue, 2013-08-13 at 11:12:16 +0900, Mike Hommey wrote: > On Tue, Aug 13, 2013 at 03:52:51AM +0200, Guillem Jover wrote: > > I'd like to switch the default dpkg-source compressor to xz for V2+ > > (not for V1) source formats, as suggested by Ansgar Burchardt in [0].

Re: jessie release goal: verbose build logs

Hi! On Tue, 2013-08-13 at 15:16:49 -0700, Russ Allbery wrote: > Joey Hess writes: > > Also it could save the whole log to someplace when minimizing the > > console output, to refer back to. Perhaps ../$package_$version.buildlog > > (which gets a step closer to including that in the dsc and upload

Re: jessie release goal: verbose build logs

Hi! On Tue, 2013-08-13 at 22:08:34 +0200, Joey Hess wrote: > At DebConf, Enrico came up with this idea: When the package is building > with the display going to the console, something could intercept the > stdout and convert \n to \r. Let stderr through untouched. The result > would be a build tha

Fake cross-toolchains via multiarch

Hi! I've been using this locally for some time, and been meaning to publish it here, but was prompted to do it now, due to some recent bugs filed against dpkg to support multilib style cross-toolchains. Mutlilib is IMO a hack that should just disappear in Debian at least at the packaging level, n

Re: Introducing dgit - git integration with the Debian archive

On Sat, 2013-08-24 at 17:40:00 +0100, Ian Jackson wrote: > Did you know that dpkg-source doesn't notice if sensible-editor exits > nonzero ? Nope, thanks I've just fixed this locally now, will be included in dpkg 1.17.2. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.de

Re: Removing old unmaintained X drivers

Hi! On Thu, 2013-09-26 at 23:26:22 +0200, Julien Cristau wrote: > we (the debian X Strike Force) are thinking of removing the following > packages from the archive, unless somebody steps up (soon) to take care > of them. I assume here you mean maintaining them in Debian (or perhaps upstream too?)

Re: automake transition breakages

Hi! On Mon, 2013-09-30 at 11:09:26 +0200, Ondřej Surý wrote: > I have seen these two breakages (so far): > > libgd2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724841 This uses -Werror in AM_INIT_AUTOMAKE, don't do that. > gyrus: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724917 (g

Re: libravatar in the BTS [Re: bugs.debian.org: something's wrong...]

Hi! On Wed, 2013-10-02 at 10:11:58 -0700, Don Armstrong wrote: > On Wed, 02 Oct 2013, Jakub Wilk wrote: > > Iceweasel users who want to mitigate the annoyance can put this > > snippet into their ~/.mozilla/firefox/*/chrome/userContent.css file: > > > > img[src^="http://bugs.debian.org/cgi-bin/lib

Re: Propose Release Goals (delayed ;) - xz compression

Hi! On Wed, 2013-10-16 at 17:32:37 +0100, David Goodenough wrote: > xy may only use a tiny bit, but the combination of apt-get, dpkg and > xy seems to cause problems. Its not just BeagleBones, there are x86 > machines with just 64MB still on sale. Ok, I went through the dpkg code, and have reduc

Re: tech-ctte: Decide which init system to default to in Debian.

On Fri, 2013-10-25 at 12:16:04 -0400, Paul Tagliamonte wrote: > Package: tech-ctte > Severity: normal > In response to the recent threads, I'd like to ask the tech-ctte to > please vote on and decide on the default init system for Debian. *Siiigh*, this is a decision that has project-wide

Re: Proposal: switch default desktop to xfce

On Fri, 2013-10-25 at 11:07:09 +, Thorsten Glaser wrote: > • On a VM, I might want to run very low-consuming software only, to lower > the cost of separating things into VMs of their own. (I’ll be writing a > syslog dæmon some day because sysklogd (three processes, c’mon!) is now > remove

Re: prerm/postrm considered harmful in M-A: same packages

Hi! On Thu, 2013-11-07 at 14:34:11 +0100, Josselin Mouette wrote: > I noticed a problem with several packages when they were migrated to > multiarch, and I’m afraid we have a pattern here. This was reported on this list some time ago:

Re: ITP: susv4 -- Fetch and install SUSv4 (POSIX.1:2008) documentation

On Tue, 2011-10-04 at 22:28:00 +0200, David Weinehall wrote: > Package: wnpp > Severity: wishlist > Owner: David Weinehall > > * Package name: susv4 > Version : 7 > Upstream Author : N/A > * URL : N/A > * License : Public Domain > Programming Lang: POSIX sh >

Re: Bug#639535: ITP: libdebian-copyright-perl -- perl module to parse, merge and write Debian copyright files

Hi! On Sat, 2011-08-27 at 22:08:55 +0100, Nicholas Bamber wrote: > Package: wnpp > Owner: Nicholas Bamber > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org > > * Package name: libdebian-copyright-perl > Version : 0.1 > Upstream Author

Re: dpkg predependency against tar >= 1.23, objections?

On Thu, 2011-09-29 at 18:50:35 +0200, Raphael Hertzog wrote: > On Sun, 25 Sep 2011, Guillem Jover wrote: > > > $ sudo apt-get install dpkg-dev > [...] > > > tar: unrecognized option `--warning=no-timestamp' > > > Try `tar --help' or `tar --usage&#

Re: Bug#645014: ITP: libfile-fcntllock-perl -- Perl module for file locking with flock(2)

Hi! First of all, thanks for packaging this so fast. :) On Tue, 2011-10-11 at 14:32:25 -0500, Julián Moreno Patiño wrote: > Package: wnpp > Owner: Julián Moreno Patiño > Severity: wishlist > X-Debbugs-CC: > debian-devel@lists.debian.org,debian-p...@lists.debian.org,642...@bugs.debian.org > > *

Re: Increasing minimum 'i386' processor

Hi! On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote: > The i386 architecture was the first in Linux and in Debian, but we have > long since dropped support for the original i386-compatible processors > and now require a minimum of a 486-class processor. > > I think it is time to increas

Re: Red Hat is moving from / to /usr/

On Wed, 2011-12-07 at 11:34:34 +0100, Marco d'Itri wrote: > I am not really looking forward to keep reverting these changes in my > package, and since Red Hat controls most Linux infrastructure now other > packages will face the same problem. I might be missing something but given the link your po

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

Hi! On Thu, 2011-12-15 at 13:43:19 -0400, Joey Hess wrote: > Roger Leigh wrote: > > I think an important point to consider is that /usr would not > > disappear. It could be replaced by a symlink for new installs. > > This would permit older installs to continue to use /usr, but > > the files woul

Re: Source package without a binary

Hi! On Thu, 2012-01-05 at 18:26:13 +0100, Joachim Breitner wrote: > Theoretically, there is no interesting binary package produced from this > source package and it seems that the policy does not explicitly require > that a source package produces binary packages... but I am certain that > this is

Re: Bug#655187: ITP: nacl -- High-speed software library for network communication

On Mon, 2012-01-09 at 04:49:02 +, Sergiusz Pawlowicz wrote: > Package: wnpp > Severity: wishlist > Owner: Sergiusz Pawlowicz > > * Package name: nacl > Version : 20110221 > Upstream Author : Daniel J. Bernstein > * URL : http://nacl.cace-project.eu/ > * License

Re: Providing a dummy web server package in Debian (Removing web server dependencies from web apps)

On Sat, 2012-01-07 at 10:38:04 +0100, Stefano Zacchiroli wrote: > I agree we should advertise equivs more as it is the most flexible > solution. But until it is discoverable from (not to mention integrated > with) package managers, I doubt we can make a dent in the number of > people who will get s

Bug#658774: O: openhackware -- OpenFirmware emulator for PowerPC

Package: wnpp Severity: normal I intend to orphan the openhackware package. Ideally Aurelien or the QEMU team should take preference over the adoption, if they so desire. The package description is: OpenHackWare is an OpenFirmware emulator intended to be used on PowerPC machines. It is not a re

Bug#658776: O: vgabios -- VGA BIOS software for the Bochs and Qemu emulated VGA card

Package: wnpp Severity: normal I intend to orphan the vgabios package. Ideally Aurelien or the QEMU team should take preference over the adoption, if they so desire. Thre's currently an RC bug, but I think it's actually just important. The package description is: The goal of this project is to

Bug#658886: O: proll -- JavaStation PROM 2.x compatible replacement

Package: wnpp Severity: normal I intend to orphan the proll package. Ideally either a SPARC porter or the QEMU team (although it switched to use another implementation) should have preference over the adoption, if they so desire. I've just fixed multiple build failures with the upload, so it shou

Bug#659023: O: bochs -- IA-32 PC emulator

Package: wnpp Severity: normal I intend to orphan the bochs package. I've uploaded what I had pending in my git tree for bochs 2.4.6 to unstable, and the pending changes I had for the new upstream release 2.5.1 to experimental, because the latter gets random freezes at least on the wxWidgets GUI,

Re: Please test gzip -9n - related to dpkg with multiarch support

On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote: > Well, it does mean that you might be lacking important information > because the other changelog wouldn't be present on the system. While the implicit Replaces seems the easy way out, it just seems even more fragile than the shared files a

Re: Please test gzip -9n - related to dpkg with multiarch support

On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote: > If you remove the shared files approach, how do you handle files like > lintian overrides, reportbug presubj and scripts, etc. ? The same principle that applies to all dpkg output to avoid ambiguity would apply everywhere, whenever there's

Re: Please test gzip -9n - related to dpkg with multiarch support

On Wed, 2012-02-08 at 11:25:28 -0800, Don Armstrong wrote: > On Wed, 08 Feb 2012, Neil Williams wrote: > > I don't get it. That would only affect packages which were built > > during the time that a new upload of gzip is made and all the > > buildd's making that new version available. Now, if there

Re: Please test gzip -9n - related to dpkg with multiarch support

On Wed, 2012-02-08 at 11:56:06 -0800, Russ Allbery wrote: > Riku Voipio writes: > > That is a major waste of space of having multiple copies of identical > > files with different arch-qualified names. Is that really better > > architecture to have multiple copies of identical files on user systems

Re: Please test gzip -9n - related to dpkg with multiarch support

On Wed, 2012-02-08 at 15:14:35 -0800, Steve Langasek wrote: > So I had a look at the Ubuntu archive, which already has a large collection > of packages converted to Multi-Arch: same, to provide some hard facts for > this discussion. > > - 2197 files are shipped in /usr/share by these packages, ou

Re: Please test gzip -9n - related to dpkg with multiarch support

On Wed, 2012-02-08 at 22:01:23 +0100, Jakub Wilk wrote: > In practice, the only compressor we need to care is gzip, which is > not actively maintained upstream[0]. Chances that a new version of > it will break large number of packages are minute. That assumes that we will never want to switch to a

Re: Endianness of data files in MultiArch

On Thu, 2012-02-09 at 13:52:34 +0100, Goswin von Brederlow wrote: > Aron Xu writes: > > This looks not very nice, because we need to maintain a list of > > architectures in debian/control, and when new architectures are added > > the package is potentially broken. > > If endian dependend data is

Re: Please test gzip -9n - related to dpkg with multiarch support

On Thu, 2012-02-09 at 21:50:17 +0200, Riku Voipio wrote: > On Thu, Feb 09, 2012 at 03:34:28AM +0100, Guillem Jover wrote: > > Riku mentioned as an argument that this increases the data to download > > due to slightly bigger Packages files, but pdiffs were introduced > > exactl

Summary: dpkg shared / reference counted files and version match

[ Obviously this “summary” could be considered biased, but I do think the facts presented are accurate. ] Hi, The two reasons for the shared / reference counted files (refcnt from now on) implementation in dpkg have been: * To avoid massive package proliferation (due to the mandated copyright

Re: Summary: dpkg shared / reference counted files and version match

On Fri, 2012-02-10 at 17:16:29 -0800, Steve Langasek wrote: > On Fri, Feb 10, 2012 at 06:56:00PM -0600, Jonathan Nieder wrote: > > As long as dependencies are accurate, I don't see how allowing > > co-installation of the same package for two different architectures at > > different versions is any

Re: Summary: dpkg shared / reference counted files and version match

On Sat, 2012-02-11 at 11:41:58 +0100, Stefano Zacchiroli wrote: > That is a bug and ought to be fixed in its own right. Then, the > discussion of how much we should rely on it or not is a different one, > but it's good to separate the concerns. As mentioned on the summary, this is not specific to

Re: Summary: dpkg shared / reference counted files and version match

On Sat, 2012-02-11 at 00:46:53 +0100, Marco d'Itri wrote: > It is not true that splitting the package is a one time action, every > release which adds new files will require dealing with the split. Assuming a somewhat standard packaging, using debhelper and debian/tmp or debian/, where all upstre

Re: Summary: dpkg shared / reference counted files and version match

s. That way of thinking seems backwards to me, because those problems existed before any such solution was proposed, but oh well... > On Fri, Feb 10, 2012 at 11:56:20PM +0100, Guillem Jover wrote: > > * To avoid massive package proliferation (due to the mandated copyright > > and c

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote: > If this is comprehensive, then I propose the following path forward, which > is a mix of the various solutions that have been discussed: > * dpkg re-adds the refcounting implementation for multiarch, but along > with a Policy requiremen

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

On Tue, 2012-02-14 at 14:28:58 +, Ian Jackson wrote: > Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was: > Summary: dpkg shared / reference counted files and version match)"): > > On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote: >

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

On Tue, 2012-02-14 at 14:28:58 +, Ian Jackson wrote: > I think the refcounting approach is very worthwhile because it > eliminates unnecessary work (by human maintainers) in many simple > cases. Aside from what I said on my other reply, I just wanted to note that this seems to be a recurring p

Re: A few observations about systemd

[ Sending this late reply now, which I had around as a draft, but with the latest incarnation of this debate it's become relevant again. ] Hi! On the "other kernels lack of features" I'll just point to the “Functionality Equivalence” section in the Porting Guidelines draft I've been preparing a

Re: upstart: please update to latest upstream version

On Thu, 2012-02-23 at 07:24:20 +0100, Tollef Fog Heen wrote: > ]] Tzafrir Cohen > > In sysv init scripts the daemon forks into the background. In upstrart > > and systemd it doesn't have to (or shouldn't). (not) forking requires a > > different command-line argument, normally. This leads to odd be

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

On Wed, 2012-02-15 at 16:41:21 +, Ian Jackson wrote: > Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was: > Summary: dpkg shared / reference counted files and version match)"): > > [...] But trying to workaround this by coming > >

Re: Multiarch file overlap summary and proposal

On Wed, 2012-02-15 at 19:31:10 -0800, Russ Allbery wrote: > I agree that it's asymmetric. apt-get install libfoo means libfoo:native, > but apt-get remove libfoo means libfoo:*. And asymmetric is bad, all > things being equal. But I think this may be one place where asymmetric is > still the rig

Re: Multiarch file overlap summary and proposal

On Thu, 2012-02-16 at 10:43:53 -0800, Russ Allbery wrote: > I was thinking more about this, and I was finally able to put a finger on > why I don't like package splitting as a solution. > > We know from prior experience with splitting packages for large > arch-independent data that one of the more

Re: Multiarch file overlap summary and proposal

On Wed, 2012-02-15 at 16:32:38 -0800, Russ Allbery wrote: > Guillem Jover writes: > > If packages have to be split anyway to cope with the other cases, then > > the number of new packages which might not be needed otherwise will be > > even smaller than the predicted amou

Re: Important information regarding upcoming dpkg 1.16.2 upload

Hi, On Sat, 2012-03-10 at 09:35:39 +0100, Guillem Jover wrote: > I'll be uploading dpkg 1.16.2 targeting unstable, by the end of > this weekend or beginning of next week the latest (after some final > polishing). Unfortunately I found some issues with the selection handling and wi

Re: Important information regarding upcoming dpkg 1.16.2 upload

On Mon, 2012-03-19 at 08:12:08 +0100, Raphael Hertzog wrote: > > In addition selections for packages unknown to dpkg will not be > > accepted anymore. > > I'm not sure I understand this correctly but I'm afraid that this is a > serious regression. > > It has always been possible to sort-of "dupli

Bug#666490: O: svgalib -- console SVGA display libraries

Package: wnpp Severity: normal I've just orphaned svgalib by uploading 1.4.x and 1.9.x packages with pending changes to unstable and experimental. I recently contacted upstream to send patches back, but was offered taking over upstream maintainership instead because he is not interested in it anym

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

On Wed, 2012-10-03 at 11:48:10 +0200, Niels Thykier wrote: > On 2012-10-03 11:01, Michael Tautschnig wrote: > > But then either all build infrastructure (and also lintian) don't use > > debian/control, or all these tools tolerate that blank line (with the > > exception > > of pbuilder). > > Linti

Re: symlink vs. directory "conflicts"

On Thu, 2012-10-04 at 01:53:56 -0700, Russ Allbery wrote: > Andreas Beckmann writes: > > So what is the general recommendation about packages that ship files > > over symlinked directories? Should this be forbidden because it opens > > cans of worms? > > Yes. Right. > This sort of thing: > > >

Re: symlink vs. directory "conflicts"

On Sat, 2012-10-06 at 00:29:22 +0200, Andreas Beckmann wrote: > On 2012-10-04 11:34, Guillem Jover wrote: > > Nope, dpkg does not currently have enough information (missing > > metadata) to know if a path was shipped in the package as a directory > > or as a symlink, and to b

Re: Storing additional metadata in the dpkg database [Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?]

Hi! On Mon, 2012-10-08 at 22:02:57 +0200, Michael Biebl wrote: > On 08.10.2012 20:15, Michael Gilbert wrote: > > On Mon, Oct 8, 2012 at 6:33 AM, Thomas Goirand wrote: > >> "Packages must not include files or directories under /run, > >> or under the older /var/run and /var/lock paths." > > > > Th

Re: Discarding uploaded binary packages

On Thu, 2012-10-18 at 21:30:25 -0500, Peter Samuelson wrote: > [Joerg Jaspert] > > As one thing to keep in mind - we have an acl structure in dak. > > Currently it reads something like > > > > all DD keys are allowed all uploads. > > all DM keys are allowed their own uploads according to DM rights

Re: Speeding up dpkg triggers with a list of changes

Hi! On Mon, 2012-10-22 at 20:24:33 +0300, Kari Pahula wrote: > I tried out using inotify to speed up dpkg file triggers, with man-db > as a test case, not that this approach is limited to that. > I'd say that doing this is a worthwhile thing, but I'd like to discuss > the specifics. How closely

Re: Storing additional metadata in the dpkg database [Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?]

On Wed, 2012-10-10 at 05:44:25 +0200, Michael Biebl wrote: > On 08.10.2012 22:53, Guillem Jover wrote: > > That applies as well to any path generated at maintainer script or > > run time by the package (like state, cache, log files, etc), but I > > don't think it's

Re: Speeding up dpkg triggers with a list of changes

On Mon, 2012-10-22 at 20:27:41 +0200, Guillem Jover wrote: > In the specific case of mandb I'd rather just try first to make the > interest more fine-grained (say one per manN subdir), and changing > mandb to accept subdirs. I think that could improve the current > situation quit

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Wed, 2012-10-24 at 14:59:09 +0800, Thomas Goirand wrote: > So, what will you do if: > - previous maintainer goes MIA > - Somebody wants to hija^W salvage the package and starts the procedure > - Nobody votes for this to happen... They should use the already existing MIA process instead... rega

Re: Something like nocompress DEB_BUILD_OPTION

Hi! On Fri, 2012-11-09 at 15:52:53 +0100, Bastian Blank wrote: > On Fri, Nov 09, 2012 at 12:26:19PM +0100, Bastian Blank wrote: > > | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in > > `test.gzip.deb'. > > | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb > > 62

Re: Something like nocompress DEB_BUILD_OPTION

Hi! On Fri, 2012-11-09 at 10:16:21 +, Dmitrijs Ledkovs wrote: > On 9 November 2012 09:37, Simon McVittie wrote: > > (It's possible that "faster" presets don't actually give you more > > performance if the time to write out the .deb is dominated by I/O, > > though.) > > True about I/O. Does d

Re: Where could I upload x32 port bootstrap?

Hi! On Fri, 2012-11-09 at 14:06:15 -0800, Daniel Schepler wrote: > I've asked a couple people in private mail about this, and haven't > gotten any answer, so I thought I'd ask here for ideas. Where would > be a good place to upload what I have so far from bootstrapping an x32 > port of Debian? S

Re: Gentoo guys starting a fork of udev

Hi! On Wed, 2012-11-14 at 21:49:07 +0800, Patrick Lauer wrote: > But anyway, we're getting tired of their ADHD-driven changes just to > change things - maybe we can build up enough momentum so that things > might just be less frustrating for us all. You're all welcome to join, > ignore us or do wh

Re: Gentoo guys starting a fork of udev

On Wed, 2012-11-14 at 15:23:51 -0800, Steve Langasek wrote: > On Wed, Nov 14, 2012 at 04:05:12PM +, Roger Leigh wrote: > > If you want a reliable system, you need a reliable PID 1. Putting > > additional complexity into PID1 increases the likelihood that a > > bug will bring down your *entire

Re: Gentoo guys starting a fork of udev

On Thu, 2012-11-15 at 16:32:41 +0800, Chow Loong Jin wrote: > On 15/11/2012 16:11, Guillem Jover wrote: > > TBH, I'd not trust my system to *any* critical service that uses dbus, > > AFAIK it still asserts on error conditions (including non-programmer > > errors). W

Re: Question: Packages.xz and Contents-.xz

On Thu, 2012-11-15 at 17:11:02 +0100, David Kalnischkies wrote: > 0.8.10.3+squeeze1 does as its changelog tells us. > Note through that it needs the 'xz' binary for that (as it did for bzip2, > that changed just yet with the usage of libbz2 now for wheezy and as > usual people complain about it …

Re: Something like nocompress DEB_BUILD_OPTION

On Tue, 2012-11-20 at 19:48:25 +, Thorsten Glaser wrote: > Dmitrijs Ledkovs debian.org> writes: > > Gzip is ok, but many packages these days use xz -9 --extreme deb > > xz is fine but -9 is abuse of the flexibility… > maybe I should export XZ_DEFAULTS=--memlimit=150MiB > in my build chroots…

Re: Something like nocompress DEB_BUILD_OPTION

On Sat, 2012-11-10 at 13:52:22 +0100, Bastian Blank wrote: > On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote: > Okay. I did some tests with various packages. From binary only to text > only. Thanks for the tests Bastian. It would still be nice to see a bigger sample, if

Re: x32 port bootstrap is uploaded

On Tue, 2012-11-20 at 15:10:04 +0800, Thomas Goirand wrote: > Daniel wrote: > > wget http://87.98.215.228/debian/dists/archive.pub > > debootstrap --arch=x32 --components=main,byhand,partial \ > > --keyring=`pwd`/archive.pub \ > > sid /root/x32-chroot/ http://87.98.215.228/debian/ > > Can I also

Re: Canonical pushes upstart into user session - systemd developer complains

On Sat, 2012-11-24 at 20:29:51 +0100, John Paul Adrian Glaubitz wrote: > While reading a bit on it, I found this passage: > > On Sat, Nov 24, 2012 at 08:17:35PM +0100, John Paul Adrian Glaubitz wrote: > > By making use of a Linux-specific prctl(2) call, we effectively tie > > Upstart to systems ru

Re: Canonical pushes upstart into user session - systemd developer complains

On Sat, 2012-11-24 at 22:46:29 +0100, John Paul Adrian Glaubitz wrote: > On Sat, Nov 24, 2012 at 10:28:46PM +0100, Guillem Jover wrote: > > waitid is supported on FreeBSD. > > Are you sure? According to their status page [1] it's not yet fully > implemented. The page i

Re: Canonical pushes upstart into user session - systemd developer complains

On Sun, 2012-11-25 at 23:30:01 +0800, Chow Loong Jin wrote: > [...] and the hierarchical format > that apt uses doesn't have a readily-usable parser outside of apt (at > least not that I know of). W/o getting into the debate of what format is better or nicer, the configuration format from which AP

Re: "Do not CC me"

On Sun, 2012-11-25 at 19:41:12 -0800, Russ Allbery wrote: > Henrique de Moraes Holschuh writes: > > Well, the software to do it is around for more than 15 years. Google > > for "procmail duplicate suppression". > > This works exactly backwards of how useful duplicate suppression would > actually

Re: Architecture: all + M-A: foreign

Hi! On Thu, 2012-12-06 at 02:05:13 -0600, Peter Samuelson wrote: > In bug #695229, I noted that an Architecture: all package really should > be Multi-Arch: foreign. This led to an IRC discussion between Goswin, > Steve L. and me in which I formulated the proposal: > > If a package is 'Archit

Re: [RFC] Go (golang) packaging

On Wed, 2013-01-02 at 09:15:59 +0100, Michael Stapelberg wrote: > Shawn writes: > > Henceforth when a go program depends on a go library, those go > > libraries are ALWAYS compiled in statically. Static linking causes > > many problems for distributions like Debian, and therefore this > Can you p

Re: Bug#697433: Is the Package-List field necessary for uploads ?

Hi! On Thu, 2013-01-10 at 07:32:54 +0900, Charles Plessy wrote: > Le Tue, Jan 08, 2013 at 02:42:30PM +0100, Ansgar Burchardt a écrit : > > I don't think the description for the Package-List field should document > > the valid package types. There's already a Package-Type field for that > > (defau

Re: Bug#697433: Is the Package-List field necessary for uploads ?

On Fri, 2013-01-11 at 21:05:21 +0900, Charles Plessy wrote: > Le Thu, Jan 10, 2013 at 03:58:31AM +0100, Guillem Jover a écrit : > > It will only list binary packages, not all the information for the > > source package is currently available from other fields in the .dsc > >

Re: Bug#697433: Is the Package-List field necessary for uploads ?

On Sat, 2013-01-12 at 09:07:19 +, Neil Williams wrote: > On Sat, 12 Jan 2013 15:29:13 +0900 > Charles Plessy wrote: > > By the way, isn't "Package-Type: udeb" completely redundant with "Section: > > debian-installer" ? > > Different purposes. Right. Where using Section in general should be c

Re: Bug#697433: Is the Package-List field necessary for uploads ?

On Sat, 2013-01-12 at 15:29:13 +0900, Charles Plessy wrote: > here is a new version trying to addres Simon's and Guillem's comments. > @@ -2671,6 +2671,7 @@ Package: libc6 > Description > (mandatory) > Homepage > Built-Using > +id="f-Package-Type">P

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

On Fri, 2013-01-25 at 11:19:00 -0200, Henrique de Moraes Holschuh wrote: > Now, complete documentation of the Release files, where the tags you can use > in repositories to get such nice functionality like ButAutomaticUpdates... > Does anyone know where such a thing might dwell? I don't think ther

Re: screen says "Bad tty" if /dev/console is a symlink

On Sat, 2013-01-26 at 22:57:59 +0400, Игорь Пашев wrote: > The patch fo screen.cc [1] introduces the function CheckTtyname(): > > int > CheckTtyname (tty) > char *tty; > { >struct stat st; > >if (lstat(tty, &st) || !S_ISCHR(st.st_mode) || > (st.st_nlink > 1 && strncmp(tty, "/dev

Re: screen says "Bad tty" if /dev/console is a symlink

On Sun, 2013-01-27 at 01:30:54 +0400, Игорь Пашев wrote: > Did I break anything? > Too paranoid? Given the “intention” of the previous code, not enough I'd say. :) About the question of removing the pathname checks, that's something the maintainers would have to answer. > Index: screen/tty.sh >

Re: screen says "Bad tty" if /dev/console is a symlink

On Mon, 2013-01-28 at 14:17:13 +0400, Игорь Пашев wrote: > So, is it ok? > > Index: screen/tty.sh > === > --- screen.orig/tty.sh2013-01-27 02:16:57.916935245 + > +++ screen/tty.sh 2013-01-27 02:33:12.831241123 + >

Re: No native packages?

On Sun, 2013-01-27 at 19:16:44 +0100, Jakub Wilk wrote: > Dmitrijs Ledkovs wrote on his blog[0]: > > Generally if software is useful in Debian Project it can be useful > > for other debian-like and unlike projects. In particular native > > packages do not offer the same patching flexibility as 3.0

Re: Bootstrappable Debian - proposal of needed changes

On Wed, 2013-01-30 at 17:27:13 +, Wookey wrote: > +++ Ian Jackson [2013-01-16 13:50 +]: > > > * The concrete syntax in build-depends should not use < > but rather > >reuse the architecture qualification syntax. > > I have just been told of a specific reason to avoid using '< >' : > D

Re: No native packages?

On Fri, 2013-02-01 at 22:25:18 +0100, Jakub Wilk wrote: > * Guillem Jover , 2013-01-29, 20:31: > > if you are going to patch the package you might as well do the one > > line change from "3.0 (native)" to "3.0 (quilt)", and rename the > > source tarball to

Re: screen says "Bad tty" if /dev/console is a symlink

On Sun, 2013-01-27 at 16:20:25 +, Roger Leigh wrote: > Given the amount of work already done by the Hurd porters, would > it be viable to undef PATH_MAX and do a test build to look at how > much this breaks? The other advantage is that it reduces duplicate > codepaths in all the places where w

Re: upstream advise page about circular dependencies (bootstrapping)

On Tue, 2013-02-12 at 21:41:11 +0100, Thomas Koch wrote: > Paul Wise: > > Which software is this and why does it need itself to build? Is it a > > compiler? > It's the dmd compiler for the language D. It still contains non free parts > and > isn't packaged. In the moment the compiler relies on a

Re: No native packages?

On Mon, 2013-02-04 at 18:43:22 +0100, Jakub Wilk wrote: > So what do you propose instead? It's not like native packages get > NMUed because of great entertainment value of the NMU process, but > because there's no better choice. The same thing we usually do when confronted with a dead upstream pro

Re: No native packages?

On Sat, 2013-02-16 at 12:11:29 +0100, Stefano Zacchiroli wrote: > On Wed, Feb 13, 2013 at 03:41:53AM +0100, Guillem Jover wrote: > > > (Random data point: I have 14 packages with versions indicating they > > > are NMUed native packages installed on my system. Some of the

Re: Bug#701585: marked as done (general: Can't select other languages)

On Tue, 2013-02-26 at 16:57:48 -0800, Russ Allbery wrote: > Let alone http://www.columbia.edu/~fdc/utf8/ where I'm still missing: > > Vietnamese (nôm) (only some characters) > Mongolian (Classic) > > These may actually be covered by fonts in Debian, but I don't know how to > find them. I

Re: Bug#701585: marked as done (general: Can't select other languages)

On Wed, 2013-02-27 at 13:50:59 +0800, Paul Wise wrote: > When we finally implement DEP-11, we will have the means to implement > automatic font installation based on needed characters. Hopefully for > jessie we will be able to catch up with Fedora, who have had this for > a while now: > > http://w

Re: Bug#701585: marked as done (general: Can't select other languages)

On Wed, 2013-02-27 at 09:17:05 -0800, Russ Allbery wrote: > Guillem Jover writes: > > I think these should be covered somehow by fonts-freefont-ttf and > > ttf-unifont. > > ttf-unifont did indeed cover Mongolian (Classic). Thank you! You're welcome, I also get bo

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Sun, 2013-03-31 at 20:25:45 +0200, Ansgar Burchardt wrote: > I assume this means that a non-working set of packages could also > migrate to testing (if there was no freeze). The freeze only prevents breakage for wheezy, but after wheezy one can still get a "broken system" due to a partial upgra

Re: Splitting the devscripts package

On Mon, 2013-04-01 at 14:41:53 +0200, Benjamin Drung wrote: > Am Sonntag, den 31.03.2013, 00:13 + schrieb Ben Hutchings: > > There is no reason why Debian couldn't continue to be upstream for > > these, but hosting on freedesktop.org might make them more visible to > > other distributions. > >

Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)

On Wed, 2013-04-03 at 20:18:44 +0200, Philipp Kern wrote: > On Wed, Apr 03, 2013 at 03:33:30PM +0600, Andrey Rahmatullin wrote: > > On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote: > > > > And not, we do not have epochs to temporarily downgrade a package > > > > after a botched upload.

Re: Git packaging workflow discussion on planet.d.o

On Thu, 2013-04-04 at 23:07:04 +0800, Thomas Goirand wrote: > gen-author-list: > git log --format='%aN <%aE>' | awk '{arr[$$0]++} END{for (i in > arr){print arr[i], i;}}' | sort -rn | cut -d' ' -f2- A better way to write the above could be: gen-author-list: git shortlog -nes | tr

Re: Git packaging workflow discussion on planet.d.o

On Sat, 2013-04-06 at 04:40:00 +0800, Thomas Goirand wrote: > On 04/05/2013 06:57 PM, Guillem Jover wrote: > > A better way to write the above could be: > > > > gen-author-list: > > git shortlog -nes | tr -s ' '| cut -f2- > > > > which in ad

<    1   2   3   4   5   6   7   8   9   10   >