And now for your kind attention, the devuan-dev meet notes for
Wednesday, July 24th, 2019.
plasma41
------------------------------------------------------------------------
# Devuan meet July 24, 2019 @20:30 UTC
Pad is here:
https://pad.dyne.org/code/#/2/code/edit/g4WFVJYFQFYBdlW13TIjof4P/
Meet here: https://vdc.dyne.org/devuan
* Please post notes prior to the meet.
* Please add your name as 'Present' below when you get to the
meet.
* When adding a comment in someone else's notes, please
pre-pend your name like this: (whoever) whatever . . .
Present: rrq, danyspin97, jaromil, fsr, helios21, CenturionDan,
blinkdog, RickMoen
## Old Business
## Old Actions
- How is the point release coming along?
## New Business
### fsmithred
- (fixed) packages.devuan.org not updating.
- amprolla.txt needs to be trimmed.
- Move devuan-baseconf_0.6.4+devuan3.1 from ceres to beowulf.
- Move refractasnapshot-base and -gui 10.2.9 from ceres to beowulf.
- /bin, /lib, /lib64, /sbin are symlinks in initrd.img. Do we care?
- refractainstaller questions
- should installer make some special files and links in /dev?
(d-i does, refractasnapshot does)
2019-07-18 beowulf install
mini.iso (2019-06-27) in vbox. dos partition table, bios boot.
standard system utils only (didn't see console productivity)
- grub claims the system is configured to boot via EFI.
Suggests "force grub installation to the efi removable media path"
'dpkg -l' in chroot shows grub-pc is installed
- No grub boot menu in uefi boot. Boots to grub prompt.
### jaromil
- the grub2 saga: further investigation done with parazyd shows that the
problem is caused by lsb_release taking the ID= from /etc/os-release
(don't mind the case difference, lsb does tr for first char
uppercase!) this is a problem affecting a lot of other things that
refuse to work on anything not debian.... and so
We propose to NOT change the ID in /etc/os-release (in our forked
base-files)
- (Centurion_Dan) - I think that we should file bug-reports in debian
with patches for every package that looks at /etc/os-release to
ensure they do sane things with it. But for beowulf, we will change
the ID in /etc/os-release back to "Debian"
Resolutions: Consensus to change that do "debian" in order to not fork
too many packages included grub2 now constituting the problem
Centurion_Dan will commit the change to the base-files package
- in our investigation we also stumble again into the devuan-baseconf
package which it may be obsolete as of today. Anyone has an idea of
what it serves?
- (fsr) right now the vesion of devuan-baseconf in ceres will serve to
remove /data/etc/apt/apt.conf.d/05disable-suggests in those systems
that upgraded to beowulf in the past week. Other than that, it
provides two files that aren't needed. 05disable-suggests and
avoid-systemd.
- (Centurion_Dan) - disable-suggests could be moved to base-files
which we fork anyway, and we can drop that package.
Resolution: We get rid of devuan-baseconf, also will be removed
from debootstrap
### Centurion_Dan
- Dak repeat build failures.
Currently grappling with the issue of dak rejecting .dsc uploads for
source packages already seen with a hash mismatch. The issue stems
from .dsc's being gpg clearsigned, and every rebuild of the source
produces a dsc with the same content, but as is to be expected the gpg
sig is always different each time the package is built. The proposed
fix I am working on is a patch dak to ignore the sig for the purpose
of generating the fingerprint dak uses to compare every uploaded file.
There is a built in function in apt-pkg (already used by dak) from
python-apt that I will use to achieve this. (Dak uses file hashes as a
fingerprint to prevent reuploads of the same file name with different
content, failing with a "Hash mismatch error" if the file has changed,
and silently skipping the upload if it already has the file in the
database.) The most complicated part of the fix is having to make dak
re-generate the hashes for all the uploaded files to use the
sig-stripped content for the checksum hashes.
- Orig tar balls.
- A concern has been raised about our packages orig tarballs not
having the same checksum as debian's.
- This is because we build all our packages out of git using the
upstream/%(version)s or upstream-tag to build the source that is
imported from what is in the official package repo in
salsa.debian.org.
- The reason for the differing orig tarball checksums relates to tar
including file metadata (timestamp, timezone, uid & gid) which means
that even unpacking and repacking a tar ball without touching any
file can result in a tarball with a different hash.
- It has been suggested an explanation be given for this behaviour of
our builds and rightly suggest that at least we make this obvious to
users that our orig tarball checksums may not match that of debian.
- Also suggested is that there may be some concerns about the integr
## New Actions
- jaromil will coordinate with parazyd about ascii point release.