Hi,
Daniel Lewart wrote:
> I did find 215 MiB of exact duplicate files.
> ...
> 24724624 Oct 30 10:07 firmware/firmware-atheros_20240909-2_all.deb
> 24724624 Oct 30 10:07
> pool/non-free-firmware/f/firmware-nonfree/firmware-atheros_20240909-2_all.deb
These two most probably share their content i
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
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
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,
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 -i
Hi,
Antoine Beaupré wrote:
> Severity set to 'grave' from 'normal'
This is really overdone.
See jigdo as a peculiar way of downloading the ISO with a MD5 check
where e.g. wget has none at all.
And as said, for now jigdo seems indispensible for the fat ISO sets.
> If the ISO image generation is
Hi,
Daniel Kahn Gillmor wrote:
> If jigdo would use the SHA256sum entries instead of the MD5 entries when
> it is doing ISO assembly, then everyone could still fetch full DVD sets
> or BD sized installation ISOs
I am kindof the second-last jigdo export, but not at all with .deb
entrails.
Are you
Hi,
Debian's simpleburn depends among others on cdrskin.
If it asks for cdrecord, then it has not been properly adapted to
this dependency.
A simple workaround would be to create a symbolic link
sudo ln -s /usr/bin/cdrskin /usr/bin/cdrecord
cdrskin understands many cdrecord options as of year
Hi,
> I'm not sure we want to continuously give it back until it builds (which
> it might on schroeder, since it didn't fail there yet)...
I would assume the problem is deterministic and depends on
the exact tree of file names which is given to genisoimage
as input.
So adding a few names of empty
Hi,
> isoinfo gave me this..
Looks like quite a normal bootable ISO 9660 filesystem image.
Much like the Debian and Ubuntu ISOs which get burned to DVD
all over the world.
Still hard to believe that the problem should sit in this
image and not in burner drive and medium.
How much evidence do y
Hi,
(For some reason my subscription to this bug does not work.
Better Cc: me.)
> I guess this backup tool
> creates iso's witch are not compattible with DVD file system.
> (Universal Disk Format (UDF), ISO/IEC 13346 and/or ECMA
The error message originally stems from the drive's firmware.
I
Hi,
> :-[ WRITE@LBA=538f0h failed with SK=4h/TRACKING SERVO FAILURE]:
This is a problem between drive and medium.
It does not necessary mean that either of them is bad.
But at least the combination does not work properly.
Try other media. If the problem persists, get another drive.
Have a nice
Hi,
Cyril Brulebois wrote:
> genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and
> './tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.
> [...]
> Probably some FS-dependent fun? Anyone would have a clue about it?
Looks like an internal error of genisoimage.
'.' should be mapped to a
Hi,
Helmut Grohne wrote:
> As for the libburn maintainers, I suggest to change the comment in the
> header to not include the verbatim string "burn_abort(>0)" in order to
> not confuse doxygen.
Done by
http://www.libburnia-project.org/changeset/5122
Do you have more advise for me ?
E.g. for t
Hi,
Matthias Klose wrote:
> fix it in libburn or disable building the docs.
> upstream did tell you that they didn't want to update that
> for newer doxygen versions.
If you mean me, as upstream of libburn, then you got me wrong.
I am willing to help Debian packaging in any way. Just give
me clea
Hi,
i am the upstream programmer of libburn.
If i can do anything to help fixing the problem, please tell me.
About the doxygen complaints (of which i am unsure whether they are
the reason for the stalled build process):
libbu
Hi,
i see i made a mistake when writing:
> The problem was introduced in october 2012 by
It was introduced in october 2010, not 2012.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@li
Hi,
a Brasero flaw was found in the course of Debian bug 688229.
It would provide an explanation for the problems which are
described here. Especially it is involved when burning directly
to optical media and not involved when writing ISO filesystems
to hard disk.
The problem was introduced in oc
Hi,
> The log shows some Growisofs message and not the one I have.
> Although, could it be that it is dependent on the libburn version?
The libburn plugin was not used. Only the libisofs one.
A run with growisofs as burn engine would also suffer from the bug
we found in the libisofs plugin.
But
Hi,
Paul Menzel wrote in his patch:
> Substituting this command with the variable fixes the problem reported in
> GNOME Bugzilla bug 655601.
I have to stress that the found bug does _not_ explain the
original report of
https://bugzilla.gnome.org/show_bug.cgi?id=655601
(which is what i call the
Hi,
> 000 001 C D 0 0 1 001 \0
Yes. That is the start of a Primary Volume Descriptor block.
Please mount the medium and use diff to compare the files in
the image with their originals on hard disk. Just to be sure.
(Mounting does not check all
Hi,
> - while (priv->libburn_src->read_xt (priv->libburn_src, buf,
> sector_size) == sector_size) {
> + while (read_bytes == sector_size) {
> I am building it right now.
Crossing fingers ...
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.deb
Hi,
staring at lines 201, 202, and 216 of
http://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libisofs.c
i realize that this loop drops every second block !
read_bytes = priv->libburn_src->read_xt (priv->libburn_src
Hi,
i have to correct myself:
> > 004 002 C D 0 0 1 001 \0 \0 \0 \0 \0
i wrote:
> It should sit at block 17.
> So it looks like we lose 17 blocks at start.
Well, it sits now at block 8.
So we lost 9 blocks before it.
Have a nice day :)
Thomas
--
To UNSUBSC
Hi,
> I am also going to print out the sector size. (Or just use GDB.)
The loop condition (read_bytes == sector_size) suggests that
it must be 2048. Only this alignment is guaranteed for the
output of libisofs.
(Actually it would be a good reason for the 50 % bug if libisofs
would not obey this
Hi,
> + res = burn_drive_convert_fs_adr ("stdio:/tmp/my_emulated_drive,
> libburn_device);
Isn't there a quotation mark missing before the comma ?
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
Hi,
i think i can spot a byte eating problem in
http://git.gnome.org/browse/brasero/commit/?id=5ff86b48
resp. the master-branch commit
http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39
-
Hi,
> Could you please CC me
I will try to remember. :)
But maybe you better subscribe by a mail to
688229-subscr...@bugs.debian.org
> Is there some way to simulate a burner to find out what happened?
libburn would accept burner addresses like
stdio:/tmp/my_emulated_drive
which would behav
Hi,
Paul Menzel wrote:
> $ dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c
> ...
> 000 > \0 0 034 001 \0 \0 001 034 0 F 034 + \0 \0 +
> 020 034 F p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001
> 040 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 2
Hi,
> brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %)
It went well, at least as far as libisofs was involved.
So this is not the problem with premature end after 50 %.
And it is not the riddling CD problem, where Brasero CDs are
unreadable, whereas xorriso burned CDs ar
Hi,
for the records: I managed to get my changes in burn-libburn.c into
effect by copying from
brasero-2.30.3/plugins/libburnia/.libs/libbrasero-libburn.so
to
/usr/lib/brasero-0/plugins/libbrasero-libburn.so
I assume it is better to achieve this the Debian way.
At least i could verify that i
Hi,
on the risk to discourage Simon from testing SAO, i have to report
a fact that weakens my TAO/SAO theory in his special case.
Brasero writes TAO too, when copying an image from hard disk to CD,
or when storing a newly generated image intermediately on hard disk.
I had hoped to find the final
Hi,
> get the source package (apt-get source) and just edit
> plugins/libburnia/burn-libburn.c
Does it still have that name ?
Are there other occasions of burn_write_opts_set_write_type() in 3.4 ?
(Meanwhile i stirred up the system enough to get this:
Message from syslogd@debian2 at Jul 7 21
Hi,
Simon Wenner wrote:
> xorriso seems to work as expected.
Your report and the one of Alain Rpnpif support the theory that your drives
dislike CD write type TAO with your particular CD media or in general.
I failed to force Brasero into using the other write type. (Details below.)
I see in Bra
Hi,
> I get that growisofs is not recommended for burning CD-R[W]
It flatly refuses:
:-( /dev/sr0: media is not recognized as recordable DVD: A
The growisofs runs were surely with DVD or BD.
> simple solution is to remove the offending plugin from brasero plugin
> directory ("install_path"/l
Hi,
> - Disabling the option "Burn the image directly without saving to disc"
> (see screen shot) creates a working CDs (that can be ejected
> automatically too).
I will have to try at least the eject aspect.
> But anyway, I updated to brasero 3.4.1 and I can still reproduce the bug.
How did y
Hi,
> Hm, did you try to mess up with gconf-editor
Not yet.
But i try now:.
I do not see an alternative to
apps|brasero|config|priority|libisofs-image
Well i now set
apps|brasero|config|priority|growisofs-burn 1
This did not change anything. Now growisofs process to see while the
DVD burn
Hi,
Alain Rpnpif wrote:
> This works fine for CR-RW only but not
> with CD-R (I have crashed 2 CD-R to confirm).
> With CD-R, some files are full of 00H.
This supports the theory of poor compatibility of drive and media.
Blank CD-RW and CD-R are handled identically by burn software.
They make no
Hi,
Paul Menzel wrote:
> Until then I suggest to not bother anymore with that problem.
It gives libisofs a bad name.
Probably the squeeze Brasero is two notches too old.
This comment could explain why:
https://bugzilla.gnome.org/show_bug.cgi?id=655601#c5
> ... > Nico Zanferrari 2012-01-1
Hi,
in order to apply George's patch anyway, i have tried to disable
libburn so that growisofs would be used with DVD.
No success.
Both, growisofs and libburn are enabled but also greyed, so that i
cannot change their checkboxes.
Whatever, just in case it brings any new insight:
$ cd brasero-2
Hi,
i had a look at brasero build logs and have to drop the appealing theory
of sizeof(off_t) == 4.
The compiler gets a sufficient macro to avoid this: -D_FILE_OFFSET_BITS=64
I now managed to build Brasero brasero-2.30.3-2 from the Debian sources.
It shows no differences to the previously instal
Hi,
> Command for what?
For building the Brasero that was downloaded as source.
dpkg-buildpackage seems to be the right one.
> But as George put, the problems are about Data projects, that
> means - as far as I understand - to choose some files from your disk and
> burn them directly to a CD/DV
Hi,
George Danchev wrote:
> $ dpkg-checkbuilddeps # to check you have all build-dependencies installed
> $ dpkg-buildpackage
Ok. The messages from remnant root-owned result files tell me
that this is indeed 2.30.3-2.
dpkg-source: error: cannot write brasero_2.30.3-2.dsc: Permission denied
Aft
Hi,
> PS: Somehow the Debian bug report address was not in CC but it was
> archived [1] anyway. Did you put it in BCC? Anyway, I added it back to
> the CC list.
I thought i addressed my mails
To: 617...@bugs.debian.org
Cc: all others.
but To: shows up with rpn...@free.fr.
I am using a halfwa
Hi,
George Danchev wrote:
> Thomas (or anyone else), could you please try brasero on your squeeze box (I
> currently don't have any burners at reach),
Ok, for once ... :))
I will cry on your shoulder if it freezes my good old fvwm display.
Actually i avoided trying myself because i do not want t
Hi,
Josselin Mouette wrote:
> That would be brasero-list:
> https://mail.gnome.org/mailman/listinfo/brasero-list
Is there a chance that we could work together to find out what's wrong ?
If not George Danchev's patch already brings insight, that is.
Released libisofs-1.2.2 would be a good test b
Hi,
Paul Menzel wrote:
> So unfortunately it looks like there is no list for Brasero and you need
> to use the GNOME Bugzilla bug tracker.
Well, there is a list, the last entry is of january 2012, and it
complains about the burn errors which seem to have emerged in
spring 2011.
https://mail.gno
Hi,
i am currently the developer of libburn and libisofs.
> https://bugzilla.gnome.org/show_bug.cgi?id=655601
I know about such problems, but i do not know how to get into a
discussion with Brasero developers.
My impression is that the libisofs plugin causes libisofs to end
prematurely. libburn
48 matches
Mail list logo
