Bug#959941: RFP: codium -- Code editing. Redefined.
Hi! Instead of VSCode/Codium I would recommend Pulsar. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060778 (ITP: pulsar-edit -- A Community-led Hyper-Hackable Text Editor (formerly Atom)). However, to get any Electron app in Debian somebody would need to package Electron first, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842420 (RFP: electron -- Build cross platform desktop apps with JavaScript, HTML, and CSS).
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Thanks for checking. The arch i386 is going away, so it can be ignored/disabled. Issues with BLHC and reprotest should be fixed if they are easy. Having them both pass is not a hard requirement. Most important here is that you checked all failures and there was nothing else. I don't have any suggestions how to get around the wasm binary issue right now. Let me think about it for a couple of days.
Bug#1075734: RFS: mangl/1.1.5-1 [ITP] -- Graphical man page viewer
Hi! If you are not using Salsa CI simply because you didn't know about it, then check out https://salsa.debian.org/salsa-ci-team/pipeline I will check the Mentor website and look for opportunities to document Salsa CI better.
Bug#1073456: RFS: colorize/0.66-1 -- Colorizes text on terminal with ANSI escape sequences
I didn't claim that you must use Salsa or CI. I was just curious to learn is there a particular reason this package is not using Salsa-CI to validate that all easily testable things are correct?
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Cool, latest version indeed is on Salsa https://salsa.debian.org/zig-team/zig/-/blob/main/debian/control Vcs-Browser: https://salsa.debian.org/zig-team/zig Vcs-Git: https://salsa.debian.org/zig-team/zig.git Homepage: https://github.com/ziglang/zig The CI at https://salsa.debian.org/zig-team/zig/-/jobs/5643130 fails on: /bin/sh: 1: ./obj-x86_64-linux-gnu/zig: not found Do you need help getting past this?
Bug#1075734: RFS: mangl/1.1.5-1 [ITP] -- Graphical man page viewer
Yes, using Salsa or CI is not required, but I was curious is there particular reason this package is not using Salsa-CI to validate that all easily testable things are correct?
Bug#1075734: RFS: mangl/1.1.5-1 [ITP] -- Graphical man page viewer
Hi! There are no CI runs visible at https://salsa.debian.org/monty/mangl/-/pipelines Any particular reason this package is not using Salsa-CI to validate that all easily testable things are correct? - Otto
Bug#1073456: RFS: colorize/0.66-1 -- Colorizes text on terminal with ANSI escape sequences
Hi! > Vcs : http://cgit.refcnt.org/colorize.git/ Any particular reason this is not hosted on Salsa and using Salsa-CI to validate that all easily testable things are correct? - Otto
Bug#1061087: RFS: bash-unit/2.3.1-1 [ITP] -- bash_unit - bash unit testing
Hi! I noticed the CI at https://salsa.debian.org/mdosch/bash-unit/-/pipelines/665767 is failing on reprotest. If you are unable to fix it, you could mark the test as 'allow failure' so it won't make the whole pipeline report failure. - Otto
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi! > * Vcs : https://github.com/NickHastings/zig-debian Any particular reason this is not hosted on Salsa and using Salsa-CI to validate that all easily testable things are correct? - Otto
Bug#932088: gdebi does not ask for a root password, just silently closes
The symptoms here sound very much like https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/1854588 which has now been fixed in Ubuntu, but not submitted to Debian There was also a fix drafted in https://salsa.debian.org/atzlinux-guest/gdebi/-/commit/1de6b00bef539de4458021dc02ed2110f76ab630 but not record if it worked. It wasn't uploaded to Debian. I think the root cause why gdebi is broken is that it is unmaintained. Looking at https://tracker.debian.org/pkg/gdebi the source code hosting points to https://code.launchpad.net/~gdebi-developers/gdebi/trunk. Last version in this source code was 0.9.5.7 in 2015, followed by commit that source code moved to https://code.launchpad.net/~gdebi-developers/gdebi/+git/main in 2022, yet that location has zero new commits since the 0.9.5.7 in 2015. If it was maintained, and there was a git repository people could contribute to, many of these bugs would have been fixed. Currently it is just maintainers doing one-off emergency fixes without storing anything in git in a way that would allow for contributions from users like Doug Brown in LP#1854588.
Bug#1075993: dpkg: Please allow merge requests on Salsa
Hi! > Well dpkg already has multiple repos, and they are being kept in sync, > by having a main instance and then replicas! I think doing this > automatically without a merge-based workflow, for multiple pushers, > would either be racy, or not possible at all w/o making a mess of it. Git fully supports accepting Merge Requests / Pull Requests from multiple places. You just apply the commit on the main place like you usually do and push and you are all good. > > Under no situation would a sync of the mirror overwrite the Merge > > Requests. If I for example file a Merge Request at > > https://salsa.debian.org/dpkg-team/dpkg from a source branch in my own > > fork, there is no way for you to overwrite that merge request branch. > > Your own fork should indeed be safe from overwrites, but that was not > my point :), AFAIUI GitLab based forges store MRs against that project > as refs under the refs/nerge-requests hierarchy, that's why you can > fetch them remotely by adding something like this in your local tree > under .git/config: > > [remote "some-name"] > url = git@gitlab-url:repo/repo.git > fetch = +refs/heads/*:refs/remotes/some-name/* > fetch = +refs/merge-requests/*/head:refs/remotes/some-name/mr/* > > Then when you fetch, you'll see the MRs as those branches for that > remote. A «git push --mirror» will forcibly add, update or delete > remote branches to match the local (on the git server) bare repo, and > my assumption has always been that this would remove those refs, but > perhaps GitLab protects them someway and does not let you remove them > even by force, or when mirroring. TBH have never bother to test that, > but I think that's a bit besides the point as I mentioned. You have a very elaborate explanation of something that nobody does, never has happened, and which is not even technically possible. What you are indirectly expressing here is just that you don't like Salsa/GitLab and don't want to learn or think how it works or what benefits it brings, but rather focus on coming up with reasons not to use it, even imaginary ones. ... > One of the concerns is that this spreads this information for the > project, so that others will have a harder time seeing where things > are happening, and stores that information in a place where it will > be harder to extract (once, not if) Salsa goes away. With git being Everything relevant about the code change is in the git commit message itself. I don't think allowing Merge Requests on Salsa would mean that you need to store the metadata about MRs forever. They are useful to facilitate making the change, such as tracking if the code passes CI and what is the state of the MR. Once it is merged or closed it is fine to forget about the MR. ... > primary hosting site, and there that makes perfect sense. Although > GitLab or GitHub review capabilities are not very ideal compared to > either mail based workflows or even Gerrit. Salsa is also very slow, > which is quite frustrating. GitLab and GitHub track things like CI and submission status, which is completely missing from email. And both on GitLab and GitHub you can actually also review by email if you don't want to be assisted by the UI. I do agree on the slowness, and have filed https://salsa.debian.org/salsa/support/-/issues/395 > But in any case, just to wrap up, this is not about not knowing how > these forges work, or their potential advantages, etc. I'm open to > reconsider this in general, and I've also been pondering for a while The fact that your first response to this bug report was to immediately close it paints a clear picture that you have a strong gut feeling is against the proposal, and your half-arguments reflect that you really want to come up with reasons to not support MRs. I just wish you would have replied simply that you don't like using Salsa MRs but left the bug report open for more people to potentially voice their opinion (assuming there is dpkg-team, perhaps there isn't).
Bug#1075993: dpkg: Please allow merge requests on Salsa
Hi! Thanks for a quick reply! > > Please allow Merge Requests at https://salsa.debian.org/dpkg-team/dpkg > > so that it is easier for others to contribute to the package. > > These repos are just mirrors (I've updated the repo descriptions there > now), like the ones on Codeberg, where stuff gets «git push --mirror»'ed > into them. So enabling MR could cause accidental diverging history which > would be messy, and given how --mirror works and how I think GitLab > tracks MRs, my assumption has been that those MR branches would be > deleted on mirror push anyway. > > It would also spread where to look for changes, currently already > the BTS and the mailing list. > > So, thanks for the request, but I think I'm going to decline it. Git is a distributed version control system. You can perfectly fine have multiple repositories and then sync between them. Under no situation would a sync of the mirror overwrite the Merge Requests. If I for example file a Merge Request at https://salsa.debian.org/dpkg-team/dpkg from a source branch in my own fork, there is no way for you to overwrite that merge request branch. It is true that if you accept Merge Requests, then you would have to read email notifications from both patches submitted via bugs.debian.org as well as via salsa.debian.org. However that is very minor extra work. The benefit of accepting Merge Requests on salsa.debian.org is that you can see that the CI you are using is passing and the submission didn't regress anything testable. I think you were very quick to jump to the conclusion that accepting Merge Requests is somehow a burden or extra work. I am confident that if you give it a try, and more people contribute to improving dpkg, the overall benefit far outweighs the minor inconvenience of getting email notifications of patches from two systems.
Bug#1074780: Acknowledgement (pdns-backend-mysql: autopkgtests use of mysql* commands don't work directly with new MariaDB 11.4 with mariadb-* commands)
> > > > /tmp/autopkgtest-lxc.pxhhitlw/downtmp/build.JDD/src/debian/tests/smoke-mysql: > > line 7: /usr/bin/mysqld_safe: No such file or directory > > Well I imagine you (or upstream) renamed some binaries, but the > package name stayed the same? Thanks, somehow I wasn't able to spot that earlier. > I imagine that will need a patch. Here you go: https://salsa.debian.org/debian/pdns/-/merge_requests/3
Bug#1074780: Acknowledgement (pdns-backend-mysql: autopkgtests use of mysql* commands don't work directly with new MariaDB 11.4 with mariadb-* commands)
Hi Christian! Can you help read the PowerDNS autopkgtest logs to understand why they are failing now? ke 3. heinäk. 2024 klo 23.24 Otto Kekäläinen kirjoitti: > Hi Marc and Christian! > > Just checking if you can help with debugging the pdns autopkgtest issues? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074780 >
Bug#1070160: Acknowledgement (libfmt: Please allow merge requests on Salsa)
Hi! Could you please consider this request? Thanks
Bug#1075993: dpkg: Please allow merge requests on Salsa
Package: dpkg Severity: wishlist Hi! Please allow Merge Requests at https://salsa.debian.org/dpkg-team/dpkg so that it is easier for others to contribute to the package. Thanks!
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
Thanks for the tips. Unfortunately running just the single test without any other load on the system still crashes it and system load was otherwise zero, so it is not due to slowness. I also tested explicit debug run and various ways to invoke gdb, but --debug didn't yield any new info and all gdb variants try to launch xterm which does not work over ssh, or if gdb is invoked manually directly it just crashes with "Breakpoint 1 at 0xc38ffc: file ./sql/signal_handler.cc, line 133.". cd builddir/mysql-test && \ export MTR_PRINT_CORE=detailed && \ ./mtr main.partition --debug ./mtr main.partition --gdb='b handle_fatal_signal; r' ./mtr main.partition --boot-gdb='b handle_fatal_signal; r' ./mtr main.partition --boot-gdb='--quiet --tui;b mysql_parse;r' ./mtr main.partition --manual-gdb='b handle_fatal_signal; r' --verbose --verbose gdb -x /home/otto/mariadb-server/builddir/mysql-test/var/tmp/gdbinit.mysqld.1 /home/otto/mariadb-server/builddir/sql/mariadbd cd builddir/mysql-test && \ export MTR_PRINT_CORE=detailed && \ ./mtr --force --testcase-timeout=120 --suite-timeout=540 --retry=3 \ --verbose-restart --max-save-core=1 --max-save-datadir=1 \ main.partition vardir: /home/otto/mariadb-server/builddir/mysql-test/var Checking leftover processes... Removing old var directory... Creating var directory '/home/otto/mariadb-server/builddir/mysql-test/var'... Checking supported features... MariaDB Version 11.4.2-MariaDB-3-debug - SSL connections supported - binaries are debug compiled - binaries built with wsrep patch Collecting tests... Installing system database... == TEST RESULT TIME (ms) or COMMENT -- worker[01] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019 main.partition [ fail ] Test ended at 2024-07-06 05:17:58 CURRENT_TEST: main.partition mysqltest: At line 3010: query 'select id from t1 where data = 'ab' order by id' failed: (2013): Lost connection to server during query The result from queries just before the failure was: < snip > insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14, 'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ; select id from t1 where data = 'ab' order by id; id 4 5 6 14 15 16 drop table t1; create table t1(id int unsigned not null, data text default null, key data_idx (data(1),id) ) default charset=utf8 partition by range (id) ( partition p10 values less than (10), partition p20 values less than (20) ); insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14, 'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ; select id from t1 where data = 'ab' order by id; More results from queries before failure can be found in /home/otto/mariadb-server/builddir/mysql-test/var/log/partition.log - found 'core' (0/1) Core generated by '/home/otto/mariadb-server/builddir/sql/mariadbd' Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). -- [New LWP 3251707] [New LWP 3251701] [New LWP 3251702] [New LWP 3251704] [New LWP 3251700] [New LWP 3251703] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1". Core was generated by `/home/otto/mariadb-server/builddir/sql/mariadbd --defaults-group-suffix=.1 --de'. Program terminated with signal SIGUSR1, User defined signal 1. #0 0xfff80001026928c0 in __pthread_kill_implementation (threadid=1892278227175616, signo=10, no_tid=0) at ./nptl/pthread_kill.c:43 43 ./nptl/pthread_kill.c: No such file or directory. [Current thread is 1 (Thread 0xfff80001022a88c0 (LWP 3251707))] #0 0xfff80001026928c0 in __pthread_kill_implementation (threadid=1892278227175616, signo=10, no_tid=0) at ./nptl/pthread_kill.c:43 #1 0x01000154ca3c in my_write_core (sig=10) at ./mysys/stacktrace.c:424 #2 0x01c39778 in handle_fatal_signal (sig=10) at ./sql/signal_handler.cc:357 #3 #4 0x01f35cac in ha_partition::init_record_priority_queue (this=0xfff800011cca4790) at ./sql/ha_partition.cc:5657 #5 0x01f363b4 in ha_partition::index_init (this=0xfff800011cca4790, inx=0, sorted=true) at ./sql/ha_partition.cc:5762 #6 0x01939870 in handler::ha_index_init (sorted=true, idx=0, this=0xfff800011cca4790) at ./sql/handler.h:3495 #7 join_read_always_key (tab=0xfff800011ccd1870) at ./sql/sql_select.cc:24407 #8 0x0191df74 in sub_select (join=0xfff800011c017560, join_tab=0xfff800011ccd1870, end_of_records=) at ./sql/sql_select.cc:23632 #9 0x0195c6ec in do_select (procedure=0x0, join=0xfff800011c017560) at ./sql/sql_select.cc:23146 #10 JOIN::exec_inner (this=0xfff800011c017560) at ./sql/sql_select.cc:5010 #11 0x0195cd60 in JOIN::exec
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
I built the binary in debug mode and that yielded a stacktrace: *** main.partition w38 [ retry-fail ] Test ended at 2024-07-06 01:14:43 CURRENT_TEST: main.partition mysqltest: At line 3010: query 'select id from t1 where data = 'ab' order by id' failed: (2013): Lost connection to server during query The result from queries just before the failure was: < snip > insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14, 'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ; select id from t1 where data = 'ab' order by id; id 4 5 6 14 15 16 drop table t1; create table t1(id int unsigned not null, data text default null, key data_idx (data(1),id) ) default charset=utf8 partition by range (id) ( partition p10 values less than (10), partition p20 values less than (20) ); insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14, 'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ; select id from t1 where data = 'ab' order by id; More results from queries before failure can be found in /home/otto/mariadb-server/builddir/mysql-test/var/38/log/partition.log - found 'core' (1/1) worker[38] > Restart - not started Core generated by '/home/otto/mariadb-server/builddir/sql/mariadbd' Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). -- [New LWP 3175949] [New LWP 3175830] [New LWP 3175886] [New LWP 3175896] [New LWP 3175931] [New LWP 3175902] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1". Core was generated by `/home/otto/mariadb-server/builddir/sql/mariadbd --defaults-group-suffix=.1 --de'. Program terminated with signal SIGUSR1, User defined signal 1. #0 0xfff80001028928c0 in __pthread_kill_implementation (threadid=1892278236620992, signo=10, no_tid=0) at ./nptl/pthread_kill.c:43 43 ./nptl/pthread_kill.c: No such file or directory. [Current thread is 1 (Thread 0xfff8000102baa8c0 (LWP 3175949))] #0 0xfff80001028928c0 in __pthread_kill_implementation (threadid=1892278236620992, signo=10, no_tid=0) at ./nptl/pthread_kill.c:43 #1 0x01000154ca3c in my_write_core (sig=10) at ./mysys/stacktrace.c:424 #2 0x01c39778 in handle_fatal_signal (sig=10) at ./sql/signal_handler.cc:357 #3 #4 0x01f35cac in ha_partition::init_record_priority_queue (this=0xfff800011cca7c10) at ./sql/ha_partition.cc:5657 #5 0x01f363b4 in ha_partition::index_init (this=0xfff800011cca7c10, inx=0, sorted=true) at ./sql/ha_partition.cc:5762 #6 0x01939870 in handler::ha_index_init (sorted=true, idx=0, this=0xfff800011cca7c10) at ./sql/handler.h:3495 #7 join_read_always_key (tab=0xfff800011cd285c0) at ./sql/sql_select.cc:24407 #8 0x0191df74 in sub_select (join=0xfff800011c017560, join_tab=0xfff800011cd285c0, end_of_records=) at ./sql/sql_select.cc:23632 #9 0x0195c6ec in do_select (procedure=0x0, join=0xfff800011c017560) at ./sql/sql_select.cc:23146 #10 JOIN::exec_inner (this=0xfff800011c017560) at ./sql/sql_select.cc:5010 #11 0x0195cd60 in JOIN::exec (this=0xfff800011c017560) at ./sql/sql_select.cc:4796 #12 0x0195a938 in mysql_select (thd=0xfff800011c000dc8, tables=0xfff800011c015f48, fields=..., conds=0xfff800011c016818, og_num=1, order=, group=, having=, proc_param=, select_options=, result=, unit=, select_lex=) at ./sql/sql_select.cc:5326 #13 0x0195ac54 in handle_select (thd=0xfff800011c000dc8, lex=0xfff800011c005170, result=0xfff800011c017538, setup_tables_done_option=) at ./sql/sql_select.cc:628 #14 0x018a0d64 in execute_sqlcom_select (thd=0xfff800011c000dc8, all_tables=0xfff800011c015f48) at ./sql/sql_parse.cc:6141 #15 0x018aea04 in mysql_execute_command (thd=0xfff800011c000dc8, is_called_from_prepared_stmt=false) at ./sql/sql_parse.cc:3950 #16 0x018b6168 in mysql_parse (thd=0xfff800011c000dc8, rawbuf=, length=, parser_state=) at ./sql/sql_parse.cc:7862 #17 0x018b929c in dispatch_command (command=COM_QUERY, thd=0xfff800011c000dc8, packet=0xfff800011c00bdb9 "", packet_length=, blocking=true) at ./sql/sql_class.h:254 #18 0x018bc800 in do_command (thd=0xfff800011c000dc8, blocking=true) at ./sql/sql_parse.cc:1406 #19 0x01a5ee1c in do_handle_one_connection (connect=, put_in_cache=true) at ./sql/sql_connect.cc:1437 #20 0x01a5f16c in handle_one_connection (arg=0x100031b2a58) at ./sql/sql_connect.cc:1339 #21 0x01f490e4 in pfs_spawn_thread (arg=0x10003190318) at ./storage/perfschema/pfs.cc:2201 #22 0xfff800010289068c in start_thread (arg=0xfff8000102baa8c0) at ./nptl/pthread_create.c:444 #23 0xfff800010290b410 in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:79 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 6 (Thread 0xfff80001024dc8c0 (LWP 3175902)): #0 0xfff800010288cc4c in
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
Notes on how I setup the schroot on stadler: source porterbox.sh psetup sparc64 pinstall git-buildpackage gdb debian-goodies mariadb-server-core perl-modules-ipc-system-simple pinstall build-essential bison cmake cracklib-runtime debhelper-compat default-jdk dh-exec libboost-dev libbz2-dev libcrack2-dev libcurl4-openssl-dev libedit-dev libfmt-dev libjemalloc-dev libjudy-dev libkrb5-dev liblz4-dev liblzma-dev liblzo2-dev libncurses-dev libnuma-dev libpam0g-dev libpcre2-dev libsnappy-dev libssl-dev libsystemd-dev liburing-dev libxml2-dev libzstd-dev lsb-release po-debconf psmisc unixodbc-dev uuid-dev zlib1g-dev dpkg-buildpackage -uc -us -b find-dbgsym-packages ./builddir/sql/mariadbd pinstall libc-bin-dbgsym libc6-dbgsym libatomic1-dbgsym libcap2-dbgsym libcrypt1-dbgsym libgcc-s1-dbgsym libnuma1-dbgsym libpcre2-8-0-dbgsym libssl3t64-dbgsym libstdc++6-dbgsym libsystemd0-dbgsym liburing2-dbgsym libzstd1-dbgsym zlib1g-dbgsym dpkg-buildpackage -uc -us -b
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
Hi!
On Tue, 2 Jul 2024 at 23:24, John Paul Adrian Glaubitz
wrote:
>
> Hello Otto,
>
> On Tue, 2024-07-02 at 21:10 -0700, Otto Kekäläinen wrote:
> > I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed
> > on sparc64.
> >
> > Are there any sparc64 hackers interested in taking a look?
> >
> > The build itself passed and most of the post-build passes, but some
> > tests cause the database to crash. Stack traces are visible in the
> > logs:
> >
> > https://buildd.debian.org/status/fetch.php?pkg=mariadb=sparc64=1%3A11.4.2-2=1719891893=0
> > https://buildd.debian.org/status/logs.php?pkg=mariadb=sparc64
>
> I would suggest rerun the build plus testsuite on the porterbox stadler
> with glibc debug packages installed in the chroot so you can get a more
> usable backtrace.
It took me many hours to get the schroot setup correctly with proper
debug symbol packages (answer was: libatomic1-dbgsym libcap2-dbgsym
libcrypt1-dbgsym libgcc-s1-dbgsym libnuma1-dbgsym libpcre2-8-0-dbgsym
libssl3t64-dbgsym libstdc++6-dbgsym libsystemd0-dbgsym
liburing2-dbgsym libzstd1-dbgsym zlib1g-dbgsym) but I have now the
full build log at stadler:/tmp/build2.log if anyone here wants to take
a look and give suggestions on what might be going on.
Below is one of the crashes with full traces to the extend I got it
now (though some parts seems to have been optimized out by compiler):
main.partition w23 [ retry-fail ]
Test ended at 2024-07-05 15:03:17
CURRENT_TEST: main.partition
mysqltest: At line 3010: query 'select id from t1 where data = 'ab'
order by id' failed: (2013): Lost connection to server
during query
The result from queries just before the failure was:
< snip >
insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14,
'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ;
select id from t1 where data = 'ab' order by id;
id
4
5
6
14
15
16
drop table t1;
create table t1(id int unsigned not null,
data text default null,
key data_idx (data(1),id)
) default charset=utf8
partition by range (id) (
partition p10 values less than (10),
partition p20 values less than (20)
);
insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14,
'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ;
select id from t1 where data = 'ab' order by id;
More results from queries before failure can be found in
/home/otto/mariadb-server/builddir/mysql-test/var/23/log/partition.log
- found 'core' (1/1)
worker[23] mysql-test-run: WARNING: Test reserved for w47 picked up by w23
worker[23] > Restart - not started
Core generated by '/home/otto/mariadb-server/builddir/sql/mariadbd'
Output from gdb follows. The first stack trace is from the failing thread.
The following stack traces are from all threads (so the failing one is
duplicated).
--
[New LWP 3082605]
[New LWP 3082578]
[New LWP 3082562]
[New LWP 3082574]
[New LWP 3082573]
[New LWP 3082575]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
Core was generated by `/home/otto/mariadb-server/builddir/sql/mariadbd
--defaults-group-suffix=.1 --de'.
Program terminated with signal SIGUSR1, User defined signal 1.
#0 0xfff80001028928c0 in __pthread_kill_implementation
(threadid=1892278236620992, signo=10, no_tid=0) at
./nptl/pthread_kill.c:43
43 ./nptl/pthread_kill.c: No such file or directory.
[Current thread is 1 (Thread 0xfff8000102baa8c0 (LWP 3082605))]
#0 0xfff80001028928c0 in __pthread_kill_implementation
(threadid=1892278236620992, signo=10, no_tid=0) at
./nptl/pthread_kill.c:43
#1 0x01a85b74 in handle_fatal_signal (sig=10) at
./sql/signal_handler.cc:357
Backtrace stopped: Cannot access memory at address 0xf0
Thread 6 (Thread 0xfff80001024dc8c0 (LWP 3082575)):
#0 0xfff800010288cc4c in __futex_abstimed_wait_common64 (private=0,
cancel=true, abstime=0x0, op=, expected=0,
futex_word=0x100019f84c0 ) at
./nptl/futex-internal.c:57
_arg2 =
_arg5 = 0
__o0 = 512
__o3 = 0
_arg3 = 0
_arg6 = 4294967295
__o1 = 393
__o4 = 0
_arg1 = 1099538859200
_arg4 = 0
__g1 = 142
__o2 = 0
__o5 = 4294967295
sc_cancel_oldtype = 0
sc_ret =
#1 __futex_abstimed_wait_common (futex_word=0x100019f84c0
, expected=0, clockid=, abstime=0x0,
private=0, cancel=true) at ./nptl/futex-internal.c:87
err =
clockbit =
op =
#2 0xfff800010288fd20 in __pthread_cond_wait_common (abstime=0x0,
clockid=0, mutex=0x100019f84d0 , cond=0x100019f8498
) at ./nptl/pthread_cond_wait.c:503
spin = 0
buffer = {__routine = 0xfff800010288fa1c
<__condvar_cleanup_waiting>, __arg = 0xfff80001024db928, __canceltype
= -524287, __prev = 0x0}
cbuffer = {wseq = 4, cond = 0x100019f8498 ,
mutex = 0x100019f84d0 , private = 0}
Bug#1074782: sqitch: autopkgtests failing with new MariaDB 11.4
Hi Christian! Could you help with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074782? It might be the same root cause as for pdns in 1074780.
Bug#1074780: Acknowledgement (pdns-backend-mysql: autopkgtests use of mysql* commands don't work directly with new MariaDB 11.4 with mariadb-* commands)
Hi Marc and Christian! Just checking if you can help with debugging the pdns autopkgtest issues? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074780
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
Hi!
I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed
on sparc64.
Are there any sparc64 hackers interested in taking a look?
The build itself passed and most of the post-build passes, but some
tests cause the database to crash. Stack traces are visible in the
logs:
https://buildd.debian.org/status/fetch.php?pkg=mariadb=sparc64=1%3A11.4.2-2=1719891893=0
https://buildd.debian.org/status/logs.php?pkg=mariadb=sparc64
Example:
main.unsafe_binlog_innodbw2 [ fail ] timeout after 7200 seconds
Test ended at 2024-07-02 03:42:48
Test case timeout after 7200 seconds
== /<>/builddir/mysql-test/var/2/log/unsafe_binlog_innodb.log ==
connection h;
set autocommit = 0;
insert into t8 (select * from t2 for update);
connection i;
set autocommit = 0;
update t9 set e = (select b from t2 where a = d for update);
connection j;
set autocommit = 0;
create table t10(a int not null, b int, primary key(a)) select * from
t2 for update;
connection b;
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
connection c;
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
connection d;
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
connection e;
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
connection f;
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
connection g;
== /<>/builddir/mysql-test/var/2/tmp/analyze-timeout-mysqld.1.err
==
mysqltest: Could not open connection 'default' after 500 attempts:
2002 Can't connect to local server through socket
'/<>/builddir/mysql-test/var/tmp' (61)
- found 'core' (1/1)
Core generated by '/<>/builddir/sql/mariadbd'
Output from gdb follows. The first stack trace is from the failing thread.
The following stack traces are from all threads (so the failing one is
duplicated).
--
warning: Can't open file anon_inode:[io_uring] which was expanded to
anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file anon_inode:[io_uring] which was expanded to
anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file
/<>/builddir/mysql-test/var/2/mysqld.1/data/tc.log during
file-backed mapping note processing
[New LWP 969330]
[New LWP 969347]
[New LWP 969342]
[New LWP 969408]
[New LWP 969383]
[New LWP 971740]
[New LWP 969373]
[New LWP 972862]
[New LWP 972863]
[New LWP 972864]
[New LWP 971041]
[New LWP 972865]
[New LWP 972866]
[New LWP 972869]
[New LWP 969345]
[New LWP 972870]
[New LWP 969377]
[New LWP 972868]
[New LWP 969346]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
Core was generated by `/<>/builddir/sql/mariadbd
--defaults-group-suf'.
Program terminated with signal SIGABRT, Aborted.
#0 0xfff80001026928c0 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0xfff8000100036ca0 (LWP 969330))]
#0 0xfff80001026928c0 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
#1 0x01a85b74 in handle_fatal_signal (sig=6) at
./sql/signal_handler.cc:357
Backtrace stopped: Cannot access memory at address 0xf0
Thread 19 (Thread 0xfff800010e0018c0 (LWP 969346)):
#0 0xfff80001027092dc in syscall () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1 0xfff8000100902ff4 in ?? () from /lib/sparc64-linux-gnu/liburing.so.2
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 18 (Thread 0xfff8000102cea8c0 (LWP 972868)):
#0 0xfff800010268cc4c in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1 0xfff8000102690060 in pthread_cond_timedwait () from
/lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#2 0x016f9dac in psi_cond_timedwait (that=0x100019f5db8
, mutex=0x100019f5e28 ,
abstime=0xfff8000102ce9a40, file=0x10001049368 "./sql/thread_cache.h",
line=176) at ./mysys/my_thr_init.c:611
state = {m_flags = 256, m_operation = (unknown: 0x93ea64),
m_cond = 0x70001, m_mutex = 0xfff80001008d40c0, m_thread =
0xfff80001038c2d40, m_timer_start = 1719884508841233192, m_timer =
0x668376fc, m_wait = 0x22ba6f63}
locker = 0x0
result =
#3 0x0193efdc in inline_mysql_cond_timedwait
(src_file=0x10001049368 "./sql/thread_cache.h", src_line=176,
abstime=0xfff8000102ce9a40, mutex=, that=) at ./include/mysql/psi/mysql_thread.h:1086
No locals.
#4 Thread_cache::park (this=) at ./sql/thread_cache.h:176
error =
abstime = {tv_sec = 1719892008, tv_nsec = 582643000}
connect = 0x0
flushed =
abstime =
connect =
flushed =
_now_ =
error =
#5 do_handle_one_connection (connect=,
put_in_cache=true) at ./sql/sql_connect.cc:1450
create_user =
thr_create_utime =
thd = 0xfff800017c000c68
#6 0x0193f0cc in handle_one_connection (arg=)
at
Bug#1074670: Fwd: [debian-mysql] Processed: Re: amarok: FTBFS: unsatisfiable build-dependency: libmariadb-dev (= 1:10.11.8-1) but 1:11.4.2-1 is to be installed
Hi! This https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074670 is a result of the MariaDB build with the embedded server using excessive disk space. I have filed reverting MR at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/89 and asked upstream for advice in https://lists.mariadb.org/hyperkitty/list/develop...@lists.mariadb.org/thread/Y7J2OEUMEZEGVD23L5K5KTBABXF3H6VS/
Bug#1074566: mariadb-client-compat and mariadb-server-compat have an undeclared file conflict
Thanks for reporting this! There were Breaks/Replaces in place but they had a typo in version string. Fixed now, and also ran the check_for_missing_breaks.py script to with all previous versions ever released of MariaDB to ensure all scenarios are covered: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/db83a5a4112f6151d0d86d25adfe34be9329b841
Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration
Hi! > > Are you OK if I push this to https://salsa.debian.org/debian/rocksdb ? > Please do. I will try to answer other parts of your email today. I have now created and configured the RocksDB repository under the salsa.debian.org/debian project. As a token of acceptance that you are OK to use this as the place to host the source code going forward, please accept the Merge Request to update the Vcs-* fields: https://salsa.debian.org/debian/rocksdb If you want, I can also import the latest v9.3.1 version and submit a Merge Request of the import for you to review. - Otto
Bug#1074599: command-not-found: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 15: invalid continuation byte
Source: command-not-found
Version: 23.04.0-1
Severity: severe
Running /usr/lib/cnf-update-db failed on:
Traceback (most recent call last):
File "/usr/lib/cnf-update-db", line 32, in
col.create(db)
File "/usr/share/command-not-found/CommandNotFound/db/creator.py",
line 96, in create
self._fill_commands(con)
File "/usr/share/command-not-found/CommandNotFound/db/creator.py",
line 141, in _fill_commands
self._parse_single_contents_file(con, f, sub.stdout)
File "/usr/share/command-not-found/CommandNotFound/db/creator.py",
line 242, in _parse_single_contents_file
if not (l.startswith('usr/sbin') or l.startswith('usr/bin') or
^
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position
15: invalid continuation byte
The command is currently unusable.
I added a print statement and seems the parser is failing on file from aspell:
b'usr/lib/aspell/xh.dat\t\t\t\t\tuniverse/text/aspell-xh\n'
b'usr/lib/aspell/xh.multi\t\t\t\t\tuniverse/text/aspell-xh\n'
b'usr/lib/aspell/xh.rws\t\t\t\t\tuniverse/text/aspell-xh\n'
b'usr/lib/aspell/xhosa.alias\t\t\t\tuniverse/text/aspell-xh\n'
b'usr/lib/aspell/zu.dat\t\t\t\t\tuniverse/text/aspell-zu\n'
b'usr/lib/aspell/zu.multi\t\t\t\t\tuniverse/text/aspell-zu\n'
b'usr/lib/aspell/zu.rws\t\t\t\t\tuniverse/text/aspell-zu\n'
b'usr/lib/aspell/zulu.alias\t\t\t\tuniverse/text/aspell-zu\n'
b'usr/lib/aspell/\xedslenska.alias\t\t\t\tuniverse/text/aspell-is\n'
Traceback (most recent call last):
File "/usr/lib/cnf-update-db", line 32, in
col.create(db)
File "/usr/share/command-not-found/CommandNotFound/db/creator.py",
line 96, in create
self._fill_commands(con)
File "/usr/share/command-not-found/CommandNotFound/db/creator.py",
line 141, in _fill_commands
self._parse_single_contents_file(con, f, sub.stdout)
File "/usr/share/command-not-found/CommandNotFound/db/creator.py",
line 242, in _parse_single_contents_file
if not (l.startswith('usr/sbin') or l.startswith('usr/bin') or
^
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position
15: invalid continuation byte
This seems to be trigered by the i in "Islenska":
/usr/lib/aspell/íslenska.alias aspell-is
See
https://packages.debian.org/search?mode=path=bookworm=all=any=contents=slenska.alias
As a temporary workaround I used this try-statement:
def _parse_single_contents_file(self, con, f, fp):
# read header
suite=None # FIXME
for l in fp:
try:
l = l.decode("utf-8")
except UnicodeDecodeError:
continue
if not (l.startswith('usr/sbin') or l.startswith('usr/bin') or
l.startswith('bin') or l.startswith('sbin')):
continue
try:
command, pkgnames = l.split(None, 1)
except ValueError:
continue
Bug#1074558: Acknowledgement (mariadb: FTBFS on sparc64: Multiple tests fail network connection issues)
Control: retitle -1 mariadb: FTBFS on sparc64: Multiple tests crash / time out
Ignore the previous list of issues, it a mistake from wrong architecture.
The actual sparc64 build at
https://buildd.debian.org/status/fetch.php?pkg=mariadb=sparc64=1%3A11.4.2-1=1719764783=0
failed on timeouts/crashes from these tests:
main.partition w13 [ fail ]
main.backup_stages w8 [ fail ] timeout after 7200 seconds
main.mysqldump-timingw2 [ fail ] timeout after 7200 seconds
main.sp-i_s_columns w6 [ fail ] timeout after 7200 seconds
Example crash stack trace:
main.partition w13 [ fail ]
Test ended at 2024-06-30 14:16:16
CURRENT_TEST: main.partition
mysqltest: At line 3010: query 'select id from t1 where data = 'ab'
order by id' failed: (2013): Lost connection to server
during query
The result from queries just before the failure was:
< snip >
insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14,
'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ;
select id from t1 where data = 'ab' order by id;
id
4
5
6
14
15
16
drop table t1;
create table t1(id int unsigned not null,
data text default null,
key data_idx (data(1),id)
) default charset=utf8
partition by range (id) (
partition p10 values less than (10),
partition p20 values less than (20)
);
insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14,
'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ;
select id from t1 where data = 'ab' order by id;
More results from queries before failure can be found in
/<>/builddir/mysql-test/var/13/log/partition.log
- found 'core' (0/1)
Core generated by '/<>/builddir/sql/mariadbd'
Output from gdb follows. The first stack trace is from the failing thread.
The following stack traces are from all threads (so the failing one is
duplicated).
--
[New LWP 3099949]
[New LWP 3099936]
[New LWP 3099935]
[New LWP 3099937]
[New LWP 3099941]
[New LWP 3099908]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
Core was generated by `/<>/builddir/sql/mariadbd
--defaults-group-suf'.
Program terminated with signal SIGUSR1, User defined signal 1.
#0 0xfff80001028928c0 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0xfff80001024f68c0 (LWP 3099949))]
#0 0xfff80001028928c0 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
#1 0x01a85b74 in handle_fatal_signal (sig=10) at
./sql/signal_handler.cc:357
Backtrace stopped: Cannot access memory at address 0xf0
Thread 6 (Thread 0xfff8000100036ca0 (LWP 3099908)):
#0 0xfff800010290049c in poll () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x01735f44 in poll (__timeout=-1, __nfds=,
__fds=) at
/usr/include/sparc64-linux-gnu/bits/poll2.h:39
No locals.
#2 handle_connections_sockets () at ./sql/mysqld.cc:6324
sock = {fd = 12, is_unix_domain_socket = ,
is_extra_port = , address_family = ,
m_psi = 0x10002884700}
error_count = 0
cAddr = {ss_family = 1, __ss_padding =
"\001\000\002.\254\251\000\000\000\000\000\000\000\000\377\370\000\001\002\260\fH\000\000\a\376\377\352d\241\000\000\001\000\000s\177\230\000\000\000\000\000\000?p\000\000\001\000\001\004\226`\000\000\a\376\377\352d\241\000\000\001\000\000st@\000\000\a\376\377\352d\241\000\000\001\000\000sm@\000\000\000\a\000\000\000\000\377\370\000\001\000\035\223\300\377\370\000\001\003p6\300\027\335\315\330\n=\230\302",
__ss_align = 1099527935632}
retval =
fds = {array = {buffer = 0x1000289ad68 "", elements = 3,
max_element = 16, alloc_increment = 16, size_of_element = 8, m_psi_key
= 0, malloc_flags = 0}}
termination_fds = {32, 33}
event_fd = {fd = 32, events = 1, revents = 12600}
#3 0x017374e4 in mysqld_main (argc=,
argv=) at ./sql/mysqld.cc:6022
please_close_stdin =
ho_error =
new_thread_stack_size =
user =
#4 0xfff800010282f088 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#5 0xfff800010282f1a4 in __libc_start_main () from
/lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#6 0x01729000 in _start ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 5 (Thread 0xfff80001024a88c0 (LWP 3099941)):
#0 0xfff8000102846af0 in sigtimedwait () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x0172bed4 in my_sigwait (code=,
sig=, set=0xfff80001024a79e0) at
./include/my_pthread.h:191
siginfo = {si_signo = 7, si_errno = 4, si_code = -524287,
__pad0 = 122151936, _sifields = {_pad = {0, 0, 256, 36733056, -524287,
57708736, -524287, 57708736, 400412120, 149706496, 256, 16307856,
-524287, 57711104, 0, 0, -524287, 38433537, 256, 13217932, 0, 0, 0, 0,
0, 0, 0, 0}, _kill = {si_pid = 0, si_uid = 0}, _timer = {si_tid = 0,
Bug#1071428: Acknowledgement (mariadb: FTBFS on x32: size of array compile_time_assert is negative)
The upload of 1:11.4.2-1 still shows essentially the same error: [ 67%] Building C object tests/CMakeFiles/mariadb-client-test.dir/mysql_client_test.c.o cd /<>/builddir/tests && /usr/bin/cc -DHAVE_CONFIG_H -DMYSQL_CLIENT -D_FILE_OFFSET_BITS=64 -I/<>/libmariadb/include -I/<>/builddir/libmariadb/include -I/<>/wsrep-lib/include -I/<>/wsrep-lib/wsrep-API/v26 -I/<>/builddir/include -I/<>/include/providers -I/<>/include -I/<>/client -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall -Wdeclaration-after-statement -Wenum-compare -Wenum-conversion -Wextra -Wformat-security -Wmissing-braces -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Wvla -Wwrite-strings -std=gnu99 -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MT tests/CMakeFiles/mariadb-client-test.dir/mysql_client_test.c.o -MF CMakeFiles/mariadb-client-test.dir/mysql_client_test.c.o.d -o CMakeFiles/mariadb-client-test.dir/mysql_client_test.c.o -c /<>/tests/mysql_client_test.c In file included from /<>/tests/mysql_client_fw.c:17, from /<>/tests/mysql_client_test.c:38: /<>/tests/mysql_client_fw.c: In function ‘main’: /<>/include/my_global.h:384:18: error: size of array ‘compile_time_assert’ is negative 384 | typedef char compile_time_assert[(X) ? 1 : -1] __attribute__((unused)); \ | ^~~ /<>/tests/mysql_client_fw.c:1446:3: note: in expansion of macro ‘compile_time_assert’ 1446 | compile_time_assert(sizeof(MYSQL) == 1272); | ^~~ [ 67%] Linking CXX executable mariadb-binlog cd /<>/builddir/client && /usr/bin/cmake -E cmake_link_script CMakeFiles/mariadb-binlog.dir/link.txt --verbose=1 /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall -Wenum-compare -Wenum-conversion -Wextra -Wformat-security -Wmissing-braces -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,-z,relro,-z,now "CMakeFiles/mariadb-binlog.dir/mysqlbinlog.cc.o" -o mariadb-binlog ../libmariadb/libmariadb/libmariadb.a ../mysys/libmysys.a ../mysys_ssl/libmysys_ssl.a -lssl -lcrypto ../mysys/libmysys.a ../dbug/libdbug.a ../strings/libstrings.a ../mysys/libmysys.a ../dbug/libdbug.a ../strings/libstrings.a -lz -lm -ldl make[4]: *** [tests/CMakeFiles/mariadb-client-test.dir/build.make:79: tests/CMakeFiles/mariadb-client-test.dir/mysql_client_test.c.o] Error 1 make[4]: Leaving directory '/<>/builddir' make[3]: *** [CMakeFiles/Makefile2:10242: tests/CMakeFiles/mariadb-client-test.dir/all] Error 2
Bug#1053487: [debian-mysql] Bug#1053487: FTBFS update for MariaDB 10.11.5-3
With the upload of MariaDB 1:11.4.2-1, the hppa build is failing on openjdk-5-jre-headless dependency. The last 10.11 series build was successful up until the test suite fails on some tests having extra optimized debug info.
Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration
Hi! Check out https://salsa.debian.org/otto/rocksdb/ It has the import you did plus some tweaks: - branches follow DEP-14 and instead of 'master' and 'upstream' there is 'debian/latest' and 'upstream/latest' - the same repo is a fork of the upstream repo so that it is easy to cherry-pick/backport/upstream fixes from Debian to upstream or from unreleased upstream to Debian patches - config debian/gbp.conf has been created so you can run effortlessly 'gbp import-ref' etc commands and git-buildpackage automatically knows about correct branch names and upstream release tag naming scheme - there is no tarball import process configured, as upstream releases are pure tag releases (plus notes) at https://github.com/facebook/rocksdb/releases - also Salsa-CI added and ensured it passes (see https://salsa.debian.org/otto/rocksdb/-/pipelines) On my own local repo I have these remotes configured now so I can help you with maintenance on Salsa yet automatically push to GitHub as well: git remote -v origin g...@salsa.debian.org:otto/rocksdb.git (fetch) origin g...@salsa.debian.org:otto/rocksdb.git (push) origin g...@gitlab.com:ottok/rocksdb.git (push) origin g...@github.com:ottok/rocksdb.git (push) upstream https://github.com/facebook/rocksdb.git (fetch) upstream https://github.com/facebook/rocksdb.git (push) Are you OK if I push this to https://salsa.debian.org/debian/rocksdb ? Next time there is a release the commands to import would be: git fetch upstream --tags gbp import-ref --verbose --upstream-version 9.2.2 Does this make sense to you?
Bug#1073227: RM: galera-3/unstable -- RoM; obsoleted by galera-4
Package: ftp.debian.org Severity: normal Hi, Please remove src:galeara-3 from unstable. Galera 3 has been replaced by Galera 4, which has been available in unstable and testing for years. Ref: https://tracker.debian.org/pkg/galera-3 https://tracker.debian.org/pkg/galera-4
Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration
Good, looks like you got the hang of it. I will post my suggestion that involves having a config similar to https://salsa.debian.org/debian/entr/-/blob/debian/latest/debian/gbp.conf but upstream as 'main' and some other tweaks for easier long-term maintainability, along with explanation why my suggestion is what it is. Are you ok hosting the package in salsa.debian.org/debian namespace? Or at least mirror it there?
Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration
Hi! I am travelling and on slow internet. I will review and hopefully help you with feedback this weekend.
Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration
Hi! I can do the import on your behalf to spare you the effort of readig git-buildpackage docs. Thanks for confirming you are open to have package in git!
Bug#970043: Request to help test ia64 build for galera-4
Thanks Frank and others! I appreciate your assistance in testing the build. I will proceed to merge this before the next upload then. I just wanted to add here the regular Debian Developer's point of view: after every upload of every package I maintain, I always check the buildd status, investigate all build failures and try to get them working. As long as ia64 is among the build targets[1], I feel it is implied that DDs should try to get the build working. I have been sending bug reports to upstream and they have helped several times in making modifications to the source code to make all builds pass. If you some day in the future think that ia64 work is not valuable use of a regular DD's use of time, I'd appreciate seeing some announcement on debian-devel@ for example so that I and others know that we should invest our limited Debian time in other things. [1] https://buildd.debian.org/status/package.php?p=galera-4
Bug#1069802: bullseye-pu: package galera-4 26.4.18-0+deb11u1
I uploaded now with 'dput --delayed=7 ftp-master *.changes' as it is unlikely this will get any further review, nor need it as it is just a regular new minor upstream release. There is no tentative date at https://release.debian.org/ yet but at least this will be in -proposed after this.
Bug#1069639: Acknowledgement (bookworm-pu: package galera-4 26.4.18-0+deb12u1)
I uploaded now with 'dput --delayed=7 ftp-master *.changes' as it is unlikely this will get any further review, nor need it as it is just a regular new minor upstream release.
Bug#970043: Request to help test ia64 build for galera-4
Hi! I have a patch to tentatively fix Debian package galera-4 builds on ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19 Would anybody be interested in helping out and testing if the build fully passes now? Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043 Thanks! - Otto
Bug#1071699: [debian-mysql] Bug#1071699: mariadb-server: Moved mariadb socket, debian-start reports error connecting to old socket
Thanks for reporting! The lifecycle of /run should always be longer than the process existing. I think /run is cleared only on reboot. Contributions are welcome from you or anybody reading this bug report. If you have a patch (or not ideally Merge Request on Salsa) I am happy to review.
Bug#1071654: screenkey: Enable Salsa-CI
Package: screenkey
Severity: normal
Tags: patch
X-Debbugs-CC: wav...@thregr.org
This bug report is filed to notify that
https://salsa.debian.org/georgesk/screenkey/-/merge_requests/2.patch is
available.
Personally I would prefer all feedback to be posted at
https://salsa.debian.org/georgesk/screenkey/-/merge_requests/2 as
bugs.debian.org is very inefficient as a code review platform and you
can't see the CI results in the bug report anyway, and this patch is
to improve the CI.
From 79d1281af8236beeb08bdfa17615ecce91b872e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Otto=20Kek=C3=A4l=C3=A4inen?=
Date: Sat, 3 Jun 2023 16:37:51 -0700
Subject: [PATCH] Enable Salsa-CI
This will help ensure easily machine detectable regressions don't slip
into the code base.
This also makes any future contribution process faster and more
reliable, as any contributor submitting a Merge Request will get
immediate feedback, and the maintainers save time by not having to point
out basic mistakes.
---
debian/salsa-ci.yml | 9 +
1 file changed, 9 insertions(+)
create mode 100644 debian/salsa-ci.yml
diff --git a/debian/salsa-ci.yml b/debian/salsa-ci.yml
new file mode 100644
index 000..3de2c8b
--- /dev/null
+++ b/debian/salsa-ci.yml
@@ -0,0 +1,9 @@
+---
+include:
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+# If Salsa-CI is not running at
+# https://salsa.debian.org/%{project_path}/-/pipelines, ensure that
+# https://salsa.debian.org/%{project_path}/-/settings/ci_cd has in field "CI/CD
+# configuration file" filename "debian/salsa-ci.yml"
--
GitLab
Bug#1071495: closed by Colin Watson (Re: Bug#1071495: debbugs: Please enable Salsa-CI in Salsa repository)
For the record, https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 was not merged fully and the Salsa-CI is not yet passing, so I filed https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/20 which you can see in the MR status as CI passing.
Bug#1071495: debbugs: Please enable Salsa-CI in Salsa repository
Package: debbugs Severity: important With https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 the build is again passing and Lintian errors fixed, and Salsa-CI would be passing if it had been merged. The master branch has still build failures though and they are not evident to maintainers and contributors because the repository does not have Salsa-CI enabled. There are no email notifications about failing builds and https://salsa.debian.org/debbugs-team/debbugs/-/pipelines and is empty. Please consider enabling Salsa-CI for this repository to catch regressions early and to help maintain overall good code base health. Thanks!
Bug#1071494: debbugs: Revert "Salsa-CI: Allow autopkgtest to fail for now"
Package: apt Severity: important Tags: patch Please include https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/20.patch in debbugs. If you have feedback about the submission, please post it at https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/20 and allow me a couple of days to respond/polish the submission. The link above will also show if CI passed. The URL above will always contain the latest and best patch for this submission.
Bug#1071491: debbugs: Extend the user visible copyright notices with link to Salsa project
Package: apt Severity: normal Tags: patch Please include https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/6.patch in debbugs. If you have feedback about the submission, please post it at https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/6 and allow me a couple of days to respond/polish the submission. The link above will also show if CI passed. The URL above will always contain the latest and best patch for this submission.
Bug#1071490: apt: Enable Salsa-CI
Package: apt Severity: normal Tags: patch This bug report is filed to notify that https://salsa.debian.org/apt-team/apt/-/merge_requests/348.patch is available. Personally I would prefer all feedback to be posted at https://salsa.debian.org/apt-team/apt/-/merge_requests/348 as bugs.debian.org is very inefficient as a code review platform and you can't see the CI results in the bug report anyway, and this patch is to improve the CI.
Bug#1071428: mariadb: FTBFS on x32: size of array compile_time_assert is negative
Source: mariadb Version: 1:10.11.8-1 Forwarded: https://jira.mariadb.org/browse/MDEV-34195 Tags: confirmed, help, ftbfs User: debian-...@lists.debian.org Usertags: x32 X-Debbugs-CC: debian-am...@lists.debian.org After importing 10.11.8 in Debian, dropped the temporary patch and uploaded with the result that x32 is now failing (it wasn't failing on the previous 10.11.7-5 revision): https://buildd.debian.org/status/fetch.php?pkg=mariadb=x32=1%3A10.11.8-1=1716020141=0 [ 67%] Building C object tests/CMakeFiles/mariadb-client-test.dir/mysql_client_test.c.o cd /<>/builddir/tests && /usr/bin/cc -DHAVE_CONFIG_H -DMYSQL_CLIENT -D_FILE_OFFSET_BITS=64 -I/<>/libmariadb/include -I/<>/builddir/libmariadb/include -I/<>/wsrep-lib/include -I/<>/wsrep-lib/wsrep-API/v26 -I/<>/builddir/include -I/<>/include/providers -I/<>/include -I/<>/client -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall -Wdeclaration-after-statement -Wenum-compare -Wenum-conversion -Wextra -Wformat-security -Wmissing-braces -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Wvla -Wwrite-strings -std=gnu99 -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MT tests/CMakeFiles/mariadb-client-test.dir/mysql_client_test.c.o -MF CMakeFiles/mariadb-client-test.dir/mysql_client_test.c.o.d -o CMakeFiles/mariadb-client-test.dir/mysql_client_test.c.o -c /<>/tests/mysql_client_test.c In file included from /<>/tests/mysql_client_fw.c:16, from /<>/tests/mysql_client_test.c:38: /<>/tests/mysql_client_fw.c: In function ‘main’: /<>/include/my_global.h:384:18: error: size of array ‘compile_time_assert’ is negative 384 | typedef char compile_time_assert[(X) ? 1 : -1] __attribute__((unused)); \ | ^~~ /<>/tests/mysql_client_fw.c:1442:3: note: in expansion of macro ‘compile_time_assert’ 1442 | compile_time_assert(sizeof(MYSQL) == 1272); | ^~~ make[4]: *** [tests/CMakeFiles/mariadb-client-test.dir/build.make:79: tests/CMakeFiles/mariadb-client-test.dir/mysql_client_test.c.o] Error 1 make[4]: Leaving directory '/<>/builddir' This is a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063738 for tracking on x32 specifically as upstream fixed this issue on all other archs in https://jira.mariadb.org/browse/MDEV-33429.
Bug#1071245: gnupg2: package uninstallable in Debian Sid
Package:gnupg2 Version: 2.2.43-5 Severity: important (Sharing on debian-devel as gnupg2 is a core package and this breaks hundreds of reverse dependencies) Latest gnupg2 in Debian Sid cannot be installed. This also prevents all packages that depend on gpg to be installed as well. Personally I noticed this via devscripts installation failing: root@d3f13440934b:/tmp/test# apt update && apt install -y devscripts --no-install-recommends Get:1 http://deb.debian.org/debian sid InRelease [198 kB] Get:2 http://deb.debian.org/debian sid/main amd64 Packages [9876 kB] Fetched 10.1 MB in 5s (2205 kB/s) 35 packages can be upgraded. Run 'apt list --upgradable' to see them. Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: Unsatisfied dependencies: devscripts : Depends: gnupg but it is not installable or gnupg2 but it is not installable Error: Unable to correct problems, you have held broken packages. root@d3f13440934b:/tmp/test# apt update && apt install -y gnupg2 --no-install-recommends Hit:1 http://deb.debian.org/debian sid InRelease 35 packages can be upgraded. Run 'apt list --upgradable' to see them. Package gnupg2 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: gpgv Error: Package 'gnupg2' has no installation candidate root@d3f13440934b:/tmp/test# apt update && apt install -y gnupg --no-install-recommends Hit:1 http://deb.debian.org/debian sid InRelease 35 packages can be upgraded. Run 'apt list --upgradable' to see them. Package gnupg is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: gpgconf gpg gnupg-utils gnupg1 Error: Package 'gnupg' has no installation candidate This is perhaps related to the arch:all packages faling to build https://buildd.debian.org/status/fetch.php?pkg=gnupg2=all=2.2.43-5=1715908547=0 This is easily testable and using CI would have prevented this, as CI is now failing on the exact same thing at https://salsa.debian.org/otto/gnupg2/-/jobs/5735016 You can adopt CI by merging https://salsa.debian.org/debian/gnupg2/-/merge_requests/16, making sure the Salsa-CI passes, and only uploading after that. Thanks!
Bug#933032: Add Salsa-CI integration
Status: The MR https://salsa.debian.org/java-team/mariadb-connector-java/-/merge_requests/1 was merged 4 years ago but the project https://salsa.debian.org/java-team/mariadb-connector-java does not have pipelines enabled, and thus the Salsa-CI hasn't been running. I did confirm by running the CI at https://salsa.debian.org/mariadb-team/mariadb-connector-java/-/pipelines that it works, so there is no technical reason not to have CI enabled in the repository.
Bug#1069535: [debian-mysql] Bug#1069535: Bug#1069535: galera-3: FTBFS on armel: dh_auto_test: error: cd obj-arm-linux-gnueabi && make -j1 test ARGS\+=--verbose ARGS\+=-j1 ARGS=--output-on-failure retu
control: forward -1 https://github.com/codership/galera/issues/659 control: forwarded -1 https://github.com/codership/galera/issues/659
Bug#1069535: [debian-mysql] Bug#1069535: Bug#1069535: galera-3: FTBFS on armel: dh_auto_test: error: cd obj-arm-linux-gnueabi && make -j1 test ARGS\+=--verbose ARGS\+=-j1 ARGS=--output-on-failure retu
Forwarded: https://github.com/codership/galera/issues/659
Bug#1070160: libfmt: Please allow merge requests on Salsa
Package: libfmt Severity: wishlist Hi! Please allow CI and Merge Requests at https://salsa.debian.org/zhsj/fmtlib so that it is easier for others to contribute to the package. I would for example like to submit a Merge Request to include https://salsa.debian.org/otto/fmtlib/-/commit/07463212495f74196b6380423476827802a7be36 https://salsa.debian.org/otto/fmtlib/-/pipelines/672003 ..and some follow-up fixes.
Bug#1038435: libmariadb-java: Request to upgrade
Control: retitle -1 libmariadb-java: Request to upgrade to MariaDB Connector Java 3.x series Hi! Latest upstream version of MariaDB Connector Java is 3.3.3. Current version in Debian is 2.7.6-1. Do you have any plans to import the latest version to Debian? - Otto
Bug#1069895: [debian-mysql] Bug#1069895: mariadb-server: InnoDB to hang on systems with very intensive write loads when running out of I/O slots. This problem is fixed with MariaDB Server 10.11.7. Can
We can put 10.11.7 in Stable until it yas been accepted in Testing first. It is on the way though.
Bug#1069898: mariadb-server: Command History is shared for all users
Hi! Can you share more details what you mean? Perhaps steps to reproduce?
Bug#1053334: galera-4: FTBFS because of expired certificates
Bullseye oldstable update request filed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069802 You can +1 it if you want to show support.
Bug#1069802: bullseye-pu: package galera-4 26.4.18-0+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: mari...@packages.debian.org Control: affects -1 + src:galera-4 I propose that the latest minor maintenance version of Galera be included in the oldstable release update of Debian. Packaging source is ready at https://salsa.debian.org/mariadb-team/galera-4/-/tree/debian/bullseye and pending upload. ## Changelog galera-4 (26.4.18-0+deb11u1) bullseye; urgency=medium * Switch to upstream aware DEP-14 branch structure in gbp.conf * New upstream release 26.4.18. Includes multiple bug fixes, see https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.18.txt * For previous release details see https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.17.txt https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.16.txt https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.15.txt https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.14.txt * New upstream signing key 3D53839A70BC938B08CDD47F45460A518DA84635, verified from 26.4.17 release notes * New upstream release includes multiple Debian build and post-build test failure fixes: - Generate keys and certificates for SSL tests (Closes: #1053334) - Attempt to bind to UDP and skips tests if not available (Related: #1007954) - Fix 'uuid == WSREP_UUID_UNDEFINED' (Related: #970044) - Fix issues reported -Werror when compiling (Related: #970043) - Fix UBSAN issues (Closes: #1053183, Related: #970042) ## Debdiff A source debdiff is attached, which was created with commands: git diff --stat debian/26.4.14-0+deb11u1..debian/bullseye | xz > debian-26.4.18-0+deb11u1.debdiff.stat.xz git diff debian/26.4.14-0+deb11u1..debian/bullseye | xz > debian-26.4.18-0+deb11u1.debdiff.xz ## Quality control - Bookworm specific CI passed at https://salsa.debian.org/mariadb-team/galera-4/-/pipelines debian-26.4.18-0+deb11u1.debdiff.xz Description: application/xz debian-26.4.18-0+deb11u1.debdiff.stat.xz Description: application/xz
Bug#1053334: galera-4: FTBFS because of expired certificates
> What about bullseye, which is also a supported distribution? > > I have not reached the point where I want to do NMUs for these kind > of bugs, but if this were my package, I would certainly do an upload > for bullseye as well. If I can be of any help, please say so. This bug report was about Bookworm, but sure, we can do Bullseye as well. WIP at https://salsa.debian.org/otto/galera/-/commits/debian/bullseye If you want to help, you can file a MR on Salsa at any time or review existing open MRs. No need to do NMUs - the actual upload is not the work, but doing the commits and filing the stable-update bug reports to release manager.
Bug#1053334: galera-4: FTBFS because of expired certificates
I was able to reproduce this for Bookworm both locally and in CI at https://salsa.debian.org/mariadb-team/galera-4/-/jobs/5620032 After importing latest upstream build/test passes: https://salsa.debian.org/otto/galera/-/jobs/5624466 Stable upload request filed at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069639
Bug#1069639: bookworm-pu: package galera-4 26.4.18-0+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: mari...@packages.debian.org Control: affects -1 + src:galera-4 I propose that the latest minor maintenance version of Galera be included in the stable release update of Debian. Packaging source is ready at https://salsa.debian.org/mariadb-team/galera-4/-/tree/debian/bookworm and pending upload. ## Changelog galera-4 (26.4.18-0+deb12u1) bookworm; urgency=medium * Switch to upstream aware DEP-14 branch structure in gbp.conf * New upstream release 26.4.18. Includes multiple bug fixes, see https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.18.txt * For previous release details see https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.17.txt https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.16.txt https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.15.txt https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.14.txt * New upstream signing key 3D53839A70BC938B08CDD47F45460A518DA84635, verified from 26.4.17 release notes * New upstream release includes multiple Debian build and post-build test failure fixes: - Generate keys and certificates for SSL tests (Closes: #1053334) - Attempt to bind to UDP and skips tests if not available (Related: #1007954) - Fix 'uuid == WSREP_UUID_UNDEFINED' (Related: #970044) - Fix issues reported -Werror when compiling (Related: #970043) - Fix UBSAN issues (Closes: #1053183, Related: #970042) ## Debdiff A source debdiff is attached, which was created with commands: git diff --stat debian/26.4.13-1..debian/bookworm | xz > debian-26.4.18-0+deb12u1.debdiff.stat.xz git diff debian/26.4.13-1..debian/bookworm | xz > debian-26.4.18-0+deb12u1.debdiff.xz ## Quality control - Bookworm specific CI passed at https://salsa.debian.org/mariadb-team/galera-4/-/pipelines debian-26.4.18-0+deb12u1.debdiff.stat.xz Description: application/xz debian-26.4.18-0+deb12u1.debdiff.xz Description: application/xz
Bug#1069094: [debian-mysql] Bug#1069094: mariadb: FTBFS on hurd-i386
I converted this to MR at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/77 Waiting for CI to pass and for a second person to approve. Perhaps Daniel Black? Svante: Would you like to submit the two patches upstream as well?
Bug#1069535: [debian-mysql] Bug#1069535: galera-3: FTBFS on armel: dh_auto_test: error: cd obj-arm-linux-gnueabi && make -j1 test ARGS\+=--verbose ARGS\+=-j1 ARGS=--output-on-failure returned exit cod
Galera 25.3.37 was last release from upstream in 3.x series. I suspect the best resolution here is to wait a bit and then just file removal request for galera-3 in sid/trixie when we are confident there is no MariaDB 10.1/2/3 users out there anymore.
Bug#1053183: marked as done (galera-4: FTBFS on sparc64: one of sever post-build test fail)
This seems to be passing now with latest version: >From >https://buildd.debian.org/status/fetch.php?pkg=galera-4=sparc64=26.4.18-1%7Eexp1=1713134650=0: Running tests... /usr/bin/ctest --force-new-ctest-process --output-on-failure Test project /<>/obj-sparc64-linux-gnu Start 1: gu_tests 1/7 Test #1: gu_tests . Passed4.80 sec Start 2: gu_tests++ 2/7 Test #2: gu_tests++ ... Passed 18.70 sec Start 3: check_gcomm 3/7 Test #3: check_gcomm .. Passed6.97 sec Start 4: gcache_tests 4/7 Test #4: gcache_tests . Passed0.69 sec Start 5: gcs_tests 5/7 Test #5: gcs_tests Passed 11.46 sec Start 6: galera_check 6/7 Test #6: galera_check . Passed 20.74 sec Start 7: wsrep_test 7/7 Test #7: wsrep_test ... Passed0.03 sec 100% tests passed, 0 tests failed out of 7
Bug#970043: Info received (galera-4: FTBFS on ia64: [libgalera_smm.so] Error 1)
Status update: This exact same issue is still affecting ia64 builds for latest Galera 26.4.18 in Debian: https://buildd.debian.org/status/fetch.php?pkg=galera-4=ia64=26.4.18-1%7Eexp1=1713220669=0
Bug#1069094: [debian-mysql] Bug#1069094: mariadb: FTBFS on hurd-i386
Thanks Svante for the patches! I will test these next weekend.
Bug#1058671: [debian-mysql] Bug#1058671: mariadb-server: [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
Hi Daniel! Do you think this change is still needed? Do you want to participate in some open source development/testing to make it work? On Sun, 14 Jan 2024 at 16:03, Otto Kekäläinen wrote: > > FYI: Discussion about this continued in > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/61 >
Bug#1053334: galera-4: FTBFS because of expired certificates
Galera patch releases have been accepted as stable updates before. That is also what users expect. Thanks for reminding about this though, I yad forgotten about it. Will do it next weekend.
Bug#895570: devscripts: wrap-and-sort should default to -ast
Hi! > > The research done in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895570#50 looks good. > > > > Do we have now agreement to default to -ast or -astb for packages that have > > Debhelper 14+? > > I don't think making w-a-s defaults depend on the debhelper compat level was > considered, and I think we don't yet have a clear agreement on -st vs -ast. Thanks for the quick reply Paride. For the defaults, I see that '-a' is the most common option, so if the decision is between -st vs -ast, seems to me it should be the latter? I am not the decision maker here, but I would strongly vote for coupling the behavior with Debhelper 14+ usage so that we can add Lintian rules and Salsa-CI automation to suggest maintainers to run `wrap-and-sort -ast` on packages that haven't done it. By coupling the new defaults to a new Debhelper version we can keep wrap-and-sort "backward compatible" and avoid annoying people on current versions by having sudden changes in behavior. If changes apply only starting from a specific version, the transition will be smoother.
Bug#1060371: git-buildpackage: feature request: gbp sync
Today I filed https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/342
("Detect missing tags: force maintainer to continue tagging upload
commits if it was done before") which would be easy to implement if
something like `gbp sync` already existed.
Bug#895570: devscripts: wrap-and-sort should default to -ast
The research done in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895570#50 looks good. Do we have now agreement to default to -ast or -astb for packages that have Debhelper 14+?
Bug#1067491: time_t transition upgrade: failed systemctl call in preinst due to missing pre-dependencies
Thanks Wouter for reporting this and Michael for submitting a merge request for a potential fix! The libcrypto.so.3 is from the OpenSSL package. In your upgrade case it seems to be switching from libssl3 [i386] to libssl3t64 [i386]. Your MariaDB packages are amd64. This makes me wonder what is actually going on. Were you able to recover? Can you now run manually 'systemctl --system daemon-reload'? This is the line dpkg was most likely running: https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/mariadb-server.postinst#L289
Bug#1065787: 64-bit time_t transition: cargo needs manual intervention
Hi! Is anyone perhaps planning to fix cargo? For example curl isn't building on armel/armhf now and numerous packages that depend of curl are not building on armel/armhf. Thanks in advance to the person who steps up.
Bug#1066019: mariadb: FTBFS on hurd-i386: information_schema_disks.cc:69:31: error: ‘PATH_MAX’ was not declared in this scope
Source: mariadb
Version: 1:10.11.7-2
Tags: confirmed, help, ftbfs
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org
After fixing https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063739
the builds of MariaDB currently fail with:
[ 86%] Building CXX object
plugin/disks/CMakeFiles/disks.dir/information_schema_disks.cc.o
cd /<>/builddir/plugin/disks && /usr/bin/c++
-DHAVE_CONFIG_H -DMYSQL_DYNAMIC_PLUGIN -D_FILE_OFFSET_BITS=64
-Ddisks_EXPORTS -I/<>/wsrep-lib/include
-I/<>/wsrep-lib/wsrep-API/v26
-I/<>/builddir/include
-I/<>/include/providers -I/<>/sql
-I/<>/include -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC
-fstack-protector --param=ssp-buffer-size=4 -O2 -g -static-libgcc
-fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized
-fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall
-Wenum-compare -Wenum-conversion -Wextra -Wformat-security
-Wmissing-braces -Wno-format-truncation -Wno-init-self
-Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual
-Wnon-virtual-dtor -Wvla -Wwrite-strings -std=gnu++11 -fPIC
-Wdate-time -D_FORTIFY_SOURCE=2 -MD -MT
plugin/disks/CMakeFiles/disks.dir/information_schema_disks.cc.o -MF
CMakeFiles/disks.dir/information_schema_disks.cc.o.d -o
CMakeFiles/disks.dir/information_schema_disks.cc.o -c
/<>/plugin/disks/information_schema_disks.cc
/<>/plugin/disks/information_schema_disks.cc:69:31:
error: ‘PATH_MAX’ was not declared in this scope; did you mean
‘AF_MAX’?
69 | Column("Disk", Varchar(PATH_MAX), NOT_NULL),
| ^~~~
| AF_MAX
/<>/plugin/disks/information_schema_disks.cc:70:31:
error: ‘PATH_MAX’ was not declared in this scope; did you mean
‘AF_MAX’?
70 | Column("Path", Varchar(PATH_MAX), NOT_NULL),
| ^~~~
| AF_MAX
make[4]: *** [plugin/disks/CMakeFiles/disks.dir/build.make:79:
plugin/disks/CMakeFiles/disks.dir/information_schema_disks.cc.o] Error
1
make[4]: Leaving directory '/<>/builddir'
make[3]: *** [CMakeFiles/Makefile2:8478:
plugin/disks/CMakeFiles/disks.dir/all] Error 2
Full log at
https://buildd.debian.org/status/fetch.php?pkg=mariadb=hurd-i386=1%3A10.11.7-2=1709941524=0
Bug#1065787: cargo: 0.70.1+ds1-2+b1 FTBFS on armhf/armel due to uninstallable dependencies
Package: cargo Version: 0.70.1+ds1-2+b1 I noticed that the latest build (probably for 64-bit time_t) at https://buildd.debian.org/status/package.php?p=cargo=sid fails to build for armhf and armel. The armhf build complains about Extra-Depends: dpkg-dev (>= 1.22.5), gcc-13 (>= 13.2.0-16.1), libssl-dev (>= 3.1.5-1.1), but I checked and all of these exists in armhf, so not sure what is going on. For armel the latest gcc 13.2.0-18 didn't build, but the dependency version 13.2.0-16.1 did, so it should be all good. I am not sure what is going on here. Could it be that cargo has some special build-depend rules in debian/control etc. Filing this bug to make sure the packager is aware of the build being stuck. This issue currently blocks the builds of python-cryptography[1] on armel/armhf, which in turn blocks stunnel[2], which in turn blocks curl[3] which in turn blocks a dozen packages. [1] https://buildd.debian.org/status/package.php?p=python-cryptography=sid [2] https://buildd.debian.org/status/package.php?p=stunnel4=sid [3] https://buildd.debian.org/status/package.php?p=curl=sid
Bug#1037124: btop: amusingly high CPU temperature shown on 80 core arm64
Hi Philip! Thanks for reporting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037124 in Debian. The bug you describe is not due to anything in the Debian packaging, but most likely a common bug for upstream https://github.com/aristocratos/btop. Do you have experience in C++ development? Do you want to take a stab in the open source spirit to fix this issue yourself? This command-line tool is pretty simple, and building and rebuilding it yourself while testing that your changes work is relatively trivial if you have any C background. If you end up submitting a PR upstream, please mark this Debian bug as "Forwarded".
Bug#1012611: btop: Problems with rounding and locale when the string must be short. E.g. "1.87 GiB" -> " 1,0G"
Hi Marco! Thanks for reporting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012611 in Debian. The bug you describe is not due to anything in the Debian packaging, but most likely a common bug for upstream https://github.com/aristocratos/btop. Do you have experience in C++ development? Do you want to take a stab in the open source spirit to fix this issue yourself? This command-line tool is pretty simple, and building and rebuilding it yourself while testing that your changes work is relatively trivial if you have any C background. If you end up submitting a PR upstream, please mark this Debian bug as "Forwarded".
Bug#1065275: mariadb: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition
Since this is now the first time I noticed that new time_t should be available for testing and I started testing, I noticed that MariaDB has built-in check to prevent it from running on 2038 at all: # date Thu Mar 3 05:55:28 UTC 2039 # ./sql/mariadbd --version 2039-03-03 5:58:55 0 [ERROR] This server doesn't support dates later than 2038 Seems to stem from This is due to https://github.com/MariaDB/server/blob/11.5/sql/mysqld.cc#L3903-L3908 I am looking into this now as well.. On Sat, 2 Mar 2024 at 16:41, Otto Kekäläinen wrote: > > > > Could you Sebastian perhaps quickly skim through the commit that > > > implemented this > > > https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/8194544349982990fb2585c2a8c15c4db3904735 > > > and say if there might be something else missing as well? > > > > Did you mean > > https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/d2a0784f1e01b6613fefda17199a4e9867a126c3? > > > > At least for now that looks good. > > No I meant the original one, but you have now seen the original and > amendment and had no further comments, so seems good. > > I see Steven just uploaded curl 8.6.0-3.2 to fix the curl issues. I > will continue to wait a bit for the basic dependencies to stabilize, > for example this seems to affect many packages: > > libnsl2 depends on: > - libtirpc3:armel (>= 1.0.2) > libtirpc3t64 conflicts with: > - libtirpc3:armel (< 1.3.4+ds-1.1) > > I will upload new MariaDB as soon as I can verify that it is buildable.
Bug#1065275: mariadb: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition
> > Could you Sebastian perhaps quickly skim through the commit that > > implemented this > > https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/8194544349982990fb2585c2a8c15c4db3904735 > > and say if there might be something else missing as well? > > Did you mean > https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/d2a0784f1e01b6613fefda17199a4e9867a126c3? > > At least for now that looks good. No I meant the original one, but you have now seen the original and amendment and had no further comments, so seems good. I see Steven just uploaded curl 8.6.0-3.2 to fix the curl issues. I will continue to wait a bit for the basic dependencies to stabilize, for example this seems to affect many packages: libnsl2 depends on: - libtirpc3:armel (>= 1.0.2) libtirpc3t64 conflicts with: - libtirpc3:armel (< 1.3.4+ds-1.1) I will upload new MariaDB as soon as I can verify that it is buildable.
Bug#1062841: Bug#1065275: mariadb: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition
Currently MariaDB is not building[1] at all due to: ** mariadb build-depends on: - libcurl4-openssl-dev:amd64 libcurl4-openssl-dev depends on: - libcurl4t64:amd64 (= 8.6.0-3.1) mariadb build-depends on: - cmake:amd64 cmake depends on: - libcurl4:amd64 (>= 7.16.2) libcurl4t64 conflicts with: - libcurl4:amd64 (< 8.6.0-3.1) ** I can also see piuparts failing on broken libpam0t64[2] and a bunch of other tests failing various installability problems but seems they started before this upload, so they seem to happen only because many other packages right now during the transition have issues. Anyway I have the change[3] done in version control and I am ready to upload once I get some confirmation that this is now final. [1] https://buildd.debian.org/status/package.php?p=mariadb [2] https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/5393728 [3] https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/d2a0784f1e01b6613fefda17199a4e9867a126c3
Bug#1062841: Bug#1065275: mariadb: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition
Hi Sabastian! > * The package is built with the wrong ABI. > * The package migrates to testing before the change is enabled in > testing and builds there would be produced against the wrong ABI. > > Please add dpkg-dev (>= 1.22.5) to Build-Depends and upload the new > version ASAP. Thanks for following up with builds and transitions. I can do an upload quickly but would like to avoid having to do a third one, so: Could you Sebastian perhaps quickly skim through the commit that implemented this https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/8194544349982990fb2585c2a8c15c4db3904735 and say if there might be something else missing as well? Additional background info: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062841 - https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68
Bug#1062841: [debian-mysql] Bug#1062841: mariadb: NMU diff for 64-bit time_t transition
Ok, thanks for the clarification. I will merge https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68 then and upload to unstable within a couple of days. The MariaDB armhf and armel builds are broken due to regression in upstream anyway, so no transitions for this package will happen until I do the upload with the fix.
Bug#1062841: [debian-mysql] Bug#1062841: mariadb: NMU diff for 64-bit time_t transition
About this suggested change (penging at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68): >From the announcement message https://lists.debian.org/debian-devel-announce/2024/02/msg0.html lists we can find in https://people.canonical.com/~vorlon/armhf-time_t/source-packages lists: ``` mariadb: libmariadbd19 ``` However nothing about MariaDB is elsewhere. This finding about libmariadbd19 seems like a false positive as nothing depends on it. The library is used for building embedded servers and typically statically linked. I am not inclined to merge this change unless somebody points out some additional motivations why it is needed. If the libmariadb3 package was affected, it would be another story, but this libmariadbd19 is not worth renaming.
Bug#1062841: [debian-mysql] Bug#1062841: mariadb: NMU diff for 64-bit time_t transition
Hi Graham! I have your change pending at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68. Do you want me to put it into unstable now?
Bug#1063739: Bug#1006531: mariadb: FTBFS on hurd-i386: cmake/plugin.cmake: Plugin AUTH_SOCKET cannot be built
Thanks Daniel! Pushed to https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/70 for additional testing/review
Bug#1062841: [debian-mysql] Bug#1062841: Bug#1062841: mariadb: NMU diff for 64-bit time_t transition
Hi! I did additional testing and converted the attached patch into a MR ready to be merged on the debian/latest branch and uploaded to unstable: https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68 Seems the experimental builds for MariaDB went OK. Let me know when is the correct time to upload this to unstable.
Bug#1052519: New upstream version 7.2
Thanks for maintaining this package in Debian, it is very useful! Could you please update it to latest version 7.2 so both Trixie and also Ubuntu 24.04 will ship with a fresh version? Thanks
Bug#1062841: [debian-mysql] Bug#1062841: mariadb: NMU diff for 64-bit time_t transition
Hi! Please do not do non-maintainer-uploads. This package is actively maintained, we can just include your patch in the next upload in a couple of days. On Sat, 3 Feb 2024 at 11:57, Graham Inggs wrote: > > Source: mariadb > Version: 1:10.11.6-2 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > mariadb as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for mariadb > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: unable to detect > ___ > pkg-mysql-maint mailing list > pkg-mysql-ma...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint
Bug#1006531: [debian-mysql] Bug#1006531:
Thanks! This is pending now at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/66
Bug#1061348: [debian-mysql] Bug#1061348: mariadb: install PAM modules and systemd unit files into /usr
I opened an MR about this one at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/65 to get CI validation. I will do some more testing over the weekend and then merge both. Thanks for your contribution!
Bug#1061348: [debian-mysql] Bug#1061348: mariadb: install PAM modules and systemd unit files into /usr
Thanks, I wil check all occurrences of /lib after https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/29 has been approved and merged. Your review on that one would be appreciated.
Bug#1028273: [debian-mysql] Bug#996706: mariadb-server-10.5: run directory is not created in multi-instance mode
Hi Peter and Toby! The issues about systemd are potentially fixed in https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/29 Please test it (you can download the .deb packages from the pipeline build artifacts (https://salsa.debian.org/otto/mariadb-server/-/pipelines/628913) and let me know how it went. If I get validation that it works now, I will upload this to Debian and make the bugs you reported as fixed. Thanks!
Bug#1060056: mariadb-server: mariadb-hotcopy fails for performance_schema and sys
Control: forwarded -1 https://github.com/MariaDB/server/pull/2995 This will be fixed in Debian next month when MariaDB 10.11.7 releases
Bug#1057180: Info received (bullseye-pu: package mariadb-10.5 1:10.5.23-0+deb11u1)
Hi oldstable release managers, I got email after my upload 11 days ago that 10.5.23 was accepted in oldstable-proposed-updates but I don't see any updates under 'News' at https://tracker.debian.org/pkg/mariadb-10.5 yet. Is the update progressing automatically somewhere?
Bug#747824: RFP: atom -- hackable editor
Control: outlook -1 Superseded by Pulsar ITP #1060778 Seems there was a lot of interest in this Atom ITP. I just wanted to let you know that I filed an ITP[1] for packaging Pulsar, which superseded Atom[2]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060778 [2] https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/
Bug#702162: RFP: estonianidcard -- Metapackage installing all the packages for Estonian ID card support
Hi! On a quick review of the deb packages offered at https://www.id.ee/en/article/install-id-software/ and the related source code https://github.com/open-eid and documentation https://open-eid.github.io/ I did not spot any reason why it could not be properly packaged for Debian officially. If this RFP had more +1's I might do it. Are there enough Debian/Ubuntu users in Estonia to justify the effort?
Bug#842420: Status of packaging Electron?
Hi! I am a big fan of Pulsar[1] so I filed the ITP[2] for it which led me to dive into the status of Electron[3] and NodeJS and JavaScript in Debian in general. Electron seems already to be shipped[4] among others in FreeBSD ports, Arch, Manjaro, Nix and OpenSUSE, but not in Fedora or Debian. The approach in Debian seems to be that each npm module is converted into a deb package, and thus the JS team has 1700+ packages to maintain[5]. Electron packaging has been pending for the past 7 years due to this packaging dependency requirement I assume. So I guess the logical next step is just to map out all dependencies of Electron (and Pulsar) and then simply get each npm module they depend on packaged one-by-one? Can somebody who has a working setup of js_task_edit.py[6] update the Electron wiki page and also create a new one for Pulsar? And once we have the list we can start using npm2deb[7] and following the NodeJS packaging guide[8] we just package the modules and see how far we get with reasonable effort? - Otto [1] https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/ [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060778 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842420 [4] https://repology.org/project/electron/versions [5] https://qa.debian.org/developer.php?login=pkg-javascript-de...@lists.alioth.debian.org [6] https://wiki.debian.org/Javascript/Nodejs/Tasks [7] https://wiki.debian.org/Javascript/Nodejs/Npm2Deb [8] https://wiki.debian.org/Javascript/Nodejs/Manual
Bug#1058671: [debian-mysql] Bug#1058671: mariadb-server: [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
FYI: Discussion about this continued in https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/61
Bug#1060778: ITP: pulsar-edit -- A Community-led Hyper-Hackable Text Editor (formerly Atom)
Package: wnpp Severity: wishlist Owner: Otto Kekäläinen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pulsar-edit Version : 1.112.1 Upstream Contact: ad...@pulsar-edit.dev * URL : https://pulsar-edit.dev/ * License : MIT Programming Lang: JavaScript Description : A Community-led Hyper-Hackable Text Editor Anyone can test the app using upstream package https://download.pulsar-edit.dev/?os=linux=linux_deb which installs everything in /opt/Pulsar/. This is an Electron app and I am looking for advice from other NodeJS and Electron app maintainers on how to package this properly in Debian.
Bug#1035725: rdiff-backup bug
On Sat, 20 May 2023 at 12:24, Henrik Riomar wrote: > > Reproduction of the bug is simple with safekeep from a system running Debian > 11 trying to backup a system running Debian 12. > > The backup can not even start, just get "Exception ''restrict_path'' raised > of class ''" from rdiff-backup on Debian 12. > > Full back-trace from safekeep in the upstream bug report here: > https://github.com/rdiff-backup/rdiff-backup/issues/872 Looking at https://github.com/rdiff-backup/rdiff-backup/issues/872 this was fixed in latest rdiff-backup, which is now available in Debian unstable. If you can confirm that this version fixes the issue, I can backport it to Debian Bookworm as well.
