7;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
onsistent 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
t; 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
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 OpenG
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.or
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 th
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 PROTEC
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
&g
sitry 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
atform 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
orward.
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
danger
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)
rd 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". Troubl
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 tcl8.5. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611650
Wookey
--
Principal hat
;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 UNSUBSCR
+++ 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 t
c.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 do
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/
urity 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/
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
downloads and info.
Wookey
+++ 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
-
svinit-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%
sys
+++ 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
+++ 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. Havi
md? 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 'preve
+++ 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 wo
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
s 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 jus
x27;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 t
uld 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...
ng, 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
--
Princ
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
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
s 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, Balloonboar
ocations, 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 hat
+++ 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 bugrepo
iew, 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, bu
0 392188
>
>KDE:
>
> total used free sharedbuffers cached
>Mem:506756 499724 7032 6772 10516 109760
>-/+ buffers/cache: 379448 127308
>Swap: 392188 21632
orts 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
--
P
t 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: Li
y-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 deb
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, Balloonb
ry 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..
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
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
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
wi
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.deb
+++ 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 nu
(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
eating 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
wi
osmetic 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.
fault 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
he 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
--
+++ 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 t
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
+++ 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 UNSUB
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 leas
+++ 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-
ou 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, star
tes 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
nce 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: Lin
oduction 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 listm
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
ke 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&q
+++ 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 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: L
27;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 ma
. 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/
--
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/
--
re 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 debia
e 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 de
t 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 humourl
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 choi
re 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, Wookwar
gration, 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, Wookwa
d
> 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, Ball
+++ 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 b
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.
ibc 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 "u
ot 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
--
w 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/
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/
--
T
ts 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
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.or
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 ind
y(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/
ust 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/
--
+++ 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
e 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://w
//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 ge
ort 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, Balloon
.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
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
re
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, AR
|| 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
erraintool'
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,
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-req
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
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
1 - 100 of 407 matches
Mail list logo
