Re: Updating partman-auto and grub-installer
Hi, John Paul Adrian Glaubitz (2018-07-21): > Both partman-auto and grub-installer contain sparc64-related fixes in > their git repositories. However, the packages themselves have not been > updated for a while since Christian is no longer if my information > is correct. I think there's a missing “active” there. ;) > Is it okay when I go ahead and upload new versions of both these > packages with the latest changes included? That looks fine to me if you make sure to receive bug mail for packages you upload (like you would for packages you NMU). You'll see l10n updates from time to time (that's the case for both packages right now). Please add a changelog entry with credits. You'll find them at: https://d-i.debian.org/translations.txt > PS: I'm not subscribed to debian-boot, please keep me CC'ed. Done. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Fixing the missing serial console after installation issue
Hi, Samuel Thibault (2017-10-01): > Ok, then that's indeed what is special about sparc64, and then AIUI > your patch is welcome :) > > (and ideally should be backported to previous releases of Debian as > needed) Just a quick comment: Having a bug report with all relevant information (what works, what doesn't, how to fix, etc.) instead of threads on debian-boot@ would really help. A more detailed changelog entry would help as well. And if you want something to be backported to older releases (version tracking, etc.), entries in the BTS are more than welcome. KiBi. signature.asc Description: PGP signature
Fwd: Re: Bug#571136: please remove useless devices from devices.tar.gz
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 patch by Marco against debootstrap (see
attachment), which changes how devices are generated; I can't really
tell how much this might affect all of you (especially with debootstrap
being arch:all, and not intended to only be used from a Debian system),
so I thought I'd send a heads-up first. You may want to look at other
mails (esp. from Marco) in the bug log for more background:
https://bugs.debian.org/571136
Please keep the bug report and Marco in copy of your replies.
Mraw,
KiBi.
--- Begin Message ---
On Jan 08, Marco d'Itri wrote:
> If there are some doubts that devices.tar.gz could still be needed in
> the future then I would start with a smaller patch which keeps all the
> old code around.
Here it is.
If somebody will report valid uses for devices.tar.gz then the old code
can be enabled again easily.
--
ciao,
Marco
diff --git a/debian/changelog b/debian/changelog
index 8a938a3..59cf216 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+debootstrap (1.0.75+nmu1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Stop creating useless device nodes. (Closes: #571136)
+
+ -- Marco d'Itri Sat, 09 Jan 2016 04:43:00 +0100
+
debootstrap (1.0.75) unstable; urgency=medium
* Stop cleaning KEEP_DEBOOTSTRAP_DIR twice, as spotted by Chris Lamb
diff --git a/functions b/functions
index 8bef5e6..cd7f1ef 100644
--- a/functions
+++ b/functions
@@ -1060,19 +1060,34 @@ setup_devices () {
hurd*)
setup_devices_hurd ;;
*)
- if [ -e "$DEVICES_TARGZ" ]; then
+ if true; then
+ setup_devices_simple
+ elif [ -e "$DEVICES_TARGZ" ]; then
zcat "$DEVICES_TARGZ" | (cd "$TARGET"; tar -xf -)
else
- if [ -e /dev/.devfsd ] ; then
-in_target mount -t devfs devfs /dev
- else
-error 1 NODEVTGZ "no %s. cannot create devices" "$DEVICES_TARGZ"
- fi
+ error 1 NODEVTGZ "no %s. cannot create devices" "$DEVICES_TARGZ"
fi
;;
esac
}
+setup_devices_simple () {
+ # The list of devices that can be created in a container comes from
+ # src/core/cgroup.c in the systemd source tree.
+ mknod $TARGET/dev/null c 1 3
+ mknod $TARGET/dev/zero c 1 5
+ mknod $TARGET/dev/full c 1 7
+ mknod $TARGET/dev/random c 1 8
+ mknod $TARGET/dev/urandom c 1 9
+ mknod $TARGET/dev/tty c 5 0
+ mkdir $TARGET/dev/pts/ $TARGET/dev/shm/
+ ln -s pts/ptmx $TARGET/dev/ptmx
+ ln -s /proc/self/fd $TARGET/dev/fd
+ ln -s /proc/self/fd/0 $TARGET/dev/stdin
+ ln -s /proc/self/fd/1 $TARGET/dev/stdout
+ ln -s /proc/self/fd/2 $TARGET/dev/stderr
+}
+
setup_devices_hurd () {
# Use the setup-translators of the hurd package, and firmlink
# $TARGET/{dev,servers} to the system ones.
signature.asc
Description: PGP signature
--- End Message ---
signature.asc
Description: Digital signature
Re: Sparc removal
Hi,
Christian PERRIER (2015-07-27):
> Quoting Joerg Jaspert (jo...@debian.org):
> > Hi,
> >
> > following the last[1] announce, I just removed sparc from
> >
> > unstable
> > experimental
> > jessie-updates
>
> .../...
>
> As a consequence, should we keep sparc-only packages -I know about
> silo-installer at least) in trunk or should they be moved to the
> attic?
Moving to attic looks good to me.
> The same stands for the installation guide specific parts as
> well. These things are not things I have followed closely over the
> years, though, so there may be good reasons to still keep Sparc-only
> components in our main tree.
I'm a bit unsure. If sparc ever comes back as sparc64, it might make
sense to reuse some bits. But I'm not sure whether both archs would be
close enough for that to happen, or if they would be different beasts
like arm{el,hf} and arm64 are. I suppose the former might be true since
it might just be about the number of bits in kernel/user-space, rather
than a completely new arch.
I've added debian-sparc@ to cc; hopefully someone knowledgeable might
jump in.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Debian Archive architecture removals
Lucas Nussbaum (2015-05-04): > I'm wondering if we could find a way to accomodate those architectures > in an official way, while still limiting the impact on ftpmasters and > other teams. I'm not entirely clear on the status of debian-ports.org, > and of what the current downsides of using debian-ports are. Maybe it's > just about supporting and advertising debian-ports as Debian's official > way to host second-class architectures. Maybe there's more to it. What > are the current downsides of moving hurd-i386 and sparc to debian-ports? Last I heard about it, it was understaffed and infra was undersized + needed some changes to make it possible to grow. This was some time ago, so I've added admin@ to make sure we get updated intel on this topic. Mraw, KiBi. signature.asc Description: Digital signature
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Source: debian-installer Version: 20131014 Severity: serious Justification: FTBFS Hi people, (-sparc, -cd, genisoimage maintainers x-d-cc'd) debian-installer 20131014 FTBFS'd on the buildd with: | […] | install -m 644 ./tmp/miniiso/boot_screens/notsupported.txt ./tmp/miniiso/cd_tree/boot | install -m 644 boot/sparc/silo.conf ./tmp/miniiso/cd_tree/boot | genisoimage -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B ... ./tmp/miniiso/cd_tree | genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and './tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''. | Unable to sort directory ./tmp/miniiso/cd_tree/boot Full build log: https://buildd.debian.org/status/fetch.php?pkg=debian-installer&arch=sparc&ver=20131014&stamp=1381835153 I can't tell for sure since it's been a while but I think I was unable to reproduce it on a porterbox. Probably some FS-dependent fun? Anyone would have a clue about it? Thanks for your time. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131209224418.24637.51617.reportbug@arya
Re: Bits from the Release Team (Jessie freeze info)
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: Digital signature
Preparation for d-i beta 1
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 than the required 10 days. My hints file[2] list those, which I tried to keep under two categories: l10n-only, and other changes (code/packaging), so that one can easily determine guilty packages if regressions are found. 1. http://d-i.debian.org/testing-summary.html 2. http://release.debian.org/britney/hints/kibi After tonight's britney run (22:00 UTC), the remaining packages should be: - those who are RC-buggy (e.g. libusb); - those with missing builds; mostly because they were uploaded lately, and they are not built everywhere yet (e.g. recent l10n updates); - a special case for that last category: the linux kernel, with its bumped ABI. Questions: A. if we build a debian-installer package against the old linux kernel ABI, and then images with that debian-installer, will the installer be able to install a kernel with the old ABI to begin with, *and* a kernel with the new ABI in a few days when it reaches testing? Or will the images be broken when that happens? (added debian-kernel to Cc accordingly). B. I'm pondering asking the release team to put back into place the “block-udeb” hints, so that one can make sure candidates for testing are only allowed into testing after review. The wheezy freeze is going to start with a freeze exception for what's in unstable at this point, so it looks like retaining some bits of control would be nice. Any drawback? C. debian-live: do you need to be in the loop for debian-installer alpha/beta/rc releases? If the answer to (A) is OK with old/new kernel, I think I'll prepare a debian-installer package in the upcoming hours (or days, depending on the remaining migrations), and perform some tests, then probably ask debian-cd to prepare some prospective images. If there's any volunteer which would be kind enough to start building a wiki page with the changes between alpha 1 and beta 1, that would be super nice. I'm not sure whether we have nice tools for this, I guess we would need to find changes involving the initramfs, but also major changes outside. Pointers welcome. If you have any comment on the process, any pending changes (you would like to have in beta 1) left, I'm all ears, but the clock's ticking. Mraw, KiBi. signature.asc Description: Digital signature
Re: SPARC daily d-i builds
Gaudenz Steinlin (11/01/2011): > As all my attempts to find someone willing to setup d-i daily builds > on a sparc buildd [1] failed. I'm going to give up now and will not > bother you again until some steps up to do the necessary work or > provide me with buildd access. I added the following note to the d-i > daily builds overview page: Due to the lack of porter and buildd > admin interest there are currently no daily builds for the SPARC > architecture. These builds will be reenable as soon as someone finds > the time to do the necessary buildd setup. > > I would also be willing to do the neccessary setup myself if someone > provides me with the necessary access to a sparc buildd. So, again, it's not about lack of interest, it's about lack of time. Also, you could have pinged debian-wb-t...@. I believe aba did most of the d-i autobuilding stuff, so he might have some clue to share. I've added this list to the loop. KiBi. signature.asc Description: Digital signature
Re: Fwd: Re: Fwd: Old kernels used for sparc daily builds
Gaudenz Steinlin (23/12/2010): > Two more weeks and no answer from either Geert or the SPARC buildd > maintainers. Mails can be overlooked by buildd maintainers when they start with “Hi Geert”, indeed. As for the lack of an answer, you can find reasons on -priv...@. KiBi. signature.asc Description: Digital signature
Re: “Sponsor ” needed for X sparc video drivers
Jurij Smakov (20/11/2010): > Ok, everything is uploaded to experimental (except newport, which is > wrong architecture). The patch I had to apply to get sunleo driver > to build in a chroot is attached. Many thanks! (everything pushed, including the sunleo patch, only missing newport at this point) Mraw, KiBi. signature.asc Description: Digital signature
Re: “Sponsor ” needed for X sparc video drivers
Hi Tyler. Tyler (16/10/2010): > I also thought that debian had some sparc machines available for > building and testing packages? (How do you test a video driver remotely?) It's slightly easier to have a fellow DD upload packages than logging into porterboxes, getting all needed packages installed (probably in a specific chroot since it's experimental), and then do remote-signing of packages; that's why I asked here. Mraw, KiBi. signature.asc Description: Digital signature
“Sponsor ” needed for X sparc video drivers
Hi, I don't have sparc hardware, so I can't build this bunch of sparc-only X video drivers, and I'd be grateful if somebody could sponsor those to experimental (as in: build && sign && upload) for me. Packages: http://people.debian.org/~kibi/queue/xserver-xorg-video-suncg14_1.1.1-4.dsc http://people.debian.org/~kibi/queue/xserver-xorg-video-suncg3_1.1.1-4.dsc http://people.debian.org/~kibi/queue/xserver-xorg-video-suncg6_1.1.1-4.dsc http://people.debian.org/~kibi/queue/xserver-xorg-video-sunffb_1.2.1-3.dsc http://people.debian.org/~kibi/queue/xserver-xorg-video-sunleo_1.2.0-4.dsc http://people.debian.org/~kibi/queue/xserver-xorg-video-suntcx_1.1.1-4.dsc Checksums: http://people.debian.org/~kibi/queue/SHA256SUM http://people.debian.org/~kibi/queue/SHA256SUM.sig Thanks already! Mraw, KiBi. signature.asc Description: Digital signature
Re: Build of atlas under sparc
Julien Cristau (09/09/2010): > Sylvestre Ledru: > > I would like to know if you could restart the build of the atlas > > package in unstable. Once the backlog's been reduced, which should happen soon, see: https://buildd.debian.org/stats/sparc.png > You're asking the wrong people. The buildd admin for each arch is > $a...@buildd.d.o. (Keeping debian-sparc@ Cc'd anyway, people may want to know buildds were lagging behind, but are now catching up.) Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#591802: FTBFS on sparc: [po/fr/LC_MESSAGES/csound5.mo] Error -11
Felipe Sateler (06/08/2010): > I also just managed to build it on smetana. Looks like the buildd is > borked. > > What should I do next? I guess I'm going to give it back again and again, until it builds… I'm open to any ideas, of course. Mraw, KiBi. signature.asc Description: Digital signature
