So when introducing a new soname (no just a new package name), then one
should move to time64 even on i386 ?
The problem with doing this is that
1. A reverse dependency may depend on more than one library that uses time_t
in it's API. Said reverse dependency would not be able to be sanely
I am a researcher at the University of Waterloo, conducting a project to study
reproducibility issues in Debian packages.
The first step for me is to link each Reproducibility-related bug at this link:
> The same applies to the GNOME/GTK stack, where Flatpak is the way to go
> for active development. libgtk-3-dev is really only for building Debian
> packages from their point of view, too.
Perhaps, but what matters is not upstream's point of view but Debian
user's point of view.
My perception
Then there was the short netbook boom, but AFAIR some early ones
had 64bit CPUs but 32bit-only firmware.
My memory is that at the height of the boom the dominant processors
were the N270 and N280, which are 32-bit only. By the time 64-bit
netbook processors showed up the boom was on the
The puppet source package, recently recently dropped the puppet-common binary
package. This package has been a transitional dummy package since stretch.
Unfortunately there are still a substantial number of packages depending on it.
They are listed by maintainer at the end of this mail (the
Relevant packages and bugs:
943107 git-buildpackage: Python2 removal in sid/bullseye
This bug is not marked as rc.
Nevertheless I believe that this bug report is in-fact a false positive. From
what I can tell git-buildpackage, even in buster, does not (build-)depend on
python 2 or any
Because of their design, binNMUs are unreproducible, see #894441 [3] for
the details (in short: binNMUs are not what they are ment to be: the source
is changed and thrown away)
To be specific, the source tree is extracted, then an entry is added to
debian/changelog and then the package is
On 12/02/19 13:26, Ian Jackson wrote:
peter green writes ("Re: Recreating history of a package"):
https://github.com/plugwash/autoforwardportergit/blob/master/pooltogit will
take dscs in a pool structure and import them into git repos (one per source
package) using dgit, building t
Alternatively if one wanted to get more sophisticated than just
importing every version from snapshot in version number order, one
might write something to look inside the package at the changelogs to
try to discern the branch structure.
Why are they creating 32-bit virtual machines?
At least with virtualbox 32-bit VMs can run on any host. 64-bit VMs require
VT-x which is all too often disabled in the BIOS.
Nearly 3 months ago there was a mass bug filing on packages with dead alioth
lists as maintainer. Many of these bugs are still open with no maintainer
response
https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Alists.alioth.debian.org;submitter=debian.axhn%40manchmal.in-ulm.de
> In my perception, the biggest reason is a social one. The is resistance
> to the fact that issues with autopkgtests out of one's control can block
> one's package (this is quite different than in Ubuntu).
Can you elaborate on how this is different than in Ubuntu? It sounds
pretty similar to
If you do reintroduce it, please note the extra steps (reopening bugs
in particular)
On that note one thing that doesn't seem to be easy/well documented is how to go about
finding the bugs that affected a package at the time of it's removal. If I go to the bugs
page for the package and select
I have been working on a tool called Autoforwardportergit for automating the
process or merging
downstream changes with new versions from Debian. A downstream in this case
could be anything
from your private modified versions of some packages to a major derivative
distribution.
It was created
On 17/09/17 10:38, Alexander Wirt wrote:
If you currently manage a user-support or discussion list, or run one
of the big teams
Just because a team isn't big or established doesn't mean they don't need a
place to discuss issues relating to their activities, some of which do not
relate to
Firstly: developers trying to be *too* clever are likely to only make
things worse - don't do it! Whatever you do in your code, don't bodge
around the 32-bit time_t problem. *Don't* store time values in weird
formats, and don't assume things about it to "avoid" porting
problems. These are all
Andrey Rahmatullin writes ("Re: source-only uploads"):
> On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> > Just yesterday I completely broke a key package used to build
> > many Java packages, and I couldn't even rebuild it to fix the issue.
>
> Why? Does it B-D on itself?
And,
I would have thought porters would be following the buildd/piuparts/CI
pages for their port (where available) and thus would not need to be
notified about arch-specific FTBFS or testing issues. If porters are
relying on package maintainers or some automation to notify them
instead of being
In the past I don't believe any person can maintain
over than 500 packages by oneself. However when I'm
actually analysing Sources.gz from Debian Mirror,
astonishing things emerges.
There is really DDs who maintain over than 500 packages
in main section.
You mean there are DD's listed on the
The unusual problems with the g++-5 transition are:
Another big one is the descision was taken NOT to
change the sonames when making sub-transitions. I
presume this was done to avoid deviating from upstream
sonmaes but the flip side has been that major
sub-transitions have become "all or
I just hacked together some scripts (the code is in two parts, the
overall control code is in bash script while the changelog processing is
in python) to deal with merging local changes (provided in the form of a
debdiff) with a new version from Debian (provided in the form of a dsc)
I still
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay (biosdevname names look similar).
The stability of these names
Perhaps we need a political decision here?
I think it's mostly a practical one, as I don't see much disagreement
about the objectives here: What is the best way to arrange things to
support 'released, supported, all-equal' ports vs 'best-effort, let
them get out of sync' 2nd-class ports (both
Was that before or after arm64 and ppc64el migrated off ports to the
main archive?
I'm pretty sure ppc64el was never on debian-ports, it went straight from
an IBM run repository to the main archive.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
algobox
This one looks like a (partial) false positive: the outdated 0.8 source
is still around in Sid since the 0.9 version doesn’t build under sparc
(because it can’t…),
Looks like qtwebkit-opensource-src needs a symbols file update for sparc.
--
To UNSUBSCRIBE, email to
Hmmm, this is what I missed. :-( I guess the only chance is to upload
to t-p-u, right?
Afaict you could do a source amd64 arm64 armel armhf i386 mips mipsel
powerpc ppc64el s390x upload to unstable so that binaries for all
release architectures were supplied by you rather than by buildds.
Jonathan McDowell wrote:
I would ask that DDs make some effort to help
those with weak keys get their new, stronger keys signed. Please sign
responsibly[4],
If you have signed someones old key is it considered responsible to
sign their new key based on a transition statement signed by the old
Dimitri John Ledkov wrote:
Hello all,
gmp has been recently re-licensed and all architectures and ports have
the updated gmp in jessie/sid. Well, all but powerpcspe x32 both of
which recently have negative slope on their build status graphs.
Thus GPLv2 and LGPLv3 compatible software packages
I am not sure what's the timeframe for GnuPG 2.1.0[1] release, but would
it be possible to skip the RSA and go directly for ECDSA, before we
start deprecating DSA? Or at least have an option to do so? (Well,
unless GnuPG 2.1 release is too much far in the future.)
IMO we need to phase out
What is the correct way to deal with this kind of problem ? I cannot find in
the policy something
about conflict between system and non-system user.
I don't think there is much that can reall be done to fix the
fundamental problem which is that system users and regular users have to
live
this is dangerous it changes results, sometimes significantly (e.g. for
complex numbers), only use if you don't care about correctness or have
verified its still correct.
IME, audio processing software can get away with it. Csound and its 400+
library of opcodes has been built with this
Johannes Schauer wrote:
Until these two issues are fixed we will not be able to get an algorithmic
answer to the question of what constitutes the minimum required set of
packages.
There is also the complication of what I will call non-key self
building compilers. fpc is an example
These
Right now, we have the problem that an upload of a
previously compiled source package that’s “totally unimportant” will be
sorted before all source packages in state “uncompiled”.
Only if we also get a waiver that allows testing to go out-of-sync for these
arches. Otherwise, no thanks.
I cannot install libdb4.8-dev + libdb4.8, because it conflicts with libdb5.1.
This does not seem to be true, the dev packages conflict but afaict the
libraries themselves (at least the versions from debian squeeze and
wheezy) do not. So as long as you don't need libdb5.1-dev installed you
They are stable as long as the kernel and the hardware do not change too
much; e.g. enabling the other graphics card in a hybrid setup
sometimes adds a PCIe bus, so all names shift around.
Or adding something like a firewire card which happens to be based on a
PCIe to PCI bridge chip would
I do occasionally check for identical files on different systems by
comparing their md5sums. So, just out of interest, could someone tell me
(how to find out) how many non-identical files with identical md5sums
there are there on a typical (say, amd64) Debian system?
Assuming the output of md5
But either way, the problem is that .dsc and .deb version numbers are
not used only by dpkg. Lots of tools use them, inside and outside of
Debian packages, inside and outside of Debian infrastructure. We
cannot be sure that they all use dpkg's own interfaces to do so (e.g.
dpkg
Since yesterday, my tools can now finally turn the whole dependency
graph
Does this whole dependency graph include the implicit build-dependency
every package has on build-essential?
The above case for example has no
alternative solution as the cycle is of length two and has no other way
of
My previous experiments with multiarch cross-building had run into lots
of build-dependency and tool problems and as a result I hadn't got
arround to actually building anything beyond trivial test programs.
Unfortunately I have now discovered that when I try to link against
some libraries I
I've been attempting to use multi-arch for cross-building packages for
raspbian (a debian derivative I am working on for armv6 hardfloat) and
run into a few things which I thought i'd share and/or ask about.
Build-depends installation:
apt-get build-dep is fine if you are building an
I'm trying to get nacl built on more architectures in debian, in
particular I want to see it build on arm*.
In order to build successfully nacl needs to determine the CPU frequency
(the CPU frequency determined at build time is not used in the final
binaries afaict but if it's not determined
Russell Coker wrote:
On Sun, 23 Sep 2012, peter green plugw...@p10link.net wrote:
In order to build successfully nacl needs to determine the CPU frequency
(the CPU frequency determined at build time is not used in the final
binaries afaict but if it's not determined then the build will fail
On 22/09/12 15:28, peter green wrote:
I'm trying to get nacl built on more architectures in debian, in
particular I want to see it build on arm*.
In order to build successfully nacl needs to determine the CPU frequency
I think you need to analyse what it's doing with the CPU frequency
While working on debian one thing I have not managed to find is
documentation on what packages can and can't assume about the build
environment. Does such documentation exist and if not should it be created.
Some specific cases i'm wondering about:
I just discovered that on my beagleboard XM
peter green wrote:
Some time ago I found that a package (I think it was openjdk but I
don't remember for sure) which relied on uname -r
sorry I meam -m not -r
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
Now, you can build packages without using dpkg-buildpackage by calling
rules directly, and in that case the rules file would need to call
dpkg-architecture, but someone would have to convince me that that was
an interface worth supporting for non-native builds
The big reason it's worth
Some packages have runtime dependencies on packages that they do not
have corresponding build-dependencies for. This leads to the building of
uninstallable packages which in turn leads to problems with testing
transition of packages.
Currently there are two workarounds for this situation
1:
Just curious, let's say version 15.xxx of a package is released but then
found to be faulty, and upstream isn't releasing a new version soon.
OK.. faulty is a rather vauge term
Can the developer somehow recall it?
Not really, it's probablly theoretically possible to remove a package from
Many packages seem to provide ENABLE/DISABLE variables in
/etc/default/foo, providing a confusing red herring for this
task --- a second method which does not work nearly as well,
as you pointed out
Though there are some situations where it is nessacery. Consider
vtund for example which has
Ummm ... don't we strongly encourage all package maintainers to read
d-d-a? If not, we should. It is very low traffic and sometimes
important.
Sure: “All developers are expected to be subscribed to this list.” [0],
but Oliver was referring to “users”. On the other hand, his example mail
(To:
(note: this message quotes from multiple mails by different people)
WouterFirst and foremost, I do not believe that setting -Werror in a
Wouterdebian/rules file is the best way to maintain a package; -Werror is a
Wouterdevelopment option which should not be used in a release build (which a
So, what do you suggest for this? Of course, this file _is_ a conffile
(i.e. should never be automatically overwritten, so just moving it
over to /var/lib is not just compiling with a different path set). If
I don't automatically upgrade the file, users will end up with a
confused daemon unable
I am trying to get ridge on the problem with lvm2. Therefore I have to
get some old packages from snapshot.debian.net. Unfortunately it seems
to be broken for some time now.
While the syntax you use doesn't seem to work anymore and /archive appears
empty it seems you can still browse directly
IMHO any bugs filed merely due to the presence of the code without the
means to trigger the error in normal builds should be wishlist.
What is particularlly insiduous about this issue is that it could
easilly be activated by accident if the maintainer or a NMUer builds and
uploads a new
I have tried the amd64-version on a Lenovo R61 as well as on my
Macbook. Maybe I should try the i386 on the Macbook because it did
not boot properly and I could not use the keyboard.
someone already reported this (it's a problem with syslinux), but i have
almost no to no hope that this will
I suspect this mean that 0.25% (1 of 400) of the machines reporting to
popcon.debian.org got a corrupt/inconsitent dpkg database.
Afaict dpkg has no mechanism in place for detecting or recovering from database curruption. The format of the datbase
means that curruption tends to lead to dpkg
It looks like the search you tried is just broken.
The search tool works but it is rather dumb and the instructions are misleading.
_i386 will only find packages with _i386 in the filename. So it will NOT find
arch all packages like module-assistant. There does not seem
to be a way to search
I am wondering if it is a good idea to remove lilo entirely. At the
moment, lilo has been pulled from testing, and the code is in a shape
Can either version of grub handle all the cases that lilo can? for
example can either of them handle the situation where root is on lvm and
there is
none*. And not cleaning up yourself also improves performance for short
running apps.
How so?
The libraries request memory from the kernel in pages (4k on i386, will vary
on other architectures), they then run thier own heap management system within
those pages. Some memory managers will
2) Introduce a default-mta package (currently) depending on exim4. All
packages requiring a MTA should depend on default-mta | mail-transport-agent.
This will have the extra advantage that we (and others like CDDs and derived
distros) easily could swap default MTA.
What concerns me about this
I have had an accident on my Debian-Archiv-Server and unfortunatly the
files Packages.gz, Packages.bz2, Sources.gz, Sources.bz2 and
Release from the directories
Afaict snapshot.debian.net has woody down to r4 and all point release of sarge
and etch.
For older point releases of woody you
We encourage people to not file duplicate bug reports, and check the BTS
first. So I check the BTS, the bug is there, I don't file a new one (I
do send a me too). 6 weeks later, the bug is closed because the
submitter's email is bouncing and he's on vacation anyway.
It sounds like what is really
62 matches
Mail list logo
