Re: [Libcdio-devel] Opaque CdIo_t and interaction with libiso9660

Gabriel - Thanks for reporting the problem and trying to push Debian forward. I don't know what's wrong, but I will try to investigate when I get a chance. On Mon, Mar 24, 2025 at 8:48 AM Gabriel F. T. Gomes < gabr...@inconstante.net.br> wrote: > Dear Libcdio developers, > > I need your help wit

Re: [Libcdio-devel] libcdio 2.2.0 version relesed.

On Wed, Jan 15, 2025 at 8:32 AM Greg Troxel wrote: > Please let us know when it appears on the GNU ftp site. The pkgsrc > entry is pointing at that, and I don't want to flip to github and back. > > (I realize ftp upload credential fixing may not be super fast...) > This is not likely to happen

[Libcdio-devel] libcdio 2.2.0 version relesed.

libcdio 2.2.0 was just released on GitHub. It is a slight modification to the 2.1.1 release that occurred recently. Jan Alexander Steffens who works with Arch Linux noticed there was API and ABI breakage and that we neither bumped the ".so" number on the shared libraries, not the internal version

[Libcdio-devel] libdio 2.1.1 released

Libcdio 2.1.1 has now been released. You see what has changed and get tarballs from github now: https://github.com/libcdio/libcdio/releases/tag/2.1.1 Thanks again to all who have contributed in the last 7 years since the last release. I haven't been able to get the key signing on ftp.gnu.org work

Re: [Libcdio-devel] libcdio 2.1.1 release beginning of 2025

will be released within a week. Thanks to all who have contributed. On Wed, Dec 25, 2024 at 2:12 PM Rocky Bernstein wrote: > It's been over 5 years since the last release. At the beginning of 2025, > I will work on a 2.1.1 release. > > If you have comments or concerns, now wou

Re: [Libcdio-devel] Clang formatting for libcdio C source code

