Re: Q: Ubuntu PPA induced version ordering mess.
On 2024-07-01 23:59 +0200, Alec Leamas wrote: > But this is not about third parties, it's about upstream which publishes PPA > packages. So far these are by far the most used Linux packages. > > I also hesitate to add an epoch, after all they are basically considered > evil. But if we should not use them when upstream has a broken versioning we > are about to replace, when should we use it? Quite. People are quite resistant to spoiling neat version numbers with epochs, and no-one likes them, but they don't do any actual harm (except sometimes break scripts and tools that forgot to allow for them), and this seems seems like a very sensible use case: essentially jus thwat they are intended for.. Yes it was upstream that messed up not us/you, but we have the technology and you can make user's lives easier by just adding an epoch. It's a pity upsream didn't know about the 0~ trick so that it wouldn't matter what crazy version string was used, but it's done now. I guess the only potential argument against it (beyond 'we don't like epochs') is 'how big is the userbase now and later'. i.e if this is actually fairly new and there aren't really that many users with the duff versions, but maybe in the future there will be 100 times more getting their packages from us, ubuntu and upstream PPA, then that's a reasonable argument to make them have to deal with it manually in exchange for 'neat' epochless versions forevermore for all those future users when everyone has forgotten about this cock-up. Ultimately you are the maintainer so it's up to you. From what you have said, I think I'd epoch in this case, unless I thought the current set of users could be considered 'de minimus' from the point of view of say 5 years time. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Strange armel build error
On 2024-08-16 17:46 +0200, Alec Leamas wrote: > > From another perspective: what is the right thing to do in a situation like > this? Trying to hunt down the problem, and thus causing all sorts of noise > like this message? This is what the policy says, but still... > > Or just exclude that architecture i. e., list all archs but armel? You should at least inform the relevant debian-ports list (less noisy than debian-devel, but as you can see debian-devel worked well in this case so that's not an unreasonable choice), and not just turn the architecture off. This can be via a cc:ed bug or just a mail. Bugs help track issues so future maintainers can find their similar problem (arch-specific issues often appear in multiple packages, needing similar solutions). If you get no response after a couple of weeks and need to do an upload then it is fair enough to disable the architecture until a fix arrives, but idealy prod again and wait a while if you can. One of the good things about debian is that we support a range of architectures (to the best of our abilities). Packagers are not expected to know how to fix arch-specific issues but they are expected to ask someone who might if they can help, and not just degrade debian by removing packages from arches without at least filing a bug + asking. All IMHO of course, and recognising that porter responses can be both slow and nonexistent, but I do think it's important that we try keep debian as consistent as possible across architectures, and don't just reach for the 'disable' button. For someone on a particular arch that is the same as the 'remove from archive' button in effect. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Strange armel build error
On 2024-08-17 17:58 +0200, Alec Leamas wrote: > > > Fair enough. But TBH, i just cannot wait "a couple of weeks" for a possible > reply; there are users waiting for the backports as I write. Fair enough. If you can't wait then you can't wait. > To make it more interesting, the simple -latomic fix doesn't seem to cut it That's a pity, it sounds plausible. I'll try to take a look. > To me, the reasonable approach would be to inform the porter list (need to > figure out which) and then disable armel for now. As soon as there is a > solution I could and should upload it. That is indeed a totally reasonable approach. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#285814: ITP: libtom0 -- wraper library for using OpenGL from tcl
Package: wnpp Severity: wishlist * Package name: libtom0 Version : 0.2 Upstream Author : [EMAIL PROTECTED] * URL : http://perso.club-internet.fr/dropfred/index_en.html * License : GPL Description : wraper library for using OpenGL from tcl Tom is an OpenGL wrapper for Tcl / Tk. About 90 % of OpenGL functionality is implemented, plus some GLUT (OpenGL utility) functions. It supports Linux and Windows. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-k7 Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15
How should we deal with 'pointless-on-this-arch' packages?
In general debian builds everything for every architecture. This is a very good plan and finds a lot of bugs. However there are some packages which are clearly not sensible on some arches. Numerical analysis software in general on arm is a good example of this class. Arm hardware is generally slow and more seriously has no floating point hardware (except very exceptionally). No-one in their right mind would run numerical analysis on an arm box, for any purpose other than testing that they could. Now in an ideal world we would gratutiously build these packages anyway, just to check that they do build on said architecture, but there is a cost to doing this. Buildd time and archive space. Buildd time particularly, for slow arches, is a resource we don't have a huge abundance of. So, 'is pretty much pointless' has not to date been deemed a reason to mark a package 'not for us'. However, It seems to me that if the porters _and_ the package maintainer agree that there really is no real point in building a package for a particular arch, and it takes signifcant resources to do so, that it is best to mark such packages 'not for us'. However I don't think we should just start doing this unilaterally, so I am posting here to canvass opinion. Should inappropriateness be a criterion for deciding a package is not-for-us? Should we perhaps have a more general mechanism than such ad-hoc marking to indicate innappropriate combinations of package and architecture? An example of this genre is fityk, which currently times out on arm, trying to build large C++ files. It is curve-fitting software. It could probably be built, but one wonders if it is worth the effort. The author is happy to not have it built for arm. I'm sure there are others in the same situation, although I have not done extensive research to try and produce a list. (cc: me - I'm not subscribed) Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On 2006-10-14 12:06 +0200, Ingo Juergensmann wrote: > On Sat, Oct 14, 2006 at 02:30:14AM +0100, Wookey wrote: > I believe the Vancouver proposal went into wrong direction by excluding > (slower) archs from releases. Of course, dropping archs is a quick and easy > way to lighten the load for a release, but IMHO it is wrong, because it's > damaging and destroying one of Debians biggest strengths: being an universal > OS that can be run on nearly every arch. > > Of course nobody wants to extent the releases beyond any sane time just due > to some slower archs. The question is: how can Debian release more > frequently and on time even when some slower archs are falling behind and > can't keep up with >6100 source packages? > > The answer is quite simple: reduce the load for those archs by not forcing > them to build *every* package, but only a certain subset of them. > I think everyone will agree that every arch should have a basic set of > packages to be suitable to use it like some shells, some editors, ssh, > debian-installer, compilers, linkers, etc. > It doesn't make much sense to build all Desktop related packages for an arch > that is mainly used remotely or as an embedded device. I don't think that > anyone will run KDE on top of an NSLU2 or on a Linksys WRT54G. No - but they might well run it on an Iyonix, and maybe even a balloon. Even though arm is mostly-embedded there are a few desktop machines (which merely illustrates the problem of general package classifications). > Same may be valid for m68k, although there *are* users that are using their > m68ks as an X-Terminal or such. But those are rare. As you say m68k is leading the way in terms of still being a useful arch but not able to cope with 'all of debian'. Arm is following. > So, it's better, IMHO, to reduce the number of packages for those archs by > defining some sort of requirements: > > - what is *required* to make use of that arch (f.e. example packages in > section base, admin or with priority required)? > - what is commonly used on those archs? popcon can gives some hints like > MTAs, fetchmail, UUCP, DHCP-stuff or similar things (gcc, debugger, ...) > - what is rarely used? (Desktop Environments, Browsers, numerical analysis > tools) > - what is unuseable on that arch? (qemu, Xen, flight simulators, cluster > software, ...) Clearly something like this could be a general solution to the problem. I do think there is value in defining characteristics of packages so that choice can be made, but it is not an easy thing to do. Even on a slow arch which is not normally used as a desktop, desktop packages are often needed. Should such classification be done per-arch, or generally. Should we perhaps have 'core' and 'other' (like ubuntu's main and multiverse (or whatever it which)). Perhaps debtags could be used as an appropriate classification mechanism. Perhaps embedded debian could be developed to fill the 'smaller machine' niche, although that is not necessarily a very good fit (emdebian is about shrinking all packages as well as subsetting). And any such descisions have implications for how the release process is managed. Nevertheless I think it is clear that we do need mechanisms to keep the load and package set appropriate for slower arches. If we design the mechanism properly I would hope it could be useful for various categorisation/subsetting purposes within debian. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: restricted sourceless ARM uploads
On 2006-12-20 17:39 +0100, Aurelien Jarno wrote: > Hi, > > For those who don't know, I have setup 8 emulated ARM build daemons and > started to upload packages. To know why and for more information, see > [1]. Very impressive piece of work aurelien! We ought to discuss if there is any significant reason not to use qemu 'machines' instead of actual hardware for slower arches. How fast is each of your build machines in comparison to existing buildds? The offered Hedges machine is more than twice as fast as existing buildds and really ought to be brought into the network - it has been offered for about 2 months now. I will mail DSA again to see if anyone will tell what needs to be done next, by whom, and when. It is very rude to people making such offers to give no response at all for such a long time. Fortunately bill seems very tolerant of Debian's foibles, and we can at least use it as a private developer-access machine in the meantime. > Note that I would have been happy to not start those build daemons, but > given the way the arm build daemons are administrated, something had to > be done. Perhaps you are right. Let us all try to keep this discussion constructive. > Anyway, I have been able to fix a few packages that were not built > successfully. For the others, I have extracted from wanna-build a list > of package that build successfully, but have failed to build for > various reasons. Can you update the armbuildd wiki page with this? (I expect you are going to anyway). Thanx you for your efforts on the arm port over the last few months - they have been extremely helpful. Can we make aurel32 an arm buildd maintainer? I think he has shown both competence and dedication this year. I'm sure having more than one maintainer would be helpful. Aurel - do you want to commit to this task? Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: restricted sourceless ARM uploads
On 2006-12-20 19:58 +0100, Bill Allombert wrote: > On Wed, Dec 20, 2006 at 12:32:25PM -0600, Bill Gatliff wrote: > > > > Could you try those packages on hedges? (You can get developer access > > from Wookey if you need it). Hedges has 512MB real and 1.5GB swap. And > > unlike leisner, the netwinders, or nslu2s, it's expandable if needed. > > No use, this will simply thrash the box to no end. Try to build openvrml > for example. It failed on europa after 1000 minutes of inactivity: > > <http://buildd.debian.org/fetch.cgi?&pkg=openvrml&ver=0.15.10-8&arch=arm&stamp=115084&file=log> This built OK on hedges in about 6 hours. Is a binNMU needed? (meant to get back about this earlier but forgot I had it running). Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please revoke your signatures from Martin Kraff's keys
+++ Javier Fernández-Sanguino Peña [06-05-25 20:00 +0200]: > > That being said I (personally) already decided ...[people] > not showing any passports or showing passports: > > - which did not had the *same* spelling as the name in the key (letter by > letter) > > will not get a signature from me. That's fine of course. Everyone is entitled to their own ID-checking standards. But I should point out that my passport does not match the name on my key because my govt is incapable of issuing an ID with my correct name on it (apparently). Passports office software and issuing practice assumes that the name contains at least one space. I have picture ID with my correct name on it but it is issued by entities much more 'fake' than the Transnational Republic (The Verein fuer Hohlenforscher in Bad Mittendorf, Austria, and Cambridge Universitry library). I have no idea what it would take to persuade you that I am who I say I am, but if you _only_ accept National Passports then it would appear to be impossible in my case (which I realise is something of a corner-case). Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: compaq iPaq
On Wed 16 Aug, Jason Gunthorpe wrote: > > On Tue, 15 Aug 2000, Joey Hess wrote: > > > It's been pointed out that emdebian (http://www.emdebian.org/) is > > essentilly an effort to do just this. [shrink debian to fit > > handhelds] > > It is? I use their stuff and the main focus is cross compilers and cross > environments for debian, not really shrinking and porting debian proper. > > That it is, it is more tools for embedded development rather than an > embedded operating system. We (emdebian) want to do both these things. The latter is what is urgent right now for developers of 'funky handhelds', but the former is also needed for those handhelds to be of much use beyond specific vertical applications. http://www.handhelds.org/ (the compaq research lab, who did the port to the ipaq) is encouraging development of small-platform linux software. Emdebian intends to use the resulting good stuff to produce a proper small-device distro. The needs of genuinely embedded devices and general-purpose handheld computers are not quite the same, but the restrictions are similar so we hope that a distro can be produced that covers both these areas. It's an interesting area. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Re: Upcoming debian meetings
On 2007-02-08 16:52 +0100, Andreas Schuldei wrote: > If you know of other meetings, locations and/or sponsors that > would be interested in hosting meetings, please let me know! Some of us are at the Free Software World conference 3.0 in Badajoz, (Speaking about the Debian Extremadura workmeetings) and the politicos here have just commited to continue the series of Debian meetings which ran here in 2006 (translations, d-i, emdebian, q-a, skolelinux) I'm not sure exactly when, where, or what form this will take, but you should definately talk to them about how best to take that forward. I suggest best initial contact is Cesar Gomex Martin: [EMAIL PROTECTED] Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming debian meetings
On 2007-02-08 20:19 +0100, Ana Guerrero wrote: > On Thu, Feb 08, 2007 at 04:25:32PM +0000, Wookey wrote: > > > > I suggest best initial contact is Cesar Gomex Martin: > > [EMAIL PROTECTED] > > > > gomex-> gomez :) > > (in both surname and email address) Indeed - thank you. I have no idea how I managed to get it wrong twice. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Last call for keys for keysigning in New York City, USA during DebConf10
+++ Aníbal Monsalve Salazar [2010-07-19 14:19 +1000]: > [Resending as I've had problems posting this message] > > As part of the 11th Debian Conference in New York City, USA, there will > be OpenPGP (pgp/gpg) keysignings. If you intend to participate in the > DebConf10 keysignings, please send your ascii armored public key as > explained at [0] no later than Tuesday 20th of July, 2010 at 23:59 UTC. Ah. I have made nice new key (like I was told to at the last debconf). And I suppose I should get it signed. But it on a machine at home and I am in prague all this week, unable to get back into that box for boring technical reasons. So there is no way I can send it to you before the 20th. If it will be a big hassle for me to send it very late (around 25th) then don't worry. I will just do a few quiet signings. I live in Cambirdge so signing is not at all hard to get done (indeed Steve mcintyre is now about 12m away in the next office :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100720162010.gs30...@dream.aleph1.co.uk
tcl8.5 breaks dpkg-cross assumptions and multiarch
tcl8.5-dev contains /usr/lib/tcl8.5/tclConfig.sh
which is a symlink pointing to /usr/share/tcltk/tcl8.5/tclConfig.sh
Currently dpkg-cross only copies symlinks across when crossing a
package if the symlink points to somewhere within /lib. symlinks
outside /lib are ignored because they are not arch-dependent so
shouldn't need to be crossed.
The file /usr/lib/tcl8.5/tclConfig.sh is used by packages which build
extensions to tcl (such as sqlite), so that files does need to be
present.
The file is essentially a cache of the config options TCL was built
with so that extensions can make sure they match up. However it is not
arch-independent. e.g. Line 22 of that file is
TCL_CC='x86_64-linux-gnu-gcc' on the x86_64
version and TCL_CC='arm-linux-gnueabi-gcc' on the armel version.
Other options also differ between 32-bit and 64-bit arches for example.
So this file is arch-dependent in that it's different for each arch it
is built-on but arch-independent in that it's just a shell file.
Debian policy (8.2) says:
---
It is recommended that supporting files and run-time support programs
that do not need to be invoked manually by users, but are nevertheless
required for the package to function, be placed (if they are binary)
in a subdirectory of /usr/lib, preferably under /usr/lib/package-name.
If the program or file is architecture independent, the recommendation
is for it to be placed in a subdirectory of /usr/share instead,
preferably under /usr/share/package-name. Following the package-name
naming convention ensures that the file names change when the shared
object version changes.
Files and support programs only useful when compiling software against
the library should be included in the development package for the
library
---
A maintainer reading the above could reasonably decide that /usr/share
was the right place for this file, because the file itself (being just
shell) is arch-independent. The problem is that the contents are
arch-dependent. Policy is not at all clear on this distinction (It's
been making my head hurt all day). For multiarch, or existing
dpkg-cross cross-compiling, to work, arch-dependent needs to mean
either form _or_ content (see below for elaboration).
The original tcl build puts both tclConfig.sh and tcl.m4 in /usr/lib
but the debian packaging moves them to
/usr/share/tcltk/tcl8.5 and /usr/share/aclocal/ respectively
Currently the sqlite build fails because it looks for tclConfig.sh in
/usr//lib/tcl8.5/ and doesn't find it there, because
dpkg-cross didn't copy the symlink (or original) there.
So, the questions is - which of these is the correct fix:
1) make dpkg-cross copy over symlinks even when they point into
/usr/share
2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of
/usr/share/tcltk/tcl8.5
3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5
instead of /usr/lib/tcl8.5 when building
I note that the supplied tcl8.5.m4 file actually lists a whole pile of
possible locations for the file:
for i in `ls -d ${libdir} 2>/dev/null` \
`ls -d ${exec_prefix}/lib 2>/dev/null` \
`ls -d ${prefix}/lib 2>/dev/null` \
`ls -d /usr/local/lib 2>/dev/null` \
`ls -d /usr/contrib/lib 2>/dev/null` \
`ls -d /usr/share/tcltk/tk8.5 2>/dev/null` \
`ls -d /usr/lib 2>/dev/null` \
`ls -d /usr/lib64 2>/dev/null` \
However that list doesn't include anything ending in tcl8.5
(i.e /usr//lib/tcl8.5 or /usr/share/tcltk/tcl8.5) and perhaps
should by way of 'back-up plan', although I haven't actually looked
into the detals of how that is used.
Consideration when deciding how to fix this include:
Squeeze will be released in a few days with this broken so we will be
stuck with the /usr/share/ file location for some time there. Any fix
going into Ubuntu should make Natty easily enough.
For Multiarch tcl-dev will be a Multiarch:same package (i.e a
'library' package) (despite the name, it contains nothing but headers,
libraries and the above config.sh and m4 files), so the two different
tclConfig.sh files supplied by the DEB_BUILD_ARCH and DEB_HOST_ARCH
packages (when cross-building) will clash and the 2nd package will not
be installable. This, it seems to me, is the clinching argument that
the correct fix is to change the tcl build to put these files in
/usr/lib.
This also implies that policy 8.2 needs to be clarified to explain
what 'arch-independent' means.
Are there other situations which expect to find the tclConfig.sh file
in /usr/share? Is so those need considering.
Does anyone disgree with the above conclusions? And do people agree
that policy 8.2 could be clearer on this point?
I've filed a bug containing some of the above discussion and a patch
for
Re: tcl8.5 breaks dpkg-cross assumptions and multiarch
+++ Steve Langasek [2011-01-31 12:18 -0800]: > > So, the questions is - which of these is the correct fix: > > 1) make dpkg-cross copy over symlinks even when they point into > > /usr/share > > 2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of > > /usr/share/tcltk/tcl8.5 > > 3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5 > > instead of /usr/lib/tcl8.5 when building > > 1+2: dpkg-cross should also copy over symlinks that point to /usr/share. > When such symlinks exist, it's almost invariably because *something is > looking for the information in that location*. So as a general policy, they > should also be made available in a crossed package. But if something is looking for arch-independent stuff in /lib then in general that's wrong, and I'm not aware of any examples of correctly-packaged packages that need this. Any arch-independent files will be supplied by an arch all package that the build should depend on if needed. dpkg-cross has gone for 10 years without needing symlinks pointing into /usr/share, so I'm reluctant to add them without some evidence that it's actually correct. Its policy of only crossing arch-dependent files is the right one, I believe. (It does allow symlinks within /usr/src which presumably has/had a good reason.) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201005222.gm4...@dream.aleph1.co.uk
Re: tcl8.5 breaks dpkg-cross assumptions and multiarch
+++ Loïc Minier [2011-02-01 12:50 +0100]: > On Tue, Feb 01, 2011, Wookey wrote: > > But if something is looking for arch-independent stuff in /lib then in > > general that's wrong, and I'm not aware of any examples of > > correctly-packaged packages that need this. Any arch-independent files > > will be supplied by an arch all package that the build should depend > > on if needed. > > I might be getting your point wrong, but I certainly see a lot of files > in /lib itself which are arch-independent data used for early boot > (before /usr is available); PNG files and text files which would be > identical on all architectures. Sorry, I wasn't being very clear. By 'something is looking for arch-independent stuff in /lib' I really mean in /usr//lib, used during cross-building, (which will be put there by dpkg-cross-ed packages) (or in /usr/lib/ or /lib/ put there by dpkg on multiarch systems). Yes there are various things in /lib that are not arch-dependent. dpkg-cross does not put most(any?) of those in -cross packages. In fact this is so true that it doesn't copy /usr/lib/tcl8.5/tclConfig.sh over into the cross package either. I should have checked that. Bum. dpkg-cross in fact only picks files out of packages by positive identification as libraries or headers. It misses out generic 'other stuff' in ((/usr)/lib, which generally works pretty well, but in this tcl case it's not suffient for tcl-depending apps to cross-build. Bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599206 discusses this issue. dpkg-cross is intended to put files needed for cross-building into -cross packages and it's currently missing this one out. Unfortunately because it doesn't match any of the 'standard paterns for cross-useful files' this can only be fixed by adding a fairly specific regexp, which is worrying close to special-casing or deciding that in fact just fishing out specific things from /usr/lib is too conservative and we should take the view that everything in /usr/lib is potentially useful in cross-building and should be copied into -cross packages. In multiarch world everything in (/usr)/lib is going to end up in /usr/lib/ or /lib/, unless packages are re-arranged to put them elsewhere, and we expect this to work fine so perhaps dpkg-cross should start doing the same thing, and thus discuver any problems this does potentially create. Would that actually do any harm? What files which are currently missed out of -cross packages would actually cause breakage if copied over into /usr//lib? I just tried a modified dpkg-cross on a pile of packages and whilst many come out the same, you do get quite a lot more files in some packages and some packages that were previously null now have stuff in them. e.g apache-modules. So there is quite a lot of bloat, but probably no breakage. Internally we will use a dpkg-cross modified to add /usr/lib/*/tclConfig.sh to the list of things that are important for cross-building. This means we will notice any other 'awkward cases' due to missing files. An alternative view is that anything (such as sqlite3) depending on tclConfig.sh to build tcl extensions is broken and should be changed to use some other mechanism, and until then simply cannot be cross-built using the dpkg-cross mechanism. I am not familiar enough with tcl extensions to know if this is a reasonable stance or not, but given that it works just fine, and it's not hard to deal with, and (after the fix in debian bug#611650) it will carry on 'just working' in multiarch, I'm not convinced this is a reasonable stance. Which leaves us with deciding whether to just copy over tclConfig.sh or everying in /usr/lib/*/* in dpkg-cross? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110203153949.gi4...@dream.aleph1.co.uk
Fun with libtool and cross-builds
inux-gnueabi/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/lib/libc.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status libtool: install: error: relink libboundparam.la' with the above command before installing it make[4]: *** [install-libLTLIBRARIES] Error 1 I note that when doing this libtool --config shows that it does have an idea of where the right place is: maverick)wookey@kh:~/ubuntu/maverick/build/pcre3$ ./libtool --config | grep sys_lib sys_lib_search_path_spec="/usr/lib/gcc/arm-linux-gnueabi/4.4.5 /usr/arm-linux-gnueabi/lib" sys_lib_dlsearch_path_spec="/usr/arm-linux-gnueabi/lib /lib /usr/lib /usr/local/lib" I haven't worked out exactly when and where libtool applies those, but as it seems to get the compiling and linking part right they may be being used (or the compiler defaults are just working as they should). It's only the install/relink phase that is bust (so far as I can tell). pcre3 provides a simpler and quicker-to-build example of the same problem. Here are various previous postings on the subject: Simon Richter in march last year, to libtool list: http://lists.gnu.org/archive/html/libtool/2010-03/msg00013.html (no response) Loic Minier in October last year, to libtool list http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7626 (response: yes that seems to be a bug, no time to fix now, does sysroot option fix it? 'Not for me' said lool) Philip Prindeville from astlinux, July 2010, to libtool list http://lists.gnu.org/archive/html/libtool/2010-07/msg00018.html (response: send us some reproducible examples, and 'heres a ptch for the sysroot-and-deleting-.la-files case') Martin Panter from Openembedded in December 2010, to libtool-patches-gnu http://osdir.com/ml/libtool-patches-gnu/2011-01/msg00025.html which includes a patch to fix it. (response: useful discussion of possible patches) Opinions on the best way to make libtool do the right thing both now and in the future are welcome. Ther are quite a few patches in the above threads providing different solutions, and I haven't yet determined which of them have been included where. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110209190247.gc22...@dream.aleph1.co.uk
Fun with libtool and cross-builds
ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/lib/libc.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status libtool: install: error: relink libboundparam.la' with the above command before installing it make[4]: *** [install-libLTLIBRARIES] Error 1 I note that when doing this libtool --config shows that it does have an idea of where the right place is: maverick)wookey@kh:~/ubuntu/maverick/build/pcre3$ ./libtool --config | grep sys_lib sys_lib_search_path_spec="/usr/lib/gcc/arm-linux-gnueabi/4.4.5 /usr/arm-linux-gnueabi/lib" sys_lib_dlsearch_path_spec="/usr/arm-linux-gnueabi/lib /lib /usr/lib /usr/local/lib" I haven't worked out exactly when and where libtool applies those, but as it seems to get the compiling and linking part right they may be being used (or the compiler defaults are just working as they should). It's only the install/relink phase that is bust (so far as I can tell). pcre3 provides a simpler and quicker-to-build example of the same problem. Here are various previous postings on the subject: Simon Richter in march last year, to libtool list: http://lists.gnu.org/archive/html/libtool/2010-03/msg00013.html (no response) Loic Minier in October last year, to libtool list http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7626 (response: yes that seems to be a bug, no time to fix now, does sysroot option fix it? 'Not for me' said lool) Philip Prindeville from astlinux, July 2010, to libtool list http://lists.gnu.org/archive/html/libtool/2010-07/msg00018.html (response: send us some reproducible examples, and 'heres a ptch for the sysroot-and-deleting-.la-files case') Martin Panter from Openembedded in December 2010, to libtool-patches-gnu http://osdir.com/ml/libtool-patches-gnu/2011-01/msg00025.html which includes a patch to fix it. (response: useful discussion of possible patches) Opinions on the best way to make libtool do the right thing both now and in the future are welcome. Ther are quite a few patches in the above threads providing different solutions, and I haven't yet determined which of them have been included where. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110210105954.ga20...@dream.aleph1.co.uk
Re: Some observations regardig the progress towards Debian 3.1
+++ Yann Dirson [03-11-18 22:54 +0100]: > On Tue, Nov 18, 2003 at 07:29:29PM +0100, Adrian Bunk wrote: > But that last point raises another issue: does anyone really use > testing ? Would anyone use pre-testing after all ? I used testing for a couple of years on my laptop and non-critical machines. I found it a satisfactory compromise between the 'too old' of stable and the massive churn, ever-changing packages and general need-for undating and maintenance of unstable. The primary reason I changed was the 'no security for testing' problem. So I have moved them both to unstable, but it's a lot of extra work and downloads for little gain (I get new packages sooner which is interesting but rarely actually useful) - the only other advantage I get (and the secondary reason I changed) is that I can do test-builds of my packages before uploading on an unstable machine. Doing my builds on a testing machine, then uploading to unstable can mean I introduce packages compiled against the wrong library versions. Source-only uploads would solve this and I could do test-compiles on some debian machine. So I'd say yes, testing is useful to real people, especially those with low-bandwidth net connections but for whom stable is a bit too old. The only thing we need to change to make it more widely useful is to make security updates happen for it in a timely fashion. That would be a sensible use of resources I think. More people using testing ought to help keep it releasable. > > Is testing actually worth the effort? > I suppose many of use have a number of problems to mention. Could we > just (attempt to) list them all, and see if they can be fixed easily ? > Or if they require some in-depth restructuring ? > > I'll start with: > > - build-deps are ignored, causing unbuildable stuff > => handle build-deps in exactly the same way deps are Could someone explain to me why this is the case? Was it an attempt to get things into testing faster that if build-deps were honoured, or was it just expediency. It does seem more sensible to enforce build-deps too to me, but I may be missing something. > - insufficiently-narrowed deps, causing stuff to migrate where it > should not > => this looks like a real non-trivial problem to me. Ideas anyone ? Obviously it can be tricky for a maintainer to get right as they can't necessarily try all (any!) of the possibilities but it should be aspired-to. On the other hand, in my experience build-deps are sometimes unecessaily-narrowed and require new versions of things for no particular reason I can determine. I suspect the shlibdeps automation contributes to this? > > testing with its lack of security fixes, aprox. 500 RC bugs and daily > > changing packages is not usable for production systems. > > What's the problem with daily changing packages ? By nature, only > different packages can change each day. That could make it a good > compromise between stable and unstable, eg. for people in need for > up-to-date desktops. But precisely, one of the problems for those > people, is that _some_ packages _do_not_ change rapidly enough... It's all a compromise, but it's a useful compromise IMHO. It makes sense to me to view testing as a releasable version of unstable and try to keep it that way as much as possible. Build-deps being added to the unstable->testing migration criteria seems to me to be the most fundamental change needed to make that more true, and security support to make it practical for people to use/test in the real world. All the above IMHO as I don't claim to have a deep understanding of all the dependency and trnsitionning issues. I do have an interest in consistent buildability for embedded Debian though. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Bug#170945: ITP: therion -- Cave survey drawing software
Package: wnpp Version: N/A; reported 2002-11-27 Severity: wishlist Package name: therion Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> URL : http://www.therion.sk/ License : GPL Description : Cave survey drawing software Therion is a suite of programs to generate cave surveys/maps. Therion uses Survex, metapost and pdftex to convert textual descriptions of centreline, and passage drawings into finished PDF or postscript drawings in single-sheet or atlas form. A graphical front end (xtherion) allows the drawing data to be entered sensibly, either from new or traced over scanned background images. It also helps with raw survey data entry, replacing the survex-svxedit package. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux knossos 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: LANG=en_GB, LC_CTYPE=en_GB
ITP survex
Survex is cave-surveying software, available for several platforms (Unix, Windows, RISCOS, DOS). IT has been available as an unofficial debian package for a year or so since I first had a go at packaging it, and the upstream author included that and made them work. However the packaging is primitive as well as unofficial so I've decided its time to do it properly. This work has been progressing astonishingly slowly so I refrained from posting here, but as I'm in danger of making some progress, I decided it was time to post an ITP. see http://www.survex.com/ for the current downloads and info. Wookey
Re: SV: MATE 1.8 has now fully arrived in Debian
+++ Svante Signell [2014-06-24 19:57 +0200]: > > I strongly recommend the systemd-must-die package to prevent systemd > components being installed when dist-upgrading without the user being > aware. Where is this package? I'm not finding it in testing or the pts? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626102028.gs10...@stoneboat.aleph1.co.uk
Re: SV: MATE 1.8 has now fully arrived in Debian
+++ Matthias Urlichs [2014-06-26 11:58 +0200]: > Hi, > > Andrew Shadura: > > http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+sysvinit&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%Y-%m&beenhere=1 > > > Sorry, but this only demonstrates that you don't know what you're talking > about. > > For a comparison that's even remotely meaningful you want sysvinit-core, > not sysvinit. http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+sysvinit-core&show_installed=on&want_legend=on&want_ti%20+cks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%Y-%m&beenhere=1 Which shows about a change from 'peak sysvinit-core' in mid-april: Mid april Now sysvinit-core:89% 81% systemd-sysv: 6% 19% Which seems plausible. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626104535.gt10...@stoneboat.aleph1.co.uk
Re: SV: MATE 1.8 has now fully arrived in Debian
+++ Svante Signell [2014-06-26 12:31 +0200]: > On Thu, 2014-06-26 at 11:20 +0100, Wookey wrote: > > +++ Svante Signell [2014-06-24 19:57 +0200]: > > > > > > I strongly recommend the systemd-must-die package to prevent systemd > > > components being installed when dist-upgrading without the user being > > > aware. > > > > Where is this package? I'm not finding it in testing or the pts? > > Not in any official Debian repo unfortunately: > > http://users.unixforge.de/~tglaser/debs/dists/etch/wtf/Pkgs/mirabilos-support/ Can it be uploaded please? As has been observed, there is a reasonable number of people who would like an easy way to control explicitly when/if they change to systemd for pid 1. Having to get it from a separate repo should not be necessary. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626133349.gv10...@stoneboat.aleph1.co.uk
Re: SV: MATE 1.8 has now fully arrived in Debian
+++ Marco d'Itri [2014-06-26 16:29 +0200]: > On Jun 26, Wookey wrote: > > > Can it be uploaded please? As has been observed, there is a reasonable > > number of people who would like an easy way to control explicitly > > when/if they change to systemd for pid 1. Having to get it from a > apt-get install equivs Yes and write an equivs control file. I could (I even know how to already), but if there is a standard package then we don't have to do that individually. I'm sure we have plenty of less-used software than this will be, at least for a while. And a less inflamatory name would be sensible, but I do enjoy the humour in the one it has :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140627105544.gh10...@stoneboat.aleph1.co.uk
Re: How to avoid stealth installation of systemd?
+++ Thorsten Glaser [2014-07-01 14:45 +]: > Juliusz Chroboczek wrote: > > >So I'm turning to this list for help: > > > > 1. Could some competent person tell me the right way to tell apt that it > > should fail an upgrade rather than installing systemd? I guess > > I could make a dummy package that conflicts with systemd, but I'm > > I made such a dummy package, and Wookey wanted to upload it > yesterday IIRC. It is not on https://ftp-master.debian.org/new.html > yet, though. Ah yes. E-busy. Just uploaded 'prevent-systemd'. Whilst it's sat in NEW, you can get it from: http://wookware.org/software/repo/ i.e deb http://wookware.org/software/repo/ sid main You get a choice of 'prevent-systemd' which stops it running as init but allows the -shim and libpam packages so that logind and the like will work. Or 'systemd-must-die' which conflicts with everything systemdish. There may be a need for an intermediate package too, but lets see how this goes for people. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140701152301.gm10...@stoneboat.aleph1.co.uk
Re: How to avoid stealth installation of systemd?
+++ Lars Wirzenius [2014-07-01 18:34 +0100]: > On Tue, Jul 01, 2014 at 04:23:01PM +0100, Wookey wrote: > > You get a choice of 'prevent-systemd' which stops it running as init > > but allows the -shim and libpam packages so that logind and the like > > will work. Or 'systemd-must-die' which conflicts with everything > > systemdish. > > Wookey, > > Please rename the systemd-must-die package to something neutral. Thank > you. OK. I did rename the source package, but I liked the binary and thought anyone else who actually wanted this would enjoy it too, so it seemed appropriate despite not being entirely 'PC'. I think some people are failing to see the humour in this name (and Dawkins knows we could use some humour round this subject), but I guess if it's not going to be allowed then it's not going to be allowed. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140701231331.gs10...@stoneboat.aleph1.co.uk
Re: MATE 1.8 has now fully arrived in Debian
+++ Stefano Zacchiroli [2014-06-30 11:43 +0200]: > On Mon, Jun 30, 2014 at 10:27:49AM +0100, Lars Wirzenius wrote: > > On Mon, Jun 30, 2014 at 10:42:09AM +0200, Tollef Fog Heen wrote: > > > ]] Thomas Goirand > > > > +1 for keeping the name which is funny > > What's funny about an OS stating publicly that a specific piece of Free > software---shipped and installed by default by that very same OS---"must > die"? Every package name in debian is not a 'statement of the OS' as a whole. Each one is just a package name, most of which are vaguely descriptive, some are punny, many rather cryptic. None that I can think of are a 'statement'. The systemd people won the argument. Giving those who prefer not to use it (yet) a slightly childish package to install is a small consolation for them and really shouldn't be taken very seriously. I'm afraid the name amused me - and I assume I'm not the only one. But OK. I get it - this is still too contentious to have any room for this sort of foolishness and if it's to exist at all it'll have to be called something boring. That's a little sad, but we'll all survive. This isn't supposed to be a big deal, just a small convenience. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140702005305.gt10...@stoneboat.aleph1.co.uk
Re: possible MBF: automatically detecting unused build dependencies
+++ Steve Langasek [2014-07-07 15:07 -0700]: > On Mon, Jul 07, 2014 at 09:14:44PM +0200, Johannes Schauer wrote: > > I agree that it should not be a bug if a package does not fail if a certain > > build dependency is not installed. > > > Nevertheless, those "false positives" that were generated this way are still > > useful to be later marked with once build profiles are > > allowed in the archive because they are obviously droppable. > > No, marking build-dependencies with build profiles should be driven by what > is needed to break build-dep loops, not by what build-deps are "droppable" > without further modification of the packages. Excessive stage1 profile > tagging will result in unnecessary extra builds during a bootstrap. Whilst I agree that a build-dep being droppable is not necessarily sufficient reason to mark it as a stage1 profile, I don't agree with your reasoning. Having a profile available does not mean that it will necessarily be used/built. The path through the bootstrap is determined by currently-buildable and profilable packages. Having more profiles marked just potentially gives us more possible routes through the dependecny graph, which (up to a point) is generally a useful thing with a new arch as you don't always know in advance which packages will be most trouble. The chosen route is unlikely to use all the profiles available unless there really are only just enough to do it at all. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707224831.gt10...@stoneboat.aleph1.co.uk
Re: trying to build debs of Enlightenment for wheezy
+++ John Holland [2014-07-11 19:09 -0400]: > Subject says it all - I've been working on this a bit, and I have a few > problems - I hope these aren't too newbie of questions. > > Presently I'm working on EFL, Enlightenment Foundation Library, which > is the lion's share of the work in terms of dependencies. > I apologize if this is the wrong place to ask these questions. If that > is the case please direct me to the right place. The right place is the debian-mentors mailing list https://lists.debian.org/debian-mentors/ You will get good advice there. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712091344.gx10...@stoneboat.aleph1.co.uk
Re: let missing-debian-source-format lintian tag be a warning!
+++ Michael Gilbert [2014-07-15 18:39 -0400]: > On Tue, Jul 15, 2014 at 3:50 PM, Scott Kitterman wrote: > > It would be nice, however, to have a way to specify the alternate behavior > > in > > a consistent reliable way (meaning something I can put in the package when I > > add source/format). > > Archive consistency is far more important than individual maintainer > preference about this behavior. People that work on lots of different > packages deserve dpkg-source to act consistently across the entire > archive. I would strongly second this view. As a porter it is a very good thing thing that all quilt/3.0 packages behave the same way, whatever the maintainer's preferences. Having some aply patches and some not, would just be yet another source of random oddness in packages, and we have more than enough of that already. > This would be far better solved with a system conffile of some sort > like /etc/dpkg/dpkg-source.cfg, which admittedly doesn't exist yet. Agreed. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140716001905.gk22...@stoneboat.aleph1.co.uk
Re: NMUing generally
+++ Holger Levsen [2014-07-16 15:17 +0200]: > Hi Riku, > > On Mittwoch, 16. Juli 2014, Riku Voipio wrote: > > This a side-effect from Debian's policy that discourages fixing bugs in > > other maintainers packages via NMUs. Somehow, it is felt better to > > remove packages from testing than possibly offending the maintainer with > > an unwarranted NMU. > > Huh, as I see it, this has changed and a.) NMUs to fix RC bugs are generally > very much encouraged and b.) NMUs to fix other bugs are also perceived much > better nowadays than "in some old days". > > Especially if the NMU is properly done (eg documented in the BTS, uploaded to > DELAYED-foo, etc) I've hardly seen any complaints in recent years. Mostly. I've done a pile recently (40+) (largely autoconf-update bugs) and only had one instance of outright hostility, a few queries, a few pre-empting uploads by the maintainer, and a couple of 'thanks, please upload ASAP'. The majority just went through with no explicit response. That was almost all packages that have had a bug filed for between 5 years and a couple of months, where an NMU seems unarguable. So that does mean we are down to less than 2% obnoxious maintainers :-) I'm now getting on to ones where I file a new NMU bug along with the delayed upload, and that feels a bit 'pushier'. We'll see how that goes. I still feel like I need to make excuses for not filing a bug, waiting a couple of weeks and _then_ doing an NMU, which of course is a great way of adding a pile of fairly pointless delay. BTW is there a reason why nmudiff doesn't actually do the upload, as well as filing the bug? It's very easy to forget the upload and thus confuse the maintainer by saying 'I have uploaded foo to delayed/X' when in fact you've not. It could easily enough run dupload or dput at the end... I do think there is plenty more room for soialising more NMUing. There are piles of bugs in the archive that mostly just need uploading, and many packages with a backlog of minor bugs, or packaging that frankly just needs updating. But a lot of this quickly gets into 'updating' and 'de-crufting' rather than simply minimally-bug-fixing. I suspect that would see more pushback if one did much of it. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140716214758.gt22...@stoneboat.aleph1.co.uk
Bug#755035: ITP: rt-app -- Test application which simulates a real-time periodic load
Package: wnpp Severity: wishlist Owner: Wookey * Package name: rt-app Version : 0.2_alpha Upstream Author : Giacomo Bagnoli * URL : https://github.com/gbagnoli/rt-app * License : GPL2 Programming Lang: C Description : Test application which simulates a real-time periodic load rt-app is a test application that starts multiple periodic threads in order to simulate a real-time periodic load. It supports the SCHED_OTHER/SCHED_FIFO/SCHED_RR kernel mechanisms as well as the AQuoSA framework and SCHED_DEADLINE. It can be run with a simple command-line config, or a more complex set of tasks/threads configured in a (json) config file. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717025839.863.18622.report...@kh.home.wookware.org
Re: Reintroducing FFmpeg to Debian
+++ Andreas Cadhalpun [2014-07-28 01:20 +0200]: > Hi all, > > some of you may have noticed a weird ffmpeg package in the NEW queue[1]. > Let me explain: > * Ok, let's say I'm a multimedia maintainer and want to try out >building my package against your ffmpeg, what should I do? > > Any maintainer interested in switching should get in touch, and we'll > gladly help preparing the transition. > The FFmpeg version currently in NEW has been there for more than > 2 months and is thus outdated. If you want to test the current > packages, you can build them from the repository on Alioth [17] > (e.g. using git-buildpackage). Thanks for doing this work. I too am a bystander in the ffmpeg/libav debate but I have an interest due to having fixed up the ubuntu and deb-multimedia mythtv packages for Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570611 http://wookware.org/software/repo/pool/main/m/mythtv/ Those packages work and and been patched to use libav. However I have found a few bugs in real usage (like crashing after 40mins). Because upstream deveop exclusively with ffmpeg it would be very useful to rebuild tose packages against ffmpeg and see if they work the same/better/worse. Thanks for providing info on how to do this. Personally I'd like to see ffmpeg in debian so I could trivially build against it and (quite probably) use it by default if available, simply because it's inline with upstream and less likely to break. I really don't see sufficient reasons why we shouldn't at least put it experimental so that maintainers can easily test this stuff. Yes the whole fork thing has worked out most unfortunately, but ISTM that Andreas' packaging is a sensible way to let maintainers use this package or libav and easily test with both. Yes, in theory I could fix up any bugs due to divergence between the two libraries but that's not going to happen in practice as I know nothing of multimedia libraries and codecs. I just want a mythtv package in Debian (as opposed to debian-multimedia and ubuntu where they have been for years), and am happy to do packaging-level work to make that happen. (I've also been a tad busy with arm64 and cross toolchains and bootstrapping to make anything other than very slow progress on this project...) But overall, I vote for letting it through new. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805154525.gp22...@stoneboat.aleph1.co.uk
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
+++ Reinhard Tartler [2014-08-08 08:29 -0400]: > To the best of my knowledge, there are only two high-profile projects > that play hardball to require FFmpeg: Mplayer and mythtv. Neither of > those do that (again to the best of my knowledge) mainly because of > technical but rather very political reasons. The case of mplayer has > been elaborated extensively in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the > following "discussion" with Reimar - my conclusion from that is while > technically possible, nobody wants to make mplayer work with Libav - > and that's why it was removed, not because of the FFmpeg dependency). > For Mythtv I can only say that they didn't even bother engaging any > discussion. My expertise here is extremely limited, but some practical experience shows that mythtv does at least basically work fine with libav. I did find one serious issue so far (in one version, on one piece of hardware, so hardly extensive testing), but I have no data to know if it is any better with ffmpeg, just a feeling that it might because becuase that's what upstream test with. I believe the mythbuntu builds are using libav rather than the internal ffmpeg, but I could be wrong...? Who kows for sure? I have just got another dev interested in helping with mythtv, so it might still make it into jessie. And his help might give us time to delve into this a bit further and fond out if using ffmpeg does make it materially better or not. That testing is easier if ffmpeg is available in debian, but obviously possible without. Thanks for your response, which provides some useful info. I assure you that it was worth your time. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808150500.gz7...@stoneboat.aleph1.co.uk
Re: Multiarch capabilities for mingw crossbuilds too?
+++ Joerg Desch [2014-08-08 05:38 +]: > Today I've read about Debians Multiarch capabilities for the first time. > Is it possible to use this technique to build deb packages of libraries > for the mingw crosscompile toolchain too? In principle, yes. In practice right now, no. Stephen Kitt has looked into this and gave a comprehensive talk at this year's mini-debconf (But I can't find a URL as I'm not sure that Sylvestre has actually uploaded them anywhere). I think this pdf is the slides though: http://www.sk2.org/talks/crossporting-to-windows.pdf It has the potential to be exceedingly slick and remove a whole load of packaging cruft we currently have to make windows/mingw-ready versions of libraries. There is some discussion on this therad: https://lists.debian.org/debian-devel/2011/04/msg01243.html > I have to build Windows executables and therefore need some libraries. > For now, I build and install them locally. It would be fine to have a > way just to apt-get install them. > > Any chance? Yes, but it needs some work. I'm sure Stephen would love some help :-) I don't know if he's made any progress since feb. The trickiest part is that, having demonstrated that this works, we would have to change the definition of 'architecture independent' a little to include 'posix/non-posix' which mostly means moving a lot of libc stuff from arch-independent locations to arch-dependent locations, and that might be a hard sell in Debian. It _should_ only affect libc packaging, but work needs to be done to demonstrate that. Everything else is straightforward, and indeed a simplification of the current state for any package that produces win32/64 libs. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808154122.gb7...@stoneboat.aleph1.co.uk
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
+++ Wookey [2014-08-08 16:05 +0100]: > > My expertise here is extremely limited, but some practical experience > shows that mythtv does at least basically work fine with libav. It turns out that this is completely wrong (as hinted at in later mails). I was mislead by info in bugreports. The (prospective) Debian and Ubuntu (and deb-multimedia) Mythtv packages do not use libav. So far as I can tell they all use the internal ffmpeg fork (for the reasons explained elsewhere in this thread). It would appear that rebuilding against libav is a non-trivial piece of work. Rebuilding against system ffmpeg would presumably be easier, but still not necessarily simple. Both will reduce speed and/or functionality and at least initially probably introduce bugs. Unless we were to decide to make an exception re internal libraries (which seems unlikely in this case given the general discussion on security load), this package is not going to make it into Debian anytime soon, which from my POV is very sad - I had thought we were closer than this. Still, it's only been 5 years so far - don't want to rush these things :-) I hope we can at least maintain some compatible packages outside the archive. Hopefully some tuits will be found to make some progress on this (we're (well Simon Iremonger is) doing some mythtv-on-arm builds/testing at the moment) to see what does/doesn't work there. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811142032.gi7...@stoneboat.aleph1.co.uk
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
+++ Kees de Jong [2014-08-12 02:03 +0200]: >Are we really comparing RAM here as if it were the 90's? How many people >here use Android? Today it needs 512 MB to function properly. In two years >that could be 1 or 2 GB and that's a mobile OS. How much RAM does your >browser use? Too much! I agree browsers use more ram than desktops these days, or at least the big ones (firefox, chrome) do. >My Chrome/Firefox easily uses 1 GB. My GNOME 3.10 desktop >(running Fedora now because I needed a modern GNOME version for Exchange >support for work) is using about 800 MB to 1200 MB. Do I really care? No, >because RAM is cheap and I have 8 GB. Do I need to buy more? No, because 8 >GB is still more than enough. That's fine so long as your hardware is new enough to take more memory. Anyone with an ARM machine will be in the 512MB/1G/2G camp. My laptop (x200s) officially maxes out at 4G, although it turns out that 8G does actually work in practice. Memory usage does still matter as your hardware doesn't have to be particularly old to have RAM of a size that is likely to all get used, and on arm (increasingly being used for netbook/laptop/desktop usage) it's practically guaranteed. So yes, it's not the 1990s but I think we should aim to make Debian to work tolerably well on 2 or 4G systems. Alistair posted numbers suggesting 600MB for gnome3 or KDE, 360 for XFCE, 300 for LXDE, which is a difference, but not a huge one. Very significant on a 512MB machine, but not that significant on 2G. You say 800-1200 above which is twice as much. Is this the differnce between initial boot up and usage after some time, or 'various add-ons'? Knowing what 'typical' numbers are would be useful. I have various well-used XFCE desktops I could check but I'm not sure how to get a cmparable RAM-usage number of them. >If you can't run GNOME because you don't have the system specs to run a >modern desktop then you can select XFCE/LXDE in the installation menu. But >let's be fair, those people are a minority. And a default should fit the >needs of the majority. And since people easily have 4 GB of RAM or more >these days with the basic 3D acceleration I only had 2G RAM till last year (when I had to buy some more because browsers take so much damn RAM). I think we should at least consider those people in the 'typical machines' bucket. > (even a Raspberry Pi can run GNOME 3) A Pi is only 512MB, so 'barely'. Like most arm hardware memory levels are still low by modern x86 standards. They are like late 90s/early 2000s x86 machines in this regard. I don't want to over-emphasise the arm thing - it is still a minority sport - but it's a growing area of usage where memory is still limited. I just wanted to counter a little the 'everyone has buckets of RAM these days' view, whilst acnowledging that it is no longer the 90's and a 512Mb machine will struggle with any modern desktop+browser (which is sad IMHO - dawkins knows what software, especially browsers, do with all that memory! - hundreds of Mb for simple tables of built packages, for example, but I digress :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812085008.gl7...@stoneboat.aleph1.co.uk
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
+++ Anthony F McInerney [2014-08-12 00:02 +0100]: >XFCE: > > total used free sharedbuffers cached >Mem:506756 362468 144288 6568 22756 179264 >-/+ buffers/cache: 160448 346308 >Swap: 392188 0 392188 > >GNOME: > > total used free sharedbuffers cached >Mem:506756 500360 6396 1948840 37724 >-/+ buffers/cache: 461796 44960 >Swap: 392188 66672 325516 > >LXDE: > > total used free sharedbuffers cached >Mem:506756 316504 190252 8500 18920 149812 >-/+ buffers/cache: 147772 358984 >Swap: 392188 0 392188 > >KDE: > > total used free sharedbuffers cached >Mem:506756 499724 7032 6772 10516 109760 >-/+ buffers/cache: 379448 127308 >Swap: 392188 21632 370556 Thanks for this, interesting. Could you do MATE too please? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812085136.gm7...@stoneboat.aleph1.co.uk
Re: Two new architectures bootstrapping in unstable - MBF coming soon
+++ Manuel A. Fernandez Montecelo [2014-08-27 20:25 +0100]: > > Congrats! The sooner that you graduate out of debian-ports, the > better for other architectures that want to get into ;-) -- although > arm64 is still there, for some reasons. We are using the binaries in debian-ports to help bootstrap debian proper (cycle breaking), so will keep debian-ports running until everything there is also built in debian-proper, then we can turn it off, and as you observe, 'free up' a slot. That should be within the month judging by current rates of progress. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140828005517.go19...@stoneboat.aleph1.co.uk
Re: Minimum ISA
+++ Vincent Danjean [2014-10-08 23:52 +0200]: > Hi, > > Is there somewhere a list of the minimal ISA for each supported Debian > architecture? > For example, for armhf, the answer is here: > https://wiki.debian.org/ArmHardFloatPort#Minimum_CPU_.26_FPU > But I did not find this kind of information for all other Debian > architectures. > > The goals is to tweak the code generated by pocl (a free OpenCL > implementation) to be sure it will run on all supported machines. Right. We are missing a distro-wide location for this information. Currently it is effectively defined by the default build settings of gcc. But really we should have an agreed place to find this info and all compilers (but not jits as they can just use 'this machine I'm on') should use the same defaults. I'm not sure how many compilers we use to pre-build things in the archive but I suspect there are quite a few. I filed a bug aginst llvm recently as it doesn't even have a mechanism to set this info, for distros to use, yet. Deciding to have such info writen down somewhere is a good start, but ther remains an interesting question about what format you write it down in, as presumably each compiler uses (slightly?) different ISA terminology. I'd certainly like to follow up this problem next year. A useful start would be if people could list the affected packages, beyond gcc* and llvm-toolchain*. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009142533.gu19...@stoneboat.aleph1.co.uk
Re: Built-Using, again…
+++ Thorsten Glaser [2014-10-13 12:05 +0200]: > Hi all, > > > sbuild/buildd runs apt-get update, but not apt-get *upgrade, > before each build. But I assume this should not be changed > either… I _think_ we don't do this because the upgrading uses a lot of time on buildds, especially slow ones. I did do this (build in snapshot, upgrade for every build) for the whole arm64 debian-ports bootstrap and it worked fine, but the buildd did spend a lot of time upgrading the same packages over and over until the snapshot was updated (which was manual and done approx weekly). This particularly adds overhead to small, quick builds. I think existing policy on official buildds is to manually upgrade chroots approx weekly or on request? I would favour a daily snapshot/chroot upgrade (as opposed to doing it on every build) as a compromise between 'every build' and 'weeklyish'. Is there a good reason for not doing that? There is always a small risk of breakage on upgrades. Keeping the spevious snapshot as a fallback would be one easy way of that not usually causing any real problems for admins. > So we need either a technical, or a policy-ical, or a human, > solution to this problem, right? The situation could clearly be improved. (I have an interest in built-usuing currency for cross-toolchain builds). Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141013101719.gg19...@stoneboat.aleph1.co.uk
Re: piece of mind (Re: Moderated posts?)
+++ Didier 'OdyX' Raboud [2014-10-13 17:33 +0200]: > I really don't buy the argument that "the GR proposal was too quiet to > be noticed by 6+ people". I mean: the proposition happened to be in the > middle of the post-TC decision wave, on the mailing lists where it > belonged. The people who cared about the whole "default init for Debian" > question _were_ following and contributing to these various lists. I'm > therefore claiming that the people who missed the GR proposal were not > sufficiently interested (otherwise they would've been subscribed to > either -vote or -project, where these proposals belong). I might well have supported a GR (depending exactly what it said), but I'm not on -vote or -project (yes, I probably should be), so I didn't notice that one was proposed. (I was also very busy trying to do actual work). I was a little surprised that all that angst failed to generate a GR. Turn out that in fact it did. > Doing this now despite the fact that the GR didn't reach its 6 seconds, > 7 months ago, will lead to an incredibly bigger waste of time, just when > we're about to freeze testing. > > The GR train passed… At this point I'm inclined to agree. I'm just pointing out that interested people, who are moderately well-involved, really did miss that a GR was attempted. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014001348.gk19...@stoneboat.aleph1.co.uk
Re: Adding and using repositories during package installation?
+++ Malte Forkel [2014-10-22 14:44 +0200]: > Hi, > > I'm thinking about creating a metapackage to setup a software > development environment. It would not only have to depend on some > prerequisite packages, but also add repositories and install a package > from one of them. Is there an acceptable way to do that? > I guess I shouldn't use things like 'add-apt-repository' and ''apt-get > update' in maintainer scripts. I could probably add files to > /etc/apt/sources.list.d and /etc/apt/trusted.gpg.d. But how could I > perform the update required to install a package from one of the new > repositories? I take it that this package needs to be installed on the main system, not just present for builds? If you use sbuild for builds, the new (in sbuild 0.65 - targetted for jessie) --extra-package and --extra-repository options make it very easy to add a repo and packages to the build environment. That might help, or not, depending on what your actual requirements are. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022134612.gk19...@stoneboat.aleph1.co.uk
Re: Hurra for an efficient ftpmaster team!
+++ Jonas Smedegaard [2014-10-22 19:04 +0200]: > Hi, > > I have to share with you all how very positively surprised I am by the > efficiency of the ftpmaster team processing the NEW queue. I feared > that we might experience extra slow processing this close to the freeze > but my experience have been quite the contrary. > > Hurra for the ftmaster team! thirded > I know processing is not always simple and that I might just have been > "lucky" lately (read: my recent uploads may simply be easy to handle). I It's not just that. I've had some complicated ones and they have also been handled carefully and promptly. Things are working well, and we do do indeed appreciate your work, FTPmasters, especially at this busy time. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023102342.gv19...@stoneboat.aleph1.co.uk
Re: inconsistent versions of M-A: same packages
+++ Marc Glisse [2014-11-01 11:45 +0100]: > Hello, > > sorry for the naive question, but is there a plan for massively > rebuilding all "Multi-Arch: same" packages that have inconsistent > version numbers across architectures before releasing Jessie? I don't know, but I think there should be. Thank you for bringing this up. As you say, currently this is the only way to make multiarch co-installability work properly. I am happy to spend some time scheduling rebuilds to resync all arches to whichever number is highest. This problem will have been made worse by the late-in-the-cycle additions of arm64 and mips64el (despite some effort being made to avoid library binNMUs when there was a choice, specifically to minimise the size of this issue) so it's only fair that us porters take the time to fix it up. The problem evaporates when new source versions are uploaded, and I expect there will be a fair amount more of that before release time due to bugfixes. So I expect the release team have an opinion about the most appropriate time for deciding that some 'version sync only' rebuilds should be scheduled to fix remaining library-version mismatches. It is currently a feature of our bootstrap/import process that we do binNMUs of packages (to rebuild packages originally imported from debian-ports to break cyclic dependency loops on the 'kosher' buildds, or to rebuild profile-built bootstrap packages). And some of these imports have to be library packages, so this issue inevitably arises. Before multiarch this didn't actually matter. They are also heavily used for library transitions where arches have different sets of packages built against an old library (and thus need rebuilding to get rid of the old version). Changes to the system such as a mechanism for rebuilds that didn't change the version number, or changes to dpkg to consider binary rebuilds 'multiarch equivalent' would solve this in a more systematic way. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141101141901.gt28...@stoneboat.aleph1.co.uk
Re: inconsistent versions of M-A: same packages
+++ Ralf Treinen [2014-11-07 17:35 +0100]: > On Fri, Nov 07, 2014 at 02:46:31PM +, Holger Levsen wrote: > > For this reason we should probably limit ourselves to all the interesting > cases of combinations of native and foreign architectures. The only > reasonable combination that I can currently think of is > > native-arch: amd64 > foreign-archs: i386 > > Are there are any other useful combinations ? Maybe in the arm world? For cross-building there are lots of useful combinations. Many combinations are interesting but currently native is usually amd64, sometimes i386, soon other arches like arm64 and ppc64el might become more popular as native build host: native-arch: amd64 foreign-archs: , could sometimes be a list like 'armel armhf', 'powerpc ppc64el' For general runtime multiarch use I've found native-arch: arm64 foreign-arch: armhf useful recently (for using armhf packages in bootstrapping when arm64 ones were not yet available/working) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107183329.gs28...@stoneboat.aleph1.co.uk
Re: inconsistent versions of M-A: same packages
+++ Marc Glisse [2014-11-01 11:45 +0100]: > > A few random packages that currently have an inconsistent version: > zlib1g (+b1 on ppc64el) examining this I notice that whilst this page on p.d.o: https://packages.debian.org/jessie/zlib1g shows the issue, and so does this buildd one (for unstable): https://buildd.debian.org/status/package.php?p=zlib&suite=sid this one (testing buildd view) says all the versions are the same: https://buildd.debian.org/status/package.php?p=zlib&suite=jessie Is there any reason why the last URL shows the wrong version for ppc64el or is it just a bug? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110005906.gw28...@stoneboat.aleph1.co.uk
Re: inconsistent versions of M-A: same packages
+++ Wookey [2014-11-01 14:19 +]: > +++ Marc Glisse [2014-11-01 11:45 +0100]: > > Hello, > > > > sorry for the naive question, but is there a plan for massively > > rebuilding all "Multi-Arch: same" packages that have inconsistent > > version numbers across architectures before releasing Jessie? > > I am happy to spend some time scheduling rebuilds to resync all arches > to whichever number is highest. If I schedule rebuilds for expat (for example), to get all arches to +b3, I then need to check if anything has a versioned dep on libexpat1 that this will break, and then rebuild those too, right? OK. in fact some grep-dctrl runes suggest that nothing in the archive does, except libexpat1-dev, so that's OK. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110024253.gx28...@stoneboat.aleph1.co.uk
Re: Let's abandon debian-devel.
+++ Charles Plessy [2014-11-10 23:25 +0900]: > Hi all, > > >From now on I will try to see if I can give to Debian the same quality of > contribution without being subscribed to debian-devel. And I invite you to > think about it and *not* to discuss it on this list. Just a data-point: I joined d-devel when I joined debian. It was noisy and after a while I unsubscribed. And it stayed that way for several years. I did my stuff in my little corner and that worked, but I had almost no idea what was going in in Debian generally and was often surprised by events/changes. At some point I tried joining up again and have since become much more involved, at least partly due to having some feel for what is currently going on. So -devel is noisy and sometimes unhelpful, but at least for me being subscribed is definitely more useful than not being subscribed. Possibly the same effect could be achieved by joining -project. I've never tried that... So if your purpose is just to work on your packages, then yes ignore -devel - you will get a quieter life. But it does disconnect you noticeably. Perhaps that is less true than it was, as there are more alternatives (such as planet). Just some (anecdotal) data. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014122711.gd28...@stoneboat.aleph1.co.uk
Re: [Pkg-javascript-devel] Node.js and it's future in debian
+++ Patrick Ouellette [2012-05-01 23:12 -0400]: > Of course the #! line is not the issue. The issue is two upstream maintainers > separated by years and miles selected the same generic name for their binary > file. Compounding the issue, some Debian Maintainer seeking to better the > project by packaging additional software for the project failed to perform > "due diligence" in researching if any of the binary names from the proposed > new package were already in use. Just a quick question - is there an easy way to do this? I worry sometimes that I might be creating a binary name that is already used somewhere, and thus a potential clash, but it is not obvious to me how to check. Strictly this applies to every file in a package, although clashes are most likely in /usr/bin Wookey -- 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/20120502165354.gc13...@stoneboat.aleph1.co.uk
Re: Bug#648345: marked as done (FTBFS on kfreebsd-amd64)
+++ Marco d'Itri [2012-05-04 16:01 +0200]: > On May 02, Debian Bug Tracking System wrote: > > > -Architecture: any > > +Architecture: linux-any > Robert, don't you have anything better to do with your time than NMU'ing > other people's packages with cosmetic issues? > I obviously do not want to dictate how you should spend your time, but > is kfreebsd already working so well that you are bored? That doesn't look cosmetic to me. That looks like an FTBFS fix for kfreeBSD, which he gave you 5 months to do yourself before NMUing it. Seems fair enough, and he _is_ fixing kfreebsd. Wookey -- 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/20120504142545.gr27...@stoneboat.aleph1.co.uk
Re: Wheezy release: CDs are not big enough any more...
+++ Steve McIntyre [2012-05-15 13:38 +0100]: > [ re-adding CC to debian-cd and debian-boot ] > > 2. USB-targeted images > > I've also tweaked DVD#1 of each set to fit in 4GB instead of the > normal 4.7GB, so that it fits on a 4GB USB stick to make it more > useful. We could quite readily produce (say) 2GB images specifically > designed for smaller USB sticks if enough people consider that to be > useful. I'm thinking that would be a specific single extra > image. Thoughts? I have always installed from USB stick (or SD card) on everything for the last several years. It must be 4 years since I used a CD or DVD. Especially on dev boards (x86 or arm) that is usually the only medium slot you have. I assume this is common. And the USB-stick process is not as simple as it might be because you have to find the HD-media files and then _also_ find an iso image to put on. It's no wonder newbs are still downloading CD/DVD images. Only last night I tried to install current testing to an intel dev board. I tried using unetbootin which is a great way of making the USB-key install process less cryptic, but for some reason it failed to get unstable images, and could only manage testing ones. (I'll check that and file a bug tonight). I think we could usefully focus on making the USB-stick/MMC card experience simple as that covers an awful lot of modern use-cases. It currently feels like a bit of a 'poor relation'. That might mean recommending the use of Unetbootin (and making sure it works), or providing complete say 2G and 4G images and some simple way of burning them. Maybe a 'debianised' version of unetbootin that just provides debian images and hides most of the gory details, but will help stop you shooting yourself in the foot? It looks to me like we have all the parts for that, it's just the emphasis needs changing, or maybe even just the docs updating (I may not be doing this the easiest way - it's not totally obvious from the debian download page what to do - AIUI you have to read the install docs, and understand to download the hd-media files (either the image gzip or the files) and an iso from somewhere else and put it all on the stick.) > 3. Which installer image(s) should we link to as preferred? > > We're currently linking to the multi-arch amd64/i386 netinst CD from > the front of www.debian.org. I think that's still a good choice, but > I'm open to being convinced otherwise. add a netinst USB image would be a good thing IMHO. Along with the equivalent tool to a CDburner to make it painless. Maybe even make netinst USB sticks the default over CDs? And try to hide the 'hd-media' name at least in initial download selection, because it is geek-accurate, but rather confusing to a newcomer. Wookey -- 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/20120515142459.gf11...@stoneboat.aleph1.co.uk
Re: Wheezy release: CDs are not big enough any more...
+++ Timo Juhani Lindfors [2012-05-15 21:01 +0300]: Yes, turns out I failed to read the instructions right, presumably due to thinking I knew how this worked (i.e. you can't just put an iso stright onto a USB stick, and you need 'hd-media' for USB sticks). I'm glad to see that this has got significantly simpler. > ubuntu uses the usb-creator package to provide a dbus api that allows > normal users to create usb installation media. (It carefully checks that > you can not write to the internal hard disk). I think this is what most inexpert users would like to see - a reasonably idiot-proof GUI tool for downloading an installer image and putting it on the USB stick for them. usb-creator is in ubuntu but not Debian for no good reason. It has already had Debian support added. One of the uploaders, and the person who added the Debian support is a DD: Dmitrijs Ledkovs. Dmitri - is there any reason not to just upload this to Debian? I see a couple of places in the UI where it says 'Ubuntu' and it would be good if it got a bit cleverer and put in the appropriate string with dpkg-vendor, as it already does for the logo files. I also fixed up the build so it skips the not-present dh-translations on Debian, and otherwise modified the deps for Debian. I'll do some testing tonight when I have USB sticks to hand. There are probably quite a few useful utilities like this in Ubuntu universe that should get uploaded. Wookey -- 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/20120516114114.gj11...@stoneboat.aleph1.co.uk
Re: Wheezy release: CDs are not big enough any more...
+++ Mehdi Dogguy [2012-05-16 16:24 +0200]: > On 16/05/12 13:41, Wookey wrote: > >is there any reason not to just upload this to Debian? > > There are ITPs filed for it: > - http://bugs.debian.org/582884 > - http://bugs.debian.org/576359 Yes. I discovered that when I went to file an ITP :-) It turns out that there is a problem preventing upload. The rather generic name 'usb-creator' was objected-to and a request made to change it to 'startup-disk-creator' (The name the app shows). Upload seems to be stalled on changing the name of the launchpad project to give matching source and binary names. This seems well-meaning but has the unfortunate effect that nothign has happened for a year, despite several people expressing an interst in uploading. I also tested it with a debian installer image and found that it is bust due to a load of ugly code dealing with the syslinux transition from 2.3x to 2.4x around Ubuntu 10.04->10.10 (generating old images whilst running on a new machine, and vice versa, different package and different syntax). It blows up on debian due to 'GNU/Linux' not being a valid version. As we don't even have syslinux-legacy in Debian all this mess should probably just be thrown away. https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1000527 My python-foo wasn't up to actually fixing it myself. Nor do I know how important it is to keep this sort of old-release compatibility (how old?). Anyone with the enthusiasm to fix the upstream-renaming thing, or this code (not hard, just fiddly) could get this into Debian promptly I think. Wookey -- 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/20120518121724.gu11...@stoneboat.aleph1.co.uk
Re: Bug#481129: Bug#671503: general: APT repository format is not documented
+++ Julian Andres Klode [2012-05-18 13:38 +0200]: > We currently have three independent implementations of the repository > format in the archive: APT, cupt, smartpm. I think reprepro is another? /usr/share/doc/reprepro/manual.html contains a 'repository basics' section which includes useful layout/format information. Wookey -- 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/20120518174500.gf11...@stoneboat.aleph1.co.uk
Re: amd64 as default architecture
+++ Ben Hutchings [2012-05-21 00:30 +0100]: > > (Should we consider gathering selected hardware specs in popcon?) Yes please. This would really help arm people too. We currently have to guess how many people we are cutting off when minimum support is moved forward. Wookey -- 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/20120521002501.gk11...@stoneboat.aleph1.co.uk
Re: Moving /tmp to tmpfs is fine
I hesitate to prolong this thread further, but I do have a couple of data points. (and couldn't let Neil's nonsense go). +++ Neil Williams [2012-05-25 16:15 +0100]: > > So instead of fixing the defaults you suggest everybody to drop the > > programs they use (mc, firefox, mysql)? ;) > > On machines which don't have the resources for those programs, yes. > There are alternatives out there - change to a less hungry program or > expand the hardware. The idea that there are machines without the resources for mc is silly. It's a very low-resource console-based program. 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, but the 'set TMPDIR' sugestion is useless IMHO. When I start mc I have no idea what things will be unpacked under the VFS over the next days/weeks. I don't want _everything_ to go in /var/tmp and not get cleaned up automatically (is there cron job that does this for old files?) Perhaps mc should get clever and change TMPDIR itself on the fly for large files, but I don't know how practical that is. I only have 2G in this machine and astonishing slowdown due to thrashing is quite common after a few days work (generally firefoxes fault). I do begrudge /tmp (and thus tmpfs) having more than a few MB of ram. hmm. I just checked some stats: after looking inside a 45MB .deb files in mc: tmpfs382M 212K 382M 1% /tmp so it's not unpacking it there any more even though MC_TMPDIR=/tmp/mc-wookey perhaps this issue is fixed at least for this app? here's a case where a lot of space gets used in there: open a .ppt (powerpoint) file in libreoffice. The conversion involves writing a file in /tmp/ for every page/image. To open an image-heavy 256Mb .ppt I have lying about here, generates 382MB of files in /tmp. I tried to do this live when someone was having trouble with a presentation - it took over 20mins to open this file due to thrashing and I was unable to save the presenation from being something of a disaster. /tmp being a tmpfs presumably contributed to that failure (It just opened fine in about 2mins on the same machine with less memory pressure). And of course I didn't set 'TMPDIR' beforehand a) because all I did was double-click on the file in the filer, which ran libreoffice impress and b) because I had no idea that it would general hundreds of megs of files in /tmp. (I found out afterwards). So I'm with serge that this can be a real-world problem. I'm not claiming that the only solution is a real-disk /tmp, because I agree with those who do see advantages in /tmp as tmpfs so long as /tmp stays fairly small. > No problem with tmpfs being in RAM, it's all about being rational in > the selection of packages. 'firefox' is a perfectly rational choice of package on this laptop of 2G ram. mc is a rational choice on any machine. You can't solve the issue of 'unpacking huge tarballs/debs/whatevers' in /tmp' by telling people to use different packages. Something else is needed. It is possible that that something else already exists, but I must admit to now being a little confused about what actually happens as this thread contains conflicting info. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120526175935.ge11...@stoneboat.aleph1.co.uk
Re: Moving /tmp to tmpfs is fine
+++ Thorsten Glaser [2012-05-27 17:52 +]: > Wookey dixit: > > > >here's a case where a lot of space gets used in there: open a .ppt > >(powerpoint) file in libreoffice. The conversion involves writing a > >file in /tmp/ for every page/image. To open an image-heavy > >256Mb .ppt I have lying about here, generates 382MB of files in /tmp. > > Ouch. (But nobody said Staroffice/Openoffice/Libreoffice/whatsitsname > was light.) This sounds like another of these cases where the software > would benefit from changes _independent_ of the tmpfs setting. > >So I'm with serge that this can be a real-world problem. I'm > > I don’t disagree but still stand by that these are corner cases. How can 'opening a big .ppt I was just sent', be a corner case? That's the sort of thing 'normal people' do on a daily basis. And if we have any pretence of Debian being useful outside the people on this list we really should have defaults which mean it 'just works' (if your disk isn't full already). Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528061122.gk11...@stoneboat.aleph1.co.uk
Re: Moving /tmp to tmpfs is fine
+++ Henrique de Moraes Holschuh [2012-05-27 11:04 -0300]: > On Sat, 26 May 2012, Salvo Tomaselli wrote: > > > Or, it should get clever and not unpack everything. There are plenty of > > > software that are able to read into archives without extracting from > > > them. > > You can't do it for a .tar.gz or a .tar.bz and they are the most common > > kind > > of archive. > > Yes, you can. But it is slow (requires one full pass to get the file > catalog, and another to decompress file data), so you would do it only when > you expect it to be better than the alternative. > > Still, if mc will obey $TMPDIR, it is not at fault. Does it? Yes, it does. (I just checked). It even behaves well if the dir specified does not exist (complains, but starts anyway, gives errors if you try to open archives with no tmpdir, starts using it as soon as it appears). Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528061543.gl11...@stoneboat.aleph1.co.uk
Re: Migration path for 'Multi-Arch:allowed' packages
+++ Ben Hutchings [2012-06-13 12:24 +0100]: > On Tue, 2012-06-12 at 17:45 +0200, David Kalnischkies wrote: > > On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert > > wrote: > > > In particular, I filed a bug against dpkg requesting that it produce > > > more informative error messages in these cases [0], but I wonder if a > > > part of the solution shouldn't be more automated or at least presented > > > at a higher level through apt/aptitude, etc? > > > > Chicken or the egg? > > > > You need to upgrade to support MultiArch, > > but you need MultiArch to upgrade… > > (beside, how would the detection for such a message look like?) > [...] > > Maybe all maintainers who want to use Multi-Arch now in wheezy > > (and therefore drop amd64 packages) should get together and write > > a "what to do after the distribution upgrade" for the release notes, > > a (low priority) debconf message and if you want to be really fancy > > a "transitional" package which shows the same text in case the > > "dropped" binaries are executed. > [...] > > I'd be interested in this for linux-image-amd64:i386. Currently I > expect linux-image-3.2.0--amd64:i386 to remain in wheezy but we'll > still need to advise the user to enable amd64 ready for wheezy+1. If we > can document multi-arch well enough in release notes etc. then it might > be possible to drop it now. I added a user-oriented HOWTO to the multiarch doc-collection last month as there seemed to be a shortage of such docs to point to that weren't cryptic specifications, or talking mostly about cross-building. It may be a useful place to point people, or just lift the good bits from it: http://wiki.debian.org/Multiarch/HOWTO Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120613114727.gp13...@stoneboat.aleph1.co.uk
Re: Report from the Bug Squashing Party in Salzburg
+++ Bernd Zeimetz [2012-06-21 15:17 +0200]: > On 06/21/2012 02:55 PM, Russell Coker wrote: > > On Thu, 21 Jun 2012, Bernd Zeimetz wrote: > It is *easy* to use. It works out of the box. Not if you only have one name. Google+ won't let me sign up, despite emphasising the importance of using your real name _and_ having a special 'unusualy names checking service'. I still got told to piss off. I don't get that sort of aggro from IRC servers. But yes if it works for you it's one of many possible communication channels. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120621153059.go13...@stoneboat.aleph1.co.uk
Re: Remote conferencing software (audio/video chat and broadcast)
+++ Tollef Fog Heen [2012-06-21 16:04 +0200]: > ]] Russell Coker > > > What features does Google+ offer that you believe to be lacking in > > free software packaged for Debian? What do you think is the easiest > > way to fix this problem? > > Well-working multi-user video chats. I don't think we have any tool > capable of multi-user video chats at all. Having used hangouts to attend a conference recently and had endless agravation trying, (not so much from the hangouts themselves, but all the flash surrounding them and their results), but recognising that this is a useful service/facility, I am keen to help work on developing and testing a free solution. Is there a debconf-video session that could be used for discussing the wider problem of good remote-conferencing tech, or should we arrange another session? Does anyone else care about this subject (I care but am currently clueless). > As for what the easiest way to fix the problem would be, I'm not sure, > since I'm not an audio/video hacker. There does exist a > proof-of-concept implementation for Telepathy, but it's very far from > finished and production ready. That sounds interesting as something to evaluate. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120621153921.gp13...@stoneboat.aleph1.co.uk
Re: duplicates in the archive
+++ Neil Williams [2012-06-24 18:51 +0100]: > On Sun, 24 Jun 2012 19:31:12 +0200 > Arno Töll wrote: > > Dropping the bug CC. > > > On 24.06.2012 19:15, Neil Williams wrote: > > > This bug is *not* useful to anyone. Please close it and find an > > > RC bug to close instead. > > > > I'm pretty sure this could be expressed in another tone. Especially > > since we welcome everyone (you know) and we have _no_ written rule what > > belongs into Debian and what not, and nobody who decides on that beyond > > legal issues. > > This isn't about welcoming people, this is about keeping pointless > vanity packages out of the archive. Arno's point was that if you were clever you could do both. It's possible to tell someone that packaing this particular thing is a bad idea without being rude and superiour. If one does that they might go away with the impression that Debian is a civilised place where they'd like to help out, rather than a place full of people who are usually right but arrogant with it. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624183857.go13...@stoneboat.aleph1.co.uk
Re: Proprietary software that's hard to avoid.
+++ Thomas Goirand [2012-06-25 05:12 +0800]: > On 06/21/2012 10:09 PM, Tollef Fog Heen wrote: > For the booking of tickets, (public system) car software, etc., we > have no choice. Actually you can run your car on free software (since 2011), although it's definately still at the 'enthusiast' level: http://forum.diyefi.org/viewtopic.php?f=41&t=1699 And you can tune it with free software so long as it's a Subaru: http://www.romraider.com/ As it's pretty-much impossible to buy a car without an ECU in now, next time I get one I'll have to take a look at this stuff. This is one bit of proprietary software I'd be quite keen to swap out. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120625111431.gs13...@stoneboat.aleph1.co.uk
Re: cross-build-essential
+++ Wookey [2012-01-19 14:32 +]: > +++ Neil Williams [2012-01-19 13:02 +]: > > On Thu, 19 Jan 2012 12:10:28 + > > Wookey wrote: > > > > > I've thought for a long time that a package like build-essential for > > > cross-building would be a really good idea. > > > > +1 > > > > It should probably depend on build-essential itself as a starting point. > > I suppose so. You won't get far without that. OK, there has been progress in this area. Thanks to Patrick McDermmot (GSOC student) we have a patch to add support to build-essential for a crossbuild-essential- packages. http://odin1.pehjota.net/~pj/debian-bootstrap/build-essential/ The initial patches there add crossbuild-essential packages to the build-essential source, which is easy to do but leads to some questions. 1) Some of the packages that cross-build-essential depends on (cross-compiler packages) are not yet in the archive, and won't be in wheezy. That means that these packages will not be installable and thus will not migrate from unstable until the cross-compiler packages do arrive. That seems like a very good reason to keep cross-build-essential as a separate source package for now, available from emdebian.org, along with the toolchains. Anyone disagree? 2) Is the build-essential maintainer happy to include this code once the resulting packages _are_ installable? Or in the same way that he (doko) likes to keep the cross-toolchains separate should we keep them separate for the forseeable future? Does that change once everything is built in the archive? Is the maintainer happy with the implementation above? It uses the existing machinery of build-essential to be compatible but is still somewhat intrusive. A bit of background here for those who aren't following all the details: We are working towards having cross-compilers in the archive. The plan is for those toolchains to use multiarch so that the existing libc: linux-libc-dev: libgcc1: etc packages in the archive are used by the cross-toolchains, rather than being rebuilt and renamed as foo-cross packages (where practical). Prototypes of those packages for i386 and amd64 are now available at: http://emdebian.org/~thibg/repo/ You can't install them without having the modified dpkg (also in that repo) which allows depends: (i.e a specific arch) syntax. We are hopeful that that dpkg change will just scrape into wheezy so that these toolchains will be easily usable without having to have a nobbled dpkg to hand. This work, combined with sbuild's already-in-wheezy config to set up multiarch and install crossbuild-essential-, and the forthcoming -pkg-config packages, should make for painless cross-building (modulo suitable multiarch metadata in packages and packages that are actually capble of being cross-built). I'll give a more complete summary of current state at debconf. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120627190426.gg26...@dream.aleph1.co.uk
Re: cross-build-essential
+++ Svante Signell [2012-06-28 11:43 +0200]: > > The situation is even more complicated if compiling for different OSes: > Like as host (build) Linux:i386 and guest (target) kFreeBSD:amd64 or > Hurd:i386. Any plans to support such combinations with > cross-build-essential? Multiarch should support this and dpkg-architecture already does. So if someone wants to maintain toolchains to do this then adding an entry to cross-build-essential is easy. (We didn't put everything possible supported by dpkg in, because that would be 271 packages :-) Does it actually need a conventional cross-toolchain or is it like the amd64/i386 case where a chroot and a personality is all that is needed? I admit that I haven't thought about the issues for this particular case in any detail. Is there actually a demand for being able to do this? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628114748.gw13...@stoneboat.aleph1.co.uk
Re: EFI in Debian
+++ Steve Langasek [2012-07-07 15:58 -0600]: > On Sat, Jul 07, 2012 at 11:09:57PM +0200, Andreas Barth wrote: > > * Steve Langasek (vor...@debian.org) [120707 22:54]: > > > On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote: > > > > If OTOH we have to pay a fee just for our software to work on platforms > > > > that just happen to be using Microsoft’s certificate, this is clearly > > > > abusive. I would object to do so, and I believe we would (at least in > > > > Europe) have a very strong case in court against such practice. > > > > Note that the Windows 8 requirements stipulate that users must in all > > > cases > > > retain the ability to disable Secure Boot on their x86 systems from the > > > firmware. It's really a question of ease of installation, and whether > > > Secure Boot provides any additional security protection that we think it's > > > worth providing to Debian users out of the box. > > > IIRC it's not the same on embedded hardware. > > The distinction is between x86 and ARM, and the Windows 8 cert requirements > for ARM appear to have as their goal to prevent any other OS to be bootable > on that hardware. Which is pretty outrageous IMHO and may well become a serious problem once PC-like ARM hardware becomes widely available (laptops and capable tablets). It is very disappointing that once they agreed to free-up x86 everyone said, 'oh that's alright then', failing to appreciate that ARM hardware will (likely) be just as ubiquitous as x86 quite soon. Hopefully enough people will produce hardware that isn't crippled in this way, but if Windows 8 is a popular platform one may get a greatly restricited choice. Will Android machines make secure boot turn-offable or another key installable, or will thay follow the Microsoft lead and lock everything down too? A competition case is much harder to bring here because Windows has almost zero share on ARM and can use that as an excuse. Of course, as we know in Debian architecture is really irrelevant to the question of 'is this OS dominant and using its dominance in one area to restrict competition in another'? This makes the ARM/x86 distinction in the rules a devious scheme to reduce competition, which seems to be working so far (and in our case prevent us using such computers usefully at all). In an ideal world the fact that can't unlock your device and install another OS will be seen as a consumer disadvantage and reduce the supply of hardware with no ability to install alternate keys, but that seems an unlikely outcome, as most people don't care, or won't until it's too late. I'm not sure what we can actually do about this technically. Approximately nothing, except look for ways to hack the secure boot mechanism on interesting hardware. I can't recall if the rules for arm actually prevent the bootloader allowing the loading of other keys, or just prevent turning off secure boot. I think the latter, but as there is no requirement for this feature it may be rare in practice. By making this easily available in UEFI I suppose that may encourage manufacturers to enable it. > So I don't think you should expect MS to sign any UEFI > ARM bootloader binaries at all. Quite. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120708131523.gy13...@stoneboat.aleph1.co.uk
Re: solving the network-manager-in-gnome problem
+++ Ian Jackson [2012-07-13 23:48 +0100]:
> Adam Borowski writes ("Re: Recommends for metapackages"):
> > On Wed, Jul 11, 2012 at 09:32:19PM -0600, Philipp Kern wrote:
> > > On Wed, Jul 11, 2012 at 07:21:00PM +0100, Noel David Torres Taño wrote:
> > > > Installing N-M breaks unrelated software.
> > >
> > > No. At most it breaks *related* software.
> >
> > Exactly, that's why it's the "gnome-core" package that's RC-buggy, not
> > network-manager. Unless someone thinks a desktop environment's core
> > function is to mess with the network, that is.
>
> I think this discussion became circular and repetitive and useless
> quite some time ago.
>
> It is plain that the gnome-core maintainers are not going to agree to
> make this change. Therefore people who want the change made should
> either (a) shut up and put up with the status quo (b) refer the matter
> to the TC.
I am someone who employs one of the various workarounds to get the gnome
software package set _without_ network-manager (I generally insert an
exit 0 into network manager's init script (which is ugly), and install wicd)
I don't use n-m because it doesn't play nice with usb0 gadget
networking.
I was just about to refer this to the tech ctte myself when I found
that it had already been done.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834
It seems to me that there are a range of possible solutions, and
despite the length of this thread I don't think all have been
mentioned, or certainly not summarised:
1) network-manager could be recommends: instead of depends: in
gnome-core
2) An alternate meta-package could be provided for gnome-desktop
without network-manager.
3) Network manager should have an /etc/default/ ENABLE/DISABLE switch
(as wicd does)
4) gnome-core should be set to depend on network-manager | wicd (or
some network-chooser virtual package)
All of those are possible solutions which will satisfy varying numbers
of people. They are not all mutually exclusive and are listed
approximately in order of utility in terms of solving the issue (IMHO).
I do believe that at least one of the above should be done for wheezy.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120718110436.gg16...@stoneboat.aleph1.co.uk
Re: Have NetworkManager disabled by default when... (was: Recommends for metapackages)
+++ Andrei POPESCU [2012-07-18 20:56 +0300]: > On Mi, 18 iul 12, 15:01:43, Adam Borowski wrote: > > > > A different idea would be to have NM configured by default to do what it can > > do well (wifi) and stay away from all other interfaces, but because it has > > thorough assumptions that it controls all of networking in the system, this > > is not a change that could realistically be done during freeze. > > One of the reasons I'm using network-manager instead of wicd or even > plain ifupdown is the possibility to switch (more or less) seamlessly > between wired and wifi. wicd does this just fine too. Tell it to autoconnect to wired and selected wifi networks and it 'just works' (TM) for me. (wired at work, wireless at home, in the normal case). I find both daemons give a smooth experience for this usage (but wicd has the advantage of useful curses and cli interfaces). To answer another query on what happens if you have both installed: it doesn't work well unless you disable one daemon or the other. If you use the N-M control it can work OK, and wired may well work, but if you use the wicd control N-M downs the wicd UPed wireless interfaces every few seconds, the practical effect of which is no networking. I don't think we should expect this to work, but I do remember it taking me some time at a conference once to work out why on earth my wireless networking wasn't working at all, depsite everything seeming OK. wicd is easy to disable as it has a ENABLE/DISABLE option in /etc/defaults. N-M doesn't so you either have to remove it properly or resort to nobbling the init script. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120718203231.go16...@stoneboat.aleph1.co.uk
Re: AArch64 planning BoF at DebConf
+++ Henrique de Moraes Holschuh [2012-07-20 16:55 -0300]: > On Fri, 20 Jul 2012, Steve McIntyre wrote: > > Naming > > == > > > > Naming issues: ARM are calling the new 64-bit architecture > > AArch64. Other people don't like that and various other names have > > been proposed for use elsewhere. Debian/Ubuntu developers have already > > picked the name "arm64" in dpkg and elsewhere. > > Maybe a patch should be sent to GNU config upstream so that arm64 > becomes known to config.sub and config.guess as an alias for aarch64? That's not necessary, because dpkg (-architecture) does the necessary conversions between 'debian arch name' and 'GNU arch/triplet names'. So autotools already has aarch64-linux-gnu and that works fine with Debian (in the same way that 'amd64' is 'x86_64-linux-gnu' from a GNU tools POV). The one _good_ reason for using the aarch64 name is avoiding accidental matches with arm* in various bits of configery so leaving that alone probably makes sense despite the silly name. Arm64 everywhere would have been neater but unless someone is volunteering for a massive argument and changing upstream gcc and glibc and autofoo and volunteering to fix up the configery that will break in numerous places it's best left well alone. (I was all for changing it for a while, but have been persuaded, not by ARM, I hasten to add :-) that we have more important things to do with our time than bikeshed about upstream's funny naming, which does at least have the major benefit of being a unique string.) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120721011240.go26...@dream.aleph1.co.uk
Re: ARM port(s) BoF at DebConf
+++ Luke Kenneth Casson Leighton [2012-07-20 21:27 +0100]: > On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane wrote: > > As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem. > > It has 2GB RAM, reliable production use and we can buy it NOW. > > > > *) http://lists.debian.org/debian-arm/2012/07/msg7.html > > hideki, those look superb. I saw one at debconf and it is indeed really nice mini-server hardware in a proper box and everything! Not easily rackable, but nicely stackable. The only catch seems to be the price on the spec sheet which is 79000 yen, which I make to be best part of 750 euro. I'm not sure they'll sell any at that price, so hopefully that'll change. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120721012207.gp26...@dream.aleph1.co.uk
Re: RFC: Why are so many debian packages outdated?
+++ Svante Signell [2012-07-26 14:45 +0200]: > On Thu, 2012-07-26 at 10:31 +0100, Lars Wirzenius wrote: > > > > There are a ton of reasons why Debian may have an older version of > > an upstream release. For example, and I hasten to point out that > > the following list is by no means exhaustive, and not all of the > > possibilities are common: > > Very informative reply, thank you very much! One wonders if some posters recognise comedy when they see it :-) Thank you Lars, it was a fine piece of work. Now back to your normal programming of humourless pedants. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120726184810.gc16...@stoneboat.aleph1.co.uk
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
+++ Faidon Liambotis [2012-08-11 03:48 +0300]: > On 08/11/12 01:12, Russ Allbery wrote: > > There are choices that we don't support because the process of supporting > > that choice would involve far more work than benefit, and the final goal > > is excellence, not choice for its own sake. For example, we don't allow > > users to replace the system C library with a different one. That's > > something that we *could* do, but the general consensus of the project is > > that investing our effort in that is not the best way to produce > > excellence. > > I kind of disagree with that. I don't think that the fact that we don't > support multiple C libraries is the result of a "consensus decision". > > I think it's just because noone attempted to properly do that and prove > it's viability and usefulness either to a portion of the userbase or the > project as a whole. Not wishing to get into the general argument, but just to clarify that in fact this (enabling an alternative c-library) has been done in the past, showing that it is technically possible. The SLIND project (http://wiki.network-crawler.de/index.php/SLIND_Siemens_Linux_Distribution) rebuilt a reasonable subset of debian against uclibc. dpkg has had support for uclibc- for some years. It's not actually technically very difficult, although proper support would involve some intrusive changes in some places. It would actually be useful to quite a lot of people if a core subset of Debian was easily buildable for use with uclibc and busybox, but so far this work has always been done in forks and derivatives, and not pushed back in, which makes it very hard to maintain. Deciding whether that was still relevant or worth the effort would no doubt require another long thread :-) Steve and Russ have it right. We strive for technical excellence and the widest functional coverage that can sensibly be achieved in the context of a binary distro and the available resources. The implies plenty of choice, but not choice for its own sake. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120902024201.gz27...@stoneboat.aleph1.co.uk
Re: Gnome classic mode
+++ Jonathan Carter [2012-09-11 12:34 -0400]: > On 11/09/2012 11:32, Josselin Mouette wrote: > > Can we move on now? I don’t even understand how a *one-time warning* > > explaining a user that his desktop will look different from what he > > might obtain on another Debian machine can even be a serious topic of > > discussion for debian-devel. > > I think I can explain it to you. Many people who install Debian for the > first time do now know what Gnome is (or even Gnome Classic), nor do > they realise that they could or choose something else from the session > menu if they don't want to see a message telling them that something is > broken. If the message tells people to select 'gnome classic' in the logon menu to make it go away then that seems reasonable to me. (I've never seen this message as I switched to XFCE before gnome3 came out) I'd be happy if xfce was the default. Which is better depends if one prefers 'dull-but-works-everywhere' over 'shiny-but-not-universaly-liked'. I can see reasonable arguments in favour of either. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120911172230.ge12...@stoneboat.aleph1.co.uk
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
+++ Tzafrir Cohen [2012-09-12 10:32 +]: > On Mon, Sep 10, 2012 at 10:28:16AM +0100, Jon Dowland wrote: > > On Mon, Sep 10, 2012 at 06:45:42AM +0200, martin f krafft wrote: > > > also sprach Luca Capello [2012.09.09.2029 +0200]: > > > > Or, if this is tightened to OSM, 'gnome-osm-maps'. > > > > > > except the 'm' on "osm" is already a "map", so maybe osm-client. > > > > I like dropping 'gnome', and not doubling-up map, but osm may not > > be clear enough to those who aren't intimately involved, how about > > openstreetmap-client? > > How would that compare to the existing OSM clients currently in the > archive? Some of those are: > > emerillon - map viewer for the GNOME desktop > gosmore - Openstreetmap.org viewer / wayfinder / search client > josm - Editor for OpenStreetMap > merkaartor - map editor for OpenStreetMap.org And navit and marble and foxtrotGPS and gpsdrive and viking and gpxviewer and memphis. Check out the big list at http://wiki.openstreetmap.org/wiki/Software/Desktop to see the fairly thorough mining of this seam of names. Is this app in that list? Not that this burgeoning of map apps is a bad thing - no so long ago we had none, and now our cup overfloweth. Hooray for open data. And there is plenty of difference between many of these apps in render mode, navigation, UI, functionality, integration, dependencies. But it is worth examing what the particular benefits/aspects of a new app are. I am slightly perplexed to see in that list that there is a 'Gnome Map Application' that only runs on Windows. Funny old world. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120912110400.gk12...@stoneboat.aleph1.co.uk
Re: assumptions about the build environment.
+++ Wouter Verhelst [2012-09-24 13:14 +0200]: > On Sat, Sep 22, 2012 at 07:06:57PM +0200, Adam Borowski wrote: > > > > That it breaks multiarch builds. > > Multiarch builds are not done on our buildd machines. Yet. They very likely will be soon, for partial architectures and cross-toolchains. And we still want them to work, in cross-compiling configurations, too, at least for core stuff. > [...] > > As for complex "hard to patch" build systems, could you give me an example? apache/apr :-) But the case of uname _is_ easy to deal with - use dpkg-architecture. And on the original point, anything checking /sys for HOST arch stuff is likely to be getting it wrong too - fine for BUILD arch checks. > > I can't quite think of a case where patching references to uname could be > > tricky. > > I can't give you an example of *this* particular issue; but given the > amount of complex build systems I've seen, I don't think it's too > unreasonable to assume they exist. > > I'm not saying we should change policy to mandate that i386 builds in > i386 chroots should be done with linux32 running or something similar. > But I also do happen to think that tuning buildd machines to do a bit > more than what policy requires them to do is usually a good thing. For I > used to keep debhelper installed in my buildd chroots, even though it's > not part of build-essential; but since almost all packages use it in > some form or another, it was being installed and deinstalled enough that > I could gain some time by having it installed by default. The result > was of course that packages who mistakenly failed to add debhelper to > their build-depends would successfully build on my buildd hosts, but I > didn't think that was much of a problem. > > Similarly, if adding linux32 to the environment on amd64 hosts building > inside a chroot means the success rate for packages built will go up, I > don't think we should refrain from doing so -- unless, of course, doing > so would cause more problems than it would solve, which was the point of > my question. Well, this is indeed exactly the point. If we specify what can be assumed by packages, but then actually don't test that, we test something slightly different (by putting extra stuff int he environment by default) then bugs will not be found. It's a simple tradeoff between rigour and build success/hassle. In general I like the rigour in Debian and have spent the last year or so being rigourous in cross-building/multiarch stuff which has found an awful lot of (expected) breakage. (You an gloss over a lot of stuff by installing qemu in chroots when cross-building, for example, and often it's the best thing to do) In general I'm in favour of agreeing what can be relied upon and then only providing that in buildds. But you are quite right that for the purposes of buildds doing native building this improves your success rate by glossing over potentially-dubious checks, with little cost. > After all, the autobuilder network is not meant to do QA; we have > resources for doing full-archive rebuilds for that purpose. Instead, the > autobuilder network is meant to make sure we build as many packages as > possible. If we can avoid some issues in building packages that isn't > really worth spelling out in policy by just doing some minor > configuration tweak on a buildd host, I think we should do so -- and > this certainly qualifies, IMO. I only run cross-buildds, not native ones, so this isn't my call. Just bear in mind that every such choice of providing more than is strictly mandated will be hiding bugs in other circumstances. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120927121449.gp24...@stoneboat.aleph1.co.uk
Re: Depends: libfoo:foreign ???
+++ The Wanderer [2013-05-13 10:22 -0400]: > On 05/13/2013 09:46 AM, Wookey wrote: > > >+++ The Wanderer [2013-05-13 07:55 -0400]: > > >>For the full 64+32 Wine, I don't believe this is possible - or if > >>it is possible, no way of doing it has yet been documented that I > >>know of. The official Wine documentation of how to build that > >>configuration involves compiling the 32-bit side on the same 64-bit > >>host as the 64-bit side - and, importantly, compiling it against > >>the already-built but not-yet-installed 64-bit build tree. > > > >OK. I'd like to understand some more about this, as it's a similar > >issue to other cross-compiler toolchains, and if we can't solve both > >the same way then our design is poor. I was actually confusing mingw and wine when I wrote that. > By '32+64 wine' do you mean > >packages designed to be installed on an amd64 machine that run both > >32bit and 64bit windows apps? Or do you mean versions of wine to run > >on both i386 and amd64 machines? > > The former. I don't know if there's an official term for that, but I > don't know of any other; "the full 64+32 Wine" is just what I've been > using in my own conversations as a shorthand for a longer explanation. OK. And is 32-bit wine (to be installed on amd64) an amd64 binary that understands i386 code or is it actually i386 code? If the latter to what degree are wine32:amd64 and wine32:i386 any different? Do we actually (ideally perhaps) just have 2 things: wine64:amd64 (amd64, amd64, win64) wine32:i386 (amd64, i386, win32) or three things: wine64:amd64 (amd64, amd64, win64) wine32:amd64 (amd64, amd64, win32) wine32:i386 (amd64, i386, win32, if cross-built) (i386, i386, win32, if native-built) where: (Build, Host, Target) means: Build is the arch built on, Host is the arch it runs/is installed on, and target is the code/abi '(not)-emulated' Perhaps this question is too simplistic once libraries are taken into account. > >>Theoretically it might be possible to build the 64-bit side on an > >>amd64 machine, make the resulting tree available to an i386 > >>machine, let the i386 machine compile the 32-bit side against the > >>64-bit tree, make the resulting tree available to the amd64 machine > >>again, and let the amd64 machine do the final 'make install' or > >>equivalent process. > > Just to clarify: at least for a non-package-build arrangement, the amd64 > machine would have to run the 'make install' from *both* trees, > separately and in the correct order, after both builds had completed. > This isn't automated, at least not last I checked; I've had to write > wrapper scripts to automate part of it myself, for my own builds. > > >Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles > >against end up installed in a final installation (as libraries?) or > >are they really just intermediate 'during build' items? > > They do end up getting installed, though whether as libraries or not I > don't recall offhand. > > IIRC, the end result gets wineserver from the 64-bit side, wine from the > 32-bit side, and wine64 from the 64-bit side, along with supporting > files for both; I haven't examined it recently enough to remember what > libraries (aside from the numerous Wine-internal fake-DLL objects) that > may include. > > >If the former then the it should work to build the 64-bit tree, then > >have the 32-bit build depend on a package that contains those parts > >it needs to build aginst. > > I think that could work, although as far as I can see it doesn't help > the normal-build scenario (i.e. not building for a Debian package, just > for a local install), which is the angle I approach this from. Not if you need to rebuild both the 'library' and the tools (i.e the whole thing), no. But if you just want to rebuild the tools then that should work so long as the relevant 'wine32 library bits' -dev package is installed. multiarch layouts won't help for upstream builds unless they adopt support for it (which would be good). I've only been thinking about the packaged version. upstream stuff is a different matter. > Having an intermediate package containing a build tree (as opposed to > the results of installing from that build tree) seems like an > undesirable thing, though. Yes, it only makes sense if this part is essentially a library-dev package type thing which has some logical existence in it's own right, as something to build-dep on. > >Still, there may not be much point doing this, and just building both > >in one go on a 64-
Re: Apport for Debian
+++ Steve Langasek [2013-05-13 11:22 -0500]: > On Mon, May 13, 2013 at 06:21:24PM +0530, Ritesh Raj Sarraf wrote: > > On Monday 13 May 2013 03:55 PM, Arno Töll wrote: > > > note that, unlike Ubuntu we do not provide automated debug packages. > > > Hence many crash reports aren't usable at all when they are generated on > > > Debian systems. > > > This could be a start. It could help users request debug packages from > > package maintainers. > > This is a poor use of package maintainers' time. The problem of debug > symbols packages needs to be solved centrally for the whole archive, not > with continued use of one-off builds. I second this. This is one thing Ubuntu has done rather better than Debian IMHO: mechanised the process of making debug packages so there usually is one without each package having to explicitly declare it and munge the rules file to make it. Adopting some similar scheme (or even the same one) makes a lot of sense to me. Does anyone object to doing this? Are there problems with doing it? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130513165624.gx2...@stoneboat.aleph1.co.uk
Re: jessie release goals
+++ Stephen Kitt [2013-05-13 19:26 +0200]: > Yes, but that's not the problem. Take the premise that the target directory > structure is as described above, so most library development packages ship as > many headers as possible in /usr/include. For now we'll assume all > mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; but to use > mingw-targeted libraries other than mingw-w64-...-dev (libgtk for example), > the mingw toolchain needs to look in /usr/include as well. > > This is all fine as long as libc6-dev is not installed (say perhaps with > sbuild and cross-build-essential). But in a typical work environment, > libc6-dev will be installed, and because we'll always be cross-compiling on > the buildds, packages which need to build stuff for the host to run during > the build (wine-gecko does this) need build-essential too, so libc6-dev > headers end up in /usr/include and are picked up by the mingw toolchain. Thank you for explaining this. I now understand your issue. It is helpful to have an example of why a full-split might have advantages over an 'only arch-dependent' split. Or at least that we need to be careful about what the definition of 'arch-dependent' is, if we want to include windows ABIs, or uclibc ABIs (I think those two cases may well amount to the same problem). Can anyone from BSD camp tell us whether having glibc-dev headers installed in a common dir would break cross-building for them too? Simon has expanded on this helpfully already: 'glibc is somewhat special as part of the ABI' (remembering that multiarch maps to ABIs). It's good to know about this before the design is set in stone, so this conversation is timely. What I'm not sure about is whether the multiarch-cross design is seriously broken or if it's just a matter of packaging libc-dev correctly to allow for non-glibc platforms. Multiarch has thus far largely been thought of in terms of platforms you can also install Debian to as well as build for. But multiarch-cross ought to be a good fit for crossing to other platforms (within reason) too. So we should certainly consider whether we can sensibly accomodate that or not. I'm not quite sure how best to decide that. Some people need to try some stuff and report back, I suspect. Would simply moving all the libc headers to /usr/include/$multiarch fix mingw builds? How many other libraries are similarly affected? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130514163759.ge2...@stoneboat.aleph1.co.uk
Re: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon
+++ Colin Watson [2013-05-22 22:55 +0100]: > > * Append "Debian-" to the username, as in Debian-opensmtpd > > This was used by Debian-exim and not a lot else that I ever heard of. > In my view this scheme rightly failed; plenty of simple system > monitoring tools (top, ps, and the like) truncate long usernames in many > modes or turn them into UIDs, and sticking a seven-character prefix on > the front just seems to be trying to maximise the probability of trouble > like this, even though it is certainly clear. And strictly speaking upper case is not allowed in UIDs, (if only to avoid confusion and getting someone-else's email) although everything seems to cope these days in practice. I do recall seeing a warning about the 'Debian-exim' name from something-or-other once, which was how I discovered the 'rule'. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130523104845.gw11...@stoneboat.aleph1.co.uk
Re: Multi-Arch for plugin packages
+++ Simon McVittie [2013-05-30 16:27 +0100]: > The only plugins that do benefit from being Multi-Arch are those that > are loaded by more than one executable: glibc NSS modules, PAM modules, > ALSA plugins, that sort of thing. Or plugins that are used in build-depends. I don't know if this ever happens. Ideally not, and only the core program libraries would be needed to build against, but all sorts of crazy stuff goes on in people's builds. Does anyone know of examples? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530154604.gy14...@stoneboat.aleph1.co.uk
Re: Switching to mozilla ESR in stable-security
+++ Josh Triplett [2013-05-29 11:50 -0700]: > Moritz Muehlenhoff wrote: > > One problematic aspect are the various xul-ext-* packages currently > > packaged. It's very likely that some of them will break with ESR17 > > and ESR24 in the future. > > > > However, there's not much we can do here. We can select a narrow (!) > > set of important addons (e.g. enigmail for Icedove) that we will > > keep in sync through stable-security, but that doesn't scale for > > the full scale of Mozilla extensions currently packaged. > > > > In the future the majority of packages should thus rather be installed > > through http://addons.mozilla.org instead of Debian packages. > > As a user of sid who also maintains various systems running stable, I > rely on packages like xul-ext-adblock-plus to make it easier to install > specific addons systemwide. I find it much easier to install those via > the Debian packaging system rather than a user-level mechanism that > involves running Firefox as one or more target users (or more likely > doing the equivalent of creating a xul-ext-* package for local use). I > realize that you can't maintain the full library of Firefox addons as > packages, but I'm hoping that some of the most common and popular ones > stick around and stay up to date, notably Adblock Plus, HTTPS > Everywhere, and It's All Text. Absolutely, and I'd like to add lazarus, noscript, ghostery, user-agent switcher, and debian-buttons to that list of 'can't-live-without, worth maintaining as packages' add-ons. (And Tab Mix Plus is exceedingly handy too) Obviously if no-one wants to maintain them then I guess we'll have to get them the way everyone else does, but I certainly find real value in having them packaged, and am pleased every time I can get an add-on that way. Do we have helpers (as for CPAN and similar archives) to make creation and maintenance of such packages simple? I'd assume they were amenable to this approach, but am entirely unfamiliar with the issues involved with keeping them synced with browsers. If it wasn't too hard I'd be happy to maintain xul-ext-lazarus, for example. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530212940.gb14...@stoneboat.aleph1.co.uk
Re: Current and upcoming toolchain changes for jessie
+++ Matthias Klose [2013-05-07 15:25 +0200]: > == GCC 4.8 == > > GCC versions were updated to GCC 4.7.4 and GCC 4.8.0 (both updated to > the current branch). The default compilers were not yet changed in > unstable. It is planned to make GCC 4.8 the default on the x86 > architectures after the 4.8.1 release (expected later this month), and > after 4.8 does migrate to testing. Suggesting that boost transitions > from 1.49 to 1.5x at about the same time. > > The decision when to make GCC 4.8 the default for other architectures > is left to the Debian port maintainers. > > It is planned to only keep GCC 4.8 and the upcoming GCC 4.9, and to > remove 4.4, 4.6 and 4.7 from jessie. In general I think moving to gcc 4.8 is a good thing for the arm ports. New development and support appears there, and if we want to get rid of 4.7 (and 4.4 and 4.6) for jessie then the earlier we start the earlier it'll all be fixed. 4.8 is particularly useful for arm64, which I hope/expect to be in a releasable state by jessie, 4.8 is the first upstream release with official support (although in practice it's pretty good in the linaro branch of 4.7 (which is the branch we are using for that arch)). What I'm a bit vague about is what actual advantages we get beyond general optimisations, and what breaks. Vectorisation support is much improved in 4.8, but that's not used by default builds SFAIK, due to neon being optional. Cross-toolchain builds no doubt need some fixing up for 4.8 (I've only done them for 4.7), but that's work that needs doing anyway. So unless anyone can think of good reasons for sticking with 4.7 a bit longer, I'm inclined to say change the default along with x86, but defer to toolchain experts if they disagree. > == binutils == > > binutils 2.23.2 will be uploaded to unstable after GCC 4.8 as the > default on x86 reaches testing. Later updates will introduce binutils > trunk leading to 2.24, later this year. I've only tested 2.23.1 but had no trouble at all there. I'd expect 2.23.2 to be fine too. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130605155451.gj14...@stoneboat.aleph1.co.uk
Re: DebianBootstrap supported in which Debian suites?
+++ Jonas Smedegaard [2013-06-07 17:24 +0200]: > Quoting Paul Wise (2013-06-07 05:17:46) > > I would suggest the approach taken by the recent GSoC projects related > > to bootstrapping new ports. Multi-stage builds. First stage without > > docs and second stage with docs. Only the second stage gets uploaded > > to Debian. > > > > http://wiki.debian.org/DebianBootstrap > > Above wiki page seems to recommend using syntack in > Build-depends: lines which I believe is not supported as far back as > oldstable (if in any official Debian suite at all), and references > bug#661538 and #661537 still open. Correct. It is not supported in any debian suite yet. We do expect it to be supported in jessie, but probably with a revised syntax. (See http://debian.2.n7.nabble.com/build-profile-syntax-ideas-td2918264.html) We are trying to finalise this now (stalled on me currently for which I apologise to those with an interest). > What to do *today* to express bootstrapping alternatives to circumvent > circular build-dependencies? You might be able to use alternative B-Ds: Build-depend: foo | foo-minimal but this only covers some cases. In general we don't have a mechanism to do this _in the archive_ until build-profiles are supported (or at least ignored by B-D parsing tools) You can bootstrap happily using local builds and local tools that support profile builds. Existing patches here: http://people.debian.org/~wookey/bootstrap/patches/profiles/ Then just upload the final builds, and sources with the profile info only encoded as comments. > My concrete need is simpler than some, as it needs no special flags at > build-time: I want librdf-trine-perl to enable most possible optional > parts of its testsuite, including some parts which themselves > build-depend on librdf-trine-perl. > > What I will do for now is to just add those extra build-dependencies and > add a note to README.source which build-dependencies can be manually > dropped in a custom bootstrap build. I realize how painful it is for > those needing to bootstrap, but sadly neither DebianBootstrap nor > CircularBuildDependencies provide concrete help for package developers > at the moment, it seems. Agreed. And comments in the control file about this are _extremely_ helpful to people doping this work who are clueless about the details of the package in question. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130607155548.gw14...@stoneboat.aleph1.co.uk
Re: Why not to let all DDs to execute "gb"-command
+++ Matthias Klumpp [2013-06-07 23:50 +0200]: > 2013/6/7 Tollef Fog Heen : > > ]] Nicolas Dandrimont > > > >> The "accepted by DSA part" is a bit complicated. We didn't really want to > >> bother one of the busiest teams in Debian when the software wasn't even > >> packaged, and, when it came up, I felt that the reception of the idea of > >> using fedmsg was a bit lukewarm. I think we should be able to work things > >> out > >> when and if we have a working proof of concept. > > > > >From what I remember, we did have some questions about how some unique > > challenges in Debian's infrastructure will be solved, yes. I don't > > think I've seen completely satisfactory answers about it yet either, but > > I'd need to go digging to be entirely sure. > At the Tanglu Debian derivative (which is just in formation right now) > we build packages using Jenkins CI at the moment, due to this issue > and wanna-build having problems to build source-only packages and a > few other issues (difficult to set-up, weird handling of buildlogs and > some other related issues) > Jenkins isn't perfect either, so I am currently aiming to adjust > buildbot for our needs, which might be a solution (and it easier to > handle than a wb infrastructure, and can be integrated with the > existing Python tools). People keep trying to solve this problem (and this is good - it needs solving). Please take a look at pybit, which purports to be a distributed build-system designed to work for exactly this case, using MQ for the message-passing. http://packages.qa.debian.org/p/pybit.html I believe this to be a better fit than general-purpose build systems like jenkins and buildbot (which IME don't really fit the building of hundreds of different packages (as opposed to building a few packages often) very well). I haven't yet had a chance to use pybit for real (although I've been planning to try for a while, and might get a tuit soonish), but the people who built it are clueful, and it _ought_ to be better than rebuildd, simpler and more flexible than wanna-build, and more appropriate than jenkins and buildbot. I'd be very interested to hear from people working in this area whether it is indeed useful. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013061356.gg14...@stoneboat.aleph1.co.uk
Re: jessie release goal: verbose build logs
+++ Matthias Klose [2013-06-14 13:35 +0200]: > Much more often than I do like it, I see bug reports for the toolchain just > pointing to a build log. Then looking at the build log, you often just see > > CC ... > CCLD ... (sometimes even colorized) > > This doesn't really help when trying to diagnose things, and even for > successful > builds it's valuable to have the complete build log, including the parts how > the > upstream build system is called from the Debian packaging. > So I'm proposing for jessie: > > - File and track issues for packages not enabling verbose builds. >https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html > > - Fix debhelper not passing --disable-silent-rules by default. >#680686 >I think cdbs already does this. > > - Fix debhelper to show how the upstream build system is called. >#680687 >As an alternative buildds could run with DEB_BUILD_OPTIONS=verbose > > - Change Debian policy to recommend or require verbose build logs. >#628515 I'll second this. Like Doko, I've spent way too much time recently(ish) staring at build-logs. The short-form build logs are often useless for working out why something isn't working, or comparing successful native builds with failed cross builds, for example. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130614114927.gx14...@stoneboat.aleph1.co.uk
Re: Dreamhost dumps Debian
+++ Ian Jackson [2013-08-20 16:05 +0100]: > The bigger problem for a Debian LTS is this: 1. who is going to do > security support for it ? Ideally it would be the people that want releases supported longer - e.g this dreamhost outfit, and presumably many organisations like them. Security support is a very parallelisable task, so a small amout of work by a lot of interested people ought to be do-able, but for whatever reason this never seems to have prospered as a model. It would be interesting to know why those entities that would like the LTS don't choose to do this. Is it just because we don't make it easy for them or because of free-loader aspects? I have always thought that there was room for a business selling longer-term Debian support. Maybe someone does? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130820195620.gl24...@stoneboat.aleph1.co.uk
Re: Dreamhost dumps Debian
+++ Philip Hands [2013-08-21 10:35 +0100]: > Wookey writes: > > > I have always thought that there was room for a business selling > > longer-term Debian support. > > Quite. > > It seems to me that doing things to keep these people cheerful should > attract a financial reward. If that made the somewhat more enlightened > companies band together to share the LTS workload amongst themselves > somehow (possibly by having a limited distribution model of some sort, > restricted to members of the mutual-support-club) then that would be no > bad thing either. Right. Nothing stops security updates only going to those that paid, (although I'd expect them to be made available to all after some appropriate delay) although of course anyone who paid is free to re-distribute further, which could make the business fragile. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130821102244.gn24...@stoneboat.aleph1.co.uk
Re: debian-cross mailing list created
+++ Matthias Klose [2013-08-21 22:25 +0200]: > today the debian-cr...@lists.debian.org ML was created. Thank you, listmasters. > Please subscribe to this list if you are interested in cross build issues. https://lists.debian.org/debian-cross/ Just to save people working it out. We also formed a debian-cross-compilers packaging team at debconf, which is co-ordinated here: https://alioth.debian.org/projects/crosstoolchain/ so if you want to help out with actual packaging, that's the place. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130821210458.gu24...@stoneboat.aleph1.co.uk
Re: Preventing government subversion in Debian, verification of binary package uploads
+++ Erich Schubert [2013-08-24 14:51 +0200]: > What I'd like to see is that for all packages (at least for all > security relevant packages, including kernel, SSH, GPG, OpenSSL) every > package is compiled multiple times, and checksums to verify that none > of the build systems were compromised. > There will probably be a number of challenges. From different library > header versions, compiler versions to CPU architecture differences, > race conditions and the use of randomization in the build process, a > lot of parameters could cause different binary signatures. But if we > can at least get the essential packages safe this way, it would be a > good thing. > > And last but not least, all of this might already have been done and I > just missed it. > So at some point, I'd like to see Debian binaries verified by diverse > double compilation, using a number of different compilers and > different people in very different countries. There was a very interesting BOF at debconf on a subject closely related to this, which is being able to do binary-identical rebuilds at all. That is a necessary pre-requisite for the above checks, otherwise you'll always find differences that are just due to times, dates, machine names, buildd configs etc. It was not recorded, but there are good notes at: gobby -c gobby.debian.org -n debconf13/bof/reproducible-builds which I think have been turned into this wiki page: https://wiki.debian.org/ReproducibleBuilds Quite a lot of people are interested in this, for various reasons, the one you give being just one example. We did seem short of volunteers to actually push this forward and make it happen, so as ever, if you'd like to see this become a reality, do please get stuck in. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130824131115.gq1...@stoneboat.aleph1.co.uk
Re: Debian running on handhelds (or for terminals)
+++ patrick295767 patrick295767 [2013-08-26 12:34 +0200]: >Hello, >I wonder what's Debian position in regards to installations on Handhelds. >Over the years, I have installed/contributed in installing Debian on >various handheld machines, including�for instance HP Jornadas (Sarge - >archive), Psion Revo, Psion 5mx, ... armel, and finally the best of best >the Pandora. (The default OS of the Pandora is Angstrom). >As shown, Debian can be readily installed on various platforms / machines, >even with a very limited hardware. This is true, although debian installer and kernel supprt for most of these machines has been poor/missing. >My question is as follows: >�- Have we missed something? Publicity?� >- How to fix that? A temptative... One very useful resource is the Wiki.debian.org/DebianOn pages. There are loads of things Debian will install on that do not have a page there, and it would enormously help others. Debian-installer support is another really useful thing. For a long time we were hampered by the fact that parted had no support for flash-only devices, and D-I depended on parted. These days nearly everything has something that looks like a block device and parted has got smarter so this is largely no longer a blocker. Making stuff 'just work' in D-I and kernel support would be a great contribution. >I believe that Debian shall also propose more packages that are suited to >terminals, maybe to show that we can run Debian and have also lightweight >fast X11 applications. More publicity on lightweight applications? More >terminal applications in our repos? >OPIE / GPE (in particular GPE added to our repos) are also a point for >having Debian for Handelds. We've had GPE in debian for may years, but not well-maintained. Taking care of that would be great if you are interested in it. >I believed we might lack of publicity on own easily Debian is installable >on handhelds. >Debian can be installed very light. This is true but the results are often less than ideal due to missing bits of UI. We could really use people doing _actual work_ to make this better. I'd hesitate to recommend it to many users without some more work to take off some of the rough edges (unless things have improved greatly since last time I looked about a year ago). >And more recently, how manage with ARMs?� >[1]http://www.linuxuser.co.uk/news/linus-torvalds-threatens-to-cut-off-arm This is old news and has been essentially sorted by linaro (and others). The new(ish) multi-device support will make our lives as a distro much easier as we don't have to build loads of different kernels to get reasonable device coverage. >Another example on publicity, is our webpage (wiki) is out-dated (well it >is difficult to keep all up to date). >[2]https://wiki.debian.org/DebianOnHandhelds It a wiki - please update it. >I would say that Handhelds (and also older computers) are the future way >to go for Debian. Well, one aspect. Many of us still want to use it on new and non-mobile hardware too, but I agree it is underappreciated in this area, and it's an increasingly important area. This stuff is co-ordinated on the debian-mobile list. Please join there if you haven't already. We could really use more people doing actual work to make things better - much of which isn't actually hard (updating wiki pages, flash-kernel and D-I support for more devices, updating handheld-relevant packages). Lots of people are 'interested' in this are, but I'm not aware of much actual work being done. A bit of action could well generate quite a lot more interest. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130826232933.gw1...@stoneboat.aleph1.co.uk
Re: Upcoming changes in Tcl/Tk packaging
+++ Sergei Golovan [2013-09-25 12:25 +0400]:
> Hi fellow developers,
>
> I would like to introduce a few significant changes into Debian Tcl/Tk
> packages.
Thank you for doing this work, and for this clear summary.
> 1. Multiarchifying Tcl/Tk. This means splitting out the libtcl8.5
> package with libraries moved to /usr/lib/ and with common Tcl
> code in /usr/share/tcltk/tcl8.5.
>
> Any questions, comments. Anything I've missed?
Yes, the other multiarch-related change needed in tcl is making
tclConfig.sh and tkConfig.sh cross-friendly.
This is not strictly tied to the above changes, but because
tclConfig.sh is arch-specific, and revdeps are affected by the other
changes it makes sense to fix this now whilst we are making a mess.
The existing (ubuntu) patches add a compat script at
/usr/lib/tcl8.6/tclConfig.sh which calls
/usr/lib/${DEB_HOST_MULTIARCH}/tcl8.6/tclConfig.sh
which enables backwards compatibility and will usually work, so long
as whatever called it really did want the host-arch version. Fixing
rdeps to actually call the arch wanted during the build is better
because it will always work. Providing -tclConfig.sh links
would be consistent with the way this has been made config-system
friendly and distro-agnostic in other packages.
Migrating tcl to use pkgconfig instead would remove the need for this
to be arch-specific, which is an even better solution, but I don't
know how enthused upstream is about doing that.
So have you included this change too? Doing so does not require
revdeps changes so long as they only need the host arch version. We
could force them to actually choose the one they want by not including
the compatibility layer, but that seems like too big a hammer. There
are 246 packages that build-dep on {tcl|tk}(8.[456])*-dev
Some relevant bugs:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698674
https://bugs.launchpad.net/ubuntu/+source/tcl8.5/+bug/1164937
https://bugs.launchpad.net/ubuntu/+source/tcl8.5/+bug/1122120
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631995
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703421
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130925150444.gb32...@stoneboat.aleph1.co.uk
Re: how do deal with versionless mercurial software ?
+++ Dominik George [2013-10-02 15:49 +0200]: > Jerome BENOIT schrieb: > >Hello, > > > >I am packaging a versionless library software maintained via a > >mercurial repository. > >Is there any custom for this case ? > I tend to use: > > 0~MMDD+hgXX > > It sorts just below anything upstream might invent later (I don't like epoch). This is good advice. I've been bitten by just using MMDD as the version on unversioned code, and then upstream eventually inventing a version number, which of course is much smaller than 20 million, so I had to put in an epoch. Which doesn't really matter but just seems kind of annoying and unnecessary. The 'use an ISO date as version' idea comes from advice in the developer packaging docs somewhere. It would be good if this 0~ trick was mentioned there too so one could decide whether to use it or not at the time of initial packaging. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131002142447.gz32...@stoneboat.aleph1.co.uk
Re: how do deal with versionless mercurial software ?
+++ Dominik George [2013-10-02 16:23 +0200]: > > >0~MMDD > > > >should be fine. > > It isn't, it is not a unique identifier for the one "release" you are > packaging. No, but it can be a sufficient identifier so long as you don't make more than one release a day. Which exact tag/branch/hash/whatever was used for the orig tarball can be recorded elsewhere in the release. It doesn't have to go in the version number - that's a decision for the packager. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131002142741.ga32...@stoneboat.aleph1.co.uk
Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)
+++ Niels Thykier [2013-10-02 09:45 +0200]: > Hi, > > The final results are in: > > Summary table: > Arch || DDs || NMs/DMs || Other || Total > ---++-++-++---++-- > armel || 3 || 0 || 1 ||4 > armhf || 3 || 1 || 2 ||6 > armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve > McIntyre (DD) > armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), > Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McIntyre (DD) I am surprised not to see Riku Voipio and Hector Oron on this list as I know they help manage the buildds and Riku signs uploads. I don't know if they are trying to escape, or just being too slack to send mail :-) > arm64: Wookey (DD), Steve McInture (DD) There are other DDs working on this too (Doko and Riku particularly), but again they are probably trying to avoid getting any more formal responsibilities. :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131002150724.ge32...@stoneboat.aleph1.co.uk
Re: Debian XDG basedir compliance
+++ Lars Wirzenius [2013-10-11 18:48 +0100]: > On Fri, Oct 11, 2013 at 07:17:32PM +0200, Olе Streicher wrote: > > What are the status, the pros and cons here? Is there an attempt to get > > the XDG somehow into the Debian policy? > > There is no active Debian effort to make all our packages to conform > to the XDG directory spec. It is my understanding that the consensus > within Debian is that it is beyond our scope, and is something that's > best done by our upstream projects directly. That way, the results > would be shared by all users of the programs, instead of just the > Debian users of those programs. Having Debian versions of the programs > differ in this from everyone else would create a lot of confusion, and > needlessly cause everyone more support burden than is needed. I made upstream support XDG when I packaged something recently. He was a bit grumpy because it made linux different from other OSes (it was a java GUI app), but it seemed to me that this was the right thing to do. (The default was to store data in CWD so you ended up with a lot of dirs called 'data' on your disk, instead of one called '.terraintool' in $XDGHOME) This was done upstream, not just for Debian, so conforms with what you've said above, although I wasn't aware of any particular consensus. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131011180533.gr32...@stoneboat.aleph1.co.uk
Re: Bootstrappable Debian - a decision is needed, patches exist
+++ Steve Langasek [2013-10-19 20:46 -0700]: > Hi Johannes, > > My understanding is that all build-dependency loops in the archive can be > broken with a single additional stage (stage1), so only one added profile > and one added build-dependency field would be required. No, that's wrong. We need stage2 for at least toolchain bootstrapping. And practical usage has shown that distinguishing between bootstrap, cross and test deps is genuinely useful. Doko has also expressed this opinion, and in is one of the few people that has used this seriously. So I really wouldn't want to go back to the simple 'Build-Depends-Stage1: ' implementation. I agree with Guillem on this. > Yes, it could > bitrot, but it's better than not having any of the data in the source > packages at all. And if someone really finds this inelegant and insists > that we should extend the syntax of the Build-Depends field, let them step > up and make that happen instead of pointing at grandiose plans they're not > making any effort to implement. A Build-Depends-Stage1 field requires no > support from dpkg in the archive to implement. Right, but we have now written the code for the better scheme, so the only issue is actually putting it in dpkg, which applied just the same to Build-Depends-Stage1. That original scheme had an advantage when nothing better had been done or proposed. Now it has none. Guillem has now put this back on his list and promised to put somethig in soon, so I hope we'll see something which is both reasonably flexible and implemented very soon. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131023180136.gl7...@stoneboat.aleph1.co.uk
Re: Proposal: switch default desktop to xfce
+++ Neil Williams [2013-10-24 18:06 +0100]: > On Thu, 24 Oct 2013 16:40:48 +0100 > Steve McIntyre wrote: > > > This goes back to during the wheezy release cycle. There was a little > > discussion around a change in tasksel [1], but rather too late in the > > day for the change to make sense. Now we have rather more time, I > > feel. Let's change the default desktop for installation to xfce. > > I've been using XFCE from unstable for over a year now, I strongly > recommend this environment as the default desktop for Debian. I've been using it for about 9 years on most of my machines (desktop/laptop/netbook/settop-box), and exclusively for the last 7 years. It works well (better now than ~9 years ago :-) and supports a range of configurations (focus-follows-mouse, click-to-focus, top panel/bottom panel/autoraise panel, raise-on-click/raise-on-focus) which is sufficient to keep most desktop users happy. Gnome applets (maybe only old-style ones?) are easy to incude, and it's generally a very boring classic desktop gui with enough flexibility not to annoy people used to a particular desktop and its behaviour. I agree it's a sensible default if we are going to pick one. Re accessibility: There is an 'accessibility' settings box with sticky keys, slow keys, bounce keys, and mouse emulation. I really don't know how that compares to the gnome options, or whether important aspects are missing in places. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131024173752.gx7...@stoneboat.aleph1.co.uk
Re: away_0.9.5+ds-0+nmu2_multi.changes ACCEPTED into unstable
+++ Rene Engelhard [2013-10-25 08:23 +0200]: > Hi, > > WTF? > > On Fri, Oct 25, 2013 at 01:18:18AM +, Debian FTP Masters wrote: > > Changed-By: Andreas Moog [...] > > away (0.9.5+ds-0+nmu2) unstable; urgency=low > > . > >* Non-maintainer upload > > - d/p/01_fix_makefile: $LIBS need to come after $SRC while linking to > >fix building with ld --as-needed (Closes: #634323) > > A NMU for a MINOR bug is NOT something which should be done. > I quietly accepted the dbs one, but this is over the line. Really? This is boring stuff that needs doing. I would be grateful if someone did it for me on one of my packages, assuming they didn't break anything. As Simon pointed out, such uploads should go via DELAYED/10 in case the developer wanst to override (as Rene would in this case, although not for any good reason I can discerne). If xnox forgot that then a tut is in order. > It builds fine. When some distro bogusly introduces changes which make > all kind of packages breask they can fix them up; but this is not a reason > for NMUing it in Debian. Why would you want to actively prevent your package working with --as-needed? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131025103255.gb7...@stoneboat.aleph1.co.uk
