Bug#935546: debian-cd: advanced and dark-theme boot have unreadable fonts on hidpi displays
Samuel Thibault, le ven. 23 août 2019 22:03:23 +0200, a ecrit: > Steve McIntyre, le ven. 23 août 2019 21:00:19 +0100, a ecrit: > > Once you've done that, I'll backport it for buster builds too. > > Thanks, I have pushed the fix. FI, I tested the fix in the stretch branch of debian-installer, it works fine, so debian-installer can be uploaded for the next point release of stretch. Samuel
Re: Adding sha256 support into jigdo tools (jigdo and jigit)
Hi, SONAME comes from libjte/configure.ac. Dunno from where libburn got the slightly braindamaged way to compose it. From there it spread over the other libraries. libjte is its youngest victim. Shrug. The upstream revision "2.0.0" is not necessarily the .so suffix. The macro values from libjte.h have to be reflected in AC_INIT(). Thus: -AC_INIT([libjte], [1.0.0], [http://www.libburnia-project.org]) +AC_INIT([libjte], [2.0.0], [... better URL ...]) The .so suffix should increase numerically from current 1.0.0. But you are free to choose the SONAME. If you want SONAME=1 (libjte.so.1.1.0, libjte1*.deb) then: -LT_CURRENT=1 -LT_AGE=0 +LT_CURRENT=2 +LT_AGE=1 If you want SONAME=2 (libjte.so.2.0.0, libjte2*.deb) then: -LT_CURRENT=1 +LT_CURRENT=2 LT_AGE=0 Have a nice day :) Thomas
Re: Adding sha256 support into jigdo tools (jigdo and jigit)
Hi,
while exploring the need for adaptions in the build system of libsofs,
i wonder whether it is really necessary to create LIBJTE2 in libjte.ver.
Adding new functions is upward compatible.
In my libraries i add them to the current (and only) SONAME version.
Fine check for compatibility happens at compile time by the required
minimum version (e.g. iso_libjte_req_* versus LIBJTE_VERSION_*) and
at run time by calling libjte__is_compatible().
If libisoburn gets a configure.ac test for existence of
libjte_set_checksum_algorithm(), a compiler macro to enable its use,
and a configure option to disable it despite being available,
then it can even be built with the older libjte.
(Fully autostylish.)
So how about this in libjte/libjte.ver ?
LIBJTE1 {
global
...
libjte_get_next_message;
libjte_clear_msg_list;
+libjte_set_checksum_algorithm;
+libjte_set_checksum_path;
+libjte_add_checksum_demand;
+libjte_decide_file_jigdo2;
+libjte_write_match_record2;
local:
*;
};
(Good news is that even libjte2 would probably not cause changes in the
build system of libisofs. Currently it depends only on
and on libjte.so. I hope that both can keep their names.
debian/control depends on libjte1 indirectly via libjte-dev.
Adding "(>= 2.0.0)" would not really be necessary.)
Have a nice day :)
Thomas
Re: Kernel / modules version do not match in weekly testing install CD
Hello, Downloading both the latest weekly (20191028) and daily build (2019110) of debian-testing-amd64-netinst.iso the following error message is displayed: "No kernel modules were found. This is probably due to a mismatch between the kernel used by this version of the installer and the version of the kernel version available in the archive. etc" Other people, Julien Bigot, on this list have also seen the problem. Where can I find the latest netinst iso not having this problem. An yes, a bug should be filed for this problem. Thanks
Re: Adding sha256 support into jigdo tools (jigdo and jigit)
Hi,
i wrote:
> > libjte_set_checksum_algorithm() became necessary
Steve McIntyre wrote:
> ACK. I'd not thought that through fully myself here, but yes.
Here you see why it is good to have a mutually curious user-developer
relation. :))
> I'm open to changing things like option names here, obviously -
> it's your code exposing them at the top level.
But you are their only user i know of, as well as i am the only user of
libjte.
"-jigdo-checksum-algorithm" or "-checksum_algorithm_jigdo" ?
"checksum_algorithm" or "checksum_jigdo" ?
The latter already have similarily named neighbors in xorriso:
-checksum_algorithm_iso -checksum_algorithm_template
checksum_iso checksum_template
---
The user is king. Throw a coin and implement your decision for the next
diff.
---
Hm. Did you forget to mention "-jigdo-checksum-algorithm" in
xorriso/emulators.c ?
How can this pass your tests ? Doesn't
$ xorrisofs -jigdo-checksum-algorithm sha256 >/dev/null
throw
xorriso : FAILURE : -as genisofs: Unrecognized option
'-jigdo-checksum-algorithm'
(Further the new xorrisofs options have to be mentioned in function
Xorriso_genisofs_count_args() in:
static char arg1_options[][41]= {
so that some program parts know how many arguments these options consume.)
---
> I based on 1.4.7 as that was the latest
> release I had handy for the merged tree.
As soon as your tests are done and the names are decided, please send a
new updated diff and a jigit release tarball.
When i have the jigit release tarball, i will port the diff to
GNU xorriso-1.5.3. When libjte2*.deb is in testing, i will backport the
GNU xorriso changes to upstream libisoburn git and make a patch for the
pending libisoburn-1.5.2 on salsa.
Probably i will have to adapt the build system of libisofs, too.
Don't invest time in polishing xorriso code or documentation. Just make sure
that it works properly with all your use cases.
I would later appreciate a repeated test with libisoburn1_1.5.2-1_amd64.deb
when it's in unstable, and proof-reading of the docs.
Have a nice day :)
Thomas
Re: Adding sha256 support into jigdo tools (jigdo and jigit)
Arg, and our mails have just crossed I see! :-)
On Tue, Nov 12, 2019 at 07:24:16PM +0100, Thomas Schmitt wrote:
>Hi,
>
>after finding
>
> https://git.einval.com/cgi-bin/gitweb.cgi?p=jigit.git;a=log;h=refs/heads/sha256
>
> https://git.einval.com/cgi-bin/gitweb.cgi?p=jigit.git;a=blob;f=libjte/libjte.h;hb=refs/heads/sha256
>i now believe to understand that the new API call
>
> int libjte_set_checksum_algorithm(struct libjte_env *jte_handle,
>char *algorithm, int *size);
>
>became necessary because in API call write_jt_header() the static function
>parse_checksum_list() is called only conditionally. So you cannot rely on
>it as detector of checksum type.
ACK. I'd not thought that through fully myself here, but yes.
>I ponder whether i should let xorriso detect or check the type in the
>-md5-list file, depending on whether the checksum type was already
>explicitely chosen.
Maybe, that's up to you I guess.
>Guessing that you added a new "aspect" case to Xorriso_jigdo_interpreter(),
>i wonder what name you have chosen.
>Obvious but also quite long would be "-checksum_algorithm_jigdo" or
>"-checksum_algorithm_list" ("checksum_jigdo" or "checksum_list" in
>native xorrisian).
>
>Development by cliffhanger ... i need more popcorn.
*grin* I'm open to changing things like option names here, obviously -
it's your code exposing them at the top level.
Rather than keep you waiting, here's a quick and dirty diff for the
changes I've made so far. I based on 1.4.7 as that was the latest
release I had handy for the merged tree. I even started on some
trivial doc updates, but they're clearly not complete... :-)
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
Privacy is an inherent human right, and a requirement for maintaining
the human condition with dignity and respect."
-- Bruce Schneier
--- ./xorriso/lib_mgt.c~ 2017-06-29 22:32:23.0 +0100
+++ ./xorriso/lib_mgt.c 2019-11-10 16:16:41.938305902 +
@@ -765,8 +765,11 @@
goto jte_failed;
xorriso->libjte_params_given|= 8;
} else if(strcmp(aspect, "md5_path") == 0 ||
- strcmp(aspect, "-md5-list") == 0) {
- ret= libjte_set_md5_path(jte, arg);
+ strcmp(aspect, "-md5-list") == 0 ||
+ strcmp(aspect, "checksum_path") == 0 ||
+ strcmp(aspect, "-checksum-list") == 0)
+ {
+ ret= libjte_set_checksum_path(jte, arg);
if(ret <= 0)
goto jte_failed;
xorriso->libjte_params_given|= 16;
@@ -813,6 +816,21 @@
if(ret <= 0)
goto jte_failed;
xorriso->libjte_params_given|= 2048;
+ } else if(strcmp(aspect, "checksum_algorithm") == 0 ||
+ strcmp(aspect, "-jigdo-checksum-algorithm") == 0) {
+ int ck_size;
+ ret= libjte_set_checksum_algorithm(jte, arg, _size);
+ if(ret <= 0)
+ {
+ msg= libjte_get_next_message(jte);
+ if (msg != NULL)
+ {
+sprintf(xorriso->info_text, "%s", msg);
+Xorriso_msgs_submit(xorriso, 0, xorriso->info_text, 0, "FAILURE", 0);
+ }
+ goto jte_failed;
+ }
+ xorriso->libjte_params_given|= 4096;
} else {
sprintf(xorriso->info_text, "-jigdo: unknown aspect '%s'", aspect);
Xorriso_msgs_submit(xorriso, 0, xorriso->info_text, 0, "FAILURE", 0);
--- ./xorriso/xorriso.texi~ 2017-06-29 22:32:23.0 +0100
+++ ./xorriso/xorriso.texi 2019-11-10 16:27:37.565512192 +
@@ -4311,7 +4311,11 @@
@*
@strong{md5_path} sets the disk_path where to find the .md5 input file.
@*
-Alias: -md5-list
+Alias: -checksum-list
+@*
+@strong{checksums_path} sets the disk_path where to find the checksums input file.
+@*
+Alias: -checksum-list
@*
@strong{min_size} sets the minimum size for a data file to be listed
in the .jigdo file and being a hole in the .template file.
--- ./xorriso/emulators.c~ 2017-06-29 22:32:23.0 +0100
+++ ./xorriso/emulators.c 2019-11-10 16:24:08.860491692 +
@@ -2091,7 +2091,8 @@
strcmp(argpt, "-jigdo-template-compress") == 0 ||
strcmp(argpt, "-checksum_algorithm_iso") == 0 ||
strcmp(argpt, "-checksum_algorithm_template") == 0 ||
- strcmp(argpt, "-md5-list") == 0) {
+ strcmp(argpt, "-md5-list") == 0 ||
+ strcmp(argpt, "-checksum-list") == 0) {
i++;
ret= Xorriso_option_jigdo(xorriso, argpt, argv[i], 0);
if(ret <= 0)
--- ./xorriso/xorrisofs.texi~ 2017-06-29 22:32:23.0 +0100
+++ ./xorriso/xorrisofs.texi 2019-11-10 16:26:09.153079902 +
@@ -2035,6 +2035,11 @@
@cindex Jigdo Template Extraction, -md5-list
Set the disk_path where to find the .md5 input file.
@c man .TP
+@item -checksum-list disk_path
+@kindex -checksum-list set path of readable checksums
+@cindex Jigdo Template Extraction, -checksum-list
+Set the disk_path where to find the checksums input file.
+@c man .TP
@item -jigdo-template-compress "gzip"|"bzip2"
@kindex
Re: Adding sha256 support into jigdo tools (jigdo and jigit)
On Tue, Nov 12, 2019 at 09:15:34AM +0100, Thomas Schmitt wrote: >Hi, > >Steve McIntyre wrote: >> the external API for libjte is *very* close to what we had before. > >Now i'm curious. I expected no need for a change, assumed that you'd >automagically detect the checksum type from the lines in the -md5-list >file. I'd prefer to have jigdo creators make an explicit choice in the interface, rather than try to work it out automatically. It's easier to not make mistakes that way. IMHO. Yes, I've chosen differently for the make-image/jigit-mkimage clients - I want that to be as easy and automatic as possible for the end users who shouldn't have to care. >> I've got a simple diff right now that I'm >> just cleaning up and will send you shortly. > >Timing seems lucky. I have a new upstream release waiting for sponsored >upload in > https://salsa.debian.org/optical-media-team/libburn/ > https://salsa.debian.org/optical-media-team/libisofs/ > https://salsa.debian.org/optical-media-team/libsoburn/ > >If you upload a new libjte soon, then we can squeeze-in the necessary >source patches and ./debian changes. I told Dominique Dumont that my upload >request is postponed for now. (Something that fits well in any todo list.) Woot! I started on this last night, having found your gitlab setup etc. I was hoping to set up a fork and send you a MR, but the separation of libisofs, libisoburn and libburn into separate repos makes it a little more awkward to work that way. :-/ Patch coming shortly, I promise! -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Re: Adding sha256 support into jigdo tools (jigdo and jigit)
On Mon, Nov 11, 2019 at 10:30:09PM +0100, Richard Atterer wrote: >Hi Steve, > >thank you very much for continuing to take care of jigdo! It's been a loong >time since I actively worked on it. (Must have been ~2000 that I started >creating it.) > >I've updated my site to point to the URL you gave - does the text I used >work for you? Awesome, thanks. Now I need to write some text on my side! :-) >I think given that I don't work on (or even provide support for) jigdo >anymore I have no claim to be the "primary" site. Feel free to switch >debian.org to your site once your page is up. Maybe consider adding an >"honourable mention" link pointing to my old page! :-) OK, cool. >Cheers, and thanks again for keeping jigdo alive! No worries! Thanks for an awesome idea! I'll admit to not always being a fan of your coding style, but hey - every person is different! *grin* -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Re: Adding sha256 support into jigdo tools (jigdo and jigit)
Hi,
after finding
https://git.einval.com/cgi-bin/gitweb.cgi?p=jigit.git;a=log;h=refs/heads/sha256
https://git.einval.com/cgi-bin/gitweb.cgi?p=jigit.git;a=blob;f=libjte/libjte.h;hb=refs/heads/sha256
i now believe to understand that the new API call
int libjte_set_checksum_algorithm(struct libjte_env *jte_handle,
char *algorithm, int *size);
became necessary because in API call write_jt_header() the static function
parse_checksum_list() is called only conditionally. So you cannot rely on
it as detector of checksum type.
I ponder whether i should let xorriso detect or check the type in the
-md5-list file, depending on whether the checksum type was already
explicitely chosen.
Guessing that you added a new "aspect" case to Xorriso_jigdo_interpreter(),
i wonder what name you have chosen.
Obvious but also quite long would be "-checksum_algorithm_jigdo" or
"-checksum_algorithm_list" ("checksum_jigdo" or "checksum_list" in
native xorrisian).
Development by cliffhanger ... i need more popcorn.
Have a nice day :)
Thomas
Re: Adding sha256 support into jigdo tools (jigdo and jigit)
Hi, Steve McIntyre wrote: > the external API for libjte is *very* close to what we had before. Now i'm curious. I expected no need for a change, assumed that you'd automagically detect the checksum type from the lines in the -md5-list file. > I've got a simple diff right now that I'm > just cleaning up and will send you shortly. Timing seems lucky. I have a new upstream release waiting for sponsored upload in https://salsa.debian.org/optical-media-team/libburn/ https://salsa.debian.org/optical-media-team/libisofs/ https://salsa.debian.org/optical-media-team/libsoburn/ If you upload a new libjte soon, then we can squeeze-in the necessary source patches and ./debian changes. I told Dominique Dumont that my upload request is postponed for now. (Something that fits well in any todo list.) Have a nice day :) Thomas