On Tue, Dec 31, 2024 at 7:00 PM wrote: > Rocky Bernstein: > ... > > Do you all have an opinion on whether we should reformat using > clang-format > > (https://clang.llvm.org/docs/ClangFormat.html). And if so what style we > > should use? > ... > > Still eag

[Libcdio-devel] Clang formatting for libcdio C source code

Recently, in https://github.com/libcdio/libcdio-paranoia/pull/53 Adrian Reber contributed a CI integration hook to check the format of C files and make it conform to clang style. When I suggested it might also be done to libcdio, he did so in https://github.com/libcdio/libcdio/pull/7. It would ch

[Libcdio-devel] libcdio 2.1.1 release beginning of 2025

It's been over 5 years since the last release. At the beginning of 2025, I will work on a 2.1.1 release. If you have comments or concerns, now would be a good time to raise them.

[Libcdio-devel] libcdio copied from savannah.gnu.org to github

moved there. Invitations have been sent to join the organization based on membership from savannah.gnu.org membership. If you don't have an invitation and would like one, contact me. On Mon, Sep 9, 2024 at 4:20 PM Rocky Bernstein wrote: > Thanks everyone for sharing your thoughts. > >

Re: [Libcdio-devel] RFC - move libcdio from savannah.gnu.org to github?

27;s deficiencies with FSF and discussing. At some level, I think they have to know that savannah.gnu.org is not cutting it. It is not something I want to spend time on, but if others do please go ahead! If there turns out to be useful information, please let me know. On Thu, Sep 5, 2024 at 8:4

Re: [Libcdio-devel] [PATCH v2] cdtext: Count empty fields as tracks

the line. And discussion on the code is always open whenever or if ever it happens. On Thu, Sep 5, 2024 at 8:40 PM Rocky Bernstein wrote: > I have committed this patch to the branch count-empty-tracks-as-field-v2; > see > https://git.savannah.gnu.org/cgit/libcdio.git/log/?h=count-empty-

[Libcdio-devel] RFC - move libcdio from savannah.gnu.org to github?

I'd like your opinion about moving the libcdio git repository from savannah.gnu.org to github (or some other git repository) The mechanisms at savannah.gnu.org have not been improving or developing while github, gitlab, etc., seem to be constantly improving. Your thoughts?

Re: [Libcdio-devel] [PATCH v2] cdtext: Count empty fields as tracks

I have committed this patch to the branch count-empty-tracks-as-field-v2; see https://git.savannah.gnu.org/cgit/libcdio.git/log/?h=count-empty-tracks-as-field-v2 I invite review of this. If after a week or so there are no objections, I will merge this into the master branch. On Thu, Sep 5, 2024 a

[Libcdio-devel] RFC: vulnuerability patches (Wa: Vulnerable use of strcpy in iso9660_fs.c)

aised about thes, then after about a week, I will merge this in master. Attached is a more detailed report that Mansour Gashabi produced in scanning the code for weaknesses. Thanks. - Rocky On Thu, Apr 4, 2024 at 6:51 PM Rocky Bernstein wrote: > I just received a report about a place in li

Re: [Libcdio-devel] Request for Comments: converting libcdio-paranoia C style - which "standard" to use?

Libcdio paranoia has been updated as a one-shot conversion to more-closely match LLVM C code style. See https://github.com/rocky/libcdio-paranoia/pull/44 for the changes. If you have comments or concerns, let me know. On Fri, May 17, 2024 at 1:01 PM Rocky Bernstein wrote: > Sorry for

Re: [Libcdio-devel] Request for Comments: converting libcdio-paranoia C style - which "standard" to use?

of it hampering development. On Mon, May 13, 2024 at 3:47 PM wrote: > Rocky Bernstein: > ... > > For example: > > > > for(;endA > > if(buffA[endA]!=buffB[endB])break; > > Perfectly readable though a little cramped. > > [ about clang-format etc. ] &

[Libcdio-devel] Request for Comments: converting libcdio-paranoia C style - which "standard" to use?

Recently, I put out a libcdio-paranoia release https://github.com/rocky/libcdio-paranoia/releases/tag/release-10.2%2B2.0.2 to fix a bug that Whipper folks mentioned 6 years ago. For those who have looked at the code, it largely follows the C style used by the original cdparanoia code. This is a s

Re: [Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

text and slide with text are at https://rocky.github.io/blackhat-asia-2024-additional/all-notes-print.html. Also had a great time in Singapore, Malaysia, and a stopover night in Frankfurt, Germany) On Thu, Apr 4, 2024 at 6:51 PM Rocky Bernstein wrote: > I just received a report about a place

Re: [Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

First of all Thomas, your suggestions are *greatly appreciated! * Right now I am getting ready for eclipse-watching in the US and am out of town and/or vacationing. But when I get back I'll soon travel to Singapore to talk at BlackHat Asia 2014 and will spend a couple of weeks in Malaysia after th

[Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

I just received a report about a place in libiso9660 where we use strcpy() instead of strncpy(). If someone has a suggestion for how to fix, please let me know. I can send a more detailed report for those interested

Re: [Libcdio-devel] [PATCH 1/4] Add case insensitive _cdio_stricmp and _cdio_strnicmp function calls

With respect to this patch, the only nitpick I have is that we should add a comment for the new functions, even if it is something as basic as "case insensitive version of _cdio_strcmp / _cdio_strncmp" respectively. I don't mind adding that as a commit after the patch in a git branch and others can

Re: [Libcdio-devel] [PATCH 0/4] Add El Torito virtual image support

Thanks for the patches. Over the next week or so I will be looking at these and most likely merging these in. I have been meaning to do a release of the code. Usually at the end of October I do releases. That should give me plenty of leeway here. Probably for the next release, I'll use linters an

Re: [Libcdio-devel] [PATCH] libcdio.sym: Remove undefined symbols

Your changes have now been merged to master. Thanks for testing and sticking with this. On Tue, Jan 9, 2024 at 7:50 PM Nicholas Vinson wrote: > On 1/9/24 02:40, Rocky Bernstein wrote: > > I have not been able to reproduce the problem using the configure > > options given, ho

Re: [Libcdio-devel] [PATCH] libcdio.sym: Remove undefined symbols

p;id=4ebc31bf828e3503891a201ecb6ef7e92ac52359 Please try this branch out and let me know if this addresses the issue. If so, I'll merge it into master. Thanks for the bug report. On Mon, Jan 8, 2024 at 9:47 PM Nicholas Vinson wrote: > [Resending to include the mailing list] > > On 1/8/24 21:33, Rocky Bernstein wrote: &

Re: [Libcdio-devel] [PATCH] libcdio.sym: Remove undefined symbols

Thanks - I will try patching this soon. I would be interested in seeing a failure, applying the patch and seeing a fix. Would you give me more information about the environment so I can replicate this failure? Thanks. and thanks for the patch. On Mon, Jan 8, 2024 at 9:11 PM Nicholas Vinson w

Re: [Libcdio-devel] Makefile change for joliet_multi_extent, was: Unmerged branch ts-cdtext-fix

On Sun, Apr 9, 2023 at 8:05 AM Thomas Schmitt wrote: > Hi, > > ... - > > The test went too bumpy to give me enough confidence for committing to > "joliet_multi_extent" and merging. > So i propose that you take care of that branch and merge it when ready. > No problem. joliet_multi_extent has bee

Re: [Libcdio-devel] Unmerged branch ts-cdtext-fix

Sorry for the late reply. I will be out of town next week and probably not checking email On Mon, Apr 3, 2023 at 2:44 PM Thomas Schmitt wrote: > Hi, > > Rocky Bernstein wrote: > > If there are not that many changes, it might be simpler just to start a > new > > branch

Re: [Libcdio-devel] Unmerged branch ts-cdtext-fix

If there are not that many changes, it might be simpler just to start a new branch and add the changes you want there from the one where you are having a problem. On Mon, Apr 3, 2023 at 11:42 AM Thomas Schmitt wrote: > Hi, > > it looks like the two commits > bde2647b444136e2d23d303d0a02d27383f

Re: [Libcdio-devel] About old branches of mine

On Mon, Apr 3, 2023 at 5:31 AM Thomas Schmitt wrote: > Hi, > > Rocky Bernstein wrote: > > if xoriso or some other burner program in the past created ISO 9660 > images > > in a particular way, > > xorriso still produces the larger ISOs by default. Normally it does no

Re: [Libcdio-devel] About old branches of mine

Over the weekend I removed my stale branches from libcdio's git. On Fri, Mar 31, 2023 at 5:25 PM Thomas Schmitt wrote: > Hi, > > Rocky Bernstein > > test/data/multi_extent_8k.iso| Bin 524288 -> 122880 bytes > > I think both versions should be there. We s

Re: [Libcdio-devel] About old branches of mine

I just pulled master and see: test/data/multi_extent_8k.iso| Bin 524288 -> 122880 bytes I think both versions should be there. We should be testing not just how things are created currently, but also how they may have been created in the past. On Fri, Mar 31, 2023 at 4:22 AM Thomas

Re: [Libcdio-devel] Can we merge branch "joliet_multi_extent" ?

On Thu, Mar 30, 2023 at 6:36 AM Thomas Schmitt wrote: > Hi, > > Rocky Bernstein wrote: > > I have tested on Ubuntu and Windows 10 and things are fine. > > Does this mean that i shall merge "joliet_multi_extent" with "master" > now ? > Yes, please do. > > > Have a nice day :) > > Thomas > > >

Re: [Libcdio-devel] Can we merge branch "joliet_multi_extent" ?

check_multiextent.sh: ISO 9660 + Rock Ridge multiextent read test > ok. > -- ./check_multiextent.sh: Joliet multiextent listing test ok. > -- ./check_multiextent.sh: Joliet multiextent read test ok. > > I tested that this branch can be merged into a branch made from "master" > (15801fb

Re: [Libcdio-devel] CD-Text support for macOS and Windows

On Mon, Mar 27, 2023 at 11:07 AM Robert Kausch via Libcdio-devel < libcdio-devel@gnu.org> wrote: > Am 26.03.2023 um 22:58 schrieb Rocky Bernstein: > > On Fri, Mar 24, 2023 at 3:58 AM Rocky Bernstein wrote: > > For what it is worth, I was able to build the current master on

Re: [Libcdio-devel] Can we merge branch "joliet_multi_extent" ?

On Mon, Mar 27, 2023 at 8:49 AM Rocky Bernstein wrote: > > > On Mon, Mar 27, 2023 at 7:23 AM Thomas Schmitt wrote: > >> Hi, >> >> Rocky Bernstein wrote: >> > Here is a suggestion - in that branch add the new ISO image that you >> created. >> &

Re: [Libcdio-devel] Can we merge branch "joliet_multi_extent" ?

On Mon, Mar 27, 2023 at 7:23 AM Thomas Schmitt wrote: > Hi, > > Rocky Bernstein wrote: > > Here is a suggestion - in that branch add the new ISO image that you > created. > > And then add a new test for this feature. > > It seems easiest to extend test "

Re: [Libcdio-devel] Can we merge branch "joliet_multi_extent" ?

;make distcheck" to help with the latter. On Mon, Mar 27, 2023 at 3:57 AM Rocky Bernstein wrote: > in that branch -> in that branch *add* > > On Mon, Mar 27, 2023 at 3:56 AM Rocky Bernstein wrote: > >> Here is a suggestion - in that branch the new ISO image that you crea

Re: [Libcdio-devel] Can we merge branch "joliet_multi_extent" ?

in that branch -> in that branch *add* On Mon, Mar 27, 2023 at 3:56 AM Rocky Bernstein wrote: > Here is a suggestion - in that branch the new ISO image that you created. > And then add a new test for this feature. > > After that passes, then merge the whole thing back into

Re: [Libcdio-devel] Can we merge branch "joliet_multi_extent" ?

Here is a suggestion - in that branch the new ISO image that you created. And then add a new test for this feature. After that passes, then merge the whole thing back into master. My suggestion is to merge to master and let's move forward given that you've tested this. If there are further probl

Re: [Libcdio-devel] CD-Text support for macOS and Windows

On Fri, Mar 24, 2023 at 3:58 AM Rocky Bernstein wrote: > Thanks for the macOS patches. I will probably try the Windows code this > weekend. > For what it is worth, I was able to build the current master on Windows 10 pro and Msys2. I suspect though that master doesn't have R

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

is needed here, but these changes should buy us a little more time. On Sun, Mar 26, 2023 at 1:39 PM Thomas Schmitt wrote: > Hi, > > Rocky Bernstein wrote: > > > In other words, this is supposed to be a stress on you, we want you to > > > succeed. > > Mario Đanić

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

ways as well, and some of those have slight semantic differences. But for this particular situation, I am not sure merge versus rebase matters that much. Right now, I am more interested in the bigger picture. > > On Sun, 26 Mar 2023 at 12:57, Thomas Schmitt wrote: > > > Hi, >

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

On Sun, Mar 26, 2023 at 7:08 AM Mario Đanić wrote: > Hopefully you meant NO stress on him, we dont want him stressed out :D > Yes, you are correct: I meant NO stress. I am sorry for the stress this typo may have caused. > On Fri, 24 Mar 2023 at 00:08, Rocky Bernstein wrote: > >

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

On Sun, Mar 26, 2023 at 6:57 AM Thomas Schmitt wrote: > Hi, > > Rocky Bernstein wrote: > > There is no way you can mess up in git, because history is saved by > default > > for *everyone. *And specifically I have a copy. > > I still see the opportunity for a rac

Re: [Libcdio-devel] CD-Text support for macOS and Windows

Thanks for the macOS patches. I will probably try the Windows code this weekend. Personally, I welcome a more distributed approach for this project and git works well with this. Thanks again. On Thu, Mar 23, 2023 at 8:49 PM Robert Kausch via Libcdio-devel < libcdio-devel@gnu.org> wrote: > Hi al

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

On Thu, Mar 23, 2023 at 5:13 PM Thomas Schmitt wrote: > Hi, > > Rocky Bernstein wrote: > > I was thinking that Pete would do the merge since he also has commit > rights > > after the two of you decide that it is time to merge > > Everybody is more qualified as g

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

branch. And then there's the one patch from > pete_batard_ce_v3 with SHA 569c452f8d1650c0ec50ebeef7869b54ed9c8be6. > > Thanks! > > /Pete > > On 2023.03.23 20:03, Rocky Bernstein wrote: > > Ok. Just give me the SHA1 of the code that you'd like to see in master &

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

aid. Pete, and Thomas - which of these goes to master? On Thu, Mar 23, 2023 at 4:03 PM Rocky Bernstein wrote: > Ok. Just give me the SHA1 of the code that you'd like to see in master and > I will test it as well. And assuming everything works and it looks like > what has been menti

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

at Thomas has take upon himself to > create branches and carry additional testing to prepare for merging, so > thanks for doing that. > > Regards, > > /Pete > > On 2023.03.23 19:54, Rocky Bernstein wrote: > > > > > > On Thu, Mar 23, 2023 at 3:12 PM Thomas Schmitt &

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

On Thu, Mar 23, 2023 at 3:12 PM Thomas Schmitt wrote: > Hi, > > the patch applies and compiles without complaints. > > I was riddling about the exact meaning of "{ 0 }" when the struct has more > than one member. In Linux time.h struct tm is declared with 11 members. > Finally i found in C11 spec

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

I hope this is obvious but I'll say it anyway. I do not have any comment on the patches, and you should feel free to merge whenever you and Thomas are mutually satisfied. When the dust settles, if you all think we need to do a release I can do that. On Wed, Mar 22, 2023 at 5:10 PM Pete Batard wr

Re: [Libcdio-devel] [PATCH 0/2] Add Rock Ridge CE record processing

I am good with this and the other changes. Thomas or anyone else have comments? If I don't hear anything in a while, I'll just commit these to master (or Pete you can yourself.) On Tue, Feb 28, 2023 at 3:48 PM Pete Batard via Libcdio-devel < libcdio-devel@gnu.org> wrote: > The current libcdio pa

Re: [Libcdio-devel] [PATCH] iso9660: Fixing off by one error in rock.c

On Thu, Oct 20, 2022 at 4:12 PM Seija Kijin wrote: > > buffer, when it should be the 10th. > --- > lib/iso9660/rock.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/iso9660/rock.c b/lib/iso9660/rock.c > index a957d785..5b6e67d9 100644 > --- a/lib/iso9660/rock.c > ++

Re: [Libcdio-devel] libcdio tools cannot read multi-exent files with Joliet exensions on

Comments in line. On Fri, Jun 24, 2022 at 8:40 AM Thomas Schmitt wrote: > Hi, > > Ben Kohler wrote: > > I've found that for an iso > > created with (cdrtools) mkisofs -J -iso-level 3, libcdio tools like > > iso-info and iso-read are not able to handle multi-extent files. > > It's a pair of bugs

Re: [Libcdio-devel] [PATCH] Linux: Use getmntent/setmntent for reading mounts

Thanks for the patch. This should be applied now in SHA 0d550dc9 on master. But please double check. Extra appreciated is something about who you are and why this is important or how it was discovered. On Wed, Feb 2, 2022 at 9:18 PM Miguel Borges de Freitas wrote: > Also posted the patch to s

Re: [Libcdio-devel] [PATCH] Multiprocess compatible get_media_changed_linux using the new CDROM_TIMED_MEDIA_CHANGED ioctl

Thanks for the patch. It should be applied in 96a1030c now. Please double check though. On Sun, Jan 23, 2022 at 11:46 AM Lukas Prediger wrote: > Here's a patch that I posted also to savannah.gnu.org a couple of days > ago. However, I'm not sure if that is currently actively checked, so I > wante

Re: [Libcdio-devel] Haskell bindings released

Sam - Many thanks for doing this! I have added to http://www.gnu.org/software/libcdio/ mention of this. Please double check, and if you want the wording changed or removed, let me know. (Open source survives by the willingness of people to work on it.) On Sat, Jun 5, 2021 at 9:24 AM Sam May via

Re: [Libcdio-devel] NM patch for libcdio

re is some problem. Thanks On Mon, Jul 6, 2020 at 6:25 AM David Seifert wrote: > On Sun, 2020-07-05 at 19:20 -0400, Rocky Bernstein wrote: > > This seems reasonable enough. Commit 45e6509 should apply your patch. > > > > Please double check though since I make lots of mistakes

Re: [Libcdio-devel] NM patch for libcdio

This seems reasonable enough. Commit 45e6509 should apply your patch. Please double check though since I make lots of mistakes (and that's one reason I work on debuggers). Also, if you prefer in the future you can also open a github issue . L

Re: [Libcdio-devel] Rock Ridge deep directory support

; Regards, > > /Pete > > On 2020.06.16 17:47, Thomas Schmitt wrote: > > Hi, > > > > Rocky Bernstein wrote: > >> But,Thomas, if you want to redo so it is smaller that's okay too. > > > > We tested. We discussed. Let's merge. > > > > > > Have a nice day :) > > > > Thomas > > > > > > >

Re: [Libcdio-devel] Rock Ridge deep directory support

But,Thomas, if you want to redo so it is smaller that's okay too. On Tue, Jun 16, 2020 at 12:30 PM Rocky Bernstein wrote: > Ok. I let's just go with the existing image. > > On Tue, Jun 16, 2020 at 12:04 PM Pete Batard wrote: > >> On 2020.06.16 15:48, Thomas Schmitt

Re: [Libcdio-devel] Rock Ridge deep directory support

Ok. I let's just go with the existing image. On Tue, Jun 16, 2020 at 12:04 PM Pete Batard wrote: > On 2020.06.16 15:48, Thomas Schmitt wrote: > > But if it is for size, then the existing > >test/data/deep-directory.iso > > is too large by the traditional padding of 150 * 2048 bytes (which is

Re: [Libcdio-devel] Rock Ridge deep directory support

On Tue, Jun 16, 2020 at 9:46 AM Pete Batard wrote: > On 2020.06.16 14:03, Rocky Bernstein wrote: > > Oh also, I don't see that Thomas' additional CD-images to test this are > in > > there. Should they be used? > > Do we need two test images? >

Re: [Libcdio-devel] Rock Ridge deep directory support

Oh also, I don't see that Thomas' additional CD-images to test this are in there. Should they be used? On Tue, Jun 16, 2020 at 9:01 AM Rocky Bernstein wrote: > You have green light to do whenever you want. > > If you are done and would like me to test before merge, I can do t

Re: [Libcdio-devel] Rock Ridge deep directory support

You have green light to do whenever you want. If you are done and would like me to test before merge, I can do that too. On Tue, Jun 16, 2020 at 7:50 AM Pete Batard wrote: > On 2020.06.14 09:03, Thomas Schmitt wrote: > > i think the changes for RR Deep Directory Relocation work fine and shoul

Re: [Libcdio-devel] Rock Ridge deep directory support

Wow! I will look and try the code when I get a chance. Thanks! On Sat, May 30, 2020 at 8:43 AM Pete Batard wrote: > Hi, > > I have just completed my RR deep directory support proposal, which can > be found in the new rr-deep-directory branch I just pushed. > > Support for deep directory has b

Re: [Libcdio-devel] Hindsight is 2020 - Let's sort multiextents at last

On Mon, May 25, 2020 at 6:42 AM Pete Batard wrote: > Hi, > > Thanks to you both for following up on multiextent. I realize I probably > should have spent a bit more time finalizing the proposal, as there were > indeed a few missing items. > > On 2020.05.25 10:41, Rocky Be

Re: [Libcdio-devel] Hindsight is 2020 - Let's sort multiextents at last

On Mon, May 25, 2020 at 4:23 AM Thomas Schmitt wrote: > Hi, > > the changes in revise-examples-for-multi-extent look good to me. > > But there might be some more occasions of ->size which need change. > I did: > fgrep -r '>size' . | less > and tried to classify the found code snippets. > Thank

Re: [Libcdio-devel] Hindsight is 2020 - Let's sort multiextents at last

On Sun, May 24, 2020 at 3:48 PM Pete Batard wrote: > On 2020.05.24 17:00, Rocky Bernstein wrote: > > On Sun, May 24, 2020 at 9:36 AM Thomas Schmitt > wrote: > > > >> Hi, > >> > >> branch pragmatic-multiextent-2020 has now passed all my experiments

Re: [Libcdio-devel] Hindsight is 2020 - Let's sort multiextents at last

On Sun, May 24, 2020 at 9:36 AM Thomas Schmitt wrote: > Hi, > > branch pragmatic-multiextent-2020 has now passed all my experiments > which master would pass. > Insofar i propose to merge it. > Merge it then, unless anyone objects. It is good to see the long-standing problems (eventually) get f

Re: [Libcdio-devel] Proposal for fix of cd-info on MSWindows driver

Sure - push directly to master. Thanks. On Fri, May 22, 2020 at 11:55 AM Pete Batard wrote: > Hi Thomas, > > On 2020.05.22 16:21, Thomas Schmitt wrote: > > Pete Batard wrote: > >> That's called squashing. You should be able to find plenty of help on > how to > >> do that using git rebase, such a

Re: [Libcdio-devel] Proposal for fix of cd-info on MSWindows driver

On Wed, May 20, 2020 at 5:18 PM Thomas Schmitt wrote: > Hi, > > Pete Batard wrote: > > Since it's your patch, I'll let you push it to master. > > Rocky once instructed me to make candidate branches for such occasions. > It's too late in the night to try new tricks. :)) > > Pete, if you can checko

Re: [Libcdio-devel] check_cue.sh failing with cdda_4_5 image on MinGW

On Wed, May 20, 2020 at 6:56 AM Pete Batard wrote: > Hi Thomas, > > Thanks a lot for looking into this. > And my thanks,Thomas, as well. > I can understand why you are being confused, and I guess I have to > apologize for making you waste your time here, because it turns out that > the real is

Re: [Libcdio-devel] Rock Ridge RRIP Deep Directory support

On Wed, Apr 29, 2020 at 8:22 PM Pete Batard wrote: > Hi, > > I got an issue reported today from a user trying to use a Rock Ridge ISO > with folders that go more than 8 levels, and it appears that the Rock > Ridge extensions from libcdio do not support RRIP Deep Directories, as > described on pag

Re: [Libcdio-devel] libudf support for udf 2.5

On Thu, Apr 2, 2020 at 4:36 PM Lukas Rusak wrote: > Hello! > > I was wondering if there was any plans to have libudf support udf spec 2.5 > (or 2.6)? I am specifically curious about support for allocation descriptor > chains as used by bluray formats. > I think I noticed the lack of allocation d

Re: [Libcdio-devel] Miscellaneous questions, primarily on design

On Sun, Mar 22, 2020 at 5:17 AM Leon Merten Lohse wrote: > Hi, > > On 21.03.20 21:41, Samuel May wrote: > > > Thomas Schmitt wrote: > >>> * What about changing the language of a block? I know libcdio isn't > >>> primarily a disc-authoring library, though with cdtext_set(..) and > >>> cdio_get_cd

Re: [Libcdio-devel] Miscellaneous questions, primarily on design

On Sat, Mar 21, 2020 at 7:34 AM Thomas Schmitt wrote: > Hi, > > Samuel May wrote: > > > the physical button on the front of my drive stops working > > Rocky Bernstein wrote: > > if you look at the GNU/Linux code in lib/driver/gnu_linux.c around line > 80 >

Re: [Libcdio-devel] Miscellaneous questions, primarily on design

On Fri, Mar 20, 2020 at 5:01 PM Samuel May wrote: > Hello everyone! > > I'm working on Haskell bindings to libcdio I think this would be awesome! Here's a fun fact recarding haskell: the person whose code started this all and wrote a VCD authoring tool vcdimager, hvr a

Re: [Libcdio-devel] Removing homegrown bool in favor of stdbool

Change now merged in. stdbool .h is now std. On Sun, Aug 18, 2019 at 6:27 PM Rocky Bernstein wrote: > Something I've wanted to do for a long time is remove the homegrown > definition of libcdio's bool type. > > The Open Group Base Specifications Issue 6 of the IEEE Std 100

[Libcdio-devel] Removing homegrown bool in favor of stdbool

Something I've wanted to do for a long time is remove the homegrown definition of libcdio's bool type. The Open Group Base Specifications Issue 6 of the IEEE Std 1003.1 2004 Edition has this listed. See http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdbool.h.html and that says this is al

[Libcdio-devel] Using POSIX stdbool in libcdio

One of the things I'd like to see before the next release is to remove libcdio's pre-stdbool definition of bool and replace it wilth POSIX stdbool. Any takers?

Re: [Libcdio-devel] How tolerant to be towards CD-TEXT character set mislabeling ?

On Tue, May 7, 2019 at 10:13 AM Thomas Schmitt wrote: > Hi, > > i wrote: > > i created a git branch "bug53929" and committed the proposed change. > > > > "Made CD-TEXT character set interpretation more tolerant towards bad > >input. Reaction on savannah bug 53929." > > > http://git.savannah

Re: [Libcdio-devel] How tolerant to be towards CD-TEXT character set mislabeling ?

Sounds good. To delete a remote branch: git push origin --delete bug53929 More information is at https://stackoverflow.com/questions/2003505/how-do-i-delete-a-git-branch-locally-and-remotely On Fri, May 3, 2019 at 4:03 PM Thomas Schmitt wrote: > Hi, > > in order to maximize the probability f

Re: [Libcdio-devel] How tolerant to be towards CD-TEXT character set mislabeling ?

On Mon, Apr 29, 2019 at 12:18 PM Thomas Schmitt wrote: > Hi, > > > ++ WARN: CD-TEXT: Unknown character set code 123. > > --DEBUG: CD-TEXT character set: code=123 , name= , chosen=ISO-8859-1 > > tried with starmania (declaring ascii using iso-8859-1) and all title and > > performer are good > > I

Re: [Libcdio-devel] How tolerant to be towards CD-TEXT character set mislabeling ?

As Thomas asks below: should libcdio's CD-TEXT change its behavior from assuming an ASCII-encoding by default to instead to use and ISO-8859-1 encoding, which includes ASCII as a subset? Unless there is dissent, or have other ideas, we will switch to ISO-8859-1 as the default CDTEXT encoding. Tha

[Libcdio-devel] Fwd: [bug #53929] cd-text with invalid characters failing to convert to utf8

If anyone has thoughts - let me/us know. -- Forwarded message - From: Serge Pouliquen Date: Thu, Apr 25, 2019 at 9:35 AM Subject: [bug #53929] cd-text with invalid characters failing to convert to utf8 To: Rocky Bernstein , Serge Pouliquen Follow-up Comment #5, bug #53929

Re: [Libcdio-devel] libcdio 2.1.0 released and on ftp.gnu.org

On Thu, Apr 18, 2019 at 1:06 PM Greg Troxel wrote: > Rocky Bernstein writes: > > > See http://ftp.gnu.org/pub/gnu/libcdio/?C=M;O=D > > > > Thanks to everyone for the h[elp] on this release and especially to Edd > > Barrett and Thomas Schmitt. This bulk of this r

[Libcdio-devel] libcdio 2.1.0 released and on ftp.gnu.org

See http://ftp.gnu.org/pub/gnu/libcdio/?C=M;O=D Thanks to everyone for the hop on this release and especially to Edd Barrett and Thomas Schmitt. This bulk of this release is work that they did.

Re: [Libcdio-devel] libcdio-2.1.0-rc1 available for testing (Was OpenBSD vs libcdio vs Audacious)

Since I haven't heard anything from anyone in the last few days about rc2 (and there are a few more NEWS.md typos fixed in the rc2 branch), I'll plan on making a release in a day or two. On Sat, Apr 13, 2019 at 12:18 PM Rocky Bernstein wrote: > libcdio 2.1.0 release candidate 1 is

Re: [Libcdio-devel] libcdio-2.1.0-rc1 available for testing (Was OpenBSD vs libcdio vs Audacious)

Ok - these are the dangers when you get an outsider trying to make release notes. I've made a stab at correcting this in the rc2 branch. However best would be to just edit NEWS.md and make it right. Thanks for the corrections. On Sun, Apr 14, 2019 at 4:42 PM Thomas Schmitt wrote: > Hi, > > first

Re: [Libcdio-devel] libcdio-2.1.0-rc1 available for testing (Was OpenBSD vs libcdio vs Audacious)

ead failure be counted as a skipped test. Since you have write acccess to the savannah git repo you can also make changes in that branch and I'll merge that in before release. Thanks for testing. On Sun, Apr 14, 2019 at 9:05 AM Edd Barrett wrote: > On Sat, Apr 13, 2019 at 12:1

[Libcdio-devel] libcdio-2.1.0-rc1 available for testing (Was OpenBSD vs libcdio vs Audacious)

p?3929) * [Bug 53929: cd-text with invalid characters failing to convert to utf8]( https://savannah.gnu.org/bugs/index.php?3928) Thanks everione! On Tue, Apr 9, 2019 at 7:42 PM Rocky Bernstein wrote: > I have some unexpected time over the weekend, so I will plan a release > then. >

Re: [Libcdio-devel] OpenBSD vs libcdio vs Audacious

I have some unexpected time over the weekend, so I will plan a release then. Thanks for your persistence and your patience. On Tue, Apr 9, 2019 at 6:35 PM Edd Barrett wrote: > Hi Rocky, > > On Sun, Feb 24, 2019 at 10:46:52PM +, Edd Barrett wrote: > > > Haven't had time to test it out fully

Re: [Libcdio-devel] OpenBSD vs libcdio vs Audacious

Edd's changes to bsd-logging have now been merged into master. Haven't had time to test it out fully yet, but I am sure that will happen, and perhaps others can try it out too. On Tue, Feb 12, 2019 at 6:26 AM Rocky Bernstein wrote: > Thanks Edd for the work and information. I

Re: [Libcdio-devel] OpenBSD vs libcdio vs Audacious

Thanks Edd for the work and information. I haven't had a chance to look at the code yet. Maybe the next weekend I'll be able to get to it and hopefully merge it in. As for a release that's a bigger deal. We need to see if Thomas is okay with it. Also, I had been promising myself to remove the han

Re: [Libcdio-devel] OpenBSD vs libcdio vs Audacious

On Mon, Feb 4, 2019 at 4:20 PM Edd Barrett wrote: > On Sun, Jan 27, 2019 at 06:54:02PM +0100, Thomas Schmitt wrote: > > I would give set_speed_mmc() a try. > > Alas, sadly this doesn't help. TBH I can live without it, although I'd > like to silence the error message unless logging is turned up. >

Re: [Libcdio-devel] OpenBSD vs libcdio vs Audacious

On Sat, Jan 26, 2019 at 11:18 AM Edd Barrett wrote: > Hi, > > I've found some time to look into the audacious issues. > > It turns out the situation with audacious isn't as bad as I first > thought. I thought it was erroneously starting the CD on a different > track each time, but this turned out

[Libcdio-devel] libcdio-paranoia 10.2+2.0.0 released

libcdio-paranoia-10.2+2.0.0.tar.bz2 is now on ftp.gnu.org the corresponding gz file will probably be there soon. Thanks to Edd Barrett and Thomas Thomas Schmitt for doing petty much everything in this release. On Fri, Jan 25, 2019 at 4:03 AM Rocky Bernstein wrote: > If I have time, I

Re: [Libcdio-devel] Possibly libcdio-paranoia release this weekend

On Fri, Jan 25, 2019 at 5:42 AM Edd Barrett wrote: > On Fri, Jan 25, 2019 at 04:03:44AM -0500, Rocky Bernstein wrote: > > If there are objections, now is the time to speak. > > I think you said that this is pretty independent of libcdio (which we > know is broken on Ope

[Libcdio-devel] Possibly libcdio-paranoia release this weekend

If I have time, I'll put out a release of libcdio-paranoia to address audio CD's where the first track is not audio. This is currently the code on github. If there are objections, now is the time to speak.

  1   2   3   4   5   6   >