Bug#1082099: Change default config pour cyrus-imapd
Package: cyrus-imapd
Architecture: amd64
Version: 3.6.1-4+deb12u3
Severity: minor
The configuration file /etc/cyrus.conf from the package cyrus-imapd begin
with
START {
# do not delete this entry!
recover cmd="/usr/sbin/cyrus ctl_cyrusdb -r"
# this is only necessary if idlemethod is set to "idled" in imapd.conf
#idled cmd="idled"
# this is useful on backend nodes of a Murder cluster
# it causes the backend to synchronize its mailbox list with
# the mupdate master upon startup
#mupdatepush cmd="/usr/sbin/cyrus ctl_mboxlist -m"
# this is recommended if using duplicate delivery suppression
delprunecmd="/usr/sbin/cyrus expire -E 3"
# this is recommended if caching TLS sessions
tlsprunecmd="/usr/sbin/cyrus tls_prune"
}
with this two lines:
delprunecmd="/usr/sbin/cyrus expire -E 3"
tlsprunecmd="/usr/sbin/cyrus tls_prune"
the cyrus daemon would wait those two starting commands to be ended before
starting anything else.
Knowing the delprune can take long time (90 minutes for 3000 accounts),
it's not usable.
If you check the official documentation :
https://www.cyrusimap.org/imap/reference/manpages/configs/cyrus.conf.html
you can see in the “Examples” section the delprune are in the
EVENTS {
checkpointcmd="ctl_cyrusdb -c" period=30
delprune cmd="cyr_expire -E 3" at=0400
tlsprune cmd="tls_prune" at=0400
}
so no blocking when the service start.
It would be help to follow the official config who can work in much more
case than the one provided by debian package.
And they are not any downside of the official configuration, the «delprune»
would be running every day at 0400 instead one time at starting.
regards
Bug#827306:
Здравейте, добър ден, реших да се свържа с вас отново, след като се свързах с вас преди няколко месеца. Аз съм адвокат Албърт Доу, свържете се с мен за спешна дискусия. благодаря
Bug#1024167: Günaydın saygılarımla Bu e-postayı aldığınızda şaşıracağınızı biliyorum, ben Doe ve Doe odalarından avukat Albert Doe. Ülkemdeki bir bankada büyük bir fon değerinde olan merhum müşterimin
Bug#1055510: Best way to coordinate this fix
On Thu, Nov 9 2023 at 12:13:25 AM +01:00:00, Simó Albert i Beltran wrote: Please take a look at https://salsa.debian.org/debian/molly-guard/-/commit/c1120c0c3602955abe02d4d810985ad13d02cdba Sorry, I meant https://salsa.debian.org/debian/molly-guard/-/commit/c1120c0c3602955abe02d4d810985ad13d02cdba#note_440065
Bug#1055510: Best way to coordinate this fix
Please take a look at https://salsa.debian.org/debian/molly-guard/-/commit/c1120c0c3602955abe02d4d810985ad13d02cdba
Bug#1054595: ITP: nom -- command line tool that helps you lose weight
> Op 26-10-2023 17:07 CEST schreef Holger Levsen : > > > Package: wnpp > Severity: wishlist > Owner: Holger Levsen > X-Debbugs-Cc: debian-de...@lists.debian.org, m...@blinry.org > > * Package name: nom > Version : 0.1.3 > * URL : https://github.com/blinry/nom > * License : GPL2+ > Programming Lang: Ruby > Description : command line tool that helps you lose weight > > nom is a command line tool that helps you lose weight by tracking your energy > intake and creating a negative feedback loop. It's inspired by John Walker's > The Hacker's Diet (https://www.fourmilab.ch/hackdiet/) and tries to automate > things as much as possible. > > > I'm using this myself and plan to maintain it in the debian group on salsa. > > > -- > cheers, > Holger > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org > ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C > ⠈⠳⣄ > > In a world where you can be anything, be kind.
Bug#1039051: RFA: gforth -- GNU Forth Language Environment
Maybe post this in comp.lang.forth. The gforth maintainers hang out there. An update is long overdue, but my impression is that they don't work with approved releases, only nightly builds. It is unclear how that fits in with Debian. Greetings. > Op 25-06-2023 06:50 CEST schreef Peter Pentchev : > > > Package: wnpp > Severity: normal > X-Debbugs-Cc: gfo...@packages.debian.org, r...@debian.org > Control: affects -1 + src:gforth > > I request an adopter for the gforth package. Turns out that in the past > couple of years I have not given it enough care and attention. > > There is a Git repository containing all my Debian packaging work at > https://gitlab.com/gforth/pkg-debian-full > > The package was in good shape at the time of its last update, but > things have moved on since then. Notably, I tried to bring in some > new upstream beta versions every now and then, but they failed their > build-time tests, and it would appear overly optimistic to keep > pretending that I will track those test failures down. > > The package description is: > This is the GNU'ish implementation of a Forth programming environment. > . > Forth, as a language, is best known for being stack-based, and completely > extensible. Each Forth environment provides one or more dictionaries of > pre-defined words, and programming in Forth consists of defining and > executing new words that are combinations of previously defined words. It > has been said that learning Forth changes forever the way you think about > writing programs. > . > For more information about Forth, visit the Forth Interest Group web site > at http://www.forth.org/fig.html. > > Thanks in advance to whomever picks this package up!
Bug#1003868: Debian 11
In response to the bug report that covers 2.9.3-1+deb10u1: Is 2.9.3-3+deb11u1 built with the option --enable-collection-global-lock? Best, Albert van der Veen
Bug#1026965: ACPI Error: Needed [Integer/String/Buffer], found [Package]
noowner 1026965 thanks I don't have the laptop at my disposal any longer. Please someone else take ownership of the bug. Albert.
Bug#1032974: initial-window-size-chars=80x25 in foot.ini doesn't take the data from the current monitor but from the primary one if the monitors have different resolution
Package: foot Version: 1.6.4-1 How to reproduce: 1. Make sure that two different-resolution monitors are connected. 2. Start gnome with wayland from gdm3 and ensure that the high-resolution monitor is the primary one. 3. Open a uxterm window on the high-resolution monitor. 4. Put initial-window-size-chars=80x25 into ~/.config/foot/foot.ini . 5. Make xterm the current window (on the hi-res monitor) and then move the mouse pointer away from it (on the low-res monitor) without any mouse clicks. 6. Using your keyboard, start foot from the uxterm window. 7. Notice that the foot window automatically opens on the low-resolution monitor (because the mouse cursor is there). 8. Observe that 93 columns fit into the new foot window (see the screeshot). We expect the width to be, on the contrary, 80 columns upon start. (To be fair, we do get 80 when you move the foot window to the hi-res monitor.) Debug output in the uxterm window: $ foot & $ info: main.c:356: version: 1.6.4 +ime info: main.c:363: arch: x86_64/64-bit info: main.c:367: locale: de_DE.UTF-8 info: config.c:2117: loading configuration from /home/malkis/.config/foot/foot.ini info: wayland.c:1169: DP-1: 2560x1440+0x0@60Hz DELL U2715H 27.15" scale=1 PPI=111x110 (physical) PPI=111x110 (logical), DPI=108.18 info: wayland.c:1169: DP-4: 1920x1200+2560x0@60Hz SyncMaster 24.04" scale=1 PPI=96x100 (physical) PPI=96x100 (logical), DPI=94.19 info: wayland.c:1169: DP-7: 1920x1200+4480x0@60Hz SM2443DW 24.04" scale=1 PPI=96x100 (physical) PPI=96x100 (logical), DPI=94.19 warn: wayland.c:1330: no decoration manager available - using CSDs unconditionally info: fcft.c:245: fcft: 2.3.1 info: fcft.c:255: fontconfig: 2.13.1 info: fcft.c:261: freetype: 2.10.4 info: fcft.c:671: info: /usr/share/fonts/truetype/dejavu/DejaVuSansMono-BoldOblique.ttf: size=8.00pt/12px, dpi=108.18 fcft.c:671: /usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf: size=8.00pt/12px, dpi=108.18 info: fcft.c:671: /usr/share/fonts/truetype/dejavu/DejaVuSansMono-Oblique.ttf: size=8.00pt/12px, dpi=108.18 info: fcft.c:671: /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf: size=8.00pt/12px, dpi=108.18 info: terminal.c:631: cell width=7, height=15 info: terminal.c:569: using 8 rendering threads We think that some system packages might hypothetically be involved (because other applications such as firefox also show strange behaviour when getting moved between different-resolution screens) but are unsure who exactly is the culprit. (Speculating, the interface could also be a problem.)
Bug#1030691: Evince crashes on an unreadable nonempty postscript file owned by root
Package: evince Version: 3.38.2-1 I run an up-to-date Debian GNU/Linux 11 “bullseye” with wayland. This is how to reproduce the crash from a terminal emulator (I tried xterm, gnome-terminal, and foot): root@host:/tmp# rm mwe.ps root@host:/tmp# echo "test" > mwe.ps root@host:/tmp# chmod g-rwx,o-rwx mwe.ps root@host:/tmp# exit logout user@host:/tmp$ evince mwe.ps Segmentation fault An expected outcome would be a meaningful error message instead of a segfault. The same bug on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1910421 https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1910421. Thanks in advance for repairing this bug.
Bug#1026965: ACPI Error: Needed [Integer/String/Buffer], found [Package]
Btw., the number after “found [Package]” in the dmesg output might change depending on the boot (now the date and time are different and the docking station is not attached). Now this number is 10f955a8.
Bug#1026965: ACPI Error: Needed [Integer/String/Buffer], found [Package]
Below you find a portion of the output of system information from Windows 11 concerning the hardware of the laptop (in German; please feel free to ask for translation into English if needed): Systemhersteller LENOVO Systemmodell 20T1S8EJ00 Systemtyp x64-basierter PC System-SKU LENOVO_MT_20T1_BU_Think_FM_ThinkPad T14s Gen 1 Prozessor Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 2304 MHz, 4 Kern(e), 8 logische(r) Prozessor(en) BIOS-Version/-Datum LENOVO N2YET35W (1.24 ), 09.07.2022 SMBIOS-Version 3.2 Version des eingebetteten Controllers 1.14 BIOS-Modus UEFI BaseBoard-Hersteller LENOVO BaseBoard-Produkt 20T1S8EJ00 BaseBoard-Version SDK0R32862 WIN Plattformrolle Mobil Sicherer Startzustand Ein PCR7-Konfiguration Erweiterung zum Anzeigen erforderlich
Bug#1026965: ACPI Error: Needed [Integer/String/Buffer], found [Package]
Typo: … As many updates have been installed in the past, … As many updates were installed in the past, …
Bug#1026965: ACPI Error: Needed [Integer/String/Buffer], found [Package]
tags 1026965 - moreinfo thanks -- Thanks for a quick reaction! The kernel.org report you've mentioned concerns a somewhat different error message. As of the submission time and right now, no updates are available for my computer in Windows. Both "System Update" of Lenovo (cf. the screenshot in the attachment) and built-in "Windows Update" (including "Optional Updates") have been checked. As many updates have been installed in the past, my interpretation is that the system is up to date now. Albert. These might indicate a firmware issue, cf. eg. the older https://bugzilla.kernel.org/show_bug.cgi?id=199983 https://bugzilla.kernel.org/show_bug.cgi?id=199983. Can you please check if there are further firwmare updates available for your device from Lenovo?
Bug#1026965: ACPI Error: Needed [Integer/String/Buffer], found [Package]
Package: linux-image-5.10.0-20-amd64 Version: 5.10.158-2 How to reproduce: 1) Boot Debian GNU/Linux 11 (bullseye), which is „stable“ now, on Lenovo ThinkPad T14s Gen 1 with Intel Core i7-10610U. 2) Search for „Error“ in the output of dmesg. 3) Find ACPI Error: Needed [Integer/String/Buffer], found [Package] 0b621212 (20200925/exresop-469) [ 4.387053] ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20200925/dswexec-431) [ 4.387198] ACPI Error: Aborting method \ADBG due to previous error (AE_AML_OPERAND_TYPE) (20200925/psparse-529) [ 4.387346] ACPI Error: Aborting method \_SB.HIDD._DSM due to previous error (AE_AML_OPERAND_TYPE) (20200925/psparse-529) [ 4.387486] ACPI: \_SB_.HIDD: failed to evaluate _DSM (0x3003) The anonymized prefix of the dmesg output till this error is attached. Now, since we see an “error”, we wonder what exactly goes wrong. How do we translate this into plain English? What exactly should we worry about? Thanks in advance, Albert [0.00] Linux version 5.10.0-20-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.158-2 (2022-12-13) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-20-amd64 root=UUID=994be375-5bdc-4b91-b60b-00f80de5f90b ro quiet [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x9a681fff] usable [0.00] BIOS-e820: [mem 0x9a682000-0x9e85] reserved [0.00] BIOS-e820: [mem 0x9e86-0x9fbe9fff] ACPI NVS [0.00] BIOS-e820: [mem 0x9fbea000-0x9fc4efff] ACPI data [0.00] BIOS-e820: [mem 0x9fc4f000-0x9fc4] usable [0.00] BIOS-e820: [mem 0x9fc5-0xa7ff] reserved [0.00] BIOS-e820: [mem 0xa800-0xa8bf] usable [0.00] BIOS-e820: [mem 0xa8c0-0xae7f] reserved [0.00] BIOS-e820: [mem 0xfed2-0xfed7] reserved [0.00] BIOS-e820: [mem 0x0001-0x00084d7f] usable [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0x77e46018-0x77e56057] usable ==> usable [0.00] e820: update [mem 0x77e46018-0x77e56057] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x0009efff] usable [0.00] reserve setup_data: [mem 0x0009f000-0x000f] reserved [0.00] reserve setup_data: [mem 0x0010-0x77e46017] usable [0.00] reserve setup_data: [mem 0x77e46018-0x77e56057] usable [0.00] reserve setup_data: [mem 0x77e56058-0x9a681fff] usable [0.00] reserve setup_data: [mem 0x9a682000-0x9e85] reserved [0.00] reserve setup_data: [mem 0x9e86-0x9fbe9fff] ACPI NVS [0.00] reserve setup_data: [mem 0x9fbea000-0x9fc4efff] ACPI data [0.00] reserve setup_data: [mem 0x9fc4f000-0x9fc4] usable [0.00] reserve setup_data: [mem 0x9fc5-0xa7ff] reserved [0.00] reserve setup_data: [mem 0xa800-0xa8bf] usable [0.00] reserve setup_data: [mem 0xa8c0-0xae7f] reserved [0.00] reserve setup_data: [mem 0xfed2-0xfed7] reserved [0.00] reserve setup_data: [mem 0x0001-0x00084d7f] usable [0.00] efi: EFI v2.70 by Lenovo [0.00] efi: TPMFinalLog=0x9fbe2000 SMBIOS=0x9cc83000 SMBIOS 3.0=0x9cc76000 ACPI=0x9fc4e000 ACPI 2.0=0x9fc4e014 MEMATTR=0x9602d018 ESRT=0x9b107000 MOKvar=0x9601d000 RNG=0x9fc4d018 TPMEventLog=0x77e57018 [0.00] efi: seeding entropy pool [0.00] random: crng init done [0.00] Kernel is locked down from EFI Secure Boot; see man kernel_lockdown.7 [
Bug#1025333: Notification with connection failure pops up despite Internet
Package: gnome Version: 1:3.38+3 My laptop is connected to the Internet via an Ethernet cable, which is what I currently want. Connections via WiFi are in general possible but today, they fail (probably because too many clients try to connect to a public wireless network), cf. the screenshot in the attachment. This failure doesn't hurt me. Still, despite already having Internet access via cable, the latop apparently tries to connect via WiFi and fails, displaying the notification with title “Verbindung gescheitert” (German for “connection failed”) and smaller text “Aktivierung der Netzverbindung ist gescheitert” (German for “activation of a network connection has failed”) every few minutes. This popup alone alone hurts. How to turn it off (without turning off the WiFi)? Moreover, it is probably useless or even harmful in general to _automatically_ try to establish another Internet connection when there's one already. More data: $ sudo cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile [ifupdown] managed=false Thx in advance Albert
Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'
Simon, thanks, this worked for me: Workaround: also upgrade samba-libs to the version from testing … It pulled, I think, also a new version of libc6. Now I finally have control :-). And also thanks for cleaning up the “Package:” mess I inadvertently created. Cheers! Albert
Bug#1021371: (no subject)
severity 1021371 important affects 1021371 - control: affects 1021371 - severity: affects 1021371 - important affects 1021371 - affects affects 1021371 - version: affects 1021371 - -1 affects 1021371 - 1:3.38.4-1 thanks Some more data: $ sudo aptitude show libsmbclient | grep Version Version: 2:4.13.13+dfsg-1~deb11u5 $ sudo aptitude show samba-libs | grep Version Version: 2:4.13.13+dfsg-1~deb11u5 (Sorry for the mess with the header: I tried my best to say that exactly two packages are affected: gnome-control-center and samba-libs. Something went wrong with the header https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1021371;msg=5 https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1021371;msg=5; I don't know what.)
Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'
Package: gnome-control-center Version: 1:3.38.4-1 Severity: important Control: affects -1 samba-libs The control center starts neither from gnome (Alt+F1 > Settings) nor from an xterm. In the last case, we get some (hopefully, useful) output: $ gnome-control-center gnome-control-center: /lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4' not found (required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0) $ (I presume that some dependencies of samba-libs or gnome-control-center are outdated or simply wrong.) The system is Debian stable 11 “bullseye” with a few updated packages from Debian testing. I'd be happy if this bug report finds attention soon because the package, as of now, is useless to me: the control center won't start (e.g., I have no means to adjust printers or screens). Thanks in advance, Albert
Bug#1016213: You can close this
I figured out i was doing things wrong (compiling with libc++ and them removing it manually form compile_commands.josn) so this is a PBKAC please close the bug report.
Bug#1016213: clang-tidy-14: clang-tidy aborts when run
Package: clang-tidy-14 Version: 1:14.0.6-2 Severity: normal X-Debbugs-Cc: aa...@kde.org Running clang-tidy-14 asserts, example I have run the same in archlinux clang-tidy-14 and it does not assert, so I think it may be a Debian specific issue clang-tidy-14 --use-color -p=/tmp/poppler_build /builds/aacid/poppler/poppler/NameToCharCode.cc PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: clang-tidy-14 --use-color -p=/tmp/poppler_build /builds/aacid/poppler/poppler/NameToCharCode.cc 1. parser at end of file Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): /usr/lib/x86_64-linux-gnu/libLLVM-14.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x31)[0x7f003d286a71] /usr/lib/x86_64-linux-gnu/libLLVM-14.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0xee)[0x7f003d2847be] /usr/lib/x86_64-linux-gnu/libLLVM-14.so.1(+0xea5fa6)[0x7f003d286fa6] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12200)[0x7f004657d200] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZNK5clang4Stmt9getEndLocEv+0xb)[0x7f0043bae89b] clang-tidy-14(_ZN5clang4tidy11readability27BracesAroundStatementsCheck13findRParenLocINS_6IfStmtEEENS_14SourceLocationEPKT_RKNS_13SourceManagerEPKNS_10ASTContextE+0x54)[0xa74404] clang-tidy-14(_ZN5clang4tidy11readability27BracesAroundStatementsCheck5checkERKNS_12ast_matchers11MatchFinder11MatchResultE+0x240)[0xa73c00] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x109f717)[0x7f0043de2717] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZN5clang12ast_matchers8internal21BoundNodesTreeBuilder12visitMatchesEPNS2_7VisitorE+0x12c)[0x7f0043e1419c] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x109f197)[0x7f0043de2197] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x10acd85)[0x7f0043defd85] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x10aacf9)[0x7f0043dedcf9] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x10d0ab1)[0x7f0043e13ab1] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x10a7082)[0x7f0043dea082] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x10a1aa4)[0x7f0043de4aa4] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x10a324b)[0x7f0043de624b] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x10a1471)[0x7f0043de4471] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x10a97ab)[0x7f0043dec7ab] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(+0x10a16cf)[0x7f0043de46cf] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZN5clang12ast_matchers11MatchFinder8matchASTERNS_10ASTContextE+0x367)[0x7f0043db5b17] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZN5clang17MultiplexConsumer21HandleTranslationUnitERNS_10ASTContextE+0x2c)[0x7f00452c9bbc] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZN5clang8ParseASTERNS_4SemaEbb+0x244)[0x7f00437779a4] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZN5clang14FrontendAction7ExecuteEv+0x67)[0x7f004528e547] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE+0x336)[0x7f00451e3eb6] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZN5clang7tooling21FrontendActionFactory13runInvocationESt10shared_ptrINS_18CompilerInvocationEEPNS_11FileManagerES2_INS_22PCHContainerOperationsEEPNS_18DiagnosticConsumerE+0x189)[0x7f004548fff9] clang-tidy-14[0xbc9e94] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZN5clang7tooling14ToolInvocation13runInvocationEPKcPNS_6driver11CompilationESt10shared_ptrINS_18CompilerInvocationEES7_INS_22PCHContainerOperationsEE+0x134)[0x7f004548fd44] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZN5clang7tooling14ToolInvocation3runEv+0x57d)[0x7f004548ecad] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.14(_ZN5clang7tooling9ClangTool3runEPNS0_10ToolActionE+0x10de)[0x7f004549196e] clang-tidy-14(_ZN5clang4tidy12runClangTidyERNS0_16ClangTidyContextERKNS_7tooling19CompilationDatabaseEN4llvm8ArrayRefINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcENS7_18IntrusiveRefCntPtrINS7_3vfs17OverlayFileSystemEEEbbNS7_9StringRefE+0x422)[0xbc4e32] clang-tidy-14(_ZN5clang4tidy13clangTidyMainEiPPKc+0x208b)[0x5c238b] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xcd)[0x7f003beac81d] clang-tidy-14(_start+0x2a)[0x5be1ba] /builds/aacid/poppler/poppler/NameToCharCode.cc: terminated by signal 11 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.14-arch1-1 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages clang-tidy-14 depends on: ii clang-tools-14 1:14.0.6-2 ii libc6 2.33-8 ii libclang-common-14-dev 1:14.0.6-2 ii libclang-cpp14 1:14.0.6-2 ii libgcc-s1 12.1.0-7 ii libllvm14 1:14.0.6-2
Bug#825317: Dzień dobry,
Dzień dobry, Cieszę się, że mogę się z Państwem skontaktować w sprawie pozyskania funduszy mojego zmarłego klienta, z którym macie to samo nazwisko i obywatelstwo, który został wam przekazany jako jego najbliżsi krewni. Skontaktuj się ze mną po więcej szczegółów, a dojdziemy do porozumienia w sprawie legalności i uzyskania podstawy. Dziękuję Adwokat Albert Doe.
Bug#1001748: clang-tidy: run-clang-tidy symlink is broken
Package: clang-tidy Version: 1:13.0-53 Severity: normal X-Debbugs-Cc: aa...@kde.org Dear Maintainer, /usr/bin# ls -l run-clang-tidy lrwxrwxrwx 1 root root 20 Nov 30 21:19 run-clang-tidy -> run-clang-tidy-13.py /usr/bin# ls -l run-clang-tidy-13.py lrwxrwxrwx 1 root root 41 Dec 5 12:07 run-clang-tidy-13.py -> ../lib/llvm-13/share/clang/run-clang-tidy /usr/bin# ls -l ../lib/llvm-13/share/clang/run-clang-tidy ls: cannot access '../lib/llvm-13/share/clang/run-clang-tidy': No such file or directory -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.7-arch1-1 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages clang-tidy depends on: ii clang-tidy-13 1:13.0.0-9+b2 clang-tidy recommends no packages. clang-tidy suggests no packages. -- no debconf information
Bug#996761: kwin-x11: KWin crashes and doesn't start
Thank you, Patrick and Bernhard; downgrading worked for me as well. Very much appreciated. On Mon, Oct 18, 2021 at 11:24 PM Francisco José Calvo wrote: > > Hello Bernhard, yes it is same issue mentioned in #996726, not related to > nvidia-driver. > > Thanks a lot. > > El lun., 18 oct. 2021 23:16, Bernhard Übelacker > escribió: >> >> Hello Francisco, hello Albert, >> this might be the same as in bug #996726 >> and not directly related to the nvidia driver. >> >> I hit a crash in kwin_x11 with an AMD graphics card >> and could workaround by installing >> libkdecorations2-5v5_5.21.5-2_amd64.deb like >> mentioned in #996726. >> >> Kind regards, >> Bernhard >> >> https://bugs.debian.org/996726
Bug#996761: kwin crash on startup
I had the same problem as Francisco reported. My Nvidia card is NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] kwin-x11: 4:5.21.5-2 nvidia-driver: 470.74-1 linux-image-amd64: 5.14.9-2 I tried to downgrade nvidia-driver, but had problems while installing the package from stable release, so I went to install LXDE instead, which seems to work fine with the latest nvidia-driver. /Albert
Bug#979764:
Hi, Jürgen, Thank you for posting this! I also observe that the bug affects nfs-client on 5.10 kernel nfs-server is not affected (works with both 5.9 and 5.10 kernels) I followed your suggestions, but unfortunately with no luck. I tried adding principles and building the latest nfs-utils. But downgrading to 5.9 kernel helped! Thanks again Best regards, Albert
Bug#984497: weasels and doves
> Op 08-03-2021 17:36 schreef Andrius Merkys : > > > Hi, > > On 2021-03-08 15:44, Albert van der Horst wrote: > > I don't see the problem here. If there is a bug in an old version supplied > > with Debian, the bug report lands with Debian. > > Not necessary. Many users cannot tell whether a bug is caused by > upstream code or Debian packaging. Many users do not know about Debian > BTS. Thus Debian-specific bugs land in upstream trackers, and some > upstreams do not want to provide support outside what they consider > "canonical" use of their software. This surprises me. I use Debian for reliability. I expect the Debian package more reliable than whatever upstream supplies. So I would file a bug in the Debian system. I also expect that Debian wants to know the bugs of all packages, not just "Debian-specific" in order to remove packages of low quality. Maybe my esteem/expectation of Debian is too high ... > > > Then Debian can solve the bug report by renewing upstream. Sot that bug > > report is not against the package, but against the packaging. > > True, but this might be slowed down by the update process in stable. Right, but then bugs against a stable version should be rare. > Definitive fixing maybe. But if I have a problem and stable I can always load a fixed version from test. I can now see that bleeding edge developpers, who are fast moving and generating many bugs, will want to keep out of Debian. But why would Debian want them in? Anywhere, obviously it is best to grant their wish, even if they have no legal standing. FOSS is FOSS, right? > Best, > Andrius Groetjes Albert
Bug#984497: weasels and doves
I don't see the problem here. If there is a bug in an old version supplied with Debian, the bug report lands with Debian. Then Debian can solve the bug report by renewing upstream. Sot that bug report is not against the package, but against the packaging. If it persists in the newest version, the bug can be passed to upstream. Bug reports will not land at the developpers desk, or Debian has to take measures that they don't, e.g. by replacing e-mail addresses. No reasonable upstream developer will object to such an arrangement. Groetjes Albert > Op 06-03-2021 12:58 schreef Geert Stappers : > > > Preamble: >Do know that having own priorities >and working together IS possible. > > > On Sat, Mar 06, 2021 at 10:17:03AM +0800, Paul Wise wrote: > > On Fri, 2021-03-05 at 16:52 +0100, Andreas Tille wrote: > > > > > Finally the license statement is all about redistribution ... and > > > than upstream says: Do not redistribute. > > > > They appear to be fine with redistribution, > > OK > > > > just not with wide distribution by a popular Linux distribution, > > which has a stable release that is guaranteed to get out of date with > > documentation. > > Rendering that to FUD does allow me to add more FUD. > Less agressive: > The _possible_ burden on upstream > should NOT block our wish to package it. > > > > Possibly they could be convinced by having the package only available > > in Debian unstable or experimental and guaranteeing to keep it up to > > date with the latest available upstream version. > > Good relation with upstream is indeed preferred. > That relation will only exist when packaging is going on. > We are dealing with libre software. It implies that > upstream is libre to express "we don't want that it happens", > we are libre to do packaging. > Restricting ourselfs to only unstable feels wrong. > > > > On the other hand they probably also don't want to deal with bug > > reports about a build that they did not produce. > > Double you tee ef. > Please keep Fear Uncertainty and Doubt to yourself. > Now breaking that rule: > > Shady generated binaries are plain evil. > > > > (Back to more reasonable) > > It is not to us, Debian, to come with possible reasons > why upstream is "right" in blocking us. > > We, Debian, are fully aware that packaging comes > with responsebilities to quality. > > > > > Perhaps the right way is for Debian to distribute ExplosionAI software > > under different names with all documentation pointing at Debian to > > avoid upstream having to deal with bug reports from Debian users. > > > Same as was done with Iceweasel and Icedove. > > Future history will tell which lessons were learnt. > > > > Groeten > Geert Stappers > DD > -- > Silence is hard to parse
Bug#963929: O: rsh-redone -- Reimplementation of rsh and rlogin
Guus Sliepen schreef op 2020-06-28 21:33: Package: wnpp Severity: normal I intend to orphan the rsh-redone package. I no longer have time to maintain this. I am also the upstream author of this; if you want to adopt the package, you are also welcome to take over upstream maintainership. However, since no-one should be using RSH in this day and age anymore, if no one is interested I will request removal of this package. I connect to xxx pi with linux/android using rlogin/rsh all the time. Isn't it a basic simple functionality? Why "should" I not be using rsh? What could I use instead, hooking up a vt100 via an usb to RS232 interface is not very practical? The package description is: Rsh-redone is a reimplementation of the remote shell clients and servers. It is written from the ground up to avoid the bugs found in the standard clients and servers. It also fully supports IPv6. . This package provides rsh and rlogin. -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#962192: zfsutils-linux: zfs import task tries to recursivly import pools from zvols
Package: zfsutils-linux Version: 0.8.4-1~bpo10+1 Severity: important Dear Maintainer, I'm currently using zvols for kvm VMs. when i setup a FreeBSD VM with zfs root and a ubuntu vm with zfs root (yes i know zfs on zfs creates performance problems, it was for testing something) my system failed the pool import stage on the next reboot because it found the pools on the zvols which had unsuported feature flags enabled, resulting in an unbootable system (i currently have my root partion on zfs). i would not have expected it to try to import zpools on zvols... (i fixed it by removing the zvol since the tests where more or less finished anyway and the vm can easyly be recreated in this case, however it still was quite suprising to have the system fail to boot). regards, albert -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zfsutils-linux depends on: ii libblkid12.33.1-0.1 ii libc62.28-10 ii libnvpair1linux 0.8.4-1~bpo10+1 ii libudev1 241-7~deb10u4 ii libuuid1 2.33.1-0.1 ii libuutil1linux 0.8.4-1~bpo10+1 ii libzfs2linux 0.8.4-1~bpo10+1 ii libzpool2linux 0.8.4-1~bpo10+1 ii python3 3.7.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages zfsutils-linux recommends: ii lsb-base10.2019051400 ii zfs-dkms [zfs-modules] 0.8.4-1~bpo10+1 ii zfs-zed 0.8.4-1~bpo10+1 Versions of packages zfsutils-linux suggests: pn nfs-kernel-server pn samba-common-bin ii zfs-initramfs 0.8.4-1~bpo10+1 -- Configuration Files: /etc/sudoers.d/zfs [Errno 13] Permission denied: '/etc/sudoers.d/zfs' -- no debconf information
Bug#955232: Please add 9p kernel module to the cloud image.
Package: linux-image-cloud-amd64 Severity: wishlist Please consider adding kernel module '9p' to the cloud image. It is impossible to passthrough filesystem from hypervisor with the current cloud image and there are no additional packages to install it. The only way that I know to passthrough filesystem currently is to remove linux-image-cloud-amd64 and install linux-image-amd64. - Albert Akchurin -- System Information: Debian Release: 10 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-cloud-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-cloud-amd64 depends on: pn linux-image-4.19.0-8-cloud-amd64 linux-image-cloud-amd64 recommends no packages. linux-image-cloud-amd64 suggests no packages.
Bug#947040: kopano-core: PIDFILE in /etc/init.d/kopano-* does not match /etc/kopano/*.cfg
Package: kopano-core Version: 8.7.0-3 Severity: normal Dear Maintainer, First of all thanks for the wonderfull job of bringing kopano to the debian repositories! It is a lot easier to install/maintain thanks to your work. When configuring kopano, I needed to restart the server to activate the new configuration. I did a: systemctl restart kopano-server I noticed the following messages in /var/log/syslog: Dec 19 11:04:42 defiant systemd[1]: Stopping LSB: Kopano Collaboration Platform's Storage Server... Dec 19 11:04:42 defiant kopano-server[4728]: Stopping Kopano server: kopano- serverNo /usr/sbin/kopano-server found running; none killed. Dec 19 11:04:42 defiant kopano-server[4728]: failed! Dec 19 11:04:42 defiant systemd[1]: kopano-server.service: Succeeded. Dec 19 11:04:42 defiant systemd[1]: Stopped LSB: Kopano Collaboration Platform's Storage Server. Dec 19 11:04:42 defiant systemd[1]: kopano-server.service: Found left-over process 1506 (kopano-server) in control group while starting unit. Ignoring. Dec 19 11:04:42 defiant systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. Dec 19 11:04:42 defiant systemd[1]: Starting LSB: Kopano Collaboration Platform's Storage Server... Dec 19 11:04:43 defiant kopano-server[4744]: Starting kopano-server version 8.7.0 (pid 4744 uid 0) Dec 19 11:04:43 defiant kopano-server[4744]: Unable to bind to port 236: Address already in use. This is usually caused by another process (most likely another server) already using this port. This program will terminate now. In the end the 'old' kopano-server kept running, while the 'one' terminated due to 'unable to bind port 236'. Searching for the source of this problem, I found that the PIDFILE directives in /etc/init.d/kopano-* are not consistent with the ones used in /etc/init.d/kopano-*. My problem was locally solved by changing /etc/init.d/kopano-* and running 'systemctl daemon-reload'. In my opinion others can benefit if this change is integrated in the kopano- package. Thanks for all your work. If you need more info, please contact me. Albert -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kopano-core depends on: ii kopano-backup 8.7.0-3 ii kopano-dagent 8.7.0-3 ii kopano-gateway 8.7.0-3 ii kopano-ical 8.7.0-3 ii kopano-monitor 8.7.0-3 ii kopano-search 8.7.0-3 ii kopano-server 8.7.0-3 ii kopano-spamd8.7.0-3 ii kopano-spooler 8.7.0-3 ii kopano-utils8.7.0-3 kopano-core recommends no packages. Versions of packages kopano-core suggests: pn kopano-webapp -- no debconf information
Bug#814836:
Good day , my name is Albert Khanukaev , i sent you a mail and there was no response , please confirm that you did get this mail for more details. Regards. Albert Khanukaev
Bug#914716: Re: Bug#914716: molly-guard: breaks conversion to merged /usr with usrmerge
If you would like to co-mantain molly-guard with me it will be a pleasure. Thu Jun 06 19:10:09 GMT+02:00 2019 Marc Haber : On Thu, Jun 06, 2019 at 03:20:51PM +0200, Simó Albert i Beltran wrote: > Thanks for your work and, please, go ahead! Will do. Do you want me to NMU or to add myself to uploaders? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#914716: molly-guard: breaks conversion to merged /usr with usrmerge
Thanks for your work and, please, go ahead!
Bug#770064: Good day
Dear Friend, I am a lawyer by profession here in my country Togo in west Africa, one of my client from your country who worked with shell development company here in Republic of Togo. My client, his wife and their only daughter were involved in auto crash here in my country. I decided to contact you so that the $10.5M Dollars he left behind in a bank here will be transferred to your bank account immediately. For more details (johnalbertt...@gmail.com) Best regards. Barrister Albert John
Bug#770064: Good day
Bug#905080: O to ITA WAS: no response
Geert Stappers schreef op 2019-04-09 19:34:
On Tue, Apr 09, 2019 at 07:05:29PM +0200, Albert van der Horst wrote:
I followed up on a "orphaned bug" by adding a message to the bug
905080.
This got never a response.
Sadly that does happen. Good that you presist.
( How to do good presistence is another story )
You must be ironical. Following up after months, doesn't look like
persistence. It just reflects my priority list.
The priority list reflects my perception of the eagerness with
which the Debian community welcomes a capable maintainer.
Did I make a mistake with respect to the Debian protocols?
(-:learning is making mistakes :-)
Retitle the bug from "O" to "ITA" and do the actual work, next is
"RFS"
This work has no material effect. Because there are no actual defects
that
impact the usability of the package,
it just changes a maintainer name and/or a copyright message.
And I just learned that, because there are no actual, let alone
substantial defects
("bugs"), the package will not disappear from the next distribution.
Groeten
Geert Stappers
Groetjes Albert
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst
Bug#855096: unison: segfaults after connection has been established
Hi! I see this now on my cygwin install. Log file is empty, debug output is as follows. Unison 2.51.2 (ocaml 4.04.2): Contacting server... [globals] Checking path '' for expansions [startup] Roots: /cygdrive/o /cygdrive/z/mail.ru i.e. /cygdrive/o /cygdrive/z/mail.ru i.e. (in canonical order) /cygdrive/o /cygdrive/z/mail.ru [props] Setting permission mask to 200 (1777 and 200) [stasher] initBackupsLocal [stasher] d = / [stasher] Prefix and suffix regexps for backup filenames have been updated [stasher] initBackupsLocal [stasher] d = / [stasher] Prefix and suffix regexps for backup filenames have been updated Looking for changes [ui] temp: Globals.paths = [update+] Archive name is x; hashcode is x [update+] Archive name is x; hashcode is x [update+] Archive name is x; hashcode is x [update+] Archive name is x; hashcode is x [update+] Archive name is x; hashcode is x [update] Loading archive from /.unison/arc0468b Growing heap to 29824k bytes Growing page table to 4096 entries Growing page table to 8192 entries Growing page table to 16384 entries And that's it. It exits. This is a large sync of 43408 files over local disks. The initial sync was successful but a repeat fast sync fails. Albert
Bug#925535: jessie-updates missing in archive.debian.org and deb.debian.org
Package: Everything from jessie-updates Version: does not matter Hello, currently it is not possible to run an update or install packages from debian-updates main. I think this happened during the move operation of some repos to the archive. See: https://lists.debian.org/debian-devel-announce/2019/03/msg6.html i386, amd64, armhf, armel should have stayed on the regular repositories. But they have not been available for a couple of minutes but where available (or maybe restored?) again a little bit later. I think someone forgot to restore the jessie-updates files on the regular repositories. Greetings Albert Krenz
Bug#849148: autofs: Orphaning package?
Manu Alén schreef op 2018-12-24 14:22: Source: autofs Hi, I have worked with autofs and although I’m going to take care of some packages more, I think that I could have a bit time to support it. Please do not hesitate to give me advices or extra information to take care of autofs package if it is still available Thanks in advance Best Regards Manu On Fri, 23 Dec 2016 10:39:41 +1100 Dmitry Smirnov wrote: Source: autofs Severity: important X-Debbugs-CC: wdau...@gmail.com,he...@pool.math.tu-berlin.de,m...@tls.msk.ru Dear co-maintainers, I have no capacity to look after "autofs" package. It seems like none of us did any meaningful work on this package lately so I suggest either to orphan it or start caring about it... Thanks. -- Best wishes, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- George Orwell Sent from Mail for Windows 10 -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#905080: O: as31 - Intel 8031/8051 assembler
Bdale Garbee schreef op 2018-07-31 07:17: Package: wnpp Severity normal I no longer have any personal need for as31, so would like to drop it from the list of packages I maintain. I recently uploaded a fix for the segfault encountered building the usbdux driver in the firmware-nonfree source package. The only remaining open bug regards the ambiguity of upstream asserting the package is under "the BSD license" without specifying which precise variant. To the best of my knowledge, no packages in Debian depend on as31, but because there is a driver (that is not built for Debian by default) in the firmware-nonfree package that depends on it, I choose to orphan the package rather than just asking for it to be removed from the archive. I looked into this package and the upstream archive just exists. Moreover the package is up to date w.r.t. upstream since 2005. Apparently this is a superstable package where the last bugs disappeared ages ago. I would regret if this package disappears from Debian, because - the 8051 has historic interest, but also to this day practical interest - the assembler is a solid piece of software engineering, so it is worth maintaining and probably not overly time consuming. - if nothing else, it can serve as an example of the use of lex and yacc. After studying the project I'm willing to take on the orphaned 8051 assembler as31. My credentials: - dedicated to the free software movement (author of some free software) - unix/c experience since the 80's - sworn in as a maintainer at debian mentors (thanks, Geert Stappers!) - some experience with Debian packaging, and some familiarity with the policy and guidelines - extensive experience with software maintenance (as well as development) - affinity with the 8051, owner of dozens of single board computers, among them a couple 8051 based - Published a flash programmer for an Elektor board with a 8051 processor: https://forth.hcc.nl/w/Producten/Flash - a direct personal line to Willem Ouwerkerk, creator of a 8051 development system Bdale Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#914550: borgbackup needs to be rebuilt for python 3.7
Package: borgbackup Version: 1.1.7-1 Severity: grave Justification: renders package unusable Dear Maintainer, since the update to python 3.7 in debian unstable, borg is uninstable. a simple rebuild of the package seems to be enough to get a working package. regards, albert dengg -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages borgbackup depends on: ii fuse 2.9.8-2 ii libacl12.2.52-3+b1 ii libb2-10.98-1 ii libc6 2.27-8 ii liblz4-1 1.8.2-1 ii libssl1.1 1.1.1-2 ii libzstd1 1.3.5+dfsg-1 ii python33.7.1-2 ii python3-llfuse 1.3.5+dfsg-1 ii python3-msgpack0.5.6-1+b1 ii python3-pkg-resources 40.5.0-1 borgbackup recommends no packages. Versions of packages borgbackup suggests: pn borgbackup-doc -- no debconf information
Bug#907104: O: freecdb -- creating and reading constant databases
Albert van der Horst schreef op 2018-08-25 13:48: Tobias Frost schreef op 2018-08-23 22:34: Package: wnpp The current maintainer of freecdb, Gerrit Pape , is apparently not active anymore. Therefore, I orphan this package now. Embarassed by asking an unneeded question. I forgot to look up the meaning of orphan. It means a new maintainer is sought and if the package is important it is even a severe bug. Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#907104: O: freecdb -- creating and reading constant databases
Tobias Frost schreef op 2018-08-23 22:34: Package: wnpp The current maintainer of freecdb, Gerrit Pape , is apparently not active anymore. Therefore, I orphan this package now. I take this as an example of the many packages to be orphaned in one go. I looked into it and I see only one minor bug and a few whishlist items. One wishlist item of 2007 contains a patch (.diff) and is not rejected nor adapted, or even acknowledged. I think that is not acceptable. So I can see that measures have to be taken. OTOH the lack of maintenance doesn't pose problems to Debian users, so there seems no need to remove this package from Debian immediately. Doesn't it make more sense to put such packages up for adoption instead of orphaning it? Maybe there is more to it, like superseeded by a better program, low quality, obsoleteness etc. P.S. I would not have made this remarks if it was phrased "Therefore, I orphan this package of low interest to Debian now." Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#907040: marked as done (ITP: vim-julia -- vim support for julia language)
Debian Bug Tracking System schreef op 2018-08-23 18:21: Your message dated Thu, 23 Aug 2018 16:20:05 + with message-id and subject line closing ITP: vim-julia -- vim support for julia language has caused the Debian Bug report #907040, regarding ITP: vim-julia -- vim support for julia language to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#903713: plasma-browser-integration: "This_file_is_part_of_KDE" in debian/copyright?
El dissabte, 21 de juliol de 2018, a les 14:40:39 CEST, Maximiliano Curia va escriure: > ¡Hola Albert! > > El 2018-07-19 a las 18:54 +0200, Albert Astals Cid escribió: > >>> Let's see a sample header like ar/messages/kdegraphics/okular_mobi.po > > >>> # Copyright (C) YEAR This_file_is_part_of_KDE > >>> # This file is distributed under the same license as the PACKAGE package. > >>> # Zayed Al-Saidi , 2009. > >>> # Abdalrahim G. Fakhouri , 2014. > > >>> The first one is the one you mentioned, personally i think we can just > >>> delete the first line (or change them to "For Copyright see the individual > >>> names below"), they are "worthless/wrong" and if people use the "right" > >>> tools for translation their copyright is added after those lines, i.e. > >>> lines > >>> 3 and 4. > > >> The problem with this kind of copyright assignment is that it's not machine > >> readable (a line with a name is very hard to distinguish from a piece of > >> text), and tools like decopy, licensecheck, scancode, etc will simply > >> ignore > >> the list of authors. So, if you are going to change this format, please > >> consider adding a "Copyright: " to the list of authors, then this would > >> become: > > >> # Copyright: Zayed Al-Saidi , 2009. > >> # Copyright: Abdalrahim G. Fakhouri , 2014. > > > That's not possible, the Copyright line gets added by third party tools we > > do not control, and even if we updated Lokalize (the tool "most" of our > > translators use) *today*, it wouldn't get to them until years later thanks > > to how distribution of applications in Linux works at this time. > > Alright, what about: > > # This file is copyright: > # Zayed Al-Saidi , 2009. > # Abdalrahim G. Fakhouri , 2014. > > this would only mean changing the proposed "For Copyright see the individual > names below" to a string that is already supported by automatic copyright > parsers. This should be doable, i'll bring it to discussion with the wider community but i don't expect any disagreement. Cheers, Albert > > Happy hacking, >
Bug#903713: plasma-browser-integration: "This_file_is_part_of_KDE" in debian/copyright?
El dijous, 19 de juliol de 2018, a les 11:08:10 CEST, Maximiliano Curia va escriure: > ¡Hola Albert! > > Thanks for the follow up. > > El 2018-07-19 a las 00:32 +0200, Albert Astals Cid escribió: > > Yes, there is a long standing issue with the translations of the .po files > > that carry not really good copyright information most of the times. > > > Let's see a sample header like ar/messages/kdegraphics/okular_mobi.po > > > # Copyright (C) YEAR This_file_is_part_of_KDE > > # This file is distributed under the same license as the PACKAGE package. > > # Zayed Al-Saidi , 2009. > > # Abdalrahim G. Fakhouri , 2014. > > > The first one is the one you mentioned, personally i think we can just > > delete the first line (or change them to "For Copyright see the individual > > names below"), they are "worthless/wrong" and if people use the "right" > > tools for translation their copyright is added after those lines, i.e. > > lines > > 3 and 4. > > The problem with this kind of copyright assignment is that it's not machine > readable (a line with a name is very hard to distinguish from a piece of > text), and tools like decopy, licensecheck, scancode, etc will simply ignore > the list of authors. So, if you are going to change this format, please > consider adding a "Copyright: " to the list of authors, then this would > become: > > # Copyright: Zayed Al-Saidi , 2009. > # Copyright: Abdalrahim G. Fakhouri , 2014. That's not possible, the Copyright line gets added by third party tools we do not control, and even if we updated Lokalize (the tool "most" of our translators use) *today*, it wouldn't get to them until years later thanks to how distribution of applications in Linux works at this time. Cheers, Albert > > Which is easily detectable by any of the mentioned tools. > > > The second line is also wrong, what is "PACKAGE"? In my opinion now that we > > ship the translations as part of the application tarballs themselves it's > > clear-ish that unless otherwise stated in the file, the files are under the > > copyright stated in the COPYING file so we may as well delete those lines > > too. > > > Opinions? > > I agree that deleting the second line and "inheriting" the license from a > LICENSE or COPYING file is clearer than what's currently being shipped. And > from my part I would welcome such a change. > > Happy hackings, >
Bug#903713: plasma-browser-integration: "This_file_is_part_of_KDE" in debian/copyright?
El dissabte, 14 de juliol de 2018, a les 15:04:11 CEST, Luigi Toscano va escriure: > Maximiliano Curia ha scritto: > > ¡Hola Luigi! > > > > El 2018-07-14 a las 10:37 +0100, Chris Lamb escribió: > >>> My interpretation of this is that the intention is to assign the copyright > >>> to the kde project, although it's not a hundred percent clear. > > > >> I should have been clearer, sorry — I understand you are going with > >> whatever the file says but I am requesting that you make this clearer, > >> perhaps by getting a statement from upstream or similar. > > > >> "This_file_is_part_of_KDE" is really not suitable as an author, > >> whatever the file says, after all. > > > > Chris raised the issue of the po files distributed by kde containing some > > (not > > very clear) template parts, in particular the copyright assignments to > > This_file_is_part_of_KDE. > > I'm not sure that's a copyright assignment. Usually we have the FLA for that: > https://ev.kde.org/rules/fla.php > > I suspect that it was a replacement of the standard copyright assignation to > the FSF which was there in the early days but it really did not fit. > I tracked it back to this change, from 2006 (the string was later changed to > used underscores instead of spaces): > https://websvn.kde.org/?view=revision&revision=505466 > > The message is probably incorrect (without copyright is all reserved, not > public domain) but it has been like that for a while. > > I'm not sure I'm allowed to decide if it's a copyright assignment or not. I'm > probably going to ask the board of the KDE e.V., as it is a legal question. > I added Albert Astal Cid, who is and has been in charge of in the i18n team > more than me, he was part of the board in the past, and maybe we can discuss > what to do. Yes, there is a long standing issue with the translations of the .po files that carry not really good copyright information most of the times. Let's see a sample header like ar/messages/kdegraphics/okular_mobi.po # Copyright (C) YEAR This_file_is_part_of_KDE # This file is distributed under the same license as the PACKAGE package. # Zayed Al-Saidi , 2009. # Abdalrahim G. Fakhouri , 2014. The first one is the one you mentioned, personally i think we can just delete the first line (or change them to "For Copyright see the individual names below"), they are "worthless/wrong" and if people use the "right" tools for translation their copyright is added after those lines, i.e. lines 3 and 4. The second line is also wrong, what is "PACKAGE"? In my opinion now that we ship the translations as part of the application tarballs themselves it's clear-ish that unless otherwise stated in the file, the files are under the copyright stated in the COPYING file so we may as well delete those lines too. Opinions? Cheers, Albert > > > > With your kde i18n team hat on, would you consider it feasible to replace > > these strings with something clearer? > > > > If the intention is for the translators to assign the copyright to kde it > > should be assigned to KDE.e.V, if the intention is for each translator to > > keep > > the copyright assignment the This_file_is_part_of_KDE part of the template > > needs to be updated to say AUTHOR . > > > > The first case should be "scriptable" the second case, would need to > > manually > > modifying each po file that contains the "This_file_is_part_of_KDE" text. > > As I said, I don't think it's the first case, but I can ask to the e.V. > > If it's going to be the second case, I don't think that's practical when the > list of authors is still in the file. Shouldn't a string like > Copyright (C) the respective authors (see below) > work? Or something more legally fitting. > > > Finally, a request: please lower the severity of this bug. It's not a > regression, and I would assume good faith on something that has been the same > for the past 10+ years, without having a "serious" bug in the middle. > > Ciao >
Bug#859130: uploads to mentors, no updates on git repository
Geert Stappers schreef op 2018-06-12 15:34: At https://mentors.debian.net/package/lina are several uploads of verion 5.3.0-2 of lina. Some are from may, most are from 11th of june. However _no changes_ on the git repository at https://github.com/albertvanderhorst/ciforth That is not to be expected, as most complaints by lintian are about what is in the debian directory, not under control of upstream. That means the (ab)used .orig.tar.gz still gets it's forth.lab and makefile from unknown source. Since when is an upstream author 'unknown source'? The author is well known, it is me, see the copyright messages. Besides, where is the requirement in Debian that an upstream source should be a dump of a git repository? So I reject this complaint and maintain that the lina package is fit for sponsoring. The ciforth archive is not. I'm not aspiring to add a factory for generating MS-windows and Apple programs to Debian, as 1. It goes against the spirit of what I want to supply Debian with: a simple compiler that will spawn a number of e.g. single board computer related utilities. A compiler that is by far the most understandable compiler in the whole of Debian. 2. ciforth probably simply doesn't belong in Debian 3. It would require a tremendous upgrade in quality. Where I'm 100% behind the quality of lina, not so much for ciforth. I could not promote adding it to Debian. Even so, if a Debian developer thinks the ciforth compiler factory is a valuable addition *to a debian distribution*, (s)he is free to fork ciforth and get it accepted. * Please note! The famous gcc has no means to generate a native * * windows compiler. so ciforth would beat gcc to it! * * Of course chances are better with a compiler designed for * * simplicity but i'm not foolish enough to gamble that ciforth * * could pass Debian's quality checks in my life time.* See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859130#58 where that was previously reported. I doubt if this ITP is really about getting a source from a git repository into a debian package. Of course it is not. The git repository contains means to get windows and apple sources that are specifically not going into the lina package. So it is plain that you don't understand the difference between ciforth and lina, and that you don't respect the integrity of an upstream package c.q. upstream maintainer. That is the reason you're no longer my sponsor. Remember how this started? My source package contains lina.fas lina.texinfo forth.lab There was not even a Makefile . Build with fasm lina.fas which is mentioned somewhere in lina.fas The simplicity is a goal made possible with complexity in ciforth. Then the whole circus gets started with the remark that lina.fas is not a "proper source" based on a rule that was supposed to contain malevolent manufacturers, not hold back free software developpers. Anyway the "preferred source of modification" rule is obeyed by supplying everything that could be considered "preferred source of modification", so that point is covered. See also https://github.com/albertvanderhorst/ciforth/wiki/Philosophy-behind-ciforth An example of usage of the compiler including some parallel calculations: https://github.com/albertvanderhorst/primecounting I welcome a new sponsor! You will sponsor a very simple package that is mature and has a very responsive maintainer. Groeten Geert Stappers Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#859130: Feedback on lina packaging
Geert Stappers schreef op 2018-04-25 23:49: Hello Albert, Some feedback on your packaging of lina. So far my feedback. Please keep this bugreport in the loop upon further progress. Veel van wat je op merkt komt er op neer dat je de ciforth git repository als source voor lina wil beschouwen en niet https://github.com/albertvanderhorst/ciforth/releases/download/CVS_REL-5-3-0/lina-5.3.0.tar.gz M.a.w. er zijn dus source files die niet in het git repository staan als zodanig, maar door upstream (mij) als source aangeleverd worden. Het ciforth repository is geen lina repository, maar een meta systeem. Kan je het accepteren dat een tar.tgz een upstream source is en niet git? Verder kan je iets zeggen over watch files? Wat kun je er mee? Volgens mij zijn ze bedoeld voor automatisch updaten. Kan je bijv. daarmee iets oplossen als er een 64 bit versie bijkomt of arm lina bijkomt die in een cvs-repository staat? (Het lijkt me van niet, maar wat weet ik.) Heeft het dan wel zin om daar zo strak aan vast te houden? Cheers Geert Stappers P.S. onverkort wat hierboven staat ga ik al je opmerkingen serieus bekijken en eventueel het archief updaten. -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#859130: Preferred source: a fundamental question
Geert Stappers schreef op 2018-03-30 08:34: On Wed, Mar 28, 2018 at 01:24:03PM +0200, Albert van der Horst wrote: ... I invite mentors interested in the "preferred source" matter to check whether they can agree that the package now complies with debian guide lines. And at which URL is the package to be checked? Sorry. This is about a Forth, where the Assembler source is extracted from a kind of database. This database is now part of the source distribution, as are the extraction tools (m4). This is the url. https://mentors.debian.net/package/lina Groeten Geert Stappers @859130: Happy Birthday Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#892584: gnupg On a virgin buster/sid system importing a secret key fails
Package: gnupg Version: 2.2.5-1 Severity: normal Dear Maintainer, * What led up to the situation? A freshly installed buster, a new user. The user tries to import a secret key in a clear-sign format * What exactly did you do (or not do) that was effective (or ineffective)? gpg --import F00265E2.asc * What was the outcome of this action? A "not changed@ message and "error sending to agent" * What outcome did you expect instead? Proper installation of course. The same command succeeds if executed by root. Logs Follow: " albert@kiwi:~/backup/.gnupg$ gpg --import F00265E2.asc gpg: key E03927B1F00265E2: 3 signatures reordered gpg: key E03927B1F00265E2: "Albert van der Horst (manipal) " not changed gpg: key E03927B1F00265E2/E03927B1F00265E2: error sending to agent: No such file or directory gpg: error building skey array: No such file or directory gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 " ------- " root@kiwi:/home/albert/backup/.gnupg# gpg --import F00265E2.asc gpg: key E03927B1F00265E2: 3 signatures reordered gpg: key E03927B1F00265E2: "Albert van der Horst (manipal) " not changed gpg: key E03927B1F00265E2: secret key imported gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 " This suggests a privilege related or PATH related problem. The secret key was exported from gnu version 1.4. I was able to use gpg to sign a message after copying from root/.gnupg to /.gnupg which confirms that the import was succesful. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnupg depends on: ii dirmngr 2.2.5-1 ii gnupg-l10n 2.2.5-1 ii gnupg-utils 2.2.5-1 ii gpg 2.2.5-1 ii gpg-agent 2.2.5-1 ii gpg-wks-client 2.2.5-1 ii gpg-wks-server 2.2.5-1 ii gpgsm 2.2.5-1 ii gpgv2.2.5-1 gnupg recommends no packages. Versions of packages gnupg suggests: pn parcimonie pn xloadimage -- no debconf information
Bug#716143: Reject this bug report
The program passed to pforth starts with @ with no items on the stack, while @ requires one. This invokes ambiguous behaviour so pforth is fully entitled to crash. (DPANS 2.1) So this bug report must be rejected and closed. P.S. This bug report reflects an appalling lack of understanding of Forth. Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#891234: postgresql-9.6: pg_ctlcluster suppresses to much information on startup
Package: postgresql-9.6
Version: 9.6.6-0+deb9u1
Severity: normal
hi,
pg_ctlcluster, used by the startup script/systemd unit, suppresses the
output of the actual cluster startup.
however, this can lead to the situation where pg_ctlcluster tells you
that the startup failed and you should consult the logfile, however
there is no log entry because it could not open the log file.
when starting with strace, you can see that it actually tries to tell
you what the problem was, but the message gets eaten by the perl script:
strace -f /usr/bin/perl -wT /usr/bin/pg_ctlcluster --skip-systemctl-redirect
9.6-main start
[...]
[pid 2803] fcntl(10, F_SETFD, FD_CLOEXEC) = 0
[pid 2803] dup2(3, 0) = 0
[pid 2803] close(3)= 0
[pid 2803] open("/var/log/postgresql/postgresql-9.6-main.log",
O_WRONLY|O_CREAT|O_APPEND, 0666) = -1 EACCES (Permission denied)
[pid 2803] write(2, "/bin/sh: 1: ", 12) = 12
[pid 2803] write(2, "cannot create /var/log/postgresq"..., 76) = 76
[pid 2803] write(2, "\n", 1) = 1
[pid 2803] dup2(10, 0) = 0
[pid 2803] close(10) = 0
[pid 2803] exit_group(2) = ?
would it be possible not to completly supress the output of pg_ctl here,
as that a problem like in this case wrong permissions on the logfile (in
this case caused by logrotate and while running not a problem as logging
is done via syslog)
regards,
albert
-- System Information:
Debian Release: 9.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-5-amd64 (SMP w/14 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages postgresql-9.6 depends on:
ii libc6 2.24-11+deb9u1
ii libgssapi-krb5-2 1.15-1+deb9u1
ii libldap-2.4-2 2.4.44+dfsg-5+deb9u1
ii libpam0g 1.1.8-3.6
ii libpq5 9.6.6-0+deb9u1
ii libssl1.1 1.1.0f-3+deb9u1
ii libsystemd0232-25+deb9u1
ii libxml22.9.4+dfsg1-2.2+deb9u2
ii locales2.24-11+deb9u1
ii postgresql-client-9.6 9.6.6-0+deb9u1
ii postgresql-common 181+deb9u1
ii ssl-cert 1.0.39
ii tzdata 2018c-0+deb9u1
Versions of packages postgresql-9.6 recommends:
ii postgresql-contrib-9.6 9.6.6-0+deb9u1
ii sysstat 11.4.3-2
Versions of packages postgresql-9.6 suggests:
pn locales-all
-- no debconf information
Bug#887877: rsyslog start script does not create /dev/xconsole
Package: rsyslog
Version: 8.24.0-1
Severity: normal
Tags: d-i
Dear Maintainer,
After an upgrade from Debian jessie to stretch, the /dev/xconsole has
disappeared. It seems that the scripts of systemctl take over the start of the
daemon and the start/stop functions in the actual rsyslog script in init.d are
no longer run. The script contains a function that creates /dev/xconsole pipe
at startup. Since the script is no longer run, the pipe is not created,
rsyslogd does not write there and the applications reading from the pipe fail.
For the time being, I have modified the startup script for rsyslog to run the
create_xconsole() function at the beginning of the script and it works. It
would be great that the /dev/xconsole was created by the system without such
need of tweaking.
Cheers,
Albert
-- System Information:
Debian Release: 9.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages rsyslog depends on:
ii init-system-helpers 1.48
ii libc62.24-11+deb9u1
ii libestr0 0.1.10-2
ii libfastjson4 0.99.4-1
ii liblogging-stdlog0 1.0.5-2+b2
ii liblognorm5 2.0.1-1.1+b1
ii libsystemd0 232-25+deb9u1
ii libuuid1 2.29.2-1
ii lsb-base 9.20161125
ii zlib1g 1:1.2.8.dfsg-5
Versions of packages rsyslog recommends:
ii logrotate 3.11.0-0.1
Versions of packages rsyslog suggests:
pn rsyslog-doc
pn rsyslog-gnutls
pn rsyslog-gssapi
pn rsyslog-mongodb
pn rsyslog-mysql | rsyslog-pgsql
pn rsyslog-relp
-- Configuration Files:
/etc/init.d/rsyslog changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="enhanced syslogd"
NAME=rsyslog
RSYSLOGD=rsyslogd
DAEMON=/usr/sbin/rsyslogd
PIDFILE=/var/run/rsyslogd.pid
SCRIPTNAME=/etc/init.d/$NAME
[ -x "$DAEMON" ] || exit 0
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
create_xconsole() {
XCONSOLE=/dev/xconsole
if [ "$(uname -s)" != "Linux" ]; then
XCONSOLE=/run/xconsole
ln -sf $XCONSOLE /dev/xconsole
fi
if [ ! -e $XCONSOLE ]; then
mknod -m 640 $XCONSOLE p
chown root:adm $XCONSOLE
[ -x /sbin/restorecon ] && /sbin/restorecon $XCONSOLE
fi
}
case "$1" in
start)
create_xconsole
;;
esac
. /lib/lsb/init-functions
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# other if daemon could not be started or a failure occured
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --
$RSYSLOGD_OPTIONS
}
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# other if daemon could not be stopped or a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
$PIDFILE --exec $DAEMON
}
do_rotate() {
start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE --exec
$DAEMON
}
sendsigs_omit() {
OMITDIR=/run/sendsigs.omit.d
mkdir -p $OMITDIR
ln -sf $PIDFILE $OMITDIR/rsyslog
}
case "$1" in
start)
log_daemon_msg "Starting $DESC" "$RSYSLOGD"
create_xconsole
do_start
case "$?" in
0) sendsigs_omit
log_end_msg 0 ;;
1) log_progress_msg "already started"
log_end_msg 0 ;;
*) log_end_msg 1 ;;
esac
;;
stop)
log_daemon_msg "Stopping $DESC" "$RSYSLOGD"
do_stop
case "$?" in
0) log_end_msg 0 ;;
1) log_progress_msg "already stopped"
log_end_msg 0 ;;
*) log_end_msg 1 ;;
esac
;;
rotate)
log_daemon_msg "Closing open files" "$RSYSLOGD"
do_rotate
log_end_msg $?
;;
restart|force-reload)
$0 stop
$0 start
;;
try-restart)
$0 status >/dev/null 2>&1 && $0 restart
;;
status)
status_of_proc -p $PIDFILE $DAEMON $RSYSLOGD && exit 0 || exit $?
;;
*)
echo "Usage: $SCRIPTNAME
{start|stop|rotate|restart|force-reload|try-restart|status}" >&2
exit 3
;;
esac
:
/etc/rsyslog.conf changed:
module(load="imuxsock") # provides support for
Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )
Geert Stappers schreef op 2017-12-22 10:18: Control: owner -1 ! Also, is this the real source (AKA, "preferred form for modification")? Assembler is a valid language, generated assembler (nor generated shell, generated C, ...) is not. Some parts say about a configuration process that, as it seems to me, expands variables for a particular platform. ; If this is a configured assembly file, it should be accompanied with configured ; documentation (texinfo, ps, html.) ; WITHOUT THE DOCUMENTATION: GIVE UP! GET THE REAL THING! ; You have a configured system, if there are NO curly brackets on the next line. ; ; ; Configuration of this particular version: ; 32-bits protected mode ; running under Linux ; with native forth I/O So yes, I have the feeling that I'm dealing with generated assembly. The .orig.tar.gz does have ci86.lina.fas I wonder what generated it and from what. @Albert: Would you please elaborate? I appreciate and understand what "prefered form of modification is". I also understand that Debian must thread carefully here, and not accept packages that bend the rules. This package certainly doesn't not go against the spirit of the rules and may only superficially seem not to obey the letter of the law. This has been discussed already to some extent. There is a choice of assemblers . I've a kind of generic assembler code, (that is not assembler code that could be assembled by any assembler) and then an m4 script that transforms it to either fasm, .s nasm or even tasm or masm format. This is *not* generated assembler. The assembler is a genuine source. There is only a limited processing between equivalent forms, to present a readable and modifiable source to some one inclined to modify lina. There is a one to one correspondance between a line with an assembler instruction in lina.fas lina.s lina.asm lina.nasm and the preconfiguration system, and they all correspond to the same binary code. The base system also contains code for MS-windows and MSDOS or even stand alone. This is removed by m4 to present a proper Linux source. Nothing is gained by drawing all this linux foreign code into a Debian package, merely to remove it. The more so as this system is available and GPL-ed in its own right to be used by anybody interested in e.g. an UEFI system booting directly into Forth. Likewise there is also base documentation with an m4 provision to remove all the MS related documentation for a Linux texinfo file. I wanted to avoid the situation with the gnu assembler where almost all options are irrelevant for the processor one is currently working with. So in short it is a matter of configuration and selection, not generation. Groeten Geert Stappers Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )
Adam Borowski schreef op 2017-12-21 20:26: On Wed, Dec 06, 2017 at 05:51:50PM +0100, Albert van der Horst wrote: * Package name: lina Version : 5.3.0-1 Hi! I for one don't know the slightest bit about Forth, but as no one has taken this RFS, I can review packaging only -- which, while not ideal, is not a show stopper for uploading. Thanks for the review. It was hard to do everything right from the Debian documents alone. With the remarks from you and Geert Stappers, I hope to upload a version 5.3.0-1 that address most of the issues, hopefully all. I'm afraid the package fails to build, you need to add fasm to Build-Depends. Also, "defects detected by lintian" means nothing. What matters is _what_ needed to be fixed, not what tool was used to spot the defect. And I always chastize others for non meaningful change messages ... Before we even start, it would be nice if you could address the rest of issues detected by lintian -- an automated system saves a lot of human time. Sure thing. Don't waste any more time until I've addressed those. Also, is this the real source (AKA, "preferred form for modification")? This is important and I've addressed it in an answer to Geert. Your choice of a language to code a compiler is... interesting. But then, at least it's not node.js, php or python :) As I said in a reply to Geert, this is a compiler, not a scripting language on top of C. ;-) A true compiler is written in its own language after an assembly bootstrap. lina is in this vein, the bulk of the code is in the library, e.g. lina -c hello.frt runs code from the third (c-th) "block" of the library in order to compile hello.frt into an elf executable. May your family not interfere with hacking the next few days. Meow! The holidays are perfect for hacking. -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "lina" * Package name: lina Version : 5.3.0-1 Upstream Author : Albert van der Horst * URL : https://github.com/albertvanderhorst/ciforth * License : LGPL2 Section : devel It builds those binary packages: lina - close to ISO Forth interpreter and compiler To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lina Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lina/lina_5.3.0-1.dsc Changes since the last upload: * Initial release (Closes: #859130) * Added a Makefile * Administrative defects detected by lintian The relevance of this Forth in regard of the availability of other Forth's in Debian : * the connection with Forth's on microcontrollers, in partical http://home.hccnet.nl/willem.ouwerkerk/pr-bytef.htm (8051 AVR) http://home.hccnet.nl/anij/nof/noforth.html (MSP430) Tools in behalf of these (ide's, metacompiler, calibration programs) can then be built using a trusted compiler. * building real time control, portable accross Linux and MS-Windows's e.g. (requires a true parallel port:) http://home.hccnet.nl/a.w.m.van.der.horst/manx.html * ease of making elf executables and simplicity in general e.g. https://github.com/albertvanderhorst/primecounting/tree/master/sieve http://home.hccnet.nl/a.w.m.van.der.horst/ciasdis_1.0_all.deb Sponsoring efforts should be low, in view of one assembler source and basically a one line build. Regards, Albert van der Horst -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#875829: prosody crashed on error handling for stream errors
Package: prosody Version: 0.9.12-2 Severity: important Tags: patch hi, with the lua-socket version from debian stretch, prosody as shipped in the debian package crashes when handling (at least some) stream errors, see also upstream bug [0]. as mentioned in the upstream bug, the patches in [1] and [2] fix this crash as it seems (i'm testing it further, but sofar everything looks good) could these 2 patches please be applied for the debian package? thx, regards albert [0] <https://prosody.im/issues/issue/987> [1] <https://hg.prosody.im/0.9/rev/176b7f4e4ac9> [2] <https://hg.prosody.im/0.9/rev/adfffc5b4e2a> -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages prosody depends on: ii adduser 3.115 ii libc6 2.24-11+deb9u1 ii libidn111.33-1 ii libssl1.1 1.1.0f-3 ii lsb-base9.20161125 ii lua-expat [lua5.1-expat]1.3.0-4 ii lua-filesystem [lua5.1-filesystem] 1.6.3-1 ii lua-sec [lua5.1-sec]0.6-3 ii lua-socket [lua5.1-socket] 3.0~rc1+git+ac3201d-3 ii lua5.1 5.1.5-8.1+b2 ii ssl-cert1.0.39 Versions of packages prosody recommends: ii lua-event [lua5.1-event] 0.4.3-2 Versions of packages prosody suggests: pn lua-dbi-mysql pn lua-dbi-postgresql pn lua-dbi-sqlite3 ii lua-zlib0.2+git+1+9622739-2+b2 -- Configuration Files: /etc/prosody/prosody.cfg.lua changed [not included] -- no debconf information
Bug#870145: ITA: localepurge -- reclaim disk space by removing unneeded localizations
Hello, I registered you as owner of the bug 870145 because I understand you are intending to adopt localepurge package. Also I changed the subject. Thanks for your interest!
Bug#870891: molly-guard: guards against successful reboot
tags 870891 + confirmed patch thanks Thanks for the report. Please, could you test the following patch? https://gitlab.com/sim6/molly-guard/compare/master...sim6_force_reboot
Bug#868666: [debian-mysql] Bug#868666:
Hi Ondrej, Thanks for the update, seems like the packages aren't out in the mirrors yet, I'll test them asap when available and report back, pitty they didn't make it into 9.1 Best, Albert On Mon, Jul 24, 2017 at 2:05 PM, Ondřej Surý wrote: > Control: tags 865093 -moreinfo > > Hi Albert, > > stretch-pu has been already issued and recently updated to 10.1.25: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865093 > > Cheers, > Ondřej > > On 24 July 2017 13:51:12 Albert Casademont > wrote: > >> Could someone please review this? A segfault is a pretty serious issue :/ >> ___ >> pkg-mysql-maint mailing list >> pkg-mysql-ma...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint >> >
Bug#868666:
Could someone please review this? A segfault is a pretty serious issue :/
Bug#867331: Patch for sysvinit
tags 867331 + patch thanks Please could you test the following patch: https://gitlab.com/sim6/molly-guard/compare/master...sim6_sysvinit
Bug#868666: mariadb-server 10.1.23 segfaults
Package: mariadb-server Version: 10.1.23-9+deb9u1 Dear maintainer, We've been seing some segfaults when executing complex queries on cross-database joins after upgrading to Stretch from Jessie. Bug seems reported (only affects 10.1.23) and fixed upstream (10.1.24) at https://jira.mariadb.org/browse/MDEV-12673 and also related https://jira.mariadb.org/browse/MDEV-12726. Could that patch please be applied? Thanks, Albert Casademont
Bug#867331: Confirm #867331
tag 867331 confirmed thanks Thanks for the report.
Bug#856170: molly-guard: hostname should not be case-sensitive
I rewrite it without the option: https://gitlab.com/sim6/molly-guard/compare/master...sim6_hostname_case_insensitive_always I will try to create a new version of the package. Thanks!
Bug#856170: molly-guard: hostname should not be case-sensitive
Thanks for your comments. The tr command is introducing a dependency of coreutils package. This is not strictly true because we use cat. But if it is configurable we can recommend coreutils but if this is not configurable we need to add coreutils as dependency. I can change the default value of the option, but if you prefer I will remove the option.
Bug#837928: Bug#837925: usrmerge: fails to merge with molly-guard installed
I can't reproduce the failure on current fresh sid installation. I'm trying to reproduce it with the following commands: apt install molly-guard apt install libfile-find-rule-perl apt download usrmerge dpkg --force-conflicts -i usrmerge_16_all.deb Could you give me any hint or can I close the bug?
Bug#856170: molly-guard: hostname should not be case-sensitive
What do you think about this patch? https://gitlab.com/sim6/molly-guard/compare/master...sim6_hostname_case_insensitive
Bug#866803: libghc-xmonad-dev: dependency problem with ghc 8.0.2-5
Package: libghc-xmonad-dev Version: 0.12-5+b1 Severity: normal Dear Maintainer, there is dependency problem in unstable currently that prevents the upgrade of the ghc package to the latest version (8.0.2-5 at the time of writing) or prevents the installtion on a fresh install, here the output of trying it in a bare chroot: root@loki:/# apt install xmonad libghc-xmonad-dev Reading package lists... Done Building dependency tree... Done 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: The following packages have unmet dependencies: libghc-xmonad-dev : Depends: libghc-x11-dev-1.6.1.2-588a9 but it is not installable Depends: libghc-base-dev-4.9.0.0-5e731 but it is not installable Depends: libghc-containers-dev-0.5.7.1-8be09 but it is not installable Depends: libghc-data-default-dev-0.7.1.1-8e73d but it is not installable Depends: libghc-directory-dev-1.2.6.2-958b8 but it is not installable Depends: libghc-extensible-exceptions-dev-0.1.1.4-7f6c0 but it is not installable Depends: libghc-filepath-dev-1.4.1.0-6e799 but it is not installable Depends: libghc-mtl-dev-2.2.1-3d1c9 but it is not installable Depends: libghc-process-dev-1.4.2.0-e39cb but it is not installable Depends: libghc-setlocale-dev-1.0.0.4-b209c but it is not installable Depends: libghc-unix-dev-2.7.2.0-220bd but it is not installable Depends: libghc-utf8-string-dev-1.0.1.1-6f2d5 but it is not installable Recommends: libghc-xmonad-contrib-dev but it is not going to be installed E: Unable to correct problems, you have held broken packages. it looks like it needs to be recompiled against the new ghc. regards, albert -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libghc-xmonad-dev depends on: ii ghc [libghc-unix-dev-2.7.2.0-220bd] 8.0.1-17+b1 ii libc62.24-12 pn libghc-base-dev-4.9.0.0-5e731 pn libghc-containers-dev-0.5.7.1-8be09 ii libghc-data-default-dev [libghc-data-default-dev-0.7.1.1-8e 0.7.1.1-2+b1 pn libghc-directory-dev-1.2.6.2-958b8 ii libghc-extensible-exceptions-dev [libghc-extensible-excepti 0.1.1.4-8 pn libghc-filepath-dev-1.4.1.0-6e799 ii libghc-mtl-dev [libghc-mtl-dev-2.2.1-3d1c9] 2.2.1-5 pn libghc-process-dev-1.4.2.0-e39cb ii libghc-setlocale-dev [libghc-setlocale-dev-1.0.0.4-b209c]1.0.0.4-3 ii libghc-utf8-string-dev [libghc-utf8-string-dev-1.0.1.1-6f2d 1.0.1.1-4+b1 ii libghc-x11-dev [libghc-x11-dev-1.6.1.2-588a9]1.6.1.2-7 ii libgmp10 2:6.1.2+dfsg-1 ii libx11-6 2:1.6.4-3 ii libx11-dev 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxinerama-dev 2:1.1.3-1+b3 ii libxinerama1 2:1.1.3-1+b3 ii libxrandr2 2:1.5.1-1 Versions of packages libghc-xmonad-dev recommends: ii libghc-xmonad-contrib-dev 0.12-3+b1 Versions of packages libghc-xmonad-dev suggests: pn libghc-xmonad-doc pn libghc-xmonad-prof -- no debconf information
Bug#864739: amule-daemon: amuled --ec-config crashes on fresh installation
Package: amule-daemon Version: 1:2.3.2-1+b2 Severity: important Dear Maintainer, amuled --ec-config command crashes on fresh installation with the following output: sim6@storagetrunk:~$ amuled --ec-config 2017-06-13 22:48:54: Initialising aMuleD 2.3.2 compiled with wxBase(GTK2) v3.0.2 and Boost 1.62 2017-06-13 22:48:54: Checking if there is an instance already running... 2017-06-13 22:48:54: No other instances are running. 2017-06-13 22:48:59: EC configuration Enter password for mule connection: 2017-06-13 22:49:02: Password set and external connections enabled. !2017-06-13 22:49:02: ERROR: Info --- This is the first time you run aMule 2.3.2 --- !2017-06-13 22:49:02: More information, support and new releases can found at our homepage, !2017-06-13 22:49:02: at www.aMule.org, or in our IRC channel #aMule at irc.freenode.net. !2017-06-13 22:49:02: Feel free to report any bugs to http://forum.amule.org 2017-06-13 22:49:03: ListenSocket: Ok. 2017-06-13 22:49:03: Loading temp files from /home/sim6/.aMule/Temp. 2017-06-13 22:49:03: All PartFiles Loaded. 2017-06-13 22:49:03: amuled: OnInit - starting timer 2017-06-13 22:49:03: Asio thread 1 started 2017-06-13 22:49:03: Asio thread 2 started 2017-06-13 22:49:03: Asio thread 4 started 2017-06-13 22:49:03: Asio thread 3 started Assertion failed: ../src/common/socketiohandler.cpp:Install_Callback:54: Assertion 'socket->m_fd != -1' failed. shouldn't be called on invalid socket Backtrace follows: [3] wxOnAssert(char const*, int, char const*, char const*, char const*) in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7fc1f33cf23a] [4] ?? in /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0[0x7fc1f383e023] [5] ?? in /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0[0x7fc1f3835675] [6] ?? in /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0[0x7fc1f3836ae0] [7] wxSocketClient::DoConnect(wxSockAddress const&, wxSockAddress const*, bool) in /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0[0x7fc1f3836d3c] [8] wxHTTP::GetInputStream(wxString const&) in /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0[0x7fc1f38270af] [9] ?? in amuled[0x56259b0533ae] [10] ?? in amuled[0x56259b05419e] [11] wxThread::CallEntry() in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7fc1f3521012] [12] ?? in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7fc1f35296a3] [13] ?? in /lib/x86_64-linux-gnu/libpthread.so.0[0x7fc1f4a46494] [14] clone in /lib/x86_64-linux-gnu/libc.so.6[0x7fc1f280daff] Aborted Thanks! -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages amule-daemon depends on: ii amule-common 1:2.3.2-1 ii libboost-system1.62.0 1.62.0+dfsg-4 ii libc6 2.24-11 ii libcrypto++6 5.6.4-7 ii libgcc11:6.3.0-18 ii libpng16-161.6.28-1 ii libreadline7 7.0-3 ii libstdc++6 6.3.0-18 ii libupnp6 1:1.6.19+git20160116-1.2 ii libwxbase3.0-0v5 3.0.2+dfsg-4 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages amule-daemon recommends: ii amule-utils 1:2.3.2-1+b2 ii unzip6.0-21 amule-daemon suggests no packages. -- no debconf information
Bug#860193: laptop-detect: false-positive on desktop if bluetooth k/b or mouse are used
Please could you test the following version? https://gitlab.com/debiants/laptop-detect/blob/sim6_non_device_acpi_batteries/laptop-detect.in
Bug#860193: laptop-detect: false-positive on desktop if bluetooth k/b or mouse are used
Thanks for the report. I will fix it.
Bug#858601: [Pkg-samba-maint] Bug#858601: Bug#858601: winbind: user authentication using windows domain fails after upgrade to 4.2.14+dfsg-0+deb8u4
On Fri, Mar 31, 2017 at 12:33:29AM +0200, Mathieu Parent wrote: > 2017-03-30 23:50 GMT+02:00 Albert Dengg : > > sorry for the late reply i was a bit busy and re-upgrading the > > server is a slight problem as it is an activly used producticion > > server were people need > > Reading your smb.conf, it looks like you're affectected by the > vfs_shadow_copy2 regression. > > Can you test those packages, signed by me: > https://people.debian.org/~sathieu/samba/ ah...you guessed right, these packages seem to fix the problem, i will test a bit but it looks like the problem is fixed (including the winbindd error messages, for some reason) thanks for the fast reply and sorry for me jumping to the wrong conclutions. regards, albert signature.asc Description: PGP signature
Bug#858601: [Pkg-samba-maint] Bug#858601: winbind: user authentication using windows domain fails after upgrade to 4.2.14+dfsg-0+deb8u4
sorry for the late reply i was a bit busy and re-upgrading the server is a slight problem as it is an activly used producticion server were people need On Thu, Mar 30, 2017 at 10:34:28PM +0200, Mathieu Parent wrote: > )Control: tag -1 + moreinfo > > 2017-03-24 15:20 GMT+01:00 Mathieu Parent : > > 2017-03-24 11:19 GMT+01:00 Albert Dengg : > >> Package: winbind > >> Version: 2:4.2.14+dfsg-0+deb8u2 > >> Severity: important > >> > >> after upgrading windbind and samba to 4.2.14+dfsg-0+deb8u4, authentication > >> of domains users using winbind > >> does not work anymore: > >> winbindd[8142]: [2017/03/24 10:20:10.040610, 0] > >> ../source3/winbindd/winbindd_group.c:45(fill_grent) > >> winbindd[8142]: Failed to find domain ''. Check connection to trusted > >> domains! > >> > >> (getent did list at least users from winbind) > >> > >> the domain ins specified in smbd.conf and it works as expected in > >> 4.2.14+dfsg-0+deb8u2 > > > > Please send us your smb.conf. see attachment (i changed the domain name to something neutral, but > > > > What does "net ads testjoin" tells? Join is OK (and both 'getent passwd' as well as 'getent group' produces the desired output) > > Appart from the above. This looks very strange. Nothing was changed on > the winbind side between those versions. > > Are you able to use gdb and post the backtrae in this function > (fill_grent) and find why dom_name is empty? i tried to install samba-dbg and start winbindd using gdb. however a breakpoint on fill_grent did not trigger for some reason (i played around with follow-mode and tried both starting without passing arguments as well as passing -i) > > Is your smb.conf a symlink? no side note: i downgraded initially to work around the problem and upgraded today to do the test (with the same result), but a downgrade of the following packages solved it again: libnss-winbind libpam-winbind libsmbclient libwbclient0 python-samba samba samba-common samba-common-bin samba-dbg samba-dsdb-modules samba-libs samba-vfs-modules winbind regards, albert # # Sample configuration file for the Samba suite for Debian GNU/Linux. # # # This is the main Samba configuration file. You should read the # smb.conf(5) manual page in order to understand the options listed # here. Samba has a huge number of configurable options most of which # are not shown in this example # # Some options that are often worth tuning have been included as # commented-out examples in this file. # - When such options are commented with ";", the proposed setting #differs from the default Samba behaviour # - When commented with "#", the proposed setting is the default #behaviour of Samba but the option is considered important #enough to be mentioned here # # NOTE: Whenever you modify this file you should run the command # "testparm" to check that you have not made any basic syntactic # errors. #=== Global Settings === [global] workgroup = SOMEDOMAIN server string = Samba Server Version %v security = ads realm = SOMEDOMAIN.LOCAL domain master = no local master = no preferred master = no socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 use sendfile = true idmap config * : backend = tdb idmap config * : range = 10-29 idmap config SOMEDOMAIN : backend = rid idmap config SOMEDOMAIN : range = 1-9 winbind separator = + winbind enum users = yes winbind enum groups = yes winbind use default domain = yes winbind nested groups = yes winbind refresh tickets = yes template homedir = /home/%D/%U template shell = /bin/false client use spnego = yes client ntlmv2 auth = yes encrypt passwords = yes restrict anonymous = 2 log file = /var/log/samba/log.%m max log size = 50 loglevel = 0 ea support = yes acl check permissions = yes inherit acls =yes csc policy = disable store dos attributes = yes dos filemode = no load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes # Share Definitions == [Individuell] comment = "Verzeichnis fuer Datenaustausch" path = /pools/share/Individuell read only = no browseable = yes guest ok = no delete readonly = yes vfs objects = acl_xattr shadow_copy2 map acl inherit = Yes shadow: snapdir = .zfs/snapshot shadow: sort = desc shadow: format = %Y-%m-%d-%H%M nfs4:mode = special nfs4:acedup =
Bug#859130: TAG: lina -- iso-compliant Forth interpreter and compiler
Package: wntpp Severity: wishlist Information: Homepage: https://github.com/albertvanderhorst/ciforth lina is a 32 bit classic Forth system, (mostly) compliant to the ISO Forth94 standard, with a library in source form. It is small, yet allows to generate elf-executables that can be shipped to and run by non-Forth-aware users. This is unique among Forth's available to linux. It has no dependancies, so it can be used instead of a c-compilation system or Python scripter, where size matters. Also simplicity engenders reliability. Architecture: This package is (for now) limited to i386 and amd86 architectures. Background: The system is in use since 2000. It has an extensive regressiontest and comprehensive documentation. It is part of the ciforth family with compatible systems for MS-windows, OSX and MS-DOS (and similar compilers for Dec Alpha, 6809, Renesas 16, ARM) It has been used to build an assembler/disassembler (ciasdis) that has some notoriety. The license is GPL2 for the compiler itself. LPGPL applies to all library elements, including those contained within the compiler executable. Releases: https://github.com/albertvanderhorst/ciforth/release contains current releases. Binary releases are at 5.3.0 for Linux, MS-windows and OSX. Packaging: release/lina_5.3.0_i386.deb is generated by a script debian.sh from a lina_#.tar.gz release. A binary release contains the one(!) source file, so a binary release can serve as an upstream source package. This should help a prospective sponsor to swiftly go towards RFP. Maintenance: I'm the developer and maintainer since 2000 and I'm planning on continuing to develop and maintain it. Also I'm willing to adapt the package in order to smoothen the cooperation with Debian. Greetings, Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Bug#858601: winbind: user authentication using windows domain fails after upgrade to 4.2.14+dfsg-0+deb8u4
Package: winbind Version: 2:4.2.14+dfsg-0+deb8u2 Severity: important after upgrading windbind and samba to 4.2.14+dfsg-0+deb8u4, authentication of domains users using winbind does not work anymore: winbindd[8142]: [2017/03/24 10:20:10.040610, 0] ../source3/winbindd/winbindd_group.c:45(fill_grent) winbindd[8142]: Failed to find domain ''. Check connection to trusted domains! (getent did list at least users from winbind) the domain ins specified in smbd.conf and it works as expected in 4.2.14+dfsg-0+deb8u2 -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages winbind depends on: ii libbsd00.7.0-2 ii libc6 2.19-18+deb8u7 ii libldap-2.4-2 2.4.40+dfsg-1+deb8u2 ii libpopt0 1.16-10 ii libtalloc2 2.1.2-0+deb8u1 ii libtdb11.3.6-0+deb8u1 ii libtevent0 0.9.28-0+deb8u1 ii libwbclient0 2:4.2.14+dfsg-0+deb8u2 ii multiarch-support 2.19-18+deb8u7 ii samba 2:4.2.14+dfsg-0+deb8u2 ii samba-libs 2:4.2.14+dfsg-0+deb8u2 winbind recommends no packages. Versions of packages winbind suggests: ii libnss-winbind 2:4.2.14+dfsg-0+deb8u2 ii libpam-winbind 2:4.2.14+dfsg-0+deb8u2 -- no debconf information
Bug#857428: debian/postrm to remove the configuration files created by debian/postinst
tags 857428 patch thanks Hello, I created a debian/postrm to remove the configuration files created by debian/postinst: https://gitlab.com/sim6/debian-matrix-synapse/compare/debian%2Fmaster...sim6_postrm I also uploaded the package to mentors: https://mentors.debian.net/package/matrix-synapse Thanks.
Bug#849396: Remove the web part of rspamd
What do you think about remove the web part?
Bug#659404: laptop-detect: Use /sys/devices/virtual/dmi/id/chassis_type as alternative to dmidecode?
Hello, Thanks for your contribution to laptop-detect. I'm doing an ITA of this package and I would like include your contribution. I created the following commit but please do a merge request if you prefer. https://gitlab.com/debiants/laptop-detect/commit/ac832efccff4ca87a5ca01a7c3cfbb808fa386ba Thanks again.
Bug#850163: xpdf/poppler miscommunication
El diumenge, 19 de febrer de 2017, a les 23:00:53 CET, Andries E. Brouwer va escriure: > If you prefer to give that program a different name, let us call it xyzpdf. > So, the situation is that there is a widely used program called xyzpdf. > This program uses libpoppler, that is, ldd shows > > % ldd /usr/bin/xyzpdf > .. > libpoppler.so.58 => /usr/lib/x86_64-linux-gnu/libpoppler.so.58 > > Now this libpoppler as used by this program fails to work. > Maybe libpoppler is not buggy, but it blindly uses invalid data. You want libpoppler to be Clippy? Sincerely, if you tell poppler the data is in /foo it'll read /foo, if the data is not htere, though luck, maybe you want to fix the widely used program called xyzpdf to not tell poppler that the data is in a location /foo that doesn't really hold the data Best Regards, Albert
Bug#850163: xpdf/poppler miscommunication
This is not a bug in poppler, it does what we intented it to do.
xpdf doesn't use poppler.
If you have a xpdf that is using poppler someone is giving you something that
they call xpdf but it is not really xpdf.
Please don't contact the poppler project about bugs in xpdf since it has
nothing to do with us.
Best Regards,
Albert
El diumenge, 19 de febrer de 2017, a les 20:16:13 CET, Andries E. Brouwer va
escriure:
> Masanori Goto reports (Debian bug #850163):
> "Syntax Error: Missing language pack for 'Adobe-Japan1' mapping"
>
> I see the same problem. A silly workaround is adding links
>
>/cMap -> /usr/share/poppler/cMap
>/cidToUnicode -> /usr/share/poppler/cidToUnicode
>/nameToUnicode -> /usr/share/poppler/nameToUnicode
>/unicodeMap -> /usr/share/poppler/unicodeMap
>
> With these links in place his example file displays well,
> and no error messages are given.
>
> What happens is that xpdf calls poppler, and poppler needs
> to find appropriate cMap, cidToUnicode, nameToUnicode, unicodeMap
> files and directories. The poppler code that I am looking at says
>
> (poppler/GlobalParams.cc line 671)
>
> const char *dataRoot = popplerDataDir ? popplerDataDir : POPPLER_DATADIR;
>
> and the files mentioned are searched for in %s/cMap etc, where %s is
> substituted by dataRoot. The default POPPLER_DATADIR is /usr/share/poppler,
> and if this line was simplified to
>
> const char *dataRoot = POPPLER_DATADIR;
>
> then all would work. But the constructor of GlobalParams is called
> with an empty string "", and %s/cMap becomes /cMap, which is why
> creating these links solves the problem.
>
> I suggest that this be fixed both in xpdf and in poppler.
>
> The poppler fix might be to change the above line into
>
> const char *dataRoot = (popplerDataDir && *popplerDataDir) ? popplerDataDir
> : POPPLER_DATADIR;
>
> The fixed poppler works together with the current xpdf and all is well.
>
> How come GlobalParams("") is called?
> The xpdf 3.04 source calls
> globalParams = new GlobalParams(cfgFileName);
> where
> static char cfgFileName[256] = "";
>
> It appears that this xpdf call is entirely misguided:
> what poppler wants is a directory, a prefix, something like
> /usr/share/poppler, but cfgFileName is the name of the
> xpdfrc configuration file, the thing set by the -cfg option.
>
> So, in the long run also xpdf needs to be fixed.
>
> Andries
Bug#683103: Same issue upgrading from wheezy to jessie
Hello, I found the same issue upgrading a VPS from wheezy to jessie with the version 2.88dsf-59. $ ls -l /dev/shm lrwxrwxrwx 1 root root 8 Nov 28 2014 /dev/shm -> /run/shm $ ls -l /run/shm lrwxrwxrwx 1 root root 8 Oct 13 2015 /run/shm -> /dev/shm $ mountpoint /dev /dev is not a mountpoint Thanks. signature.asc Description: OpenPGP digital signature
Bug#811129: Bug #811129: fails to boot on OpenRD
Hello Vagrant, On Mon, 25 Jan 2016 10:00:59 -0800, Vagrant Cascadian wrote: > On 2016-01-25, Albert ARIBAUD wrote: > > On Mon, 25 Jan 2016 16:15:02 +0100, Albert ARIBAUD > > wrote: > >> I /think/ I've got the bug cornered (actually, I had a patch for it > >> already submitted...) but it is not the only problem with 2016.01 on > >> Open-RD. > ... > > The fix consists in two patches. I have tested the fix for the boot > > issue by applying the two patches over the non-functional source code > > of the package, then re-building for openrd, running the kwb via JTAG > > and finally flashing it -- all works fine. > > Great! > > > These two patches /will/ end up in mainline U-Boot (they're actually > > an ongoing submission of mine), but the first official release where > > they'll appear will be 2016.04. Meanwhile, I think a new 2016.01 Debian > > package should be pushed with the two patches added, so that the faulty > > package gets superseded. > > Sounds good. I'll apply them to the debian 2016.01 package if you commit > to get them upstream. :) Already done on my side :) as the v7 was actually merged to u-boot/master on the 14th -- I only noticed that now, while wrapping up this test. > > How do we proceed from here? Should I post the patches in this > > discussion? > > Yes, please post the patches to this thread. If there are URLs for the > submitted patches (e.g. patchwork), that would be nice, but not strictly > necessary. Attached to this mail, and here are the PW URLs: http://patchwork.ozlabs.org/patch/548644/ http://patchwork.ozlabs.org/patch/548645/ > live well, > vagrant Amicalement, -- Albert.diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S index 26a5934..90ee7e0 100644 --- a/arch/arc/lib/start.S +++ b/arch/arc/lib/start.S @@ -50,18 +50,20 @@ ENTRY(_start) 1: #endif - /* Setup stack- and frame-pointers */ + /* Establish C runtime stack and frame */ mov %sp, CONFIG_SYS_INIT_SP_ADDR mov %fp, %sp - /* Allocate and zero GD, update SP */ + /* Allocate reserved area from current top of stack */ mov %r0, %sp - bl board_init_f_mem - - /* Update stack- and frame-pointers */ + bl board_init_f_alloc_reserve + /* Set stack below reserved area, adjust frame pointer accordingly */ mov %sp, %r0 mov %fp, %sp + /* Initialize reserved area - note: r0 already contains address */ + bl board_init_f_init_reserve + /* Zero the one and only argument of "board_init_f" */ mov_s %r0, 0 j board_init_f diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 80548eb..4f2a712 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -83,8 +83,9 @@ ENTRY(_main) bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ #endif mov r0, sp - bl board_init_f_mem + bl board_init_f_alloc_reserve mov sp, r0 + bl board_init_f_init_reserve mov r0, #0 bl board_init_f diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index cef1c71..b4fc760 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -75,8 +75,10 @@ ENTRY(_main) ldr x0, =(CONFIG_SYS_INIT_SP_ADDR) #endif bic sp, x0, #0xf /* 16-byte alignment for ABI compliance */ - bl board_init_f_mem + mov x0, sp + bl board_init_f_alloc_reserve mov sp, x0 + bl board_init_f_init_reserve mov x0, #0 bl board_init_f diff --git a/arch/microblaze/cpu/start.S b/arch/microblaze/cpu/start.S index 14f46a8..206be3e 100644 --- a/arch/microblaze/cpu/start.S +++ b/arch/microblaze/cpu/start.S @@ -25,7 +25,7 @@ _start: addi r8, r0, __end mts rslr, r8 - /* TODO: Redo this code to call board_init_f_mem() */ + /* TODO: Redo this code to call board_init_f_*() */ #if defined(CONFIG_SPL_BUILD) addi r1, r0, CONFIG_SPL_STACK_ADDR mts rshr, r1 @@ -142,7 +142,7 @@ _start: ori r12, r12, 0x1a0 mts rmsr, r12 - /* TODO: Redo this code to call board_init_f_mem() */ + /* TODO: Redo this code to call board_init_f_*() */ clear_bss: /* clear BSS segments */ addi r5, r0, __bss_start diff --git a/arch/nios2/cpu/start.S b/arch/nios2/cpu/start.S index 54787c5..204d0cd 100644 --- a/arch/nios2/cpu/start.S +++ b/arch/nios2/cpu/start.S @@ -106,14 +106,18 @@ _reloc: stw r0, 4(sp) mov fp, sp - /* Allocate and zero GD, update SP */ + /* Allocate and initialize reserved area, update SP */ mov r4, sp - movhi r2, %hi(board_init_f_mem@h) - ori r2, r2, %lo(board_init_f_mem@h) + movhi r2, %hi(board_init_f_alloc_reserve@h) + ori r2, r2, %lo(board_init_f_alloc_reserve@h) callr r2 - - /* Update stack- and frame-pointers */ mov sp, r2 + mov r4, sp + movhi r2, %hi(board_init_f_init_reserve@h) + ori r2, r2, %lo(board_init_f_init_reserve@h) + callr r2 + + /* Update frame-pointer */ mov fp, sp /* Call board_init_f -- never returns */ diff --git a/arch/powerpc/cpu/ppc4xx/start.S b/arch/powerpc/cpu/ppc4xx/start.S index 77d4040..cb6
Bug#811129: Bug #811129: fails to boot on OpenRD
On Mon, 25 Jan 2016 16:15:02 +0100, Albert ARIBAUD wrote: > Hello all, > > I /think/ I've got the bug cornered (actually, I had a patch for it > already submitted...) but it is not the only problem with 2016.01 on > Open-RD. > > One, major, other problem is that the 2016.01 Open-RD U-Boot does not > have the "sf" command. Once the boot issue is fixed, you can flash that > U-Boot on the NOR SPI... And then next time you want to flash a new > U-Boot, you're SOL because "sf probe" and "sf write" won't work. :/ > > I am working on reintegrating the "sf" command. Once this is done, I'll > be able to properly test the boot bug and /then/ the U-Boot package can > be updated. Sorry, I mixed up different boards... no sf command on OpenRD. The fix consists in two patches. I have tested the fix for the boot issue by applying the two patches over the non-functional source code of the package, then re-building for openrd, running the kwb via JTAG and finally flashing it -- all works fine. These two patches /will/ end up in mainline U-Boot (they're actually an ongoing submission of mine), but the first official release where they'll appear will be 2016.04. Meanwhile, I think a new 2016.01 Debian package should be pushed with the two patches added, so that the faulty package gets superseded. How do we proceed from here? Should I post the patches in this discussion? Amicalement, -- Albert.
Bug#811129: Bug #811129: fails to boot on OpenRD
Hello all, I /think/ I've got the bug cornered (actually, I had a patch for it already submitted...) but it is not the only problem with 2016.01 on Open-RD. One, major, other problem is that the 2016.01 Open-RD U-Boot does not have the "sf" command. Once the boot issue is fixed, you can flash that U-Boot on the NOR SPI... And then next time you want to flash a new U-Boot, you're SOL because "sf probe" and "sf write" won't work. :/ I am working on reintegrating the "sf" command. Once this is done, I'll be able to properly test the boot bug and /then/ the U-Boot package can be updated. Amicalement, -- Albert.
Bug#811129: Bug #811129: fails to boot on OpenRD
Hello Vagrant and Martin, On Thu, 21 Jan 2016 14:08:50 -0800, Vagrant Cascadian wrote: > On 2016-01-21, Albert ARIBAUD wrote: > > On Sat, 16 Jan 2016 12:21:06 +0100, Albert ARIBAUD > > wrote: > >> On Fri, 15 Jan 2016 15:30:47 -0800, Martin Michlmayr > >> wrote: > >> > * Albert ARIBAUD [2016-01-15 22:52]: > >> > You can find the build log here, btw: > >> > https://buildd.debian.org/status/fetch.php?pkg=u-boot&arch=armel&ver=2016.01%2Bdfsg1-1&stamp=1452650663 > >> > >> Thanks. I see the build was done by newer gcc (5.3.1) and binutils > >> (2.25.90). I will set up a local buildd so that I can reproduce this( > >> and future builds an analyze them as needed). > > > > Hmm, installing a complete buildd instance seems overkill. Is there a > > simple way to set up a build environment identical to that of the > > buildd which created u-boot.kwb? I've got VMs with basic Jessie, > > Testing and Unstable installs. > > Are your virtual machines running armel? The builds in debian are native > builds, so to really replicate the build environment, you'd need to run > the builds natively as well. There are cross-toolchains available in > Debian unstable/sid, though that won't be the exact build environment, > of course. > > In any case, you'll need deb-src lines in your /etc/apt/sources.list* > files, corresponding to each of the deb lines, such as: > > deb http://httpredir.debian.org/debian sid main > deb-src http://httpredir.debian.org/debian sid main > > And then, to install the build toolchain: > > apt-get install build-essential fakeroot devscripts > apt-get build-dep u-boot > apt-get install crossbuild-essential-armel # if using cross-toolchains > > I do find sbuild + schroot to be my preferred build environment, which > handles the steps above for most cases. Some people also use pbuilder or > one of the pbuilder-based variants such as cowbuilder, which has similar > functionality. > > Hope that helps; Thanks for testing! Thanks to both of you, Martin and Vagrant, for your suggestions. Seeing as I want to replicate the build as closely as it happens, I'll go the armel native machine route and set up my old faithful EDMini-V2 as a build machine. Amicalement, -- Albert.
Bug#811129: Bug #811129: fails to boot on OpenRD
Hello Albert, On Sat, 16 Jan 2016 12:21:06 +0100, Albert ARIBAUD wrote: > Hello Martin, > > On Fri, 15 Jan 2016 15:30:47 -0800, Martin Michlmayr > wrote: > > * Albert ARIBAUD [2016-01-15 22:52]: > > > > Would you be so kind and test > > > > https://d-i.debian.org/daily-images/armel/daily/kirkwood/u-boot/openrd-client/ > > > > > > > > This is 2016.01 (no rc) > > > > > > It is the same as the one I tested first and which failed. I had > > > extracted it from > > > http://ftp.de.debian.org/debian/pool/main/u/u-boot/u-boot_2016.01+dfsg1-1_armel.deb > > > > Yes, they are the same. The d-i build process simply extracts the > > u-boot binary from the .deb, so it's easier for people to download. > > > > I'm surprised it fails to boot. Is 2016.01 from upstream working for > > you? > > I tested on the one hand the binary u-boot.kwb from d-i, and on the > other hand the binary built from the mainline U-Boot repo, tag > v2016-01, built with the toolchain fetched by U-Boot's buildman for > arm, which identifies itself as 'gcc version 4.9.0 (GCC)', using > binutils 2.24. The binary u-boot.kwb consistently fails to boot beyond > the few lines I gave. The buildman-built kwb runs consistently. > > > You can find the build log here, btw: > > https://buildd.debian.org/status/fetch.php?pkg=u-boot&arch=armel&ver=2016.01%2Bdfsg1-1&stamp=1452650663 > > Thanks. I see the build was done by newer gcc (5.3.1) and binutils > (2.25.90). I will set up a local buildd so that I can reproduce this( > and future builds an analyze them as needed). Hmm, installing a complete buildd instance seems overkill. Is there a simple way to set up a build environment identical to that of the buildd which created u-boot.kwb? I've got VMs with basic Jessie, Testing and Unstable installs. Amicalement, -- Albert.
Bug#811129: Bug #811129: fails to boot on OpenRD
Hello Martin, On Fri, 15 Jan 2016 15:30:47 -0800, Martin Michlmayr wrote: > * Albert ARIBAUD [2016-01-15 22:52]: > > > Would you be so kind and test > > > https://d-i.debian.org/daily-images/armel/daily/kirkwood/u-boot/openrd-client/ > > > > > > This is 2016.01 (no rc) > > > > It is the same as the one I tested first and which failed. I had > > extracted it from > > http://ftp.de.debian.org/debian/pool/main/u/u-boot/u-boot_2016.01+dfsg1-1_armel.deb > > Yes, they are the same. The d-i build process simply extracts the > u-boot binary from the .deb, so it's easier for people to download. > > I'm surprised it fails to boot. Is 2016.01 from upstream working for > you? I tested on the one hand the binary u-boot.kwb from d-i, and on the other hand the binary built from the mainline U-Boot repo, tag v2016-01, built with the toolchain fetched by U-Boot's buildman for arm, which identifies itself as 'gcc version 4.9.0 (GCC)', using binutils 2.24. The binary u-boot.kwb consistently fails to boot beyond the few lines I gave. The buildman-built kwb runs consistently. > You can find the build log here, btw: > https://buildd.debian.org/status/fetch.php?pkg=u-boot&arch=armel&ver=2016.01%2Bdfsg1-1&stamp=1452650663 Thanks. I see the build was done by newer gcc (5.3.1) and binutils (2.25.90). I will set up a local buildd so that I can reproduce this( and future builds an analyze them as needed). Amicalement, -- Albert.
Bug#807922: slapd: Unable to use olcTLSVerifyClient
Le 27/12/2015 à 21:10:06-0800, Ryan Tandy a écrit > Control: tag -1 upstream moreinfo Control: severity -1 normal > Hi, > > Thank you for the report, and sorry for not answering sooner. No problem. > > On Mon, Dec 14, 2015 at 03:05:22PM +0100, Obspm wrote: > >>From a fresh install (the server is a virtual machine with > >>VirtualBox), after basic configuration of slapd, without any > >>configuration other than those make by apt-get, with no special data > >>I can add this piece of ldif > > > > dn: cn=config changeType: modify > > add: olcTLSVerifyClient > > olcTLSVerifyClient: never - > > > >I always got a > > > >root@debian:~# ldapmodify -Y EXTERNAL -H ldapi:/// -f toto.ldif > >SASL/EXTERNAL authentication started SASL username: > >gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 > >modifying entry "cn=config" ldap_modify: Server is unwilling to > >perform (53) > > At the moment, I think this behaviour is intentional and by design. > > First, I would note that this only happens when you haven't performed > the minimal TLS configuration yet: > > http://sources.debian.net/src/openldap/2.4.40%2Bdfsg-1%2Bdeb8u1/libraries/libldap/tls2.c/#L199-L202 > > In this case, "unwilling to perform" means that the change can't be > applied and take effect immediately, because TLS isn't even active > yet. After you configure a server certificate or CA certificate, then > you can start setting TLS options. > > You could argue that the change should be accepted and committed, as > if it had been done offline, and saved for when TLS is next started. > (I say "change" here intentionally, even though the value in your > example is the same as the default.) > > There is room on either side, to argue that a more informative error > message could be returned along with the error code, or that there is > precedent for cn=config changes that are accepted but not applied > until some subsystem, or slapd itself, is restarted. I don't have any > particular opinion on any of this, and would rather not argue with > upstream about design choices. > > I am not forwarding this upstream right now, but I'd be willing to, if > you can say a few more words about how you think this should behave > and why. Alternatively you could open a report yourself at > http://openldap.org/its; if you do that, please link the report here. > > thanks, Ryan In fact I find the « problem ». I don't known if it's really a bug, a « not_very_user_friendly_feature » or thing like that. They are two points : 1/ I need to add those olc* in a specific order, if I don't I get those insult (unwilling to perform) 2/ If those files (certificat-private-key, ca-chain, certificat) are not readeable WHEN the daemon start, changing the right/owner (by chmod/chown) don't change anything. That's mean if when the slapd daemon start, I got the wrong owner of the private key, I need to restart the daemon AFTER changing the owner. Mixing those two constraint make you crazyespecially when, like me, you use puppet to install everything. Anyway thanks you very much for answering me and maintaining those package. Regards JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: lun 4 jan 2016 17:32:54 CET
Bug#802325: Licensing of two files in prottest
Thanks for the notice! -Eric > On Oct 25, 2015, at 10:31 AM, Andreas Tille wrote: > > Hi, > > as I told the authors of Prottest I'm packaging Prottest for Debian. Our > ftpmaster has found two files where the license derives from the globally > applied GPL-2+ > > On Sat, Oct 24, 2015 at 06:00:09PM +, Thorsten Alteholz wrote: >> prottest3-3.4-release/src/main/java/es/uvigo/darwin/xprottest/util/BrowserLauncher.java >> >> is not licensed under GPL-2+ > > This is Copyright by 1999-2001 Eric Albert who wants to get a > notification if the code is used. Eric, this is the notification > about the usage. :-) > >> prottest3-3.4-release/src/main/java/es/uvigo/darwin/prottest/util/WriterOutputStream.java >> >> doesn't seem to have a license at all. > > This file is > > Copyright (c) 1999 Mort Bay Consulting (Australia) Pty. Ltd. > > but there is no license specified. Diego, could you please clarify the > licensing of this file? > > Kind regards > > Andreas. > > -- > http://fam-tille.de
Bug#796801: grml2usb: missing dependency on grub-pc-bin
Package: grml2usb Version: 0.14.12 Severity: normal hi, if one is running an uefi based system, grml2usb will fail with --grub. problem: grml2usb depends on syslinux | grub-pc | grub-efi-amd64 that is satisfied with grub-efi-amd64, but grml2usb will try to access grub-pc files. i suggest to change the dependency the dependency to depend on grub-pc-bin and grub-efi-amd64-bin which contain the actual files (packages names for i386 will differ i think, but i don't have a system at hand to check atm.) thx regards, albert -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages grml2usb depends on: ii coreutils 8.23-4 ii grub-efi-amd64 2.02~beta2-26 ii mtools 4.0.18-2 ii python 2.7.9-1 ii python-parted 3.10.5-1 ii realpath8.23-4 ii rsync 3.1.1-3 ii syslinux3:6.03+dfsg-10 Versions of packages grml2usb recommends: ii syslinux3:6.03+dfsg-10 ii syslinux-utils 3:6.03+dfsg-10 ii xorriso 1.3.2-1.1 grml2usb suggests no packages. -- no debconf information
Bug#795964: contributors.debian.org: simplify development deployment procedure
I am working on it: https://gitlab.com/sim6/debian_contributors/compare/master...docker signature.asc Description: PGP signature
Bug#796513: contributors.debian.org: DEVEL_SYSTEM mode doesn't work
Package: nm.debian.org Severity: minor Tags: patch When I enable the DEVEL_SYSTEM mode to bypass LDAP then "./manage.py housekeeping" command doesn't work. The following commit fix it: https://gitlab.com/sim6/debian_contributors/commit/e7b8b06695dd9ccffdc0aa3b3687519ee885e025 signature.asc Description: PGP signature
Bug#796382: contributors.debian.org: wrong command in README
Package: nm.debian.org Severity: minor Tags: patch A command to post source data in README doesn't work. The following commit fix it: https://gitlab.com/sim6/debian_contributors/commit/ec45004317be53432bc125646f01f0a1abc3d8e7 signature.asc Description: PGP signature
Bug#796321: contributors.debian.org: foo-source.json example doesn't work
Package: nm.debian.org Severity: minor Tags: patch Firstly, thanks for your work. The following command doesn't add the foo source. ./manage.py import_sources foo-source.json The following commit solves it: https://gitlab.com/sim6/debian_contributors/commit/ac97c8e776331ecee2eaa3bb2a8b8d77307d5449 Thanks again. signature.asc Description: PGP signature
Bug#794524: gnome-lirc-properties complains there is no python module named glade
Package: gnome-lirc-properties Version: 0.5.1-0ubuntu1 Severity: normal Dear Maintainer, I installed gnome-lirc-properties on xubuntu wily (which I think was originally a minimal desktop install, not a full desktop install) and found it needs a python glade library that it doesn't depend upon. Its probably an easy fix of adding a dependency. Thanks so much! This is what I get when I try to run it: all@megadon:~/annex$ dpkg -l | grep glade ii libglade2-0:amd64 1:2.6.4-2 amd64library to load .glade files at runtime all@megadon:~/annex$ gnome-lirc-properties Traceback (most recent call last): File "/usr/bin/gnome-lirc-properties", line 3, in import gettext, locale, os.path, sys, gtk.glade ImportError: No module named glade -- System Information: Debian Release: jessie/sid APT prefers wily-updates APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-4-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-lirc-properties depends on: ii lirc 0.9.0-0ubuntu5 ii policykit-1 0.105-11 ii python2.7.9-1 ii python-gtk2 2.24.0-4ubuntu1 ii python-support1.0.15 ii rarian-compat [scrollkeeper] 0.8.1-6 ii scrollkeeper 0.8.1-6 ii yelp 3.16.1-1ubuntu1 gnome-lirc-properties recommends no packages. gnome-lirc-properties suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
