Hi,
being the one who usually prepares the releases, i am currently standing
in hands-off position until the time_t change is completed.
The package tracker is still complaining bitterly about the current
intermediate state.
Consider to re-open
Hi,
i'm the upstream and help with preparing the Debian packages.
So i assume that any needed action in this case is up to my sponsor
Dominique Dumont (Cc'd).
But:
Are you aware that the effort to switch to 64 bit time_t is not worth much
in a ISO 9660 producing software, even on amd64, as long
Hi,
i'm the upstream and help with preparing the Debian packages.
So i assume that any needed action in this case is up to my sponsor
Dominique Dumont (Cc'd).
But:
Are you aware that the effort to switch to 64 bit time_t is not worth much
in a ISO 9660 producing software, even on amd64, as long
Hi,
i wrote:
> >Does any of the bystanders know from what package this message text stems ?
Steve McIntyre wrote:
> That's cdrom-checker:
So that would be indirectly put into the code at
https://sources.debian.org/src/cdrom-checker/1.62/main.c/?hl=152#L152
by "Template:
Hi,
trying to get our mails in sync again. We seem to have reached consensus
in our understanding of the problem.
i wrote:
> > might possibly be "WPSettings.dat", which causes questions in the
> > internet.
Ram Reddy wrote:
> I think that this could possibly be explained by flaws in my testing.
Hi,
Ram Reddy wrote:
> Thomas Schmitt wrote:
> > FWIW check the BIOS L[123] cache settings [...]
This was posted by Nicholas Geovanis , not by me.
My suspicion is that the Lenovo Legion EFI BIOS intentionally creates
directories and empty file "/efi/Lenovo/BIOS/SelfHealing.fd&
Hi,
Ram Reddy wrote:
> https://drive.google.com/file/d/1Zd6iufVRsfIu-qzC-tJx4FEvCOESOz4_/view?usp=sharing
I downloaded the tarball and compared the original FAT filesystem with the
various modified filesystem images.
--
In
Hi,
Ram Reddy wrote:
> I tested the installer on one of my laptops, and found that its contents
> didn't change.
Good to know that the software in the ISO still works from read-only DVDs.
> On the Lenovo Legion 7i Gen 5*, Lenovo Thinkpad X1 Carbon Gen 2*, Lenovo
> Thinkpad X1 Carbon Gen 5
Hi,
Ram Reddy wrote:
> [...] usb drive [...] debian-12.2.0-amd64-netinst.iso [...]
> [...] Integrity Test section [...]
> ./boot/grub/efi.img failed the MD5 checksum verification. Your installation
> media or this file may have been corrupted.
> [...]
> It was always byte 2303211, line 21165
Hi,
congrats for solving this long standing problem.
A few years ago this would have been great news for Knoppix, which staid
for quite a while with SYSLINUX for EFI. But somewhere between versions
8.6 (2019) and 9.3 (2022) it switched to GRUB.
Although the most recent commit on
Hi,
when comparing 12.0.0 with 11.5.0 i see three file trees which have grown
substantially:
du of mounted debian-11.5.0-amd64-netinst.iso :
5 /firmware
126611 /install.amd
308479 /pool
du of mounted debian-12.0.0-amd64-netinst.iso :
221108 /firmware
156509 /install.amd
Hi,
Pete Batard wrote:
> Debian does not use an efi.img.
Oh it does with ISOs for i386 and amd64. There is a data file in the ISO
filesystem named
/boot/grub/efi.img
advertised as MBR partition of type 0xEF and as El Torito boot image
for EFI:
$ xorriso -indev
Hi,
James Addison wrote:
> The problem, in both cases, was that I hadn't copied the '.disk' dotfile
> directory from the install media ISO filesystem(s) in each case.
Besides such user pitfalls with the produced ISO and the problem of
symbolic links there are other constraints which an ISO has
Hi,
the use of xorrisofs/genisoimage option -f would convert those links
into shared content data files, too.
Side note:
Differing from my statement in bug #1031696, the current xorriso version
does not complain about dangling symbolic links when -f is given. It
silently includes them as
Hi,
James Addison wrote:
> Thinking aloud: as an alternative, would adding the '-f' flag to MKISOFS
> achieve the desired result for both documentation and firmware files,
> without requiring any other changes?
Let's pack up some symbolic links with -f:
$ sudo mount
Hi,
James Addison wrote:
> Please find below a proposed update to the commit message under discussion:
Only one nitpick:
> multiple filenames ("records"). The ISO9660 generation tools
> genisoimage and xorriso can use this to de-duplicate multiple linked
> files from their input,
Hi,
James Addison wrote:
> I've opened a merge request at
> https://salsa.debian.org/images-team/debian-cd/-/merge_requests/30
> [...]
> The commit message contains an effort to explain what's going on; please
> consider that message as reviewable and open to feedback too.
I'm clumsy with web
Hi,
James Addison wrote:
> My interpretation of the commands and output in your comment is that both
> genisoimage and xorriso can translate hardlinks from a source filesystem
> into deduplicated file references in a written ISO filesystem
With genisoimage we only know empirically. With libisofs
Hi,
James Addison wrote:
> it looks like the selection of CD image
> creation tool is configured per-architecture here:
> https://salsa.debian.org/images-team/debian-cd/-/blob/5aebb6794a3b8b2393663fb643e35eb8e510c9a4/Makefile#L24
I wish i would understand the clause
ifneq (,$(filter i386 amd64
Hi,
James Addison wrote:
> Something that symlinks can do is to allow image creators to save space by
> by de-duplicating files. [...]
This could be achieved by a bunch of hard links instead of the symbolic
links. In /firmware of firmware-bookworm-DI-alpha1-amd64-netinst.iso
i see only symbolic
Hi,
i have pushed the libisofs bug fix upstream
https://dev.lovelyhq.com/libburnia/libisofs/commit/acb4bd143c6374319e4f0fd91c23cd5bd93a3616
(Small but decisive.)
If you or any bystanders prefer a GNU xorriso development tarball, i can
upload one. For now i guess that you are prepared to
Hi,
the miracle of staying or moving is decided by the alphabetic sequence
of imported original and freshly made clone.
This lets the files keep their old data storage address:
-clone /hello/hello.world /hello/hello.z
This causes data storage in the new session:
-clone /hello/hello.world
Hi,
after quite some problems to reproduce your report with a simpler sequence
of xorriso runs, i come to a riddling intermediate result.
It has to do with the name of the file which gets cloned:
test -e /dvdbuffer/g && rm /dvdbuffer/g
test -e /dvdbuffer/h && rm /dvdbuffer/h
printf %s\\n
Hi,
the following commits have been made to Salsa:
--
libisoburn:
commit 69ecfb2e52295798b52532bd8b1a5c693705fafe
Author: Thomas Schmitt
Date: Sat Sep 17 17:42:52 2022 +0200
Added "Multi-Arch: foreign" to t
not let me do changes on Salsa.
But i did notice this omission, committed
commit 469750f1b47f6acd2c69032b38014f5f35feb5dc
Author: Thomas Schmitt
Date: Sat Jul 2 10:41:26 2022 +0200
and reported it in bug #1013313.
So the only explanation is that i did not push it.
Google ... "git log
Hi,
Samuel Thibault wrote:
> I was more thinking about architecture (i386, amd64, arm, etc.)
> difference, not OS difference :)
As long as it is Linux, libburn indeed behaves the same, modulo configuration
options. Similarly with libisofs, where the presence of development headers
or
Hi,
such Debian specifics are more a matter of my sponsor's opinion than
of my own. Cc-ing Dominique Dumont, therefore.
Samuel Thibault wrote:
> Since AIUI the xorriso package provides only a tool whose behavior is
> exactly the same on all architectures,
It depends on libburn which behaves
Hi,
i added to merge_debian_isos the capability to burn the resulting
ISO 9660 filesystem directly to optical media and to write it directly
to storage device files. This removes the need for having substantial
free disk space beyond the capacity to store the original ISO images.
While burning
Hi,
i wrote:
> > So if the Debian packaging software decides on its own that
> > libisofs-1.5.2 is enough at package build time, then compilation
> > [of libisoburn] will fail.
Alexandre Ghiti wrote:
> In an ideal world, the symbols should be backward compatible and then the
> 'symbols'
Hi,
like with bug #1014400 i see problems between the purpose of .symbols
and the expectations of upstream code.
Upstream code of libisoburn knows what it demands as minimum version.
Any contrary decision by a Debian packaging program can only lead to
intentional failure at compile time or at run
Hi,
do i get it right that the format is specified by
https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
?
If so, then the goal of having the file
"In many cases, the dependency generated is too strict as the
application doesn't necessarily use the newly-added symbols which
should not let me do procedures which i practice only
once per year.)
commit 469750f1b47f6acd2c69032b38014f5f35feb5dc
Author: Thomas Schmitt
Date: Sat Jul 2 10:41:26 2022 +0200
Changed new changelog entry from unstable t
Hi,
Zhang Boyang wrote:
> All OK! Thank you again :)
So as far as we two are concerned, it seems we have a candidate for
release.
Currently it only goes into the GNU xorriso tarball, which is not src of
any Debian package. I could put it into the libisoburn tarball. But as
it is specific to
Hi,
Zhang Boyang wrote:
> Theoretically if both file is already sorted, we can use the `-m' option
I like this idea. Just in case Debian grows to a million packages.
But i understand that i would need two separate files for sorting.
grep ' ./pool/' file1
fgrep -v ' ./pool/' file2
sort -k
Hi,
Zhang Boyang wrote:
> These experiments all succeeded. Thank you very much! Good Job! :)
Thank you for testing and challenging.
I wrote:
> > For now i decided to take the 50 seconds with dash.
> if you really want to reduce runtime I would suggest using
> `sort -s -u -k 2
Hi,
i explored two ways to get a correct and complete md5sum.txt after
merging and sorting:
- Generating the whole md5sum.txt from the emerging ISO's file tree is
possible by help of xorriso, although there is no file tree yet where
all regular files of the ISO can be found for checksumming.
Hi,
i wrote:
> > > md5sum.txt
Zhang Boyang wrote:
> I think maybe we should just create the md5sum from scratch?
Well, not from scratch, because the paths would come from the merged
md5sum.txt.
But indeed the merged file needs polishing:
- Some files are listed multiple times because they
Hi,
Dominique Dumont wrote:
> You may want to log this case which leads to a test failure
I understand that George Danchev considered the output of grep enough
of a message:
grep -n -E "${LIST_KWD}" "${CLOG}"
RET_GREP="$?"
ok=0
case ${RET_GREP} in
Hi,
Alexandre Ghiti wrote:
> Please find attached a patch that enables the releng testsuite.
With my upstream hat on:
I can imagine why it is desirable that log file anomalies cause a non-zero
exit value. But simply aborting the script by "exit 1" seems not to match
its concept (which is by
Hi,
Zhang Boyang wrote:
> 2) Create my own version of my-DLBD1.iso and my-DLBD2.iso from my private
> mirror.
This explains why a firmware package was missing which is in the official
DLBD-1 but obviously on your my-DLBD2.
With the new script version which merges /firmware trees:
> This time
Hi,
i tested merging of /firmware directories with barely sufficently
complete
debian-11.0.0-amd64-DLBD-[12].iso.tmp
from aborted jigdo-lite runs.
All files which are reported as being only in CUSTOM(all-in-one) by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011343#115
are listed by
Hi,
Zhang Boyang wrote:
> I will definitely try it
Meanwhile i got some insight into the riddle about diffs between merged.iso
and CUSTOM-1.iso like
Only in /groundtruth/firmware: arm-trusted-firmware-tools_2.4+dfsg-2_amd64.deb
Only in /groundtruth/firmware:
Hi,
i followed David's advise to consider the warnings of shellcheck, to drop
the demand for bash, and to check early whether all needed programs are
available. xorriso gets now checked for being young enough for the job
of replaying the boot related commands as detected with input ISO 1.
(1.3.2
Hi,
i wrote:
> > https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/test/merge_debian_isos
Steve McIntyre wrote:
> That might be a useful thing to include in a package. What do you think?
Best would be if debian-cd would take it, so that it can be adapted when
the repository format
Hi,
although it was not the final solution of this bug report, i beefed up
my merger script for Debian ISOs so that it can combine an arbitrary
number of ISOs (within the limits of /dev/loop* and mount(8)).
Maybe it can serve as answer for the next time this wish comes up.
The script is uploaded
Hi,
Ivan Shmakov wrote:
> An alternative would be to check if it’s possible to seek to
> specified positions rather than to the end of file
This should work now, by an attempt of lseek(wanted_size, SEEK_SET) if
lseek(0, SEEK_END) yields failure or 0 size.
(libisoburn commit 0c0d542, libisofs
Hi,
Ivan Shmakov wrote:
> An alternative would be to check if it’s possible to seek to
> specified positions rather than to the end of file; e. g.:
I see at least the problem that the end position of -cut_out
(byte_offset + byte_count + 1) is allowed to be unrealisticly high in
order to simply
Hi,
for now it looks like the merged ISO works as fat DVD-1.
I installed a Debian 11.2.0 system from the merged DVD-1+ DVD-2 ISO
in a qemu VM via option -cdrom. Installation went smoothly.
During reboot i aborted the VM to next deface the El Torito boot sector
of the ISO. I removed the -net
Hi,
i uploaded the first version of my merger script as
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/test/merge_2_debian_isos
Please download and give x-permission. The need for sudo can be avoided
by already mounting the two ISOs at the chosen mount points before running
Hi,
i wrote:
> > I began to ponder about a shortcut in libisofs which would trust the
> > checksum file (-checksum-list , -md5-list) enough to omit the reading of
> > all the package files' content.
Steve McIntyre wrote:
> Cute idea (grin!), but it's a non-started - we wouldn't be able to
>
Hi,
Steve McIntyre wrote:
> youre initial guess is correct. We don't generate the .iso files
> at all for the larger images [1]. This means we also don't have
> torrent files for them [2].
I began to ponder about a shortcut in libisofs which would trust the
checksum file (-checksum-list ,
Hi,
Zhang Boyang wrote:
> I guess there is no ready tool can merge two ISOs together.
Not directly. But xorriso can load the meta-data of an ISO, manipulate
that loaded model, and write the result as new ISO with the same boot
equipment as found in the loaded ISO.
As said, that would be no
Hi,
i reply to 1011...@bugs.debian.org and zhangboyang...@gmail.com because
of my question and sketch for a procedure to merge DLBD-1 and -2 after
download into the desired ALL-IN-ONE ISO.
Andrew M.A. Cater wrote to debian...@lists.debian.org:
> If the original poster wants one huge .iso as one
Hi,
some technical nitpicking.
Andrew M.A. Cater wrote:
> Also, keeping large files around on disk for a long
> time - there's some likelihood of data corruption.
The .jigdo and .template files of the DLBD ISOs are together smaller than
a netinst CD ISO. (Less than 90 MiB, see
a thorough test, especially with weird -cut_out
arguments.
---
Committed are:
https://dev.lovelyhq.com/libburnia/libisofs.git
commit 011e2e85e6dfe6e5d882d198c29fd15c02d38e5e
Author: Thomas Schmitt
Date: Tue Apr 26 12:12
Hi,
the plan to allow nearly all file types with -cut_out is dwindeling:
- lseek(SEEK_END) on S_IFCHR /dev/zero returns 0, not -1.
- open() on S_IFIFO blocks (and i don't want to know what it will do
in libisofs). IIRC a successful open() has side effects on the fifo.
- S_IFSOCK fails
Hi,
i wrote:
> > The newest easily compilable and then usable version would be
> > http://www.gnu.org/software/xorriso/xorriso-1.5.5.tar.gz
Ivan Shmakov wrote:
> Not under http://ftp.gnu.org/gnu/xorriso/ , though?
1.5.5 is a development snapshot with potentially later changing new
Hi,
Ivan Shmakov wrote:
> I’m filing this bug against versions from oldstable and
> stable, for that’s so far the only Debian packages’ versions
> I’ve tested for this issue.
As it is about an upstream wish:
The newest easily compilable and then usable version would be
Hi,
theoretically it should indeed be ok to remove this option.
Background:
The man page of genisoimage talks of "hard-linked [file] on the CD"
(which obviously should rather be "in the ISO 9660 filesystem").
ISO 9660 (aka ECMA-119) does not specify hard links but rather permits
to share data
Hi,
Felix Zielcke wrote:
> > I just tried to test it with TZ set.
> > But I always get the same binaries. No matter to what I change TZ or
> > /etc/timezone between the builds.
Vagrant Cascadian wrote:
> I can reproduce the issue in a debian sid chroot with pcmemtest 1.5-3
> from debian
I don't
Hi,
Chris Lamb wrote:
> More generally, I can't think of a scenario where the value of
> SOURCE_DATE_EPOCH request a timezone implication,
Alain Knaff mentioned mcopy option -m
"Preserve the file modification time."
which he wants to fulfill the user's expectation that the Y/M/D/h/m/s
Hi,
i wrote to info-mtools about the problem that time zone influences the
result of mcopy even if SOURCE_TIME_EPOCH is set.
Alain Knaff then proposed to set the TZ variable to UTF when pcmemtest
gets built.
https://lists.gnu.org/archive/html/info-mtools/2022-02/msg2.html
Would that be
Hi,
my favorite suspect in mtools is to see in function mk_entry():
https://sources.debian.org/src/mtools/4.0.33-1+really4.0.32-1/directory.c/?hl=98#L107
now = localtime();
(I see no debian/patches directory for mtools. So this is probably
really in effect with Debian's package.)
I
Hi,
Vagrant Cascadian wrote:
> I haven't looked into it too deeply, but got the basically the same
> results as currently showing on:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pcmemtest.html
Looks again like the FAT directory entries. The byte
Hi,
Vagrant Cascadian wrote:
> I noticed 1.5-3 is still affected by timezone differences,
Can you already say whether the differences are in the range of
partition 1 or in the range of partition 2 of the .iso (as told by
fdisk -l) ?
> If I come up with an updated patch, I'll maybe submit a new
Hi,
Chris Lamb wrote:
> Did you try the --invariant flag?
Well, i step aside and let this question reach Felix. :))
https://manpages.debian.org/unstable/dosfstools/mkdosfs.8.en.html
says that this is what we need if my theory about the second difference
is correct:
--invariant
Use
Hi,
First an observation from digging in pcmemtest/1.5-2/build64/Makefile:
What about target grub-memtest.iso ?
It has its own xorriso run and EFI System Partition image.
I guess they need treatment for reproducibility, too.
Felix Zielcke wrote:
> Here's the output for the 64bit ISO:
> [...]
>
Hi,
Felix Zielcke wrote:
> I modifed the patch now to use --set_all_file_dates.
I wonder whether the "file list" in "data.tar.xz" of
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffosc
ope-results/pcmemtest.html
is made from the files in the ISO or from the input files
Hi,
Chris Lamb wrote:
> Have you had a look at the diffoscope output after this
> patch is applied?
Where can a curious bystander get that look ?
I only found a diff from february 8:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pcmemtest.html
where i
Hi,
> I am not such a purist, so I really appreciate the comfort of a desktop like
> KDE or LXDE in this case.
It's not so much about purism in my personal case, but rather about
the unwillingness to repeatedly learn how to do the same things in
frequently (*) changing ways.
(*) Once every ten
Hi,
w_t...@t-online.de wrote:
> When I click the tiny icon beside "DVD-R sequential recording",
> the former grayed menus for speed and writing mode are now available.
> Then I can also
> start the writing process, and it does not go to max speed and completes
> successfully.
So - with the
Hi,
> I tested at first the live CD of Debian 10.
> K3B also disrespects the speed setting. But the process seems to
> adjust the speed automatically. 18x was starting speed and it was
> reduced, so that the resulting speed was 4x.
An initial utopic speed is not necessarily the fault of the burn
Hi,
i am the developer of libburn, which serves underneath xfburn and xorriso.
(No need to Cc: me, as i have now subscribed to this bug.)
--
Quite obviously this report is attributed to the wrong package.
But it is not obvious
Hi,
i wrote:
> > My only idea which does not need a code change is to employ the wodim
> > plugin of Brasero and to hope that it burns by write type SAO.
Mauro Sacchetto wrote:
> Which way?
Good question.
I have wodim installed. But last time when i tried, the wodim item was
greyed out in the
Hi,
Mauro Sacchetto wrote:
> sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
> After this, the drive is unavailable
Well, then we have found:
- The immediate cause of the problem: READ CD with LBA -1.
- A good suspect in Brasero: Function
Hi,
i made the experiments which i mentioned in the previous mail:
- The Pioneer drive does not go mad from READ CD for LBA -1 or from
READ CD MSF for sector 00:01:74.
- The ASUS drive does not go mad from READ CD MSF for sector 00:01:74.
- The TSSTcorp drive tolerates READ CD MSF for sector
Hi,
Mauro Sacchetto wrote:
> samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00
> --outfile=tdb_data.bin
> SCSI Status: Check Condition
>
> Sense Information:
> Fixed format, current; Sense key: Illegal Request
> Additional sense: Unaligned write command
Now we know from
Hi,
i now have clear evidence from a run of
sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
that the read attempt for sector 0x (= -1) brings the
ASUS DRW-24D5MT into the unusable state.
@ Mauro Sacchetto:
Could you please try to reproduce this finding
Hi,
Mauro Sacchetto wrote:
> brasero -g --brasero-media-debug > log 2>&1
(After knowing the magic words i find man pages in the web which have it.)
In the log from a successful Copy job with the Pioneer drive (sr1) i do
not see the message about "TDB".
But in the log of an immediate failure
Hi,
am i too stupid or is there really no user option to set write type SAO ?
Neither clicking around in Brasero's GUI nor searching for
BRASERO_BURN_FLAG_DAO in the source brings any insight.
I want to burn a blank CD with SAO in order to check whether this avoids
the problem with the ASUS
Hi,
the "Copy" task yields very interesting results:
A closed CD-R and a closed CD-RW which were written by write type SAO
don't spoil the drive.
Inserting a closed TAO CD-RW (burnt by Brasero) spoils the drive.
This spoiling is in effect already when the dialog window of Brasero asks
me to
Hi,
Mauro Sacchetto wrote:
> that is (more or less): "Impossible to block unity".
"unit", maybe ? The device.
> After Brasero fails, it's impossible to erase the CD with K3,
Either Brasero did its evil deed before trying to lock the unità or the
failure to do so did not prevent further access
Hi,
i managed to start fvwm2 (by Ctrl+Alt+F2 in the XFCE login window and
startx /usr/bin/fvwm2) and tried whether Brasero and ASUS drive have a
better relationship then.
They don't. It's as bad as with XFCE.
The Brasero run was started with a blank CD-RW in the drive and came,
with two pauses
Hi,
what i believe to have learned so far:
- The problem is a co-operation of ASUS DRW-24D5MT and Brasero or
some software which Brasero employs. This other software (if involved
at all) does not strike with K3B (tested by Mauro Sacchetto) or
non-GUI burn programs like wodim or xorriso.
-
Hi,
the spoiled ASUS drive does not seem to be a direct result of an attempt
to read audio CD sectors from a data CD.
The drive is rather too tolerant in that aspect. The MMC-5 specs say
that it should throw error 5,64,00 "ILLEGAL MODE FOR THIS TRACK", but
the drive doesn't.
It does not go bad
Hi,
Mauro Sacchetto wrote:
> I actually managed to burn a blank CD-RW with brasero as well.
> The problem arises when the CD-RW already has content.
Not for me. Blank CDs behave better with the automounter (but not with
the prompt window which offers me to start the file manager).
But when they
Hi,
the drive and Brasero work with DVD+RW, unformatted DVD-RW, and
formatted DVD-RW.
No bad symptoms to see, except that i get molested by the automounter
and that i often have to repeatedly double click the drive field and
the "Burn" button before burning begins.
These successes give me the
Hi,
Mauro Sacchetto wrote:
> I don't have the option of using more than one burner.
I could try with more USB burners. But we already know that it is a
problem between Brasero or its helper software on one side and the
firmware of ASUS DRW-24D5MT on the other side.
There may be other burner
Hi,
i booted kernel 4.19.0-17 which stems from a Debian 10 upgrade.
Same as with 5.10-rc3:
I started up brasero with empty tray of all drives. After inserting the
CD-RW into the ASUS, brasero does not see it. xorriso shows that the
drive is already in the bad state.
So i did a power cycle with
Hi
i have to correct my previous report:
> The obscure SCSI error 5,21,04 "Unaligned write" appears only with the ASUS.
It appears with the PIONEER too, but not with the TSSTcorp drive.
(And Brasero spoils the ASUS even if the message does not appear.)
Nevertheless, i riddle what SCSI command
Hi,
Mauro Sacchetto wrote:
> I installed on testing (kernel 5.14...) the kernel 5.10 from stable
> (backports), but I received the same error
So i fired up my experimental machine which has Debian 10 but kernel
5.10.0-rc3 cloned from git branch "linux-block" and modified to fix
a few bugs in
Hi,
Mauro Sacchetto wrote:
> samiel@darkstar:~$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed
> $isoimage
> [...]
> xorriso : UPDATE : 378 of 378 MB written (fifo 0%) [buf 100%] 0.0x.
> xorriso : UPDATE : Thank you for being patient. Working since 728 seconds.
> Writing to '/dev/sr0'
Hi,
(No need to Cc: me, i am subscribed to the bug report 998718.
If you are subscribed too and don't want to be Cc:ed, then tell me.)
> thanx for your quick reply
That's because new udevadm said "XORRISO". I found the bug report by my
evening patrol with Google.
Hi,
i am upstream programmer of libburn, which might be in charge of
burning underneath Brasero. Regrettably i cannot interpret Brasero's
messages unless they come from libburn or libisofs. So i am not sure
whether i can help with fixing Brasero.
The statement by other software that no medium is
Hi,
the commits 69b1290 and 68e0410 of
g...@salsa.debian.org:optical-media-team/libisoburn.git
should solve the issue with the next upload.
See for the new state of the description
Hi,
it is usable as a standalone tool, which shall make safer the procedure
of copying a Debian ISO image onto a USB stick. As a shell script it is
hopefully widely usable on all GNU/Linux systems which offer lsblk(8).
Nevertheless, it already has one customer which uses it as component:
rnel.dk/linux-block
---
From 154a68527351db091e5de60388ba4cfb1fe779fd Mon Sep 17 00:00:00 2001
From: Thomas Schmitt
Date: Mon, 21 Sep 2020 18:20:14 +0200
Subject: [PATCH 0/1] isofs: prevent file time rollover after year 2038
The time val
patch for the name length issues.
It is based on 5.10:
--
From 3d484405f0ad8d10ef490281da157bfdd7450cb6 Mon Sep 17 00:00:00 2001
From: Thomas Schmitt
Date: Tue, 22 Sep 2020 12:34:50 +0200
Subject: [PATCH 1/1] isofs: truncate ove
Hi,
this could be a bug in live-build.
It seems to use "xorriso -as mkisofs" option -isohybrid-mbr on systems
which have no PC-BIOS firmware and thus get no ISOLINUX BIOS bot equipment
in the ISO.
Line 69 in
https://sources.debian.org/src/live-build/1:20210122/scripts/build/binary_iso/
adds
Hi,
i am the developer of libburnia, including cdrskin and xorriso.
Feel free to ask for advise about how to use their features to achieve
what K3B needs.
I have to warn, though, that UDF is not supported by libisofs.
Besides the fact that some smaller operating systems cannot deal with
files of
1 - 100 of 446 matches
Mail list logo
