Re: amd64 as default architecture
On May 20, Ben Hutchings wrote: > Then in wheezy+1: > 3. amd64 kernel flavour for i386 dropped. Why can't we use the multiarch package in wheezy? -- ciao, Marco signature.asc Description: Digital signature
Re: amd64 as default architecture
On Sat, 2012-05-19 at 19:44 -0700, Steve Langasek wrote:
> Hi Ben,
>
> On Sun, May 20, 2012 at 03:16:15AM +0100, Ben Hutchings wrote:
> > Most new PCs have an Intel or AMD 64-bit processor, and
> > popcon.debian.org shows amd64 numbers almost matching i386.
>
> > So in wheezy I would like to see:
> > 1. Default architecture (top of the list for installation media/manual)
> > being amd64 ('64-bit PC').
> > 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> > a secondary architecture (debconf note?).
>
> My biggest concern with this is the same that prevented Ubuntu from
> switching to amd64 as a default for 12.04 - namely, that even though almost
> all new hardware coming out would benefit from a 64-bit OS, there's a
> sizeable fraction of users for whom a 64-bit CD would be nothing more than a
> coaster.
I certainly don't propose to have any pages where amd64 is the only
option. But where we have lists of multiple architectures, I would like
to see '64-bit PC' first.
Quite a few such lists sorted alphabetically by Debian architecture
name, which means that 'amd64' comes first. However, 'amd64' confuses
many people, and sorting by descriptive name puts '32-bit PC' first.
> https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035088.html
>
> Now perhaps it's easier for Debian to switch this default than it is for
> Ubuntu, since Debian's choice of default arch doesn't have quite the same
> "all or nothing" impact on pressed CDs and the like. But IMHO it's better
> for our users to choose a default that's safe, at the cost of some users not
> getting the most out of their hardware if they use the default.
Actually, the default Debian installation medium - in so far as it's
linked from the front of www.debian.org - is an amd64/i386 netinst
image, which encourages use of amd64 while still being 'safe'.
Ben.
--
Ben Hutchings
All extremists should be taken out and shot.
signature.asc
Description: This is a digitally signed message part
Re: amd64 as default architecture
Hi Ben,
On Sun, May 20, 2012 at 03:16:15AM +0100, Ben Hutchings wrote:
> Most new PCs have an Intel or AMD 64-bit processor, and
> popcon.debian.org shows amd64 numbers almost matching i386.
> So in wheezy I would like to see:
> 1. Default architecture (top of the list for installation media/manual)
> being amd64 ('64-bit PC').
> 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> a secondary architecture (debconf note?).
My biggest concern with this is the same that prevented Ubuntu from
switching to amd64 as a default for 12.04 - namely, that even though almost
all new hardware coming out would benefit from a 64-bit OS, there's a
sizeable fraction of users for whom a 64-bit CD would be nothing more than a
coaster.
https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035088.html
Now perhaps it's easier for Debian to switch this default than it is for
Ubuntu, since Debian's choice of default arch doesn't have quite the same
"all or nothing" impact on pressed CDs and the like. But IMHO it's better
for our users to choose a default that's safe, at the cost of some users not
getting the most out of their hardware if they use the default.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Bug#673601: ITP: haskell-patience -- Haskell implementation of the Patience Diff algorithm
Package: wnpp Severity: wishlist Owner: John Millikin * Package name: haskell-patience Version : 0.1.1 Upstream Author : Keegan McAllister * URL : http://hackage.haskell.org/package/patience * License : 3-clause BSD Programming Lang: Haskell Description : Haskell implementation of the Patience Diff algorithm This library implements the "patience diff" algorithm, as well as the patience algorithm for the longest increasing subsequence problem. Patience diff computes the difference between two lists, for example the lines of two versions of a source file. It provides a good balance of performance, nice output for humans, and implementation simplicity. For more information, see http://alfedenzo.livejournal.com/170301.html and http://bramcohen.livejournal.com/73318.html. -- 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/20120520022608.25515.25825.reportbug@vm-debian7-i386
amd64 as default architecture
Most new PCs have an Intel or AMD 64-bit processor, and
popcon.debian.org shows amd64 numbers almost matching i386.
For some time we have also provided the amd64 kernel for i386, identical
in all but the package metadata. This has not always been perfectly
compatible with i386 userland, but split 32/64-bit installations are
increasingly used and I think most bugs have been flushed out by now.
Thanks to multi-arch you can now add amd64 as a secondary architecture
and install the kernel package from amd64, and if your system is running
such a kernel then it can also support userland packages from amd64.
So in wheezy I would like to see:
1. Default architecture (top of the list for installation media/manual)
being amd64 ('64-bit PC').
2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
a secondary architecture (debconf note?).
Then in wheezy+1:
3. amd64 kernel flavour for i386 dropped.
4. Kernel and common libraries for amd64 included in i386 installation
media; kernel included on low-number disc.
5. Installer for i386 prefers amd64 kernel on any capable machine
(that's a one-line change!) and adds amd64 as secondary architecture if
this is selected.
Eventually (wheezy+2? +3?) we would stop building a kernel package for
i386.
Does anyone see a problem with the above, in particular points 1 and 2?
(Also, much of the above applies to s390x vs s390. And please let's
have ppc64 and sparc64 soon!)
Ben.
--
Ben Hutchings
All extremists should be taken out and shot.
signature.asc
Description: This is a digitally signed message part
Re: big .debian.tar.xz - EG Wordpress
* Jon Dowland: > So if I understand the situation correctly; wordpress ships a pre-build binary > which cannot be generated in Debian? Whether the source is in a separate > package or not, this does not feel right. It's not without precedent. Ocaml bootstraps off a binary blob to avoid a cyclic build dependency, for instance. -- 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/87zk93ev4p@mid.deneb.enyo.de
Re: What to do with bug reports against non-existing/removed packages
On Sb, 19 mai 12, 15:48:46, Manuel A. Fernandez Montecelo wrote: > > I don't know much about querybts, but you can ask for all [unarchived, > I think] bugs in package emacs21, for example: For that you would have to know the "package" the bug was reported against. > Hopefully somebody more knowledgable than me can help you, I usually > do it with the web interface. Yes please. At a quick look I've seen some bugs where I might be able to help triage, but I would be much more efficient with a tool that can query the BTS and feed an mbox to mutt. Both querybts and bts can do that, but I haven't found a way to query for those bugs. Thanks, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: 'php5-suhosin' is missing for wheezy
Hi... On Sat, 2012-05-19 at 15:10 +0200, Alain SAURAT wrote: > This package is only avaible for squeeze and sid, is it normal ? In addition to what Cyril already mentioned, see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663954 Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#673561: ITP: ruby-sourcify -- Extract a Ruby class or method's parse tree
Package: wnpp Severity: wishlist Owner: Gunnar Wolf * Package name: ruby-sourcify Version : 0.5.0 Upstream Author : NgTzeYang * URL : http://github.com/ngty/sourcify * License : Expat Programming Lang: Ruby Description : Extract a Ruby class or method's parse tree This library is a unified solution to extract proc code into a human-readable parse tree. It is intended as a replacement for ruby-parsetree for versions of Ruby different to 1.8. -- 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/20120519170016.16239.66829.report...@mosca.iiec.unam.mx
Bug#673557: ITP: ruby-file-tail -- Ruby library for following still-growing files
Package: wnpp Severity: wishlist Owner: Gunnar Wolf * Package name: ruby-file-tail Version : 1.0.8 Upstream Author : Florian Frank * URL : http://www.ping.de/~flori * License : GPL-2 Programming Lang: Ruby Description : Ruby library for following still-growing files Small ruby library that allows it to "tail" files in Ruby, including following a file that still is growing, like the unix command 'tail -f' can. -- 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/20120519160620.3218.67700.report...@mosca.iiec.unam.mx
Re: What to do with bug reports against non-existing/removed packages
2012/5/19 Andrei POPESCU : > On Vi, 18 mai 12, 14:34:40, Manuel A. Fernandez Montecelo wrote: >> >> So I wouldn't blindly close those bug reports, and that's why I'm >> triaging and handling them in my spare time. > > Do you know how to retrieve those bugs with querybts(1) other than by > individual bug number? I don't know much about querybts, but you can ask for all [unarchived, I think] bugs in package emacs21, for example: $ querybts emacs21 Querying Debian BTS for reports on emacs21... 292 bug reports found: ... bts (from devscripts) is a bit more sophisticated, but when you query : bts select maintainer:"" it seems to return all open bugs (not only those with empty maintainer), and if you query: bts select maintainer:" " (blank space) it returns an empty list. Hopefully somebody more knowledgable than me can help you, I usually do it with the web interface. Cheers. -- 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/CAPQ4b8kvqHK==ON-DyzZ+6gVRAYxEF4=w_vnmehazyzwcku...@mail.gmail.com
Re: big .debian.tar.xz - EG Wordpress
Hi, (Corsac was right, you'd better CC the maintainers with whom you want to discuss...) On Wed, 16 May 2012, Russell Coker wrote: > Would it be possible to have somewhere on the Debian servers for storing such > files so that they can be referenced in a README file or something rather > than > sent to everyone? I'm sure that most people who build a Wordpress package > won't use them. I don't see the point of it. This is the simplest way to ensure that anyone who distributes Debian complies with the GPL for what is shipped in the wordpress source package. Wordpress themselves are not doing it seriously enough. Their corresponding page is not up-to-date: http://wordpress.org/download/source/ Packaging wordpress is enough of a pain already, if you want to change something you should join us and help us. On Wed, 16 May 2012, Paul Wise wrote: > On Wed, May 16, 2012 at 5:45 PM, Russell Coker wrote: > > > I just downloaded the source to Wordpress from Squeeze, it's got a 14M > > .debian.tar.xz which is mostly sources for things that are included in the > > upstream tarball. The build process appears to only use the upstream > > tarball > > code so the 13MB of data in the debian/missing-sources directory isn't used > > for building. > > Seems like a bug, the best way to determine that sources are still > buildable is to always build them. You're welcome to provide a patch. On Wed, 16 May 2012, Jon Dowland wrote: > It strikes me that this is *exactly* what the multiple-source-tarballs feature > of 3.0. is for. Although, the fact these sources aren't used at all is > troubling. If Debian used them (implemented the minifying as part of the > build > process) we might catch a problem upstream miss (not necessarily a bad thing). Ditto. > Of course, many of these could be separate source/binary packages in their own > right[1], as they have value outside of wordpress, and be > Build-Depends/Depends > of wordpress. In fact a few already are: jquery (already packaged); swfupload > (not yet); tinymce (already packaged)… Indeed, some of the sources provided are for minified files that we don't even install in the binary package. But things change quickly and depending on testing and bug reports, we switch between using the embedded copy and the Debian packaged copy. So I took the easy solution. Note that I use Wordpress so I (help) maintain the Wordpress package but I have better things to do than to invent a build system that upstream wouldn't use just for the sake of it. We definitely need more help to maintain wordpress and you're welcome to join if you feel like doing it. I have done my share of work to get upstream to comply: http://core.trac.wordpress.org/ticket/19065 Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20120519140202.ga...@rivendell.home.ouaza.com
Re: What to do with bug reports against non-existing/removed packages
On Sat, 19 May 2012, Goswin von Brederlow wrote: > The BTS could then not just track the binary/source package of a bug > but also the meta-source package. That way when gcc-4.4 is removed > from the archive the bugs can still be associated with the gcc-x.y > meta package and won't be completly lost. The gcc maintainers would > still be listed as repsonsible for the bug. What may be the appropriate solution is to allow for meta-source packages to be specified at the BTS level instead. That is, I (or someone else with an owner@ hat) can just alias source packages to other source packages, so that they all appear to be the same source package. [Possibly also allowing for aliased binary packages as well, with aliases being overridden if there is a currently existing binary or source package with that name.] We can generate a list fairly automatically by parsing the changelog history looking for cases where a new source package name follows a previous source package name. Don Armstrong -- This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519135505.gb8...@teltox.donarmstrong.com
Re: 'php5-suhosin' is missing for wheezy
Alain SAURAT (19/05/2012): > This package is only avaible for squeeze and sid, is it normal ? Yes, see: http://packages.qa.debian.org/p/php-suhosin/news/20120320T163911Z.html > I have dist-upgrade my server from squeeze to wheezy and my php > won't run and send a lot of mail via cron to me. Blind dist-upgrades, bad idea. Mraw, KiBi. signature.asc Description: Digital signature
'php5-suhosin' is missing for wheezy
Hello, This package is only avaible for squeeze and sid, is it normal ? I have dist-upgrade my server from squeeze to wheezy and my php won't run and send a lot of mail via cron to me. Like this: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20100525+lfs/suhosin.so' - /usr/lib/php5/20100525+lfs/ suho'in.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20100525+lfs/suhosin.so' - /usr/lib/php5/20100525+lfs/ suho'in.so: cannot open shared object file: No such file or directory in Unknown on line 0 I suppose the version 0.9.33-1 is the uptodate version for wheezy, so can I dw it and install it with dpkg ??? thanks, Alain
Re: Bug#481129: Bug#671503: general: APT repository format is not documented
On Sat, May 19, 2012 at 07:38:59AM +0800, Paul Wise wrote:
> On Sat, May 19, 2012 at 12:58 AM, Julian Andres Klode wrote:
>
> > What's the opinion about the flat repository format, where you
> > just have one directory with Release, Packages, Sources, and
> > friends and no sub-directories?
> >
> > Should they be documented as well then? We would then have two
> > kind of documented repository formats:
> >
> > 1. Debian-style, with a pool (or similar) and a dists directory
> > 2. Flat-style, with just one directory
> >
> > This should cover everything we currently support. Although I don't
> > know much about how much stuff we support in flat directories WRT
> > Translation, Contents, and diffs.
>
> I would like to see the flat-style repository documented too, since
> some of the derivatives in the Debian derivatives census use it and I
> would like to lint their apt repositories.
I added (and others edited formatting a bit)
= Flat Repository Format =
A flat repository does not use the {{{dists}}} hierarchy of directories,
and instead places meta index and indices directly into the archive root
(or some part below it) In sources.list syntax, a flat repository is specified
like this:
{{{
deb uri directory/
}}}
Where {{{uri}}} specifies the archive root, and {{{directory}}} specifies the
position of the meta index and the indices relative to the archive root. In
Flat repositories, the following indices are supported:
* Packages (under the location {{{directory/Packages}}})
* Sources (under the location {{{directory/Sources}}})
!InRelease, Release, Release.gpg meta-information are supported as well. Diffs,
Translations, and Contents indices are not defined for that repository format.
Indices may be compressed just like in the standard Debian repository format.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120519135807.ga6...@debian.org
Bug#673515: ITP: puppetdb -- Puppet data warehouse
Package: wnpp Severity: wishlist Owner: Stig Sandbeck Mathisen * Package name: puppetdb Version : 0.9.0 Upstream Author : Puppet Labs * URL : http://docs.puppetlabs.com/puppetdb/0.9/ * License : Apache 2.0 Programming Lang: Clojure Description : Puppet data warehouse PuppetDB is a Puppet data warehouse; it manages storage and retrieval of all platform-generated data. Currently, it stores catalogs and facts; in future releases, it will expand to include more data, like reports. -- 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/20120518171419.26484.16245.report...@dagon.fnord.no
Re: What to do with bug reports against non-existing/removed packages
On Vi, 18 mai 12, 14:34:40, Manuel A. Fernandez Montecelo wrote: > > So I wouldn't blindly close those bug reports, and that's why I'm > triaging and handling them in my spare time. Do you know how to retrieve those bugs with querybts(1) other than by individual bug number? Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Processed: Re: Bug#673505: general: xorg and xserver-xorg 7.6+13 always made X and gnome-shell dead
Processing commands for cont...@bugs.debian.org: > reassign 673505 xserver-xorg Bug #673505 [general] general: xorg and xserver-xorg 7.6+13 always made X and gnome-shell dead Bug reassigned from package 'general' to 'xserver-xorg'. Ignoring request to alter found versions of bug #673505 to the same values previously set Ignoring request to alter fixed versions of bug #673505 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 673505: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673505 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.133741845624021.transcr...@bugs.debian.org
Re: debuild/dpkg-buildpackage behaves not as expected
debian-de...@liska.ath.cx (Olе Streicher) writes: > Goswin von Brederlow writes: >> debian-de...@liska.ath.cx (Olõ Streicher) writes: >>> James McCoy writes: On Wed, May 16, 2012 at 04:23:05PM +0200, Olõ Streicher wrote: > Unpatching the sources *before* the build process was cleaned up makes > no sense to me at all. Could you provide a use case for that? As was described in #649531: vcs clone cd repo ... tweak a little ... dpkg-buildpackage; # applies patches, builds, and unapplies patches vcs diff; # looks good? vcs commit >>> >>> This works only for the special case that "build" does not change any >>> source file. Otherwise you would also commit the changed source files. >> >> And it better not. There is no excuse for changing source files during >> build. > > Welcome to reality. Usually, "configure" scripts are distributed with > (upstream) source on purpose (since they shall provide an easy adoption > to the current enviroment without the need of additional packages), but > they are going to be changed during the packaging. In which case I remove them in clean since they are not source files. I'm not a fan of backup+restore for them. > Another examples are convienence copies of generated files from a parser Even more so not source. If I generate a .c/.h files from .ll/.y then they should be removed in the clean targets. > generator. Or, sometimes Makefiles are going to be *changed* (not even > regenerated!) by adding/changing dependencies at their end. Evil. Make support include directives. Put the depends into a seperate file that is completly generated. > Would you really require for all packages using autoconf that they > repackage upstream source in order to get rid of the regenerated files? > And how would you handle the case that a "Makefile" gets a system > dependent dependency extension? I don't require that upstream sources are repackaged. But I don't find it unreasonable for the clean target to remove non source files even if upstream does ship them. Note that there is a big difference between regenerating files and modifying them. Generated files aren't source and can just be removed in clean. As for Makefiles: use include. >> If you need to change a file then that means that file isn't source >> anymore but generated. Try switching to out-of-tree builds if you have >> something like that. > > What is the advantage of that? From the Debian policy, I don't see a > need why sources should kept untouched during the build process. Less surprises by someone unfamiliar with the source. For example: - you (as in some porter, not the maintainer) build the source to reproduce a FTBS - it fails as expected - you edit the broken file - you build again and it works - you call clean so you can make a patch - clean restores the original source file destroying hours of your work Or you make a patch before calling clean and that won't apply to a clean copy due to the changes made during build. >>> "patch" was meant as a target that *applies* the patches. Therefore, >>> it does not leave the sources in the same state (since it applies the >>> patches). > >> I ment: It leaves the source in the same state it found it other than >> the side effects the called target(s) have themself. > > Why would you need to have a local "patch" target? If it is somehow > generally useful, it should be common to all packages -- and than it > could just be builtin as an option into dpkg-buildpackage. Or just use > quilt directly. In my case I have a patch target since that is easier to type than QUILT_PATCHES=debian/patches quilt push -a and because under Lucid debuild/dpkg-buildpackage does not apply patches before build or unapplies the after build so I need to do that myself in debian/rules. Nowadays it is built-in as "dpkg-source --before-build". The patch target is just a convenience and backward compatibility. And for those that need a patched source when calling "debuild clean". >> My main point, which I didn't explicitly state, is this: >> >> The way debuild/dpkg-buildpackage/dpkg-source currently behave allow >> maintainers to modify the behaviour by adding something to >> debian/rules. If the clean target needs the patches applied then >> debian/rules can easily make sure that they are. > > Since "clean" usually calls the upstream cleanup, its work depends on > whether the upstream cleanup would actually work on the unchanged > package. Trying to apply the "clean" target from the unpatched source on > a directory that is built by the patched source seems to me buggy by > design and just works on accident. > >> On the other hand if the clean target doesn't need the patches applied, >> as is the case for 99.9% of all packages then applying them would be >> wastefull. > > It is just the better design: the package was built with a patched > source, so only the patched version knows for sure how to clean it up. Note that it
Re: Bug#481129: Bug#671503: general: APT repository format is not documented
* Paul Wise [120519 01:39]: > I would like to see the flat-style repository documented too, since > some of the derivatives in the Debian derivatives census use it and I > would like to lint their apt repositories. I my humble opinion the best documentation for the "flat-style" format is: "don't use it, it's an ugly hack". Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519090516.ga5...@client.brlink.eu
Re: About building packages in porterbox
On Sat, May 19, 2012 at 4:38 PM, Aron Xu wrote: > On Sat, May 19, 2012 at 4:12 PM, Colin Tuckley wrote: >> >> The problem on armel: >> >> /usr/lib/gcc/arm-linux-gnueabi/4.6/../../../arm-linux-gnueabi/libpciaccess.so: >> undefined reference to `gzopen64@ZLIB_1.2.3.3' >> >> Looks like it might be the same problem as mentioned here: >> >> http://forums.fedoraforum.org/showthread.php?t=228945 >> >> Which turns out to be an Ubuntu specific version of zlib which includes >> gzopen64. >> > > $ objdump -T /usr/lib/i386-linux-gnu/libz.so.1.2.7 | grep gzopen > d720 g DF .text 0016 Base gzopen > d740 g DF .text 0016 ZLIB_1.2.3.3 gzopen64 > > $ objdump -T /usr/lib/x86_64-linux-gnu/libz.so.1.2.7 | grep gzopen > d7f0 g DF .text 000d Base gzopen > d800 g DF .text 000d ZLIB_1.2.3.3 gzopen64 > > $ grep gzopen64 /usr/include/zlib.h > ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); > # define z_gzopen z_gzopen64 > # define gzopen gzopen64 > ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); > > Note: Information above is collected on clean Sid chroots. I encountered a similar issue with shelxle (1.0.551-1)[1] on mipsel recently, but rebuilding on mipsel porterbox didn't give more hint because the build was successful. [1]https://buildd.debian.org/status/package.php?p=shelxle -- Regards, Aron Xu -- 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/CAMr=8w5rqtsxf87cmdxngxwtzx484dlvmq8dnnrkbwrsbyi...@mail.gmail.com
Re: Enforce clean before unpatch
Thibaut Paumard writes: > Hi, > > Le 18/05/12 13:46, Goswin von Brederlow a écrit : >>> This works only for the special case that "build" does not change any >>> source file. Otherwise you would also commit the changed source files. >> >> And it better not. There is no excuse for changing source files during >> build. If you need to change a file then that means that file isn't >> source anymore but generated. Try switching to out-of-tree builds if you >> have something like that. > > In an ideal world, every file should be either source or generated. > Unfortunately in the real world some build systems modify some "source" > files. Even though, from our point of view, it would be best to get > upstream fixing this, this is not a reasonable assumption to think that > we can force them to. We can't force them but we can force ourself. If the build system doesn't support out-of-tree builds and you can't fix it to not modify source files then there still is the simple solution left to simply create a copy of the source for build purposes. Usualy a hardlinked copy is enough. In bad cases with those files that get modified (instead of replaced) changed to a plain copy instead of hardlink. 3.0 (quilt) format and component tarballs makes it easy to copy the source before build. A simple cp -al component build will do. And in clean you simply rm -rf build. Yes, that is ugly. But probably less so than having to backup a bunch of files before build and restore them in clean because the build system keeps modifying them. > Policy states that clean must revert any changes made during build, but > no policy states that no source file must be modified during build. Some things you don't do even if policy doesn't dictacte that. > This is therefore not a reasonable assumption to expect that you can > unpatch before cleaning in the general case. Violating that assumption, which is even stronger than assuming clean can be called without patches applied, leads to all sorts of trouble. For example what if you type "quilt refresh" to update a path without having called clean. Suddenly the patch contains the changes done by the build. Then you call clean and you can no longer unpatch. No thank you. A build modifying a source file is bad enough. A build modifying a source file that is also patched is a nightmare. > [...] > >> I ment: It leaves the source in the same state it found it other than >> the side effects the called target(s) have themself. > > And it's the role of the clean target to revert the changes introduced > by the "build" and "binary" targets... > >> [...] >> My main point, which I didn't explicitly state, is this: >> >> The way debuild/dpkg-buildpackage/dpkg-source currently behave allow >> maintainers to modify the behaviour by adding something to >> debian/rules. If the clean target needs the patches applied then >> debian/rules can easily make sure that they are. > > Tanks, that's certainly the point: Ole and I must have missed the > documentation on this feature. Is it sufficient to make the clean target > depend on "patch"? That tends to work usualy but is no garanty. Say for example I do call make -f debian/rules binary unpatch clean I think then, since binary would also depend on patch, the clean target would not invoke patch and fail because unpatch unapplied all patches. The example I posted earlier used clean: $(PATCH) ... for that reason and because a phony patch target doesn't mix well with stamp files. When you implement something like that make sure you test your targets with patched unapplied, partially applied and completly applied. > It's also possible that we simply have to dump a line in > debian/source/option to get the "-tc" option by default. Any pointer to > the right option would be welcome. I did look for it, but then: I can't > even find the butter in the fridge :-) Don't think so. I think when calling debuild/dpkg-buildpackage with a traget it simply invokes that target without regard to anything. >> [...] That means that the build MUST not >> modify any source files (which is simply evil to begin with) > > "Evil" is part of this world. > >> [...] > > Regards, Thibaut. 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/8762bsk1h0.fsf@frosties.localnet
Re: About building packages in porterbox
On Sat, May 19, 2012 at 4:12 PM, Colin Tuckley wrote: > > The problem on armel: > > /usr/lib/gcc/arm-linux-gnueabi/4.6/../../../arm-linux-gnueabi/libpciaccess.so: > undefined reference to `gzopen64@ZLIB_1.2.3.3' > > Looks like it might be the same problem as mentioned here: > > http://forums.fedoraforum.org/showthread.php?t=228945 > > Which turns out to be an Ubuntu specific version of zlib which includes > gzopen64. > $ objdump -T /usr/lib/i386-linux-gnu/libz.so.1.2.7 | grep gzopen d720 gDF .text 0016 Basegzopen d740 gDF .text 0016 ZLIB_1.2.3.3 gzopen64 $ objdump -T /usr/lib/x86_64-linux-gnu/libz.so.1.2.7 | grep gzopen d7f0 gDF .text 000d Basegzopen d800 gDF .text 000d ZLIB_1.2.3.3 gzopen64 $ grep gzopen64 /usr/include/zlib.h ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); #define z_gzopen z_gzopen64 #define gzopen gzopen64 ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); -- Regards, Aron Xu -- 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/CAMr=8w6JOA9Z9gao5p=wqk4tebycae6k1xynwothczq9f+7...@mail.gmail.com
Re: What to do with bug reports against non-existing/removed packages
Neil Williams writes: > On Fri, 18 May 2012 14:34:40 +0100 > "Manuel A. Fernandez Montecelo" wrote: > >> Hi, >> >> 2012/5/18 Daniel Leidert : >> > Hi, >> > >> > Our bug tracker contains items for packages, which do (not longer) exist. >> > What should happen to them? I see, that it might be a good idea to keep >> > them for the case, a package is re-introduced. But this might happen only >> > for a few packages. Most of them got removed because newer versions were >> > released. What about closing those reports, if an RM-request is filed? >> > >> > http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint= >> >> As others have said, I asked the question only a few weeks ago: >> >> http://lists.debian.org/debian-devel/2012/03/msg00946.html >> >> Reassigning 300 bugs from emacsX (X<23) to current emacs packages is >> not very helpful, really. What I did is to notify the maintainers (or >> related mailing lists) of the three biggest groups (linux, gcc, emacs) >> to decide what to do. > > There's a big difference between these bugs and the rest - here there > are clear migration paths to later packages which can be used to triage > the bug reports in order not to lose reports. A lot of the rest *can* > be closed without more triage work because the package was removed, not > replaced. e.g. gcc-4.4 bugs may be applicable with gcc-4.7 and need to > be triaged. The opensync/multisync bugs just had to be closed without > even looking at any of them. > > Identifying this subset (which could be quite large) which apply only > to packages which have no appropriate replacement packages would be a > very useful QA step and dramatically improve the total number of bugs > in this situation. For packages like gcc-x.y that know that there will be a continious progression of new sources with old sources becoming obsolete wouldn't it make sense to declare some sort of meta-source-package for them. Something like Package: gcc-4.4 Version: 4.4.7-1 Meta-Source: gcc-x.y The BTS could then not just track the binary/source package of a bug but also the meta-source package. That way when gcc-4.4 is removed from the archive the bugs can still be associated with the gcc-x.y meta package and won't be completly lost. The gcc maintainers would still be listed as repsonsible for the bug. Similary when a source package is renamed (but the old not yet removed) all the old bugs could be assigned "Meta-Source: " so on removal of the old package they automatically default to the new source name. This could be semi automatic so that new bugs against the old packages automatically get the Meta-Source info too. Just an idea. 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/87aa14k2gp.fsf@frosties.localnet
Re: About building packages in porterbox
On 19/05/12 06:34, Liang Guo wrote: > One of my packages [1] failed to build on armel, kfreebsd and hurd, > But I don't have such a machine to test my packages. Is it possible > to use debian porterbox to build the package and dig into this > problem ? The problem on armel: /usr/lib/gcc/arm-linux-gnueabi/4.6/../../../arm-linux-gnueabi/libpciaccess.so: undefined reference to `gzopen64@ZLIB_1.2.3.3' Looks like it might be the same problem as mentioned here: http://forums.fedoraforum.org/showthread.php?t=228945 Which turns out to be an Ubuntu specific version of zlib which includes gzopen64. Did your sources come from Ubuntu? Also note that armel is a 32 bit arch, so you can't expect 64 bit native functions to exist. Colin -- Colin Tuckley | +44(0)1223 830814 | PGP/GnuPG Key Id Debian Developer | +44(0)7799 143369 | 0x1B3045CE Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER -- 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/4fb755de.80...@debian.org
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Adam Borowski writes: > On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote: >> Charles Plessy writes: >> >> > Also, it is very sad that, as a project, we can not decide whether we go >> > for 3.0 (git) or not, or have a concrete list of resolvable objections >> > from the people whose work is direclty impacted by the use of this >> > format. >> >> We know what a primary concrete objection is. We discussed it at length >> at DebConf two years ago, and then on debian-devel afterwards. Uploading >> a Git archive requires reviewing the entire contents of the archive, not >> just the current code, for licensing issues, which is pretty painful from >> the ftp-master perspective. > > How come? If the .git directory shipped in the package is pruned, there is > no hidden data. All you have to review are commits that are present there, > which is exactly the same as with quilt: you need to review the tarball and > every single patch. And there you have hit the problem. If the history is pruned to just the latest version then it is pointless. All you end up is a bunch of branches without history that randomly lack their interconnections and a master branch that again lacks the interconnections to the feature branches. Any change to a feature branch will likely cause a merge conflict when you try to merge it to master because the history of past conflict resolutions is missing. And if you do keep enough history to preserve the interconnections between branches then ftp-master has to review all that history. Note: if the pruned feature branches do not cause merge conflicts then you have a set of features that is trivialy serializable (since it has no dependencies on the order) and your feature branches are identical to a set of patch files. So you have gained nothing of 3.0 (quilt). >> There was never really a satisfactory resolution to that discussion. We >> can upload very shallow clones, but they end up looking a lot like the >> existing quilt format with single-debian-patch, > > There's a whole world between shallow clones and complete ones. While > existing git porcelain provides no convenient tools to selectively > shallowify a repository, this is because no one had that need before. > > For example, if you limit yourself to a bunch of linear rebased commits atop Sorry, but if you rebase you have already lost. Rebase destroys history and makes the commit a one-shot deal. You will not have continuity. Rebase is something you can use internally or to create a serilaized patch queue but not something to distribute to the world. > of the newest upstream tag, you can exactly emulate quilt workflow except > for not having to deal with quilt's peculiarities. This goes to the point > of shipping EXACTLY the same data as quilt would, with only metadata > different[1]. And unlike what you say, commits are not flattened in any > way. If you manage to get your git branches serialized and rebased to the point of shipping EXACTLY the same data as quilt would then there really is no point of not shipping the data as quilt would. At that point you have destroyed any benefits of git but are still forcing the much more complex git format on people instead of a simple patch queue (which doesn't even need quilt or quilt knowledge to use). > If we allow non-linear Debian changes (ie, merged not rebased, etc), there > is indeed a complex question: where to cut[2]. But even then, a given commit > is either present or not. If too much old history is there, that's no > different from the upstream shipping an old tarball and a pile of patches > upon it (like ancient apache or qmail). And if we don't allow non-linear Debian changes then there is 0 benefit from not using 3.0 (quilt) format. Once you have gotten your changes serialized (linear) it is absolutely trivial to automatically create a 3.0 (quilt) format package from your git repository at no loss (other than the history you were going to prune anyway). That's what for example gitpkg does. > And besides, what's the reason behind enforcing exactly one upstream and > exactly one "Debian"? This just leads to problems if either side has > multiple layers. > >> and it's not horribly >> clear what the advantages of 3.0 (git) are at that point. Many of the >> really compelling use cases for 3.0 (git), neat stuff like possibly being >> able to just push a signed tag instead of uploading or having the package >> history when you get the source package, aren't very interesting with >> shallow clones. > > It's more a psychological issue: while you can use 3.0 (quilt) to emulate > 1.0, people don't know about that. Even though 6500 of packages in Debian > store their packaging in git, they typically fight with quilt, while that > shallow copy = single-debian-patch would at least remove that concern. It would just lead to people fighting with git. As you say the 3.0 (quilt) problem is more a psychological issue. The solution isn't to switch to a much more
Bug#673505: general: xorg and xserver-xorg 7.6+13 always made X and gnome-shell dead
Do I need to attach those info and reply to this list or do I need to re-submit another report? Thanks. On Sat, May 19, 2012 at 09:21:59AM +0200, Cyril Brulebois wrote: > Xueqian (19/05/2012): > > Package: general > > Severity: important > > > > Recently, I have upgrade packages xorg, xserver-xorg, > > xserver-xorg-input-all and x11-common from 7.6+12 to 7.6+13. > > See “Follow-up with more info” on: > http://x.debian.net/howto/report-bugs.html > > Mraw, > KiBi. -- 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/20120519074301.GA11934@Studio-14z
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Adam Borowski writes: > On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote: >> On 05/17/2012 04:52 PM, Gergely Nagy wrote: >> >> I'm confused concerning the above; the point of a VCS in this context is >> >> to >> >> track changes to the source package, and the patches are themselves >> >> important >> >> changes to the source package. If you have Git ignore the patches then >> >> Git >> >> doesn't have a complete view of the source package anymore. Why would >> >> you >> >> want to do that? >> > >> > Git does have a complete view. What the above does, is tell dpkg-source >> > to fold any changes made to the upstream sources into a single >> > patch. Since the git tree already has the patches applied (with upstream >> > sources on a different branch, most probably), it has a full view. >> > >> > This basically folds whatever patches the git tree has over upstream, >> > outside of debian/ into a single file. That's about it. Since that file >> > is generated, it has no business staying in git. >> >> Doing that is the most stupid idea ever. All it does is to ensure that you >> package can't be NMUed sanely and that people who need to work with the >> sources I have to say you are saddly mistaken there. Just because you use a single patch under debian/patches and do not track it in git in no way prevents the debian source package to work as expected. Everybody can download the source package, build it, NMU it, whatever. All he is saying is that when building from git all upstream changes not covered by existing patches shall go into debian/patches/debian-changes (instead of debian/patches/debian-changes-version) and not to track this automatically generated file in git. Which is totaly sane. >> and your patches for whatever reason have to clone your git, which might be >> not >> available or just too large for them to download - so at the end changes are >> high that they end up with a largish unreadable patch, similar to the mess we >> get from Ubuntu sometimes. >> The only thing that makes sense would be to use git-format-patch to export >> your >> patches to debian/patches and list them in the series file. Or use gbp-pq, >> which >> was made exactly for that. > > Uhm, please switch around "git" and "quilt", and say that again. Uhm, no. That is besides the point. > Quilt is a kind of really primitive VCS. It does not make sense to use both > it and a modern one, and when someone tries, this ends up with no end of > woe. Quilt sprinkles its modifications around the source, breaks timestamps > causing unnecessary rebuilds, breaks basic VCS abilities like bisection, > makes it really hard to even review history, and so on. > > You complain about forcing people to use git, while you push quilt onto > everyone else. And while git can do every single thing quilt can do, the > reverse is thoroughly untrue. > > I really wish there was a "3.0" format besides "3.0 (quilt)", so people are > not mislead into thinking they have to (or even, would gain anything) from > writing patches in quilt's format. And you too are totaly missing the point of the exercise. The point of the described setup was so that people do not have to write patches in quilt's format. The described setup gives you a 3.0 (quilt) format where quilt plays no part in your workflow and thus does not interfere with the VCS. The resulting source package that gets uploaded will use quilt but you as VCS user don't have to care about it. All the benefits of the 3.0 format without the (imho mostly imagined) quilt problems. 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/87likok4oi.fsf@frosties.localnet
Bug#673505: general: xorg and xserver-xorg 7.6+13 always made X and gnome-shell dead
Xueqian (19/05/2012): > Package: general > Severity: important > > Recently, I have upgrade packages xorg, xserver-xorg, > xserver-xorg-input-all and x11-common from 7.6+12 to 7.6+13. See “Follow-up with more info” on: http://x.debian.net/howto/report-bugs.html Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#481129: Bug#671503: general: APT repository format is not documented
Julian Andres Klode writes:
> On Fri, May 18, 2012 at 04:06:23PM +0200, Michal Suchanek wrote:
>> FWIW
>>
>> posted on the wiki: http://wiki.debian.org/RepositoryFormat
>>
>> Thanks
>>
>> Michal
>
> I have now documented the Contents indices and the diffs
> as well, mostly (sans the exact format we use for the
> patches), and Translation indices. Now we're basically
> only missing details, it is fairly complete otherwise
> (i.e. we should have mentioned every file and field
> currently in use, but may not have explained all of
> them completely).
>
> We now have documented
>
> dists/$DIST/Release (and InRelease, Release.gpg)
> dists/$DIST/$COMP/binary-$ARCH/Packages
> dists/$DIST/$COMP/source/Sources
> dists/$DIST/$COMP/Contents-$ARCH.gz
> dists/$DIST/$COMP/i18n/{Index,Translation-*.bz2}
> *.diff/Index *.diff/%Y-%m-%d-%H%M.%S.gz
>
> The other Release files have been omitted, as they are not
> used anywhere. We are only missing udeb content files and
> packages files now, which are just small subsentences.
>
> In a few months, I'd like to rework this in DocBook form,
> and submit it to debian-policy for inclusion into official
> Policy, as a sub-policy like copyright-format.
This describes repositories of the form
deb uri suite component [...]
There should be a mention of flat repositories of the form
deb url path/
This changes nothing for the contents of files but it does change their
location and I think it's worth mentioning how that sources.list entry
maps to a repository.
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/87pqa0k5dn.fsf@frosties.localnet
Re: Wheezy release: CDs are not big enough any more...
On 2012-05-19 00:52 +0200, Adam Borowski wrote: > On Fri, May 18, 2012 at 12:27:15PM -0400, Joey Hess wrote: >> Guillem Jover wrote: >> > Only as long as the debian/control information matches the one from >> > the archive override. >> >> I checked, and currently the only base package with an overridden priority >> is libsigc++-2.0-0c2a > > So, would it be safe to make dpkg-deb default to xz if priority is < > important for wheezy? It wouldn't, because not all required or important packages actually have the correct priority. For instance, insserv has priority optional but is a dependency of sysv-rc which is required. In general, switching to xz compression by default will make it impossible to debootstrap testing/unstable if the host system does not have the xzcat command, because often packages become part of the base system without further notice. Cheers, Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87396w3aun@turtle.gmx.de
