nt in case someone needs a DeLorean.
1. https://deb.debian.org/debian/dists/unstable/main/installer-armel/
2. https://deb.debian.org/debian/dists/bookworm/main/installer-armel/
I've Cc'd the ARM porters list in case someone has an opinion about
that.
Cheers,
--
Cyril Bruleb
n't seem particularly fitting to try and get a d-i release out any
day soon.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bastian Blank (2023-12-24):
> On Sun, Dec 24, 2023 at 08:38:57AM +0100, Cyril Brulebois wrote:
> > - kernel-image-* packages are now shipping /boot/vmlinuz-* (or
> > /boot/vmlinux-* depending on the arch), instead of just /boot/vmlinuz
> > (respectively /boot/vmlinux
ome other files,
I cannot be certain until it's been actually tested.
Feel free to reply to this thread if you spot other fallouts. Of course,
as usual, the best way to report installer bugs is to file them against
the relevant component, X-Debbugs-Cc-ing this list; but leaving an
e
just follow the README to prepare the installer image, and rely
on an extra USB stick to hold the firmware part (and rely on mountmedia).
But again, I have no idea how common it is for the boards we support in
the installer to require loading firmware files during the installation
process…
Cheers,
--
Hi,
Cyril Brulebois (2023-01-24):
> I'm also not sure what our plan for e.g. ARM images (concatenateable
> images) would be; I don't think we'll pull any firmware packages during a
> d-i build, so they wouldn't end up under [2], but maybe it'd be feasible
>
Cyril Brulebois (2023-01-24):
> In the meanwhile, I'll disable both mountmedia calls in the upcoming
> upload:
> - to reduce delays when official installation images are just
>self-sufficient (that's why we had that GR in the first place!);
I thought about this a
se calls are
actually important, so that we can better assess the needs, and the
possible shortcomings in the historical implementation.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
armel
(sid_armel-dchroot)kibi@amdahl:~/open-iscsi-2.1.3$ dh_listpackages
open-iscsi
libopeniscsiusr
libopeniscsiusr-dev
iscsiuio
Please let me know if you have any questions or objections, I'm happy to
help refine this further.
Cheers,
--
Cyril Brulebois (k...@de
armel.
I'm happy to provide (and test) a patch that would only hardcode the
list in debian/control, and make sure the extra steps aren't run from
debian/rules. If you like the idea, you might get a patch in the next
few hours.
Cheers,
--
Cyril Brulebois (k...@debian.org)&l
appearing in the cruft report[1] once that has
happened); that's not too nice but I don't see any obvious better fix
right now.
1. https://ftp-master.debian.org/cruft-report-daily.txt
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
anual build instead (make under build/, with a specific target), as
you'd need to pass some extra variable (see debian/rules).
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signatur
Ben Hutchings (2019-03-07):
> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
> [...]
> > > * Rebuild the debian-installer images, pulling in updates from
> > > stretch-updates, leaving only armhf netboot targets broken.
> >
> > Expanding a bit:
to s-u for one
particular upload…
> * Another point release with the kernel update sooner than planned,
> and rebuild debian-installer images.
This was brought up on #-kernel and it didn't spark joy (lots of teams
need to be around for a point release)…
Cheers,
--
Cyril Brulebois
team/flash-kernel/commit/15f739427d2b1f1aae4b371304c339e05c59b2d4
https://salsa.debian.org/installer-team/libdebian-installer/commit/5f383dab32fee2f331d07c0261e367602cd18d18
https://salsa.debian.org/installer-team/oldsys-preseed/commit/553bc764412c85dbe31af352af1aa2d0a25f81e4
Cheers,
--
Cyril Brulebois
ot be part of Buster,
|disable the image build.
|Cf. https://lists.debian.org/debian-kernel/2018/01/msg00278.html
2. https://tracker.debian.org/news/934034
This shouldn't surprise anyone but I thought I'd send you a heads-up.
Cheers,
--
Cyril Brulebois (k...@debian.or
Hi,
Karsten Merker (2017-06-28):
> the build fails due to a missing i2c-modules udeb for kernel
> 4.11. From a look at the autobuilder logs it seems that a new
> kernel build which includes the udeb has already been triggered,
> but the packages have not yet arrived in the archive. Once the
> n
Karsten Merker (2017-06-07):
> I have done test builds with both 50MB and 100MB raw image size.
> The difference in the resulting compressed binary size is less
> than 60kBytes, so that shouldn't pose a problem even for people
> on very-low-bandwidth internet connections. I suppose the
> additio
Cyril Brulebois (2017-06-07):
> I'm fine with whatever value is determined by consensus among arm
> people.
>
> Currently testing a patch to detect full disk (it's been in our build
> logs for months…).
As mentioned a couple hours ago, patches were pushed for that, an
Karsten Merker (2017-06-06):
> I guess I have found the problem: the images have a fixed size
> (~40MB uncompressed) and the netboot build has grown a few kBytes
> larger than that while the hd-media build still fits (although
> tightly). Increasing the image size should solve the problem.
I've a
Vagrant Cascadian (2017-06-06):
> I'd like to gently push for making it even larger, say 100MB. when
> debugging different kernel versions, it's often helpful to be able to
> append all modules to the initrd.gz, which can result in ~30MB+ initrd
> images, which usually means an extra step to copy
Hi,
Karsten Merker (2017-06-06):
> I guess I have found the problem: the images have a fixed size (~40MB
> uncompressed) and the netboot build has grown a few kBytes larger than
> that while the hd-media build still fits (although tightly).
> Increasing the image size should solve the problem.
W
Hi,
Diego Roversi (2017-06-05):
> Package: debian-installer
> Version: 20170525
>
> The sd-card images of debian-installer for arm-hf don't have a kernel
> image inside, and they can't boot from sd.
>
> To reproduce the problem:
>
> #wget
> http://ftp.uk.debian.org/debian/dists/stretch/main/i
Hi,
Martin Michlmayr (2016-11-10):
> * Cyril Brulebois [2016-11-10 18:27]:
> > Once a fix is implemented for this specific issue, it would be nice to
> > know what to do with the kirkwood/u-boot things for openrd. If they're
> > not going to work (again/at all), the re
Package: debian-installer
Version: 20161031
Severity: serious
Justification: FTBFS(ish)
(X-D-Cc: u-boot Maintainer & Uploaders; please keep them in the loop
when replying; also debian-arm@ for good measure.)
Hi,
Steve noted that the armel build fails on the cdimage side because
kirkwood/u-boot s
Cyril Brulebois (2016-09-30):
> Steve McIntyre (2016-09-13):
> > AFAICS it's also failing on i386, so it's not arch specific:
> >
> > https://d-i.debian.org/daily-images/i386/daily/build_cdrom_gtk.log
> >
> > ...
> > # HACK ALERT: X.Org modu
Steve McIntyre (2016-09-13):
> AFAICS it's also failing on i386, so it's not arch specific:
>
> https://d-i.debian.org/daily-images/i386/daily/build_cdrom_gtk.log
>
> ...
> # HACK ALERT: X.Org modules are excluded from the scan as mklibs
> # is unable to find symbols provided by the /usr/bin/X
Philipp Kern (2016-07-10):
> On 2016-07-04 18:08, Cyril Brulebois wrote:
> >>How would we keep that working given that backports keeps changing?
> >Backports changing isn't an issue AFAICT if we're only publishing a
> >netinst image which has all the kernel bit
Holger Levsen (2016-07-05):
> On Mon, Jul 04, 2016 at 04:01:10PM -0400, Nicholas D Steeves wrote:
> > I still wonder if a fork of the last linux:src=4.4, updated to bring
> > it to linux-4.4.14 would be a lower support burden? I'm still finding
> > that there are a fair number of issues reported
(Please keep me cc'd.)
Philipp Kern (2016-07-04):
> On 2016-07-04 15:12, Cyril Brulebois wrote:
> >Steve McIntyre (2016-07-04):
> >>There's something I've been pondering for a while, along with some
> >>other folks - it might be useful to do a "je
Hi,
Steve McIntyre (2016-07-04):
> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key upd
Hi ports people,
I'm not exactly sure what happened with debian-ports@ (I think there
were some planned changes but I don't remember the outcome), so I'm
explicitly sending this to bsd/hurd lists since I suspect the linux
ports are less likely to be affected by this.
We have a bug report with a p
Jonas Smedegaard (2015-11-11):
> Ohh, that'd be great - also to ease ability for anyone to inspect how
> those images was created.
>
> Until (eventually) packaged, can someone help point to the code to
> create those images?
Well, src:debian-installer…
> @Cyril: Regarding the concrete bug, i'
Jonas Smedegaard (2015-11-10):
> I've hit a bug¹ in a non-package part of Debian, identified that it is
> tied to variations not in package releases but web-facing parts of
> official Debian:
> http://ftp.de.debian.org/debian/dists/stretch/main/installer-armhf/$timestamp/images/netboot/SD-card-i
Hi,
Karsten Merker (2015-06-21):
> On Sun, Jun 21, 2015 at 09:17:12AM -0700, Vagrant Cascadian wrote:
>
> > On 2015-06-21, Karsten Merker wrote:
> > > If we don't pass a console variable to the kernel, d-i starts
> > > on the console device defined by the platform's stdout-path
> > > property, i
Package: debian-installer
Severity: serious
Hi,
The daily build FTBFS this way on arm64:
| # These files are used to build special kernel images for some
| # subarchitectures. Move them out of the way.
| if [ -d ./tmp/device-tree/tree/usr/lib/kernel-image-4.0.0-1-arm64 ]; then mv
./tmp/device-tr
Wookey (2015-04-13):
> OK. I've done this. I don't seem to have commit rights (should I?)
> Sendingen/hardware/supported/arm.xml
> Transmitting file data .svn: E13: Commit failed (details follow):
> svn: E13: Can't open file '/svn/d-i/db/txn-current-lock': Permission
> denied
(I
Samuel Thibault (2015-04-12):
> Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
> > All that contained in attached patch for review.
> > The manual builds fine with it.
>
> Thanks, I have fixed a couple more things and commited it.
>
> Cyril, when should we upload an updated install
Hi,
Karsten Merker (2015-03-15):
> this patchset had been postponed to after d-i RC1 as discussions
> about it were still ongoing at the time for the RC1 release.
> I have in the meantime met Ian and Steve at FOSDEM and we have
> discussed the open topics there. We came to the conclusion that
>
Karsten Merker (2015-03-09):
> On Sun, Mar 08, 2015 at 04:07:35PM +0100, Cyril Brulebois wrote:
> > Ian Campbell (2015-01-07):
> > > On Fri, 2015-01-02 at 16:40 +0100, Cyril Brulebois wrote:
> > > > Karsten Merker (2015-01-02):
> > > > > > (Do yo
Ian Campbell (2015-01-07):
> On Fri, 2015-01-02 at 16:40 +0100, Cyril Brulebois wrote:
> > Karsten Merker (2015-01-02):
> > > > (Do your patches end up adding the correct Built-Using on u-boot?)
> > >
> > > No, they don't, but d-i does not do that for
Hi folks,
Karsten Merker (2015-01-02):
> Ok, I'll change the wording for V4. My intention was to provide a
> generic README that works regardless of which compression options
> one chooses in the makefile, so that switching from .gz to .xz
> would be simple without having to think of updating doc
Karsten Merker (2015-01-02):
> > (Do your patches end up adding the correct Built-Using on u-boot?)
>
> No, they don't, but d-i does not do that for similar components
> on other platforms (syslinux/isolinux/grub) as well. Probably we
> should do that, but then it would have to be done for all
>
Added debian-cd@.
Karsten Merker (2014-12-23):
> On Thu, Dec 18, 2014 at 07:28:45PM +0100, Karsten Merker wrote:
> > On Wed, Dec 03, 2014 at 03:10:37PM -0800, Vagrant Cascadian wrote:
> > > On 2014-12-03, Karsten Merker wrote:
> > > > several armhf systems do not have u-boot (or another firmware)
Vagrant Cascadian (2014-11-22):
> Package: partman-base
> Version: 179
> Severity: important
> Tags: patch
>
> Several armhf platforms have u-boot installed directly to the device
> in an area which gets wiped out by partman. This results in
> debian-installer producing a "successful" install, bu
Karsten Merker (2014-10-01):
> Vagrant is right, the script fragment added in V2 for conditionally
> setting the console parameter is the wrong way round. I am very
> much in a hurry now to catch a train and don't want to risk
> breaking anything by rushing an untested last-minute change into
> t
Cyril Brulebois (2014-10-01):
> Karsten Merker (2014-10-01):
> > On Mon, Sep 22, 2014 at 12:17:23AM +0200, Karsten Merker wrote:
> >
> > > I have started working on implementing hd-media support for the
> > > armhf platform in debian-installer.
> > [sni
Karsten Merker (2014-10-01):
> On Mon, Sep 22, 2014 at 12:17:23AM +0200, Karsten Merker wrote:
>
> > I have started working on implementing hd-media support for the
> > armhf platform in debian-installer.
> [snip]
> > I have run some tests with the resulting tarball contents and a
> > Jesse CD1 i
[ Context: MODULES=dep in d-i on arm* ]
Karsten Merker (2014-09-25):
> > > Can you please clarify? I see this in base-installer:
> > > | if db_get base-installer/initramfs-tools/driver-policy
> > > && \
> > > |[ -z "$RET" ]; then
> > > |
Ian Campbell (2014-08-25):
> On Sun, 2014-08-24 at 21:24 +0100, Ian Campbell wrote:
> > I've timed out for now, but I'll continue prodding as I have the
> > chance...
>
> I caught up with Adam Conrad a debconf and he pointed out that __aeabi_*
> are some weird internal ABI thing which doesn't act
Ian Campbell (2014-08-22):
> The Internet(tm) seems to think that __aeabi_unwind_cpp_pr0 comes from
> libunwind, but the wifi in this hotel is making it a rather slow job
> to figure out what might be depending on that and/or whether there
> is/should be a udeb for it, I'll try and investigate fur
Cyril Brulebois (2014-08-19):
> Package: debian-installer
> Version: 20140802
> Severity: serious
> Justification: FTBFS
>
> Hi,
>
> I've noticed what $Subject says through the daily builds. Looking at
> last successful build and today's (failing) one,
Package: debian-installer
Version: 20140802
Severity: serious
Justification: FTBFS
Hi,
I've noticed what $Subject says through the daily builds. Looking at
last successful build and today's (failing) one, a few things pops up:
| -Unpacking libdebian-installer4-udeb (0.94) ...
| +Unpacking libdebi
Package: dns323-firmware-tools
Version: 0.7.2-1
Severity: important
Tags: d-i
Hi,
the following upload[1] makes d-i FTBFS on armel for the orion5x
flavour, since it seems the product_id is now mandatory. Is that the
expected behaviour?
http://packages.qa.debian.org/d/dns323-firmware-tools/news
Ian Campbell (2014-04-20):
> The kernel is in svn still, which is what I meant there.
Yeah, sorry, I didn't read carefully enough.
> I plan to push:
> armhf: move armmp subarch to the toplevel.
> arm: include dtb files for netboot.
> to d-i master shortly (once this quick test in
Ian Campbell (2014-04-20):
> On Sun, 2014-04-20 at 12:32 +0200, K. Merker wrote:
> > gitorious seems to have problems at the moment (trying to access
> > the web interface gives "bad gateway", running git clone gives
> > timeouts).
>
> It does seem to be down right now :-/.
>
> Which means I can
Hi,
Ian Campbell (2014-04-19):
> Now that armhf only has a single kernel flavour I think we can simplify
> the installer setup a bit.
>
> Firstly by moving the armmp subarch to the top level and secondly by
> dropping the version from the kernel filename. Leading to
> installer-armhf/201
Christian Hofstaedtler (2014-04-07):
> * Cyril Brulebois [140406 15:51]:
> [ shuffling your message a bit ]
> > since this upload[1],
> > 1. http://packages.qa.debian.org/r/ruby-defaults/news/20140330T152352Z.html
>
> dns323-firmware-tools depends on ruby1.9.1 but t
Package: dns323-firmware-tools
Version: 0.5-1
Severity: serious
Tags: d-i
Justification: breaks d-i builds
[ Probably a good idea to keep all those in Cc when replying:
debian-b...@lists.debian.org, z...@debian.org, debian-arm@lists.debian.org ]
Hi,
since this upload[1], we're getting a failur
Hi Michael,
I'm putting both -arm@ and -boot@ in the loop, which should provide
you with some support (full mail quoted below).
Good luck. :)
Mraw,
KiBi.
Michael Walle (2014-04-01):
>
> Hi Cyril,
>
> First of all, sorry, that i contact you directly. I don't know which mailing
> list to cont
Christian Hofstaedtler (2014-01-15):
> Package: dns323-firmware-tools
> Version: 0.3-2
> Severity: important
>
> Dear Maintainer,
>
> your package "dns323-firmware-tools" depends on an obsolete version of
> the ruby interpreter: ruby1.8.
>
> The Debian Ruby team will remove ruby1.8 from Debian
Johannes Schauer (2013-10-26):
> (I was not able to find the debian-ports list on lists.debian.org (so I
> subscribed via email) did I just miss it?)
Dead list: http://lists.debian.org/debian-ports/
AFAICT it's now an alias for all debian-$port lists.
Mraw,
KiBi.
signature.asc
Description: Di
atus is, but the right contact would usually be $arch@buildd,
added.
Mraw,
KiBi.
From 1092c4095f7545b663d2477904e79d61382ddaee Mon Sep 17 00:00:00 2001
From: Cyril Brulebois
Date: Sun, 20 Oct 2013 03:53:50 +0200
Subject: [PATCH] Bump linux kernel version from 3.10-3 to 3.11-1.
---
build/config/amd6
Hi Ian,
[ disclaimer: I don't know anything about arm*… ]
Ian Campbell (2013-09-24):
> Perhaps it would be sensible to split this patch up and add the new
> flavour now, so folks can test it, and remove the other flavours a bit
> later on.
looks OK to me.
> My only concern would be the short t
Hello Aurélien!
Aurelien Jarno (14/04/2013):
> Sorry to answer late, I only have been able to test it now.
> Unfortunately the vexpress image is now broken, due to this change:
>
> | * Replace nic-modules with nic-{usb,wireless}-modules in armhf netboot
> |images (Closes: #705118)
>
> nic-
Control: tag -1 patch moreinfo
Cyril Brulebois (10/04/2013):
> Patches (preferably tested ;)) against src:debian-installer to update
> package lists for armhf/{mx5,vexpress} are more than welcome. Also,
> (I know I'm asking a lot), “fast is good”.
Ben Hutchings kindly sent some p
Source: debian-installer
Version: 20130409
Severity: serious
Justification: FTBFS
Hi folks,
I unfortunately missed or forgot about those changes on the kernel side:
|* [armhf/mx5] udeb: Add missing storage drivers (Closes: #697128)
| - Add ata-modules including libata, pata-modules inclu
Hi folks,
as you may know, nobody else stepped up, so I'm volunteering again to
try and get a new debian-installer release out, codenamed « beta 1 ».
I have looked at the packages mentioned on the udeb testing summary
page[1] and I have “urgented” many of them, so that they reach testing
sooner t
Source: debian-installer
Version: 20100719
Severity: serious
Justification: FTBFS
User: debian-arm@lists.debian.org
Usertags: armel
Hi,
debian-installer failed to build on armel:
| mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 -n
"Debian kernel" -d ./tmp/orion5x_network-c
Colin Tuckley (22/01/2010):
> Your list of buildd machines is seriously out of date if you are
> talking about armel.
You do realize you're answering to a mail dated “08 May 2007”, right?
> --
> Colin Tuckley | +44(0)1223 293413 | PGP/GnuPG Key Id
> Debian Developer | +44(0)7799 1433
s that repository open for fixes and patches? Or it's based on clean
> debian sources?
Some modified packages might be uploaded to "unreleased". "unstable"
contains packages built from unmodified debian sources.
Cheers,
--
Cyril Brulebois
pgpzr4AVOfsd9.pgp
Description: PGP signature
71 matches
Mail list logo
