Ansgar Burchardt debian.org> writes:
> On 12/18/2012 05:09 PM, Niels Thykier wrote:
[…]
> > also a talk about keeping old versions of the source package around for
> > license compliance. This is mostly related to packages "embedding"
> > (parts of) other packages during builds (I believe they w
dAgeCKo free.fr> writes:
> supported on wheezy. Indeed, the first kernel version I have to compile
> is a 2.6.37, which, as far as I know, requires gcc 4.3.
http://snapshot.debian.org/package/gcc-4.3/
That being said, you may not succeed installing this on wheezy,
so use a squeeze chroot. (Due
Thomas Goirand debian.org> writes:
> Though I'm in the favor of dropping binaries rather than source-only,
This could even help the cases of packages that need itself
to be built.
When a packager does a source+binary upload of foo (= 1.2-1),
it would be built in a clean, minimal chroot (yes, I’
Johannes Schauer dixit:
>If you were ever involved in porting Debian to a new architecture or
>know how a port was done, please do not hesitate to either write me an
For reviving m68k:
> - did you cross compile parts of Debian? How much? How hard was it?
Only to test kernels and a few userspace
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… hmm… something to think about…
(for m68k, I might actually use less, set
Ben Hutchings decadent.org.uk> writes:
> 64-bit architecture that supports a 32-bit userland. I think the only
> interesting difference is that x32 has 64-bit time_t.
And double the GPRs (General Purpose Registers), and each of them
in double the width. I expect this to help modern compilers a
Arno Töll debian.org> writes:
> Pretending we had a working concept to throw away binaries and how to
> deal with arch:all packages, why don't we introduce a control/changes
> file flag similar in spirit to "XS-Autobuild: yes" instructing dak not
> to throw away binaries upon explicit request - s
Henrique de Moraes Holschuh dixit:
>From: Andi Kleen
>To: linux-ker...@vger.kernel.org, linux-kbu...@vger.kernel.org
>The problem is that the tarball includes /lib/{modules,firmware},
>but on FC17 /lib is a symlink. tar when it unpacks the tarball
>replaces the symlink with the directory. So the
Ian Jackson dixit:
>There is still nothing per se wrong with circular dependencies
Actually, I’m hitting an APT bug during dist-upgrades right now
for packages with circular dependencies, usually two (perl with
perl-modules, and g++-$version with its library), when they are
indirectly depended on
Guillem Jover dixit:
>then some of the cases this tries to address (the “optional” nature of
>dependencies for derivatives for example) would get covered by my
>build-profiles proposal in #661538, which as stated there might need
Yes, please! Besides bootstrapping, use cases do include derived
di
Russ Allbery dixit:
>I don't see any point in doing this as opposed to just moving everything
>from sbin into bin and making sbin a symlink to bin.
Alone the pain to do so (and the complaints from traditionalists)
should be enough to not do that.
There’s also the “if I want to have a look at wha
Jonathan Nieder dixit:
> pcc (Portable C compiler): unfixed - http://bugs.debian.org/638309
Yes, but that was not the main showstopper for pcc.
Besides upstream bugs on some architectures (recently,
even Linux/amd64 broke again – I’m following pcc dev),
the main problem was how to get pcc-l
Lars Wirzenius dixit:
> No other browser is available on the Amiga they're using as their only
> computer, either.
lynx-cur, w3m and links2 are known-usable on Debian/m68k,
and I’m working on iceweasel currently (already submitted
one patch, another one coming soon) and webkit (also FTBFS,
will
[… “interesting” M-A consequences …]
Oh, sorry for disturbing an anthill then. This sounds
entirely nōn-trivial to solve…
Could this work: libnss-ldap and libnss-ldapd both
provide the same virtual package and conflict with it?
Same for the pam ones but a different virtual package.
Just a wild-g
Roger Leigh dixit:
>However, if you have any lingering scripts without any LSB headers,
>you'll need to fix them up or remove them to allow dynamic boot
>ordering to be enabled. This is obviously not too desirable, since
sudo apt-get --purge install file-rc insserv-
bye
//mirabilos
--
16:47⎜«m
Bernd Zeimetz bzed.de> writes:
> On 05/29/2012 08:07 AM, Yao Wei (魏銘廷) wrote:
> > I am thinking about a more general topic like:
> > Managing packaging on VCS services other than Alioth
>
> The other way rounds works well, too - package wherever you like to and
> mirror it on Alioth, for example
Salvo Tomaselli dixit:
>> Please define who are the people you are talking about. If they aren't
>> using mktemp, please file a bug.
>
>man 3 mktemp
>BUGS
> Never use mktemp() [...]
Your manpage search order is (also) wrong:
‣ https://www.mirbsd.org/man.cgi?mktemp
(1) come before (3) secti
Charles Plessy dixit:
>upstream source moved to GitHub, and we would like to try to maintain the
>Debian package there as well.
This is not a good idea: http://mako.cc/writing/hill-free_tools.html
bye,
//mirabilos
--
I believe no one can invent an algorithm. One just happens to hit upon it
when
Joey Hess dixit:
>If programs that write large files to /tmp are changed to usr /var/tmp,
>then over time a system will accumulate orphaned large tmp files in
>/var/tmp. Nothing will come along and clean them up.
This is indeed a valid point. But that’s no regression; /tmp has
always been for sma
Wookey dixit:
>But there is this issue of the way its vfs does temporay unpacking in
>/tmp. That makes sense in the 'this is temporary, it should go away on
>reboot' sense, but some big files will use up a lot of ram when /tmp
>is tmpfs.
>
>I don't know what the right thing to do about this is, b
Salvo Tomaselli dixit:
>tmpfs will make it stay forever in the RAM, caches are flushed to disk and
>their space can be used for new things.
For sane values of “forever”, usually a second of so.
As long as there’s a way to change it¹, please don’t optimise
for the uncommon behaviour.
① tmpfs ca
Serge dixit:
>cases. Can you name some popular real-world program that write
>only small files and become noticeably faster when /tmp is on tmpfs?
Most shell scripts using << (here documents). mc, out of all things,
as long as the temporary files (e.g. of a tarball) fit inside it.
And countless
Chow Loong Jin dixit:
>On 25/05/2012 18:20, Salvo Tomaselli wrote:
>> Double-click on a .tar causes it to be unpacked in /tmp/something.
>> I suppose a lot of not so skilled users do that instead of tar -xf
>
>That doesn't seem to happen with file-roller. Perhaps you need to file a bug
Hm. mc doe
Jon Dowland dixit:
>On Fri, May 25, 2012 at 09:46:37AM +0200, Vincent Danjean wrote:
>> If some kind of sync is required by the application, I think this is
>> because the application want to ensure the data are really written to
>> the disk so that their state remains coherent even in case of cra
Henrique de Moraes Holschuh dixit:
>On Fri, 25 May 2012, Thomas Goirand wrote:
>> for small files, and in that case, it's faster. In reality, it's
>> not that much faster, thanks to Linux caching of the filesystem,
>
>Under heavy filesystem IO load, yes it is. By several orders of magnitude.
Not
Ben Hutchings dixit:
>> >> As in drop the i386 arch?
>> >
>> >No, keep i386 userland only.
>>
>> Oh, definitely not! Please keep this runnable on at least
>> machines such as Soekris (486-compatible), Pentium-M, etc.
>
>For ever and ever and ever?
Hm, 2035 or thereabounds sounds good. ;-) Then l
Guillem Jover dixit:
>> Ah, no, don’t use ar to create .deb files.
>>
>> http://www.mirbsd.org/permalinks/wlog-10_e20110818-tg-g10046.htm
>
>Using binutils' ar should be considered supported, and works fine with
>dpkg-deb and dpkg, the accepted format is documented in deb(5). I'd
The problem is t
Philipp Kern dixit:
>I also assume that Exim does send 8bit mails to non-8bit compliant MTAs (i.e.
>not advertising 8BITMIME). I don't know if that's some sort of violation.
It does, and it’s a violation, yes. I’ve cursed often enough
about that (deliberately running an MTA stripping bit7, for
s
Ben Hutchings dixit:
>> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
>> > i386.
>>
>> As in drop the i386 arch?
>
>No, keep i386 userland only.
Oh, definitely not! Please keep this runnable on at least
machines such as Soekris (486-compatible), Pentium-M, etc.
>> > h
Jon Dowland dixit:
>The stuff is things such as "minified" js. The wordpress source contains the
>minified copies, and you can get the originals in separate tarballs from the
>wordpress site.
Eh, I’d call that RC. People have been told off for not including the
corresponding source in the .orig.t
Guillem Jover dixit:
>the archive override. And if we have to keep changing the packages
>anyway to make sure they match changing priorities, we might as well
>just set the compressor (to gzip) explicitly for base packages.
Pseudo-essential packages are going to be a problem though.
What if a (hy
Adam Borowski dixit:
>using the attached script.
Ah, no, don’t use ar to create .deb files.
http://www.mirbsd.org/permalinks/wlog-10_e20110818-tg-g10046.htm
What you can do is:
$ paxtar cAf foo.deb debian-binary control.* data.*
It’s in wheezy already.
bye,
//mirabilos
--
[...] if maybe ext3f
Adam Borowski dixit:
>if udebs switched to xz (unpacking takes ~10MB memory).
-2 takes only 3 MiB, which is about 2 MiB more than gzip,
since that number is rounded.
bye,
//mirabilos
--
you introduced a merge commit│ % g rebase -i HEAD^^
sorry, no idea and rebasing just fscked │ Segme
Carsten Hey dixit:
>IIRC bzip2 had a better compression. Compressing dpkg's changelog on
>stable seems confirm this:
xz’s default compression level -6 is not good for files
smaller than 8 MiB. Try -2 instead, maybe -2e (slower).
Besides, it decompresses a lot faster than bzip2, so even
in case o
Roger Leigh dixit:
>Possibly a stupid question here but: Given that we are now autosigning
>builds, why can't the slower arches use gzip, and then after upload
>they could be recompressed with xz (and resigned) on a faster arch?
xz -2 is fast enough on m68k (IIRC, compresses not worse than bzip2
Just curious…
I thought one is supposed to use Multi-Arch now, and that
biarch/triarch can finally go away.
Seeing the trouble broonie has with zlib, why are those
packages still built anyway? Can’t they please go away?
bye,
//mirabilos
--
“It is inappropriate to require that a time represented
Aron Xu dixit:
>You might be interested in reading this thread:
>http://lists.debian.org/debian-devel/2011/06/msg00149.html
Ok, will have a look, thanks.
>Activating LTO by default seems not to be a reasonable idea (reasons
Right, it is not.
>are in the given thread), but if maintainer of a pa
Hi all,
has anyone ever wondered about adoption of LTO in Debian?
I’ve been using -fwhole-program --combine since GCC supported
it somewhat reliably (with a fallback as they have broken it
regularily at least three times) in mksh, and now several of
my packages try -flto=jobserver with a fallback
Jakub Wilk dixit:
>> * binNMUs for the same version cannot be co-installed anyway as their
>> changelogs differ.
>> ↓
>> That could be “fixed” by using the same email address and a hardcoded
>> date, or not including the binNMU entry at all, or moving that entry to a new
>> field, etc. All of whic
Cyril Brulebois dixit:
>For those not subscribed to that bug, how to reproduce[1] and possible
>fix[2] are available now. There might be other places where buffers are
>reused, I only spent a few minutes on this during my lunch break.
Your lunch breaks are amazing. Doesn’t this look like “uses un
Steve M. Robbins sumost.ca> writes:
> OK, with thanks to Lucas Nussbaum for the build results, I can report
> that only the following 23 of 237 boost rdep packages failed to build
> with boost-defaults pointing to 1.48. This shouldn't take a lot of
Hrm, I don’t see aptitude in there, but get th
Guillem Jover dixit:
> pkg-config --cflags libbsd-overlay
pkg-config is a GNU abomination and not used by BSD projects.
>For existing packages using libbsd-dev (BCCed), several headers will
>be removed in the upcoming 0.4.0 upstream release. To test that your
>packages will keep building fine,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi *,
since upstream appears dead for 4+ years, bugs are piling up, and it
doesn’t even compile with php 5.3 any more, I give up trying to pak-
kage this thing.
I’ll probably change Evolvis to use popen() or somesuch… ☹
bye,
//mirabilos
- --
Supp
Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser
* Package name: ejabberd-mod-shared-roster-ldap
Version : 0.5.1
Upstream Author : Marcin Owsiany
* URL : https://alioth.debian.org/projects/ejabberd-msrl/
* License : GPL
Programming Lang: Erlang
Russ Allbery dixit:
>>> architectures which are expected to be part of Debian. Debian has
>>> needed to adapt to BSD behavior, non-standard or not, since the project
>>> decided to include the kfreebsd architectures. That's part of porting.
>
>> What is wrong with porting kfreebsd behaivour inst
Raphael Geissert debian.org> writes:
> The shared debconf prompt idea was already discussed and discarded in one of
> the d-devel threads
Ah, okay. Didn’t know that.
> before the change was made. Which is what Thorsten's
> idea was all about.
Well, I hope you’ve got some better idea then ☺
Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser
* Package name: kwalletcli
Version : 2.01
Upstream Author : Thorsten Glaser
* URL : https://www.mirbsd.org/kwalletcli.htm
* License : Code MirOS, Logo LGPL
Programming Lang: C, C++, mksh
Description
Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser
* Package name: makefs
Version : 20090724
Upstream Author : The MirOS Project
* URL : http://www.mirbsd.org/cvs.cgi/src/usr.sbin/makefs/
* License : 4-clause BSD
Programming Lang: C
Description
Rene Engelhard dixit:
>Actually no, it's not. And it has some RC bugs right now even from
>quickly looking at it
Thanks for looking at it, still.
>- Depends: openoffice.org-common
>
>"for Writer". Please depend on writer. (which in turn depends on -common
>anyway)
Okay. I only looked for whic
Dixi quod…
>Ibwill publish URI (for criticism &c.) later.
.oO(the BTS doesn’t seem to cope with WTF-8 quite right)
https://eurynome.mirbsd.org/debs/dists/hardy/wtf/pkgs/openoffice-ext/openoffice.org-altsearch_1.2.2-1~wtf804+1.dsc
This is what we’ll use at work¹ for now; the final version will
o
Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser
* Package name: openoffice.org-altsearch
Version : 1.2.2
Upstream Author : Tomáš Bílek
* URL : http://extensions.services.openoffice.org/node/525
* License : LGPL v2.1 or later
Programming Lang
Okay, again; waldi told me there are missing information,
and that debian-de...@lists.d.o has to be Cc’d.
Package name: php-perl (Binary: php5-perl)
Version:1.0.0
Upstream Author:Dmitry Stogov
Licence:PHP 3.0 (upstream), GPL (packaging)
Language:
Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser <[EMAIL PROTECTED]>
* Package name: libbsd-arc4random-perl
Version : 1.30
Upstream Author : Thorsten Glaser <[EMAIL PROTECTED]>
* URL : http://www.mirbsd.org/man3/arc4random
* License : MirOS L
Goswin von Brederlow dixit:
>find -name \*mp3 -print0 | xargs -0 mpg123 -z
Hm. This just proves my example sucks ☺ Of course you've got
a point here, but I don't want to make another one…
//mirabile
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens
Oleg Verych dixit:
>02-08-2007, Peter Samuelson:
>> unset foo
>> [ -n $foo ] && echo foo is non-empty
>> [[ -n $foo ]] && echo foo is non-empty
>>
>> As you can see, only the second one works.
True, that's why the Korn shell invented [[.
>Not quoting possible empty argument is a script wr
Thanks for keeping me in the Cc ☺ (but I guess I earned that from a PR)
Marco d'Itri dixit:
>Bad idea
Give the user the tools to shoot himself into the foot. Besides, dash
is already using the debconf dance, so why discriminate other shells
that are fine to do it according to policy?
>bash (the
Pierre Habouzit dixit:
>> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463
This is just clueless script writers and general whining; these
issues could be fixed one by one. (Actually, even with current
Debian policy, they're bugs.)
> * [[ for test, trivial: add it as a test alias,
Mike Hommey dixit:
>Yeah, they should be given solaris's /bin/sh.
That's a Bourne shell, not a POSIX shell. Try /usr/xpg4/bin/sh there.
//mirabile
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy
Henrique de Moraes Holschuh dixit:
>OTOH, specifically using something else than /bin/sh for a fast
>POSIX-with-the-extensions-Debian-mandates shell
No, that will not make sense. People who write #!/bin/sh scripts
should be tought that they can only use so-and-so few things.
//mirabile
--
I bel
Henrique de Moraes Holschuh dixit:
>There is just too much crap out there that thinks /bin/sh is bash.
Not in Debian – /bin/sh scripts must be POSIX compliant and not use
extensions, and with my experience from mksh (minus the “stop” alias
issue, which, with mksh R30, became a non-issue), and see
Pierre Habouzit dixit:
>I don't see a valid reason for the
>user to chose what lies behind /bin/sh.
Debian policy allows it.
>If he wants to use his favourite
>sh shell features in his scripts, he shall use #!/bin/favouritesh and
Indeed, since #!/bin/sh scripts must not use non-POSIX features.
Hi everyone,
as shown in http://thread.gmane.org/gmane.linux.debian.devel.release/17423
there's currently a discussion to use dash as /bin/sh instead of GNU bash.
Until now, /bin/sh used to be a symbolic link to /bin/bash, unless dash and,
later, mksh offered to install themselves there instead,
501 - 562 of 562 matches
Mail list logo
