e d-i bugs
- test d-i regularly
- fix d-i bugs/issues
I am a DD.
--
Manuel A. Fernandez Montecelo
signature.asc
Description: PGP signature
couldn't find the admin address in the
main pages), but they're not registered in the graphs (while
powerpcpse, recently removed, still is).
https://buildd.debian.org/stats/graph-ports-week-big.png
--
Manuel A. Fernandez Montecelo
onality from the new librsvg. (And if packages do start having
such dependencies, they'll get held back too.)
That's not really true either, I needed to build a librsvg-in-c to be
able to build emacs, so it's already affecting some ports.
Cheers.
--
Manuel A. Fernandez Montecelo
ly in such
an important decision-taking meeting as this C++ one in San Diego.
Cheers.
--
Manuel A. Fernandez Montecelo
on which very few people relies upon except
for firmware. But people in this thread seem to think otherwise,
so... dunno.
At a minimum, I don't have an easy way to do the initial binary build
of librsvg-c required for the NEW queue.
There are porterboxes for that, but if it helps, I can build it for you.
Cheers.
--
Manuel A. Fernandez Montecelo
Hi,
2018-11-04 17:32 Ben Hutchings:
On Sun, 2018-11-04 at 13:15 +0100, Manuel A. Fernandez Montecelo wrote:
For example RISC-V / riscv64 will probably not have LLVM ready at least
until the LLVM stable released next March.
There are enough languages whose implementation depends on LLVM that
;t.
So the repayment for him to spend time and make Rust work in many
architectures, is to blow away his work in a lot of other arches. Not
nice.
[1] https://lists.debian.org/debian-devel-announce/2018/11/msg0.html
Cheers.
--
Manuel A. Fernandez Montecelo
2018-08-13 04:25 Paul Wise:
On Mon, Aug 13, 2018 at 1:19 AM, Manuel A. Fernandez Montecelo wrote:
2018-07-30 22:36 Adrian Bunk:
And the next burden will be if riscv64 gets added in bullseye.
[*] Unlike other arches, this one is not restricted to a single vendor
so hardware can be
le vendor
so hardware can be annouced at any time from unexpected parties;
still, only a few months are left.
--
Manuel A. Fernandez Montecelo
ions of the ISA, 128-bit is a bit
far-fetched today but riscv32 maybe not so, just that nobody was
interested so far. So the -64 was always considered as part of the name
from the start.
Cheers.
--
Manuel A. Fernandez Montecelo
ssibly send fixes or more
profiles if they're convenient for bootstrapping :)
Thanks, and thanks to Simon too for beating me to it!
--
Manuel A. Fernandez Montecelo
I suppose the
real problem is that a random developer who is trying to bootstrap
Debian on a new architecture won't know about this trick, but in case
it's helpful, I thought I would mention it.
Thanks, it's useful to know :)
(Waving to the RISC-V folks.)
o/
--
Manuel A. Fernandez Montecelo
2017-12-28 2:33 GMT+01:00 Jeremy Bicha :
> On Wed, Dec 27, 2017 at 7:07 PM, Manuel A. Fernandez Montecelo
> wrote:
>> If the idea is *not* to move those to @lists.d.o, I cannot see what we
>> should be using instead.
>>
>> Any recommendation?
>
> Someone on yo
lthough I admit that I haven't been
following very closely every single message.
If the idea is *not* to move those to @lists.d.o, I cannot see what we
should be using instead.
Any recommendation?
Cheers.
--
Manuel A. Fernandez Montecelo
--
Manuel A. Fernandez Montecelo
2016-08-28 21:50 Sean Whitton:
Hello,
On Sun, Aug 28, 2016 at 10:13:44AM +0100, Manuel A. Fernandez Montecelo wrote:
I think that one measure to improve the current situation is that, for
the people doing NMUs, to orphan the package when the number of NMUs
exceeds for example 3 or 5 in a row
o implement (and if undertaken,
takes years to complete, if ever).
Cheers.
--
Manuel A. Fernandez Montecelo
y-maintained-but-de-facto-neglected
packages are not better in that front either.
[2] I think that I see recommended somewhere that I cannot find right
now, but it is not "officially" endorsed or not general practice, as
far as I know.
--
Manuel A. Fernandez Montecelo
n be changed with:
dpkg-reconfigure apt-listchanges
--
Manuel A. Fernandez Montecelo
Hi,
2016-04-25 19:06 Helmut Grohne:
On Mon, Apr 25, 2016 at 01:28:00PM +0100, Manuel A. Fernandez Montecelo wrote:
Perhaps these OPTIONS and PROFILES should be merged, in a way that if
one is enabled, the other also is. (Is this the plan already?)
They serve different needs. Quite a few
e where your
whole set can be used to rebuild and improve itself to a full-fledge
Debian.
Unless I hear objections, I will start using those profiles and ask
lintian maintainers to relax profile checks.
This message is not an objection, just thinking aloud in the case that
the ideas above help in some way (even if only to gauge the mindset).
Cheers.
--
Manuel A. Fernandez Montecelo
dencies("Recommends"):
if not rd.installed_target_versions:
print pkg, rd
There's also:
aptitude (ncurses) -> Views -> Audit recommendations
(with explanations/rdeps in the panel at the bottom)
or its equivalent in the command line (without the explanation):
a
crease in overall quality.
Agreed. I think that the moment we're leaning too much towards the side
of not pruning the cruft for a long time, and some automatic ways to
detect it (as the many measures proposed in the thread) would be a nice
thing to have.
Cheers.
--
Manuel A. Fernandez Montecelo
2015-09-29 17:38 Wookey:
+++ Manuel A. Fernandez Montecelo [2015-09-29 12:27 +0100]:
Maybe it would be a good idea to split the architectures, and have one
port for legacy-but-still-sold-or-useful i386 and move the current i386
to only support newer, common-use i686 hardware.
It seems to me
a port as well, excluding
undesided packages.
Cheers.
--
Manuel A. Fernandez Montecelo
ut I would typically be doing other things at the same
time (like selecting a bunch of packages to upgrade, or choosing manually
between the optional or suggested dependencies that I want to install along with
the package).
Hope that helps.
--
Manuel A. Fernandez Montecelo
--
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/20150401225858.ga26...@reva.itsari.org
2014-11-25 11:14 Dimitri John Ledkov:
On 24 November 2014 at 18:56, Manuel A. Fernandez Montecelo
wrote:
Would it make sense to trigger rebuilds (or binNMUs, or actions to the same
effect) for all packages in a given architecture when there are important
changes in the toolchain, e.g. the
needs and methods to approach them.
Cheers.
--
Manuel A. Fernandez Montecelo
--
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/20141124185606.ga29...@reva.itsari.org
c/people
--
Manuel A. Fernandez Montecelo
--
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/20141016170333.ga2...@reva.itsari.org
2014-08-28 01:55 Wookey:
+++ 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
x27;m curious about what happened with that, does anybody
know?
Cheers.
--
Manuel A. Fernandez Montecelo
--
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/201
e that the team is busy and all, but adding the changes
from a NMUdiff is not too much extra job in my experience (if that's
what you find annoying about it?).
Cheers.
--
Manuel A. Fernandez Montecelo
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "u
2014-05-15 02:10 Wookey:
The debian-port arm64 rebootstrap is progressing nicely, and we just
passed 4200 source packages built, with another few hundred
pending. There are now 2 buildds running.
In the course of that 344 have failed to build, (see
http://buildd.debian-ports.org/status/architect
2014-04-25 23:32 Wookey:
+++ Manuel A. Fernandez Montecelo [2014-04-25 09:42 +0100]:
... a recent/ongoing thread, about using dh-autoreconf or something
similar ...
Nobody in the thread tried to apply the same logic with configure
script compared to minified .js. The case of configure
2014-04-26 11:00 Vincent Bernat:
❦ 26 avril 2014 01:31 CEST, Manuel A. Fernandez Montecelo
:
Compared to that amount of work, stripping a few files from a tarball
using uscan is utterly trivial and I don't see why it is a problem.
It's quite a bit harder to do the right thing an
2014-04-26 02:30 Charles Plessy:
Le Fri, Apr 25, 2014 at 03:48:51PM +0200, Bas Wijnen a écrit :
Ignoring a bug because you set your priorities is understandable and
(in some cases) good. Adding an override is not.
There are also benefits from using an override:
- It shows that the message h
2014-04-26 07:51 Ben Finney:
"Steve M. Robbins" writes:
On April 25, 2014 11:02:29 PM Ben Finney wrote:
> We promise the source for everything any recipient downloads as part
> of Debian. If non-source files are distributed in Debian source
> packages, without a way to confidently guarantee th
2014-04-26 00:08 Vincent Bernat:
❦ 25 avril 2014 17:40 CEST, Neil Williams :
Compared to that amount of work, stripping a few files from a tarball
using uscan is utterly trivial and I don't see why it is a problem.
It's quite a bit harder to do the right thing and persuade upstream to
not incl
2014-04-25 8:49 GMT+01:00 Matthias Urlichs :
> Hi,
>
> Manuel A. Fernandez Montecelo:
>> a) the minified .js is still source code, by definition.
>
> Sorry, but _my_ definition of "source code" is "whatever you customarily
> edit when you want to change somet
2014-04-25 5:20 GMT+01:00 Gunnar Wolf :
> Manuel A. Fernandez Montecelo dijo [Fri, Apr 25, 2014 at 01:27:02AM +0100]:
>> To both things above, I don't think that this is different to my example of
>> 'configure' script without corresponding .ac/.in; and I don&
2014-04-25 01:07 Gunnar Wolf:
And even having a pointer to the upstream project is not enough: We
have to ship full sources, both for (part of) our licenses'
requirements, and to be able to properly support our projects in the
future. If http://some.developer.net/projects/JS-Foo disappears from
2014-04-25 00:02 Jonas Smedegaard:
Quoting Manuel A. Fernandez Montecelo (2014-04-25 00:23:33)
2014-04-24 21:31 Jonas Smedegaard:
>Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47)
>> a) the minified .js is still source code, by definition.
>
>Which def
2014-04-24 21:31 Jonas Smedegaard:
Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47)
a) the minified .js is still source code, by definition.
Which definition?
https://en.wikipedia.org/wiki/Source_code
https://en.wikipedia.org/wiki/Minified
Basically, no matter how much you
Correction:
2014-04-24 20:48 Manuel A. Fernandez Montecelo:
b) The first lines of the unminified file clearly states the software projects,
^^
minified
version, and URLs to get the non-minified versions, so if users want to
Hi,
Moving from debian-devel-games to debian-devel@ for opinions about if this
lintian warning is OK to override or not, or in general about what to do with
lintian warning about minified JS.
2014-04-24 00:33 Bas Wijnen:
lintian is right that the file does not have source, but we don't ship th
2013-06-11 17:13 Barry deFreese:
On 6/11/2013 11:56 AM, Andrey Rahmatullin wrote:
On Tue, Jun 11, 2013 at 07:04:30AM -0400, Stephen M. Webb wrote:
Normally you would keep the old version's changelog. But even if you don't,
there's no need
for an ITP in cases like this, or when part of a packag
Package: wnpp
Severity: wishlist
Owner: Debian SDL packages maintainers
* Package name: libsdl2-net
Version : 2.0.0~rc1
Upstream Author : Sam Lantinga
* URL : http://www.libsdl.org/tmp/SDL_net/
* License : zlib/linpng
Programming Lang: C
Description :
Package: wnpp
Severity: wishlist
Owner: Debian SDL packages maintainers
* Package name: libsdl2-mixer
Version : 2.0.0~rc1
Upstream Author : Sam Lantinga
* URL : http://www.libsdl.org/tmp/SDL_mixer/
* License : zlib/linpng
Programming Lang: C
Description
2012/5/19 Andrei POPESCU :
> On Vi, 18 mai 12, 14:34:40, Manuel A. Fernandez Montecelo wrote:
>>
>> So I wouldn't blindly close those bug reports, and that's why I'm
>> triaging and handling them in my spare time.
>
> Do you know how to retrieve
2012/5/18 Thomas Preud'homme :
> According to [1] salome is not part of any debian release now. Did I miss
> something? IIRW, for package still in stable, if the -done mail contains the
> right version then the bug will still be visible as long as it affects stable.
Oh yes, egroupware only in olds
2012/5/18 Neil Williams :
> There's a big difference between these bugs and the rest - here there
> are clear migration paths to later packages which can be used to triage
> the bug reports in order not to lose reports. A lot of the rest *can*
> be closed without more triage work because the packag
Hi,
2012/5/18 Daniel Leidert :
> Hi,
>
> Our bug tracker contains items for packages, which do (not longer) exist.
> What should happen to them? I see, that it might be a good idea to keep them
> for the case, a package is re-introduced. But this might happen only for a
> few packages. Most of
2012/4/3 Gergely Nagy :
>> Why do these bugs loose that link to their source package? Have they
>> been gone so long the package isn't even in old-stable anymore and the
>> BTS doesn't record the source package anywhere?
>
> Pretty much, yes.
Also happens that the source package generates several
2012/4/1 Gergely Nagy :
>> 2) What to do now with all of these bug reports? Reassign them to the
>> related source package in unstable? Contact QA? Nothing at all?
>
> The best course of action would be to check whether the reported issue
> is still valid, and reassign to the appropriate (source)
Hello,
I don't know if there's a more appropriate place to ask for this, if
so please tell me.
While looking for a bug report that I knew that existed but that I
couln't find, I noticed that the bug was assigned to
libwhatever-SOVERSION_OLD, and that the current package in the archive
contains li
55 matches
Mail list logo
