Bug#1068021: RFS: debian-el/37.12 -- Emacs helpers specific to Debian users
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "debian-el": * Package name : debian-el Version : 37.12 Upstream contact : Debian Emacsen team * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/debian-el Section : lisp The source builds the following binary packages: elpa-debian-el - Emacs helpers specific to Debian users debian-el - Transition package, debian-el to elpa-debian-el To access further information about this package, please visit the following URL: https://mentors.debian.net/package/debian-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/debian-el/debian-el_37.12.dsc Changes since the last upload: debian-el (37.12) unstable; urgency=medium . * Bring back debian-autoloads.el (Closes: #1067902) * Fix comp warnings in debian-bug.el (Closes: #1067922) * Update distribution code names to recent releases * Append non-free-firmware to non-free when handling components * Move package info above copyright notice following existing practices * Bump package version to prepare for release Regards, -- Xiyue Deng
Bug#1024695: Comp warnings fix pending
Control: tags 1024695 pending Control: tags 1034734 pending Control: tags 1037179 pending Control: tags 1051478 pending thanks Hi, I have a merge request[1] pending that should fix most of the comp warnings which should be included in the next release. Stay tuned. [1] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/12 signature.asc Description: PGP signature
Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)
Hi Amin, Amin Bandali writes: > Hiya, > > Manphiz writes: > >> Manphiz writes: >> >>> Another finding is that in 28.x, if the term buffer have any further >>> questions to ask, debian-bug seems to consider the process stuck and >>> would just ignore everything and proceed. In 29.x however, the term >>> buffer seems to be able to accept user input and can process the output >>> accordingly - even if the script requires sudo and prompt for password, >>> and debian-bug can properly include the output in the generated email >>> for bug report. So with the merge request[4] it would instead skip all >>> potential additional information unfortunately. >>> >> >> Actually 28.x also works for user inputs if running term-exec without my >> problematic hooks so yeah! >> >>> As we do want to handle process termination better, while trying to keep >>> process from failing, I think temporarily disable term-exec-hook when >>> processing the output and restore after the report is generated should >>> probably work in most cases. Just wondering whether this is acceptable >>> in the process of debian-bug? >>> >> >> Forgot to mention that this is implemented as the 2nd commit in the >> MR[4] and tested on bookworm and trixie to be working. >> >>> [4] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/11 > > Thank you for the patch. :-) This seems like a reasonable fix to me, > and if David has no comments or objections I'd be happy to merge it > in the coming days. > > Quick request: would you please amend your patch/MR to add a > debian/changelog entry for the change(s)? It would be good to > do a new upload soon, and it'd be nice to have debian/changelog > in tiptop shape for that. > > Thanks, > -a Thanks for the review! I've pushed another commit adding the changelog entries, and changed some of the commit message to be consistent, so please force pull if you want to test again. Would definitely look forward to hearing from David as well. P.S. I'm also testing some patches to fix the comp warnings and hopefully can be included in the next upload. Will send another merge request when ready. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1052931: pyvenv-el: FTBFS: make: *** [debian/rules:4: binary] Error 25
t :value
>> value-166)) (if (eql value-166 'ert-form-evaluation-aborted-167) nil (let*
>> ((-explainer- (and t (ert--get-explainer 'equal (if -explainer- (list
>> :explanation (apply -explainer- args-165)) nil)
>> (ert--signal-should-execution form-description-168)) nil (ert-fail
>> form-description-168))) value-166 :most-recent-result nil
>> :expected-result-type :passed :tags nil :file-name
>> "/<>/test/pyvenv-hook-dir-test.el"))
>> load-with-code-conversion("/<>/test/pyvenv-hook-dir-test.el"
>> "/<>/test/pyvenv-hook-dir-test.el" nil t)
>> command-line-1(("-l" "package" "--eval" "(add-to-list
>> 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" "--eval"
>> "(add-to-list 'package-directory-list
>> \"/usr/share/emacs/site-lisp/elpa-src\")" "-f" "package-initialize" "-L" "."
>> "-L" "test" "--eval" "(load-file \"test/test-helper.el\")" "-l"
>> "test/pyvenv-workon-home-test.el" "-l" "test/pyvenv-mode-test.el" "-l" "Test
>> ‘pyvenv-hook-dir’ redefined
>> test/pyvenv-deactivate-test.el" "-l" "test/pyvenv-activate-test.el" "-l"
>> "test/pyvenv-hook-dir-test.el" "-l" "test/pyvenv-virtualenv-list-test.el"
>> "-l" "test/pyvenv-workon-test.el" "--eval" "(ert-run-tests-batch-and-exit)"))
>> command-line()
>> normal-top-level()
>> dh_elpa_test: error: emacs -batch -Q -l package --eval "(add-to-list
>> 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval
>> "(add-to-list 'package-directory-list
>> \"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L . -L test
>> --eval "(load-file \"test/test-helper.el\")" -l
>> test/pyvenv-workon-home-test.el -l test/pyvenv-mode-test.el -l
>> test/pyvenv-deactivate-test.el -l test/pyvenv-activate-test.el -l
>> test/pyvenv-hook-dir-test.el -l test/pyvenv-virtualenv-list-test.el -l
>> test/pyvenv-workon-test.el --eval \(ert-run-tests-batch-and-exit\) returned
>> exit code 255
>> make: *** [debian/rules:4: binary] Error 25
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2023/09/25/pyvenv-el_1.21+git20201124.37e7cb1-1_unstable.log
>
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230925;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20230925=lu...@debian.org=1=1=1=1#results
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please mark it as 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
>
Prepared a merge request at [1]. Will wait for dogsleg's review.
[1] https://salsa.debian.org/emacsen-team/pyvenv-el/-/merge_requests/1
--
Manphiz
signature.asc
Description: PGP signature
Bug#999962: silversearcher-ag: diff for NMU version 2.2.0+git20200805-1.1
Nicholas D Steeves writes: > Xiyue Deng writes: > >> Control: tags 62 + pending >> >> Dear maintainer, >> >> I've prepared an NMU for silversearcher-ag (versioned as >> 2.2.0+git20200805-1.1) >> and uploaded it to mentors.debian.net. Please feel free to tell me if I >> should >> delay it longer. > > You may have noticed that the timer fired and that the upload was > accepted :) Please push a release tag to you forked remote, and then > I'll merge your work into the debian/collab-maint project. > > Best, > Nicholas > Hi Nicholas, Thanks for sponsoring the NMU! I have pushed the release commit to debian/2.2.0+git20200805-1.1 in my repo[1]. Let me know if the tag name looks OK. [1] https://salsa.debian.org/manphiz/silversearcher-ag/-/tags/debian%2F2.2.0+git20200805-1.1 -- Manphiz signature.asc Description: PGP signature
Bug#919035: elpa-persp-projectile: broken with recent elpa-perspective
Manphiz writes: > control: tags -1 patch > > I have prepared a merge request[1] as a fix. PTAL. > > [1] elpa-persp-projectile: broken with recent elpa-perspective Turned out I didn't paste the URL, silly me. Here it is: [1] https://salsa.debian.org/emacsen-team/persp-projectile/-/merge_requests/3 -- Manphiz
Bug#1052824: flycheck: FTBFS if gawk is installed
control: tags -1 pending
thanks
Manphiz writes:
> control: tag -1 patch
> thanks
>
> Gianfranco Costamagna writes:
>
>> Source: flycheck
>> Version: 33~git20230824.e56e30d-1
>> Severity: serious
>> Forwarded: https://github.com/flycheck/flycheck/issues/2036
>>
>> Hello, looks like if we build with gawk installed, a new test fails.
>>
>> I'm filing as serious, because gawk is a tool installed on many systems.
>>
>> I just added the dependency at build time and found the issue on DoM
>> http://debomatic-amd64.debian.net/distribution#unstable/flycheck/33~git20230824.e56e30d-1.1/buildlog
>>
>>
>> Test flycheck-define-checker/awk-gawk/syntax-error backtrace:
>> signal(ert-test-failed (((should (equal (mapcar #'flycheck-error-wit
>> ert-fail(((should (equal (mapcar #'flycheck-error-without-group expe
>> (if (unwind-protect (setq value-229 (apply fn-227 args-228)) (setq f
>> (let (form-description-231) (if (unwind-protect (setq value-229 (app
>> (let ((value-229 'ert-form-evaluation-aborted-230)) (let (form-descr
>> (let* ((fn-227 #'equal) (args-228 (condition-case err (let ((signal-
>> (let ((expected (flycheck-ert-sort-errors (mapcar (apply-partially #
>> flycheck-ert-should-errors((2 nil warning "x=|\n ^ syntax error" :c
>> apply(flycheck-ert-should-errors (2 nil warning "x=|\n ^ syntax err
>> (let ((process-hook-called 0) (suspicious nil)) (add-hook 'flycheck-
>> flycheck-ert-should-syntax-check-in-buffer((2 nil warning "x=|\n ^
>> apply(flycheck-ert-should-syntax-check-in-buffer (2 nil warning "x=|
>> (progn (insert-file-contents file-name 'visit) (set-visited-file-nam
>> (unwind-protect (progn (insert-file-contents file-name 'visit) (set-
>> (progn (unwind-protect (progn (insert-file-contents file-name 'visit
>> (unwind-protect (progn (unwind-protect (progn (insert-file-contents
>> (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
>> (let ((temp-buffer (generate-new-buffer " *temp*" t))) (save-current
>> (let ((file-name (flycheck-ert-resource-filename resource-file))) (i
>> (let ((mode (car tail))) (if (fboundp mode) nil (ert-skip (format "%
>> (while tail (let ((mode (car tail))) (if (fboundp mode) nil (ert-ski
>> (let ((tail modes)) (while tail (let ((mode (car tail))) (if (fbound
>> flycheck-ert-should-syntax-check("language/awk/syntax-error.awk" awk
>> (closure (truncated-stdin-mode-abbrev-table truncated-stdin-mode-syn
>> ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
>> ert-run-test(#s(ert-test :name flycheck-define-checker/awk-gawk/synt
>> ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
>> ert-run-tests((and "flycheck-" t) #f(compiled-function (event-type &
>> ert-run-tests-batch((and "flycheck-" t))
>> ert-run-tests-batch-and-exit((and "flycheck-" t))
>> (let ((selector (car-safe (prog1 argv (setq argv (cdr argv)) (if
>> flycheck-run-tests-batch-and-exit()
>> (let ((debug-on-error t)) (flycheck-run-tests-batch-and-exit))
>> (let* ((load-prefer-newer t) (source-directory (locate-dominating-fi
>> flycheck-run-tests-main()
>> load-with-code-conversion("/<>/flycheck-33~git202
>> command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
>> command-line()
>> normal-top-level()
>> Test flycheck-define-checker/awk-gawk/syntax-error condition:
>> (ert-test-failed
>> ((should
>>(equal
>> (mapcar #'flycheck-error-without-group expected)
>> (mapcar #'flycheck-error-without-group current)))
>> :form
>> (equal
>>(#s(flycheck-error # awk-gawk
>> "/<>/test/resources/language/awk/syntax-error.awk" 2 nil "x=|\n
>> ^ syntax error" warning nil nil nil nil))
>>nil)
>> :value nil :explanation
>> (different-types
>>(#s(flycheck-error # awk-gawk
>> "/<>/test/resources/language/awk/syntax-error.awk" 2 nil "x=|\n
>> ^ syntax error" warning nil nil nil nil))
>>nil)))
>>FAILED 110/562 flycheck-define-checker/awk-gawk/syntax-error (0.139626
>> sec) at test/flycheck-test.el:1
>>
>> We are already skipping a bunch of tests in a patch, so maybe we can add
>> also this one, or wait for upstream
>> to double check what is going wrong.
>>
>> G.
>>
>
> Looks like the best action here is to mark this test as flaky as well.
>
> Unfortunately I don't seem to have permission to push to
> emacsen-team/flycheck yet, so I've prepared a merge request[1] instead.
> Looking for sponsorship :)
>
> [1] https://salsa.debian.org/emacsen-team/flycheck/-/merge_requests/4
Finally got access from David. I have prepared a revision for the fix
and uploaded to mentors[1]. Now looking for sponsors :)
[1] https://mentors.debian.net/package/flycheck/
--
Manphiz
signature.asc
Description: PGP signature
Bug#1052824: flycheck: FTBFS if gawk is installed
control: tag -1 patch
thanks
Gianfranco Costamagna writes:
> Source: flycheck
> Version: 33~git20230824.e56e30d-1
> Severity: serious
> Forwarded: https://github.com/flycheck/flycheck/issues/2036
>
> Hello, looks like if we build with gawk installed, a new test fails.
>
> I'm filing as serious, because gawk is a tool installed on many systems.
>
> I just added the dependency at build time and found the issue on DoM
> http://debomatic-amd64.debian.net/distribution#unstable/flycheck/33~git20230824.e56e30d-1.1/buildlog
>
>
> Test flycheck-define-checker/awk-gawk/syntax-error backtrace:
> signal(ert-test-failed (((should (equal (mapcar #'flycheck-error-wit
> ert-fail(((should (equal (mapcar #'flycheck-error-without-group expe
> (if (unwind-protect (setq value-229 (apply fn-227 args-228)) (setq f
> (let (form-description-231) (if (unwind-protect (setq value-229 (app
> (let ((value-229 'ert-form-evaluation-aborted-230)) (let (form-descr
> (let* ((fn-227 #'equal) (args-228 (condition-case err (let ((signal-
> (let ((expected (flycheck-ert-sort-errors (mapcar (apply-partially #
> flycheck-ert-should-errors((2 nil warning "x=|\n ^ syntax error" :c
> apply(flycheck-ert-should-errors (2 nil warning "x=|\n ^ syntax err
> (let ((process-hook-called 0) (suspicious nil)) (add-hook 'flycheck-
> flycheck-ert-should-syntax-check-in-buffer((2 nil warning "x=|\n ^
> apply(flycheck-ert-should-syntax-check-in-buffer (2 nil warning "x=|
> (progn (insert-file-contents file-name 'visit) (set-visited-file-nam
> (unwind-protect (progn (insert-file-contents file-name 'visit) (set-
> (progn (unwind-protect (progn (insert-file-contents file-name 'visit
> (unwind-protect (progn (unwind-protect (progn (insert-file-contents
> (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
> (let ((temp-buffer (generate-new-buffer " *temp*" t))) (save-current
> (let ((file-name (flycheck-ert-resource-filename resource-file))) (i
> (let ((mode (car tail))) (if (fboundp mode) nil (ert-skip (format "%
> (while tail (let ((mode (car tail))) (if (fboundp mode) nil (ert-ski
> (let ((tail modes)) (while tail (let ((mode (car tail))) (if (fbound
> flycheck-ert-should-syntax-check("language/awk/syntax-error.awk" awk
> (closure (truncated-stdin-mode-abbrev-table truncated-stdin-mode-syn
> ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
> ert-run-test(#s(ert-test :name flycheck-define-checker/awk-gawk/synt
> ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
> ert-run-tests((and "flycheck-" t) #f(compiled-function (event-type &
> ert-run-tests-batch((and "flycheck-" t))
> ert-run-tests-batch-and-exit((and "flycheck-" t))
> (let ((selector (car-safe (prog1 argv (setq argv (cdr argv)) (if
> flycheck-run-tests-batch-and-exit()
> (let ((debug-on-error t)) (flycheck-run-tests-batch-and-exit))
> (let* ((load-prefer-newer t) (source-directory (locate-dominating-fi
> flycheck-run-tests-main()
> load-with-code-conversion("/<>/flycheck-33~git202
> command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
> command-line()
> normal-top-level()
> Test flycheck-define-checker/awk-gawk/syntax-error condition:
> (ert-test-failed
> ((should
>(equal
> (mapcar #'flycheck-error-without-group expected)
> (mapcar #'flycheck-error-without-group current)))
> :form
> (equal
>(#s(flycheck-error # awk-gawk
> "/<>/test/resources/language/awk/syntax-error.awk" 2 nil "x=|\n
> ^ syntax error" warning nil nil nil nil))
>nil)
> :value nil :explanation
> (different-types
>(#s(flycheck-error # awk-gawk
> "/<>/test/resources/language/awk/syntax-error.awk" 2 nil "x=|\n
> ^ syntax error" warning nil nil nil nil))
>nil)))
>FAILED 110/562 flycheck-define-checker/awk-gawk/syntax-error (0.139626
> sec) at test/flycheck-test.el:1
>
> We are already skipping a bunch of tests in a patch, so maybe we can add also
> this one, or wait for upstream
> to double check what is going wrong.
>
> G.
>
Looks like the best action here is to mark this test as flaky as well.
Unfortunately I don't seem to have permission to push to
emacsen-team/flycheck yet, so I've prepared a merge request[1] instead.
Looking for sponsorship :)
[1] https://salsa.debian.org/emacsen-team/flycheck/-/merge_requests/4
--
Manphiz
signature.asc
Description: PGP signature
Bug#1042911: (Still?) breaks Emacs 29.1 unattended-upgrade
Farblos writes: > Packages that attempted to upgrade: > [..snip..] > elpa-muse elpa-org emacs-bin-common emacs-common > emacs-common-non-dfsg emacs-el emacs-lucid > [..snip..] > > Packages with upgradable origin but kept back: > Debian testing: > [..snip..] > elpa-muse > [..snip..] > > Package installation log: > [..snip..] > > In toplevel form: > muse-split.el:41:2: Error: Cannot open load file: No such file or directory, > assoc > So, unattended-upgrades decided to keep back elpa-muse, therefore when byte-compiling it was still attempting to handle the old 3.20+dfsg-7, and hence failed with the same error when byte-compiling on Emacs 29+. So it's curious that elpa-muse was kept back given that it doesn't introduce new dependencies. I wonder whether this is because of `Unattended-Upgrade::MinimalSteps "true"', which just divide the upgrades into smaller batch and elpa-muse didn't make it to the same batch as Emacs unfortunately. -- Manphiz
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
Manphiz writes: > Nicholas D Steeves writes: > >> Hi manphiz, >> >> Manphiz writes: >> >>> Xiyue Deng writes: >>> >>> Hi sten, >>> >>> When trying to pick a new upstream to rebase, I found that pulling >>> either upstream repo will result in an incompatible git history versus >>> the current debian/master branch on salsa. >> >> This is expected, but please merge from upstream. >> >>> I wonder how I should handle this? >> >> The commit of the upstream source you import should be tagged. If >> upstream hasn't made a tagged release, then you'll need to: >> >> 1. With a the upstream of your choice set in the watch file, "gbp >> import-orig --uscan" will do the right thing in this repository. This >> is one reason why a functioning watch file that defines the correct >> upstream is useful. It should also save time to do this once, and >> then switch to a tag merging workflow for the next upstream import. >> >> OR >> >> I. Ask upstream to tag a stable release (probably NA to GNU ELPA's >> monorepo) >> II. Merge that tag to either the upstream branch, or directly to the >> Debian packaging branch. See the merge note at §i. >> III. Do fixup work to make "git diff tag -- !(debian)" clean. >> >> OR >> >> i. Merge new upstream commit to the upstream branch (which will also >> merge its history), because tags of detached HEADS behave unreliably >> through remotes; ie the tag needs to be of a commit on a branch. See >> git merge man page about what to about unrelated histories. >> ii. Create an annotated tag in the format you defined in debian/watch >> (note substitutions for special characters). I've always done this >> manually with a "Tag upstream snapshot for Debian use" annotation, but >> NOTE: There is probably a better way to create these tags by now. >> iii. Merge your annotated tag to the Debian packaging branch. >> iv. Do fixup work to make "git diff tag -- !(debian)" clean. >> >> In every case, you'll need to insure that the upstream tag is pushed to >> Salsa. >> >>> Is it OK to force push to master? >> >> No. >> >> Best, >> Nicholas >> > > Thanks Nicholas, David! I found that "git merge upstream/externals/muse > --allow-unrelated-histories" did what I wanted. However, as this merged > pulled in the whole history of upstream repo it now has 1000+ commits > since the current debian/master. To be cautious, I have created a merge > request[1] which also has the packaging updates to the latest head. > PTAL. > > [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/4 Friendly ping for comments. Or should I prepare a package and upload to mentors directly for review? -- Manphiz signature.asc Description: PGP signature
Bug#999962: RFS to solve bug#999962 (silversearcher-ag: depends on obsolete pcre3 library)
Nicholas D Steeves writes: > Manphiz writes: > >> Nicholas D Steeves writes: >>> Manphiz writes: >>>> Manphiz writes: > [snip] >>> Then finalise the changelog and build the package. >>> >> >> Done as well. > > Thanks! > >>> Finally, learn about what an "nmudiff" is, and file one at the relevant >>> bug. >>> >> >> To be careful I'd like to have you take another look before doing so[1] >> :) > > I pulled from your remote and noted the requested updates. It looks > good to me :) > Great, thanks! >> BTW, I'm not a DD or DMD yet so I'm probably not able to submit to >> delayed queue yet, right? > > Right, the upload to the delayed queue using dput is something else, and > any uploads you make to ftp-master will not succeed. I'm not sure if > mentors.debian.net has a delayed queue, and I can't see how that would > be useful--other than for practise. Did you find the relevant section > in the Developer's Reference? > Uploaded to mentors[1]. Tried to search for NMU and mentors related contents in the Developer's Reference but didn't find much. I guess mentors should be safer than the delayed queue. > Before we get to the upload you need to submit an nmudiff of the source > package. On a related note, if you don't know about these yet, > "msmtp-mta" and "apt-file" are really useful. Msmtp-mta is an > alternative to other MTAs (useful for laptops, and Spwhitton told me > about apt-file :) It's technically possible to use debdiff, but > "nmudiff" is a tool like "reportbug", but I'm not sure if nmudiff will > function without an mta, unlike reportbug. > Also sent the nmudiff to this bug. Good thing that my postfix still works :) > Best, > Nicholas > [1] https://mentors.debian.net/package/silversearcher-ag/ -- Manphiz signature.asc Description: PGP signature
Bug#1052483: emacs-gtk: rcirc doesn't rejoin channels on reconnecting
FYI I seems to be able to convince the upstream to backport the fix to 29 branch, so it will be part of 29.2. So please feel free to wait for the next point release. -- Manphiz
Bug#1052483: emacs-gtk: rcirc doesn't rejoin channels on reconnecting
control: tag -1 patch control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65882 Patch attached. -- Manphiz --- emacs-29.1+1.orig/lisp/net/rcirc.el +++ emacs-29.1+1/lisp/net/rcirc.el @@ -859,6 +859,7 @@ If QUIET is non-nil, no not emit a messa (if (rcirc--connection-open-p process) (throw 'exit (or quiet (message "Server process is alive"))) (delete-process process)) + (setq rcirc-user-authenticated nil) (let ((conn-info rcirc-connection-info)) (setf (nth 5 conn-info) (cl-remove-if-not #'rcirc-channel-p
Bug#999962: RFS to solve bug#999962 (silversearcher-ag: depends on obsolete pcre3 library)
Nicholas D Steeves writes: > I've moved this discussion from debian-emacsen to the relevant bug. > Please remove debian-emacsen from CC and add me to CC for all > follow-ups. > Dropped debian-emacsen@. > Manphiz writes: > >> Manphiz writes: >> >>> >>> Thanks Nicholas! I used licensecheck and checked manually and updated >>> d/copyright accordingly in my merge request[1]. PTAL, thanks! >>> >>> [1] https://salsa.debian.org/debian/silversearcher-ag/-/merge_requests/1 >> >> Friendly ping. > > haha @enable_pcre2_support.patch:L478 > > Thanks for adding some copyright info; this will cover a "patches > applied" view, but doesn't cover the "patches unapplied" source package > (orig.tar, debian.tar, dsc). If you manually evaluate the rules in > d/copyright you'll see that this patch becomes misattributed to the > debian/* holder, which gets even more confusing since you set yourself > as the patch author ;) Yes, I understand you synthesised commits, and > I'm fine with that, but please finish fixing up d/copyright. > Makes sense. Updated accordingly. > changelog: Please enclose "Closes: #62" in parentheses in order to > follow the style that is already in use by this package's maintainer; > it's technically still Majime Mizuno's package, after all. > Done. > Then finalise the changelog and build the package. > Done as well. > Finally, learn about what an "nmudiff" is, and file one at the relevant > bug. > To be careful I'd like to have you take another look before doing so[1] :) BTW, I'm not a DD or DMD yet so I'm probably not able to submit to delayed queue yet, right? > Thanks, > Nicholas > [1] https://salsa.debian.org/debian/silversearcher-ag/-/merge_requests/1/diffs -- Manphiz signature.asc Description: PGP signature
Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)
Manphiz writes: > Another finding is that in 28.x, if the term buffer have any further > questions to ask, debian-bug seems to consider the process stuck and > would just ignore everything and proceed. In 29.x however, the term > buffer seems to be able to accept user input and can process the output > accordingly - even if the script requires sudo and prompt for password, > and debian-bug can properly include the output in the generated email > for bug report. So with the merge request[4] it would instead skip all > potential additional information unfortunately. > Actually 28.x also works for user inputs if running term-exec without my problematic hooks so yeah! > As we do want to handle process termination better, while trying to keep > process from failing, I think temporarily disable term-exec-hook when > processing the output and restore after the report is generated should > probably work in most cases. Just wondering whether this is acceptable > in the process of debian-bug? > Forgot to mention that this is implemented as the 2nd commit in the MR[4] and tested on bookworm and trixie to be working. > [4] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/11 -- Manphiz
Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)
tag -1 - unreproducible thanks David Bremner writes: > Manphiz writes: > >> Hmm, indeed I cannot reproduce this with "emacs -Q" either. Will see >> what could have caused this. Any tips on debugging? > > The only thing I can think of is to bisect the packages you have > enabled/loaded. Finally got some time to debug this. So it turns out that these lines[1] that tries to run "debian-bug-script" may fail before debian-bug tries to get the process status, which results in bug-script-process being nil. As for why the script may fail, in my case, the package I tried to reportbug on - linux-image-6.4.0-3-amd64 - has some custom logic that will ask additional questions to gather more information, such as whether to include dmesg, whether to include network interface info, etc., which will wait for a user input before proceeding. In the meantime, I have installed with-editor which will try to export a custom EDITOR envvar in term-exec-hook as suggested[2], and if the terminal is waiting a user input, it will cause the process to fail due to the command from with-editor. (As a possible cause has been found I'm taking the liberty to remove the unreproducible tag, even though it is not cause by debian-bug itself.) So in this case, it was indeed an external addon that triggered this error as David said. However, as the comment indicated[3], it should properly handle process termination, or any addon that tries to manipulate a term process may cause debian-bug to fail. I have prepared a merge request[4] trying to handle process termination as suggested but in quite a crude way, so any suggestion is appreciated.. Another finding is that in 28.x, if the term buffer have any further questions to ask, debian-bug seems to consider the process stuck and would just ignore everything and proceed. In 29.x however, the term buffer seems to be able to accept user input and can process the output accordingly - even if the script requires sudo and prompt for password, and debian-bug can properly include the output in the generated email for bug report. So with the merge request[4] it would instead skip all potential additional information unfortunately. As we do want to handle process termination better, while trying to keep process from failing, I think temporarily disable term-exec-hook when processing the output and restore after the report is generated should probably work in most cases. Just wondering whether this is acceptable in the process of debian-bug? [1] https://salsa.debian.org/manphiz/debian-el/-/blob/master/debian-bug.el#L892-893 [2] https://gitlab.com/xiyueden/emacs.d/-/blob/master/init.el?ref_type=heads#L460-463 [3] https://salsa.debian.org/manphiz/debian-el/-/blob/master/debian-bug.el#L897 [4] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/11 -- Manphiz
Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid
control: tags -1 patch thanks Lev Lamberov writes: > Пт 15 сен 2023 @ 14:25 David Bremner : > >> Lev Lamberov writes: >> elpa-hl-todo has a versioned depends which is wrong. >>> >>> It is not wrong. It is as it is stated in the code, and as it is >>> detected by dh-elpa. >>> >>> Personally, I don't see any problem here. The hl-todo-el package is just >>> waiting for the latest upstream version of complat-el. There's no hurry >>> to make its way into testing right now. From my point of view there is >>> only a wishlist bug requesting the latest upstream version of compat-el >>> to be uploaded into unstable. >> >> Yeah, I see what you mean, but the versioned depends is unsatisfiable in >> unstable, so it doesn't make sense to upload the package to unstable, >> unless there is something weird like a circular dependency. >> >> I don't think it's OK for packages in unstable to be uninstallable in >> unstable. It certainly meets the textbook definition of a release >> critical bug, since nobody can actually use the package. > > Unstable is... well, unstable. Sometimes things break there. ¯\_(ツ)_/¯ > There's no point in removing either compat-el or hl-todo-el from testing > because of this. > > Regards, > Lev Prepared a merge request[1] to update compat-el to 29.1.4.2. Also added back "+dfsg" to version as we drop compat.texi to be DFSG-compatible. [1] https://salsa.debian.org/emacsen-team/compat-el/-/merge_requests/1 signature.asc Description: PGP signature
Bug#1051677: emacs: Provides backport of 29.1
Sean Whitton writes: > Hello, > > On Tue 12 Sep 2023 at 01:31am -07, Manphiz wrote: > >> I'll try :P > > No, not now, Haha, of course not now. I meant I'll try to become someone they'll refer to in the (not too extremely far) future. > it's already in backports-NEW. \o/ -- Manphiz signature.asc Description: PGP signature
Bug#1051677: emacs: Provides backport of 29.1
Sean Whitton writes: > Hello, > > On Mon 11 Sep 2023 at 12:02pm -07, Manphiz wrote: > >> Ah noted. I guess they'll redirect me to the actual team/person >> handling the requested packages. > > In this case you could have been that person! I'll try :P -- Manphiz signature.asc Description: PGP signature
Bug#1051677: emacs: Provides backport of 29.1
Sean Whitton writes: > Hello, > > On Mon 11 Sep 2023 at 02:10am -07, Xiyue Deng wrote: > >> Package: emacs >> Version: 1:28.2+1-15 >> Severity: wishlist >> X-Debbugs-Cc: none, Xiyue Deng >> >> It would be great to have 29.1 backported to bookworm (or potentially >> bullseye if it's not too much of a trouble :) >> >> I acknowledge that some of the addons in bookworm don't work with 29.1 >> yet, while use-package users may just upgrade to latest versions on >> Elpa/Melpa so that they continues to work. Meanwhile I will also help >> with backporting the addons gradually. > > Backport requests are to be made to the backports mailing list, and not > generally to the BTS, because typically backports are maintained by > someone other than the sid packge maintainers. > Ah noted. I guess they'll redirect me to the actual team/person handling the requested packages. > In this case however I was already in the middle of preparing a backport > while I saw your report :) Great! Thanks! -- Manphiz
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
Nicholas D Steeves writes: > Hi manphiz, > > Manphiz writes: > >> Xiyue Deng writes: >> >> Hi sten, >> >> When trying to pick a new upstream to rebase, I found that pulling >> either upstream repo will result in an incompatible git history versus >> the current debian/master branch on salsa. > > This is expected, but please merge from upstream. > >> I wonder how I should handle this? > > The commit of the upstream source you import should be tagged. If > upstream hasn't made a tagged release, then you'll need to: > > 1. With a the upstream of your choice set in the watch file, "gbp > import-orig --uscan" will do the right thing in this repository. This > is one reason why a functioning watch file that defines the correct > upstream is useful. It should also save time to do this once, and > then switch to a tag merging workflow for the next upstream import. > > OR > > I. Ask upstream to tag a stable release (probably NA to GNU ELPA's > monorepo) > II. Merge that tag to either the upstream branch, or directly to the > Debian packaging branch. See the merge note at §i. > III. Do fixup work to make "git diff tag -- !(debian)" clean. > > OR > > i. Merge new upstream commit to the upstream branch (which will also > merge its history), because tags of detached HEADS behave unreliably > through remotes; ie the tag needs to be of a commit on a branch. See > git merge man page about what to about unrelated histories. > ii. Create an annotated tag in the format you defined in debian/watch > (note substitutions for special characters). I've always done this > manually with a "Tag upstream snapshot for Debian use" annotation, but > NOTE: There is probably a better way to create these tags by now. > iii. Merge your annotated tag to the Debian packaging branch. > iv. Do fixup work to make "git diff tag -- !(debian)" clean. > > In every case, you'll need to insure that the upstream tag is pushed to > Salsa. > >> Is it OK to force push to master? > > No. > > Best, > Nicholas > Thanks Nicholas, David! I found that "git merge upstream/externals/muse --allow-unrelated-histories" did what I wanted. However, as this merged pulled in the whole history of upstream repo it now has 1000+ commits since the current debian/master. To be cautious, I have created a merge request[1] which also has the packaging updates to the latest head. PTAL. [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/4 -- Manphiz signature.asc Description: PGP signature
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
David Bremner writes: > Manphiz writes: > >> >> Hi sten, >> >> When trying to pick a new upstream to rebase, I found that pulling >> either upstream repo will result in an incompatible git history versus >> the current debian/master branch on salsa. I wonder how I should handle >> this? Is it OK to force push to master? Will it affect existing >> annotated tags? > > Please don't force push the public history. There are various ways to > "fake merge" that are preferable. Hi David, Any pointers to the "fake merge" approaches? Would like to take a look. -- Manphiz signature.asc Description: PGP signature
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
Xiyue Deng writes: > Package: elpa-muse > Severity: minor > X-Debbugs-Cc: none, Xiyue Deng > > Currently muse-el has two main upstream repositories: one from Elpa > external branch[1], one from github[2], and the two has diverged > somehow. We should decide on which repo to track in d/watch. > > [1] http://git.savannah.gnu.org/cgit/emacs/elpa.git/log/?h=externals/muse > [2] https://github.com/alexott/muse > > -- System Information: > Debian Release: 12.1 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > Hi sten, When trying to pick a new upstream to rebase, I found that pulling either upstream repo will result in an incompatible git history versus the current debian/master branch on salsa. I wonder how I should handle this? Is it OK to force push to master? Will it affect existing annotated tags? -- Manphiz signature.asc Description: PGP signature
Bug#1016558: ITA: muse-el
Nicholas D Steeves writes: > Manphiz writes: > >> Nicholas D Steeves writes: >>> Manphiz writes: >>>> Nicholas D Steeves writes: >>>>> Manphiz writes: >>> >>> You're welcome. Yes, I agree that the github fork's structure has >>> diverged less, and I vaguely remember that that may have been one of the >>> reasons why I chose to watch it for future releases, but the then tag >>> never materialised. As noted previously, I'm ok with switching to the >>> fork if that's what you'd prefer to do long-term! As the maintainer you >>> get to pick the most high-quality and well-maintained upstream for the >>> Debian source, because you're the one who is responsible to our users. >>> >> >> Sounds good. I'll give it a little more thoughts. > > Wonderful, there's no rush. As ever, in Debian, you don't need to do > something you don't want to do. > >>> Do you mind if I enhance this significantly? Find proposal in-line, at >>> the end of the email. >> >> No problem! Patch applied, rebuilt, and reuploaded to mentors[1]. >> PTAL. > > LGTM! > >>> Also, I'd like this to be more visible, so I'll >>> file a bug titled something like "Choose living upstream for muse-el, >>> and merge updates" if you don't. I'm vaguely starting to remember that >>> the issue about a future upstream was raised during my early >>> contributions, but then I forgot all about it ;) Also, as the fixes for >>> Emacs compat eventually start accumulating we'll end up becoming a >>> second fork. >>> >> >> Makes sense. Filed Bug#1051247 for tracking. Will probably get to it >> in the next revision. > > Much obliged. > > Please refinalise with 'dch -r' and commit with something like "Actually > release 3.20+dfsg-8 to unstable" (or sid, as you prefer!). Then push. Done :) > Please create an annotated tag called "debian/3.20+dfsg-8", but don't > push that tag until you receive the "ACCEPTED" email from > ftp-masters/the archive. Also done and waiting for submitting. > It will most likely be less than 24h in > between pushing the release commit and pushing the tag, during which > time you'll be waiting for me to actually make the upload. > BTW rebuilt and re-uploaded to mentors :) > As for why? Well, there's some ambiguity now about whether > commit:02e95c1 was 3.20+dfsg-8, the fix is easy, and the delay is only > another day or two. > > After this, the package is truly ready. =) > Cheers, > Nicholas > -- Manphiz signature.asc Description: PGP signature
Bug#999962: silversearcher-ag: depends on obsolete pcre3 library
control: tags -1 patch Hi, Given sten's lead, I've attempted to adapt a "minimal" patch that implements pcre2 support in a merge request[1]. The patch is still large (~700 LOC) but it's strictly targeted on adding pcre2 support and adapted from an upstream branch/fork. The details of the patch set is described at [2]. This is in hope that an NMU can be considered to solve this issue in a more timely manor. If not, it would be good that the maintainer can consider including this patch. Thanks for considering. [1] https://salsa.debian.org/debian/silversearcher-ag/-/merge_requests/1 [2] https://salsa.debian.org/debian/silversearcher-ag/-/merge_requests/1/diffs#c3fae3beb4cb2adb72f024f933eab442930904a7_0_6 -- Manphiz signature.asc Description: PGP signature
Bug#1016558: ITA: muse-el
Nicholas D Steeves writes: > Thank you for the ping! > > Manphiz writes: > >> Nicholas D Steeves writes: >>> Manphiz writes: >>>> Nicholas D Steeves writes: >>>>> Manphiz writes: >>>>>> Nicholas D Steeves writes: >>>>>>>> Nicholas D Steeves writes: >> >>>> However, as it turns out, the savannah repo has a completely different >>>> layout compared to the current one we package (which is actually based >>>> on github). >>> >> I see. Thanks for the background. I think I was meant to say that "the >> repo structure is more like the github one" to be clear. Looking at the >> git log on Savannah, it looks like they changed the directory structure >> on the first commit when importing[2]. > > You're welcome. Yes, I agree that the github fork's structure has > diverged less, and I vaguely remember that that may have been one of the > reasons why I chose to watch it for future releases, but the then tag > never materialised. As noted previously, I'm ok with switching to the > fork if that's what you'd prefer to do long-term! As the maintainer you > get to pick the most high-quality and well-maintained upstream for the > Debian source, because you're the one who is responsible to our users. > Sounds good. I'll give it a little more thoughts. >>>> In fact, the savannah one uses a Makefile that assumes the project >>>> layout as the github one while some of the directories like "lisp" are >>>> not even there (which makes me think whether targeting the savannah >>>> repo is the correct choice). >>> >>> Some words appear to be missing, so I don't understand what you mean. >>> Please consult d/rules to learn why an upstream Makefile is irrelevant >>> by-design to this package. Also, consult the dh-elpa man page and >>> perhaps also team documentation on our wiki. It's also worth consulting >>> MELPA packages (and the source used by MELPA) to see how Makefile's >>> aren't needed there either. >> >> I kinda know that an Emacs addon doesn't really require a Makefile to be >> usable for melpa. Still, I still consider leaving a non-working >> Makefile around a bad habit. Anyway, point taken. > > Agreed, it's technical debt at this point. As the new Debian > maintainer, please consider sending this upstream a patch or a request > to remove the unused file. > Indeed. Will experiment some more when working on the next revision. >>>> Therefore, I'd like to postpone the sync with savannah repo to a >>>> future upload to avoid more immediate work for uploading if that's OK. >>> >>> That's OK with me! As noted previously, I'll support the decision you >>> make in your choice of future upstream, but it needs to be a conscious >>> and principled decision. If you don't want to decide at this time, >>> please implement a method that will remind you (or a future maintainer) >>> to investigate and fix this issue. Tldr, we don't want to switch back >>> and forth between GNU source and fork source. >>> >> >> Added a reminder in d/watch as a future work[3]. > > Do you mind if I enhance this significantly? Find proposal in-line, at > the end of the email. No problem! Patch applied, rebuilt, and reuploaded to mentors[1]. PTAL. [1] https://mentors.debian.net/package/muse-el/ > Also, I'd like this to be more visible, so I'll > file a bug titled something like "Choose living upstream for muse-el, > and merge updates" if you don't. I'm vaguely starting to remember that > the issue about a future upstream was raised during my early > contributions, but then I forgot all about it ;) Also, as the fixes for > Emacs compat eventually start accumulating we'll end up becoming a > second fork. > Makes sense. Filed Bug#1051247 for tracking. Will probably get to it in the next revision. >>>> Another hackier way I can think of is to build-deps on git and run "git >>>> restore" in override_dh_auto_clean, but I felt requiring the repo to be >>>> a git repo may fail buildd? Not sure though. Anyway, it seems using a >>>> patch is a cleaner solution compared to this. >>> >>> Right, you cannot use git restore. If we used the upstream Makefile's >>> "make clean" target, I would concede that patching the Makefile was the >>> correct approach. >>> >> >> Ah OK. I understand your reasoning. I've reverted the patch approach >> and as an alternative implemented the approach in [4] i
Bug#1051090: emacsql: FTBFS: 5 unexpected results
control: tags -1 patch Hi, I have prepare a patch set that sync to the latest head version that fixes the test failures. The patch set also contains upstream patches, and Debian related work starts from 0043-Update-changelog-for-new-upstream-3.1.1-git20230417..patch. Thanks, and PTAL! emacsql-patches.tar.xz Description: application/xz -- Manphiz
Bug#1016558: ITA: muse-el
Manphiz writes: > Nicholas D Steeves writes: > >> Manphiz writes: >> >>> Nicholas D Steeves writes: >>> >>>> Manphiz writes: >>>> >>>>> Nicholas D Steeves writes: >>>>>>> Nicholas D Steeves writes: >>> >>> Hmm, indeed I also cannot search it through my email. However, directly >>> search the fingerprint works: >> [snip] >>> I wonder what I could have done wrong that it doesn't index my email >>> address? >> >> gpg --search-keys 88A41F77AA3CD668C8F8B5802DE965ED63825C93 >> gpg: data source: https://keys.openpgp.org:443 >> (1) 4096 bit RSA key 2DE965ED63825C93, created: 2015-11-20 >> Keys 1-1 of 1 for "88A41F77AA3CD668C8F8B5802DE965ED63825C93". Enter >> number(s), N)ext, or Q)uit > 1 >> gpg: key 2DE965ED63825C93: new key but contains no user ID - skipped >> gpg: Total number processed: 1 >> gpg: w/o user IDs: 1 > > OK, so it turns out I'm missing an important RTFM step when trying to > use keys.openpgp.org[1]: I need to manually verify each of my > identities. I get mixed feeling about this as pgp.mit.edu worked > out-of-the-box with just "gpg --send-key". Ah well, they have their > reasons. > >> >> It appears that all identities were deleted. Since you agree this can >> be defer this for later, this is just an FYI :) I think the way your QA >> page will work is that all identities attached to >> 88A41F77AA3CD668C8F8B5802DE965ED63825C93 will appear, so we can >> introduce it later, but to be honest I've never tested this approach. >> >> https://qa.debian.org/developer.php >> https://contributors.debian.org/ >> >>> However, as it turns out, the savannah repo has a completely different >>> layout compared to the current one we package (which is actually based >>> on github). >> >> I'm partially to blame for this confusion; just now, I used >> git-timemachine to step back through the watch history until I found >> d7dea867b86c. My mistake was thinking it was ok to use the github >> tag/release service as a notification mechanism, when the true source of >> this release (not git snapshot) was git://repo.or.cz; if I remember >> correctly, the fork was just a mirror back then, and/or it was still in >> the "wait and see what GNU does" period of this software's maturation. >> See the changelog entry for 3.20+dfsg-1. >> >> The github fork of course replicates the history of repo.or.cz, and at >> the time I set the watch file to track github, uscan didn't yet have >> mode=git (or it was experimental and/or we didn't have lightweight >> clones yet). In other words, that was an inaccurate hack of mine, and I >> should have written a comment in the watch file...sorry about that, I >> didn't know better at the time. >> >> No, our source is not "actually based on github". Did you notice that >> we don't have upstream git history in this repository? 3.20 was never >> imported from git. Tldr: I created this repo with 'gbp import-dsc'. >> >> v3.20 from the official source at the time 3.20 was imported: >> https://repo.or.cz/muse-el.git/snapshot/caaa41cbf959afb379516e88776ec374160b8a94.tar.gz >> >> which is identical to >> https://github.com/alexott/muse/archive/refs/tags/v3.20.tar.gz >> > > I see. Thanks for the background. I think I was meant to say that "the > repo structure is more like the github one" to be clear. Looking at the > git log on Savannah, it looks like they changed the directory structure > on the first commit when importing[2]. > >>> In fact, the savannah one uses a Makefile that assumes the project >>> layout as the github one while some of the directories like "lisp" are >>> not even there (which makes me think whether targeting the savannah >>> repo is the correct choice). >> >> Some words appear to be missing, so I don't understand what you mean. >> Please consult d/rules to learn why an upstream Makefile is irrelevant >> by-design to this package. Also, consult the dh-elpa man page and >> perhaps also team documentation on our wiki. It's also worth consulting >> MELPA packages (and the source used by MELPA) to see how Makefile's >> aren't needed there either. > > I kinda know that an Emacs addon doesn't really require a Makefile to be > usable for melpa. Still, I still consider leaving a non-working > Makefile around a bad habit. Anyway, point taken. > >> >>> Therefore, I'd like to postpone the sync with s
Bug#919035: elpa-persp-projectile: broken with recent elpa-perspective
control: tags -1 patch I have prepared a merge request[1] as a fix. PTAL. [1] elpa-persp-projectile: broken with recent elpa-perspective -- Manphiz
Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)
David Bremner writes: > Control: tag -1 unreproducible > > Xiyue Deng writes: > >> Package: elpa-debian-el >> Version: 37.10 >> Severity: normal >> X-Debbugs-Cc: none, Xiyue Deng >> >> I've encountered an error when using "M-x debian-bug" on certain binary >> package, such as linux-image-6.4.0-3-amd64. The error backtrace look >> like this: >> > > I can't duplicate this in testing. Maybe try with a minimal config to > isolate some interaction with other addons? > > d Hmm, indeed I cannot reproduce this with "emacs -Q" either. Will see what could have caused this. Any tips on debugging?
Bug#1050350: flycheck: keep flycheck out of testing until it finds an uploader
control: merge 1050404 -1 control: block -1 by 1050459 control: tags -1 patch Hi, I've prepared an MR[1] to handle this, which requires a newer emacs-buttercup which is being prepared at [2]. PTAL. [1] https://salsa.debian.org/emacsen-team/flycheck/-/merge_requests/3 [2] https://salsa.debian.org/emacsen-team/emacs-buttercup/-/merge_requests/1 -- Manphiz
Bug#1013298: O: flycheck -- modern on-the-fly syntax checking for Emacs
control: tags -1 patch After discussing on IRC and with permission from anarcat, I intend to adopt flycheck. An MR is being prepared at [1]. [1] https://salsa.debian.org/emacsen-team/flycheck/-/merge_requests/3 -- Manphiz
Bug#1031086: piupart: fails in many packages for /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service not owned that is not related to package tested
I've been dealing with similar spurious error of piuparts when testing some packages that it reports that package purging left files on system: , | 0m45.6s ERROR: FAIL: Package purging left files on system: | /etc/default/locale -> ../locale.conf not owned | /etc/vconsole.conf -> default/keyboard not owned | /root/.ssh/not owned | /var/cache/private/not owned | /var/lib/private/ not owned | /var/lib/systemd/coredump/ not owned | /var/lib/systemd/ephemeral-trees/ not owned | /var/lib/systemd/pstore/ not owned | /var/log/private/ not owned | | 0m45.6s ERROR: FAIL: Installation and purging test. ` Full piuparts log attached. Wondering what is the rational to check not-owned files? Is it safe to just ignore them in piuparts? +--+ | Post Build | +--+ piuparts 0m0.0s INFO: -- 0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of this logfile. 0m0.0s INFO: FAQ available at https://wiki.debian.org/piuparts/FAQ 0m0.0s INFO: The FAQ also explains how to contact us in case you think piuparts is wrong.0m0.0s INFO: -- 0m0.0s INFO: piuparts version 1.1.7 starting up. 0m0.0s INFO: Command line arguments: /usr/sbin/piuparts --schroot unstable-amd64-sbuild --no-eatmydata /home/xiyueden/Projects/debian-devel/build-area/emacs-buttercup_1.31-1_amd64.changes 0m0.0s INFO: Running on: Linux debian-hx90 6.1.0-11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08) x86_64 0m0.0s DEBUG: Starting command: ['dpkg', '--info', '/home/xiyueden/Projects/debian-devel/build-area/elpa-buttercup_1.31-1_all.deb'] 0m0.0s DUMP: new Debian package, version 2.0. size 44500 bytes: control archive=1400 bytes. 786 bytes,19 lines control 1192 bytes,14 lines md5sums 435 bytes, 9 lines * postinst #!/bin/sh 298 bytes, 7 lines * prerm#!/bin/sh Package: elpa-buttercup Source: emacs-buttercup Version: 1.31-1 Architecture: all Maintainer: Debian Emacsen team Installed-Size: 162 Depends: dh-elpa-helper, emacsen-common, emacs (>= 1:28.2+1-9) Enhances: emacs Section: lisp Priority: optional Homepage: https://github.com/jorgenschaefer/emacs-buttercup/ Description: behaviour-driven testing for Emacs Lisp packages Buttercup is a behavior-driven development framework for testing Emacs Lisp code. It allows the programmer to group related tests so they can share common set-up and tear-down code, and it allows the programmer to spy on functions to ensure they are called with the right arguments during testing. . The testing framework is inspired by the Jasmine JavaScript test framework. 0m0.0s DEBUG: Command ok: ['dpkg', '--info', '/home/xiyueden/Projects/debian-devel/build-area/elpa-buttercup_1.31-1_all.deb'] 0m0.0s DEBUG: Starting command: ['schroot', '--begin-session', '--chroot', 'unstable-amd64-sbuild', '--session-name', 'unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts'] 0m0.1s DUMP: unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts 0m0.1s DEBUG: Command ok: ['schroot', '--begin-session', '--chroot', 'unstable-amd64-sbuild', '--session-name', 'unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts'] 0m0.1s DEBUG: Starting command: ['schroot', '--chroot', 'session:unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts', '--location'] 0m0.1s DUMP: /var/run/schroot/mount/unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts 0m0.1s DEBUG: Command ok: ['schroot', '--chroot', 'session:unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts', '--location'] 0m0.1s INFO: New schroot session in '/var/run/schroot/mount/unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts' 0m0.1s DEBUG: sources.list: deb https://deb.debian.org/debian/ sid main deb https://deb.debian.org/debian/ sid contrib deb https://deb.debian.org/debian/ sid non-free deb https://deb.debian.org/debian/ sid non-free-firmware 0m0.1s DEBUG: Created policy-rc.d and chmodded it. 0m0.1s DEBUG: Created resolv.conf. 0m0.1s DEBUG: Starting command: ['schroot', '--preserve-environment', '--run-session', '--chroot', 'session:unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts', '--directory', '/', '-u', 'root', '--', 'apt-get', 'update'] 0m2.9s DUMP: Get:1 https://deb.debian.org/debian sid InRelease [210 kB] Get:2 https://deb.debian.org/debian sid/main amd64 Packages [9568 kB] Get:3
Bug#1016558: ITA: muse-el
Nicholas D Steeves writes: > Manphiz writes: > >> Nicholas D Steeves writes: >> >>> Manphiz writes: >>> >>>> Nicholas D Steeves writes: >>>>>> Nicholas D Steeves writes: >> >> Hmm, indeed I also cannot search it through my email. However, directly >> search the fingerprint works: > [snip] >> I wonder what I could have done wrong that it doesn't index my email >> address? > > gpg --search-keys 88A41F77AA3CD668C8F8B5802DE965ED63825C93 > gpg: data source: https://keys.openpgp.org:443 > (1) 4096 bit RSA key 2DE965ED63825C93, created: 2015-11-20 > Keys 1-1 of 1 for "88A41F77AA3CD668C8F8B5802DE965ED63825C93". Enter > number(s), N)ext, or Q)uit > 1 > gpg: key 2DE965ED63825C93: new key but contains no user ID - skipped > gpg: Total number processed: 1 > gpg: w/o user IDs: 1 OK, so it turns out I'm missing an important RTFM step when trying to use keys.openpgp.org[1]: I need to manually verify each of my identities. I get mixed feeling about this as pgp.mit.edu worked out-of-the-box with just "gpg --send-key". Ah well, they have their reasons. > > It appears that all identities were deleted. Since you agree this can > be defer this for later, this is just an FYI :) I think the way your QA > page will work is that all identities attached to > 88A41F77AA3CD668C8F8B5802DE965ED63825C93 will appear, so we can > introduce it later, but to be honest I've never tested this approach. > > https://qa.debian.org/developer.php > https://contributors.debian.org/ > >> However, as it turns out, the savannah repo has a completely different >> layout compared to the current one we package (which is actually based >> on github). > > I'm partially to blame for this confusion; just now, I used > git-timemachine to step back through the watch history until I found > d7dea867b86c. My mistake was thinking it was ok to use the github > tag/release service as a notification mechanism, when the true source of > this release (not git snapshot) was git://repo.or.cz; if I remember > correctly, the fork was just a mirror back then, and/or it was still in > the "wait and see what GNU does" period of this software's maturation. > See the changelog entry for 3.20+dfsg-1. > > The github fork of course replicates the history of repo.or.cz, and at > the time I set the watch file to track github, uscan didn't yet have > mode=git (or it was experimental and/or we didn't have lightweight > clones yet). In other words, that was an inaccurate hack of mine, and I > should have written a comment in the watch file...sorry about that, I > didn't know better at the time. > > No, our source is not "actually based on github". Did you notice that > we don't have upstream git history in this repository? 3.20 was never > imported from git. Tldr: I created this repo with 'gbp import-dsc'. > > v3.20 from the official source at the time 3.20 was imported: > https://repo.or.cz/muse-el.git/snapshot/caaa41cbf959afb379516e88776ec374160b8a94.tar.gz > > which is identical to > https://github.com/alexott/muse/archive/refs/tags/v3.20.tar.gz > I see. Thanks for the background. I think I was meant to say that "the repo structure is more like the github one" to be clear. Looking at the git log on Savannah, it looks like they changed the directory structure on the first commit when importing[2]. >> In fact, the savannah one uses a Makefile that assumes the project >> layout as the github one while some of the directories like "lisp" are >> not even there (which makes me think whether targeting the savannah >> repo is the correct choice). > > Some words appear to be missing, so I don't understand what you mean. > Please consult d/rules to learn why an upstream Makefile is irrelevant > by-design to this package. Also, consult the dh-elpa man page and > perhaps also team documentation on our wiki. It's also worth consulting > MELPA packages (and the source used by MELPA) to see how Makefile's > aren't needed there either. I kinda know that an Emacs addon doesn't really require a Makefile to be usable for melpa. Still, I still consider leaving a non-working Makefile around a bad habit. Anyway, point taken. > >> Therefore, I'd like to postpone the sync with savannah repo to a >> future upload to avoid more immediate work for uploading if that's OK. > > That's OK with me! As noted previously, I'll support the decision you > make in your choice of future upstream, but it needs to be a conscious > and principled decision. If you don't want to decide at this time, > please implement a method that will remind you (or a future maintainer) > to in
Bug#1016558: ITA: muse-el
Nicholas D Steeves writes: > Manphiz writes: > >> Nicholas D Steeves writes: >>>> Nicholas D Steeves writes: >>> >> >> Should have removed the redundant signatures and reuploaded to >> https://keys.openpgp.org, though I don't think I had 5 signatures on the >> same IDs? Anyway, PTAL. > > Web interface: > keys.openpgp.org > Error: No key found for email address manp...@gmail.com > > $ gpg --search-keys manp...@gmail.com > gpg: data source: https://keys.openpgp.org:443 > gpg: key "manp...@gmail.com" not found on keyserver > gpg: keyserver search failed: Not found Hmm, indeed I also cannot search it through my email. However, directly search the fingerprint works: , | $ gpg --search-key 88A41F77AA3CD668C8F8B5802DE965ED63825C93 | gpg: data source: https://keys.openpgp.org:443 | (1) 4096 bit RSA key 2DE965ED63825C93, created: 2015-11-20 | Keys 1-1 of 1 for "88A41F77AA3CD668C8F8B5802DE965ED63825C93". Enter number(s), N)ext, or Q)uit > N ` I wonder what I could have done wrong that it doesn't index my email address? > > Strictly speaking, you don't need to worry about your key until you > start wanting to make uploads (mentors, Debian Maintainer per-package > upload privileges, Debian Developer uploading), so we can defer this. Sounds good. > >>> What is your intention here? Are you rebasing our package onto this >>> fork, or are you using the fork as a code dump, or something else? >>> >> >> Well to be honest I didn't realize the github one was a fork as the >> d/watch file had been pointing there. > > "git blame debian/watch" to see who is to blame, and fix fdde4981, which > introduced this problem. > > This is a blocker to uploading the package. Fixed d/watch track the savannah git repo instead[1]. However, as it turns out, the savannah repo has a completely different layout compared to the current one we package (which is actually based on github). In fact, the savannah one uses a Makefile that assumes the project layout as the github one while some of the directories like "lisp" are not even there (which makes me think whether targeting the savannah repo is the correct choice). Therefore, I'd like to postpone the sync with savannah repo to a future upload to avoid more immediate work for uploading if that's OK. Meanwhile, when trying to figure out the emacs/elpa.git repo structure I realized that this repo is actually synced package repo on GNU Elpa as one of its branch, and the entry of muse in elpa-packages[2] says: , | (muse :url "https://github.com/alexott/muse;) ;FIXME: Not nearly in-sync ` I guess the plot thickens, but I'll just let it be for now :P > >> Also from your other mail: > > Thank you for merging these emails. > >>> I found that this UTF8 issue was already fixed upstream: >>> >>> @@ -412,11 +433,11 @@ >>> >>> https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?h=externals/muse=be347db7f1ad56f0384f76011bfd148ff3352610 >>> >>> and note that it's now an official GNU project (via copyright assignment) >>> >>> Copyright (C) 2004-2020 Free Software Foundation, Inc. >> >> So it should be clear that the Savannah one should be considered the >> canonical upstream. I'll update my question on github to ask for >> whether Alex want to forward the patches in his repo to Savannah as >> well. > > Thanks. > >> Also as a result, I've marked the patch as "Forwarded: not-needed". > > Thank you. Alternatively you can either cherry pick the upstream commit > (and export as quilt patch) and drop mine, or package a new upstream > snapshot from the savannah source, since that's what we're tracking. As discussed above, would like to postpone the sync later and actually decide what to do. > >>> Oh, there's one more thing that needs to be fixed before we upload: >>> Bug #1048114 >> >> Attempted to fix it in [2] where I just regenerated the changing file in >> sbuild. >> >> [1] https://github.com/alexott/muse/issues/16 >> [2] >> https://salsa.debian.org/emacsen-team/muse-el/-/commit/f5c217162d9c6f45c971cec2b8c70b2794bb77fe > > This doesn't look like the right approach to me, the changelog entries > related to it are unclear/misleading, and a description is missing in > the patch header. Added an explanation[3] to the patch. So basically the file gets regenerated in this build rule[4], and as the generated file changes, it fails the second build. Use a patch is the simplest way so that the file stays the same each time it builds. > Have you checked Savannah for a fix? The Savannah repo
Bug#1016558: O: muse-el
Nicholas D Steeves writes: > Hello, > > Sorry for the delay, I hadn't realised that I had forgotten to actually > send this draft: > > On Fri, 11 Aug 2023 at 22:09, Manphiz wrote: > >> Nicholas D Steeves writes: > >> Now also uploaded my PGP keys to https://keys.openpgp.org/. pgp.mit.edu >> has been unstable for a while, so a good alternative is definitely a >> plus :) > > For sure, and also, it's been the default keyserver in Debian since 2019 > (gnupg 2.2.17-1) ;) Yeah, I've also noticed pgp.mit.edu has gotten > slower and more unreliable than in the past. P.S. This might be a bit > pedantic, but doesn't your key have five redundant signatures that could > be deleted? > Should have removed the redundant signatures and reuploaded to https://keys.openpgp.org, though I don't think I had 5 signatures on the same IDs? Anyway, PTAL. >> >> I: muse-el source: patch-not-forwarded-upstream >> >> [debian/patches/0005-convert-a-muse-init.el-example-to-UTF-8.patch] >> >> >> >> I wonder whether you would also like to forward this patch upstream. >> > >> > If you really want to, go ahead, but I'm not interested in the FSF's >> > identity verification for copyright assignment process, so this might >> > end up as a futile effort. In light of this, a "hey, we have a UTF8 >> > conversion patch...would you like to convert your copy to UTF8 either >> > with or without our patch" might be smoother. If you happen to have >> > have done FSF copyright assignment paperwork, please go ahead and >> > claim ownership of that trivial patch. >> >> Forwarded upstream. As my pull request got merged fairly quickly I'm >> slightly more optimistic here. > > Hmm, it appears that these patches were forwarded to a fork. The Source > is set to git://repo.or.cz/muse-el.git (debian/and the Homepage is set > to https://www.gnu.org/software/emacs-muse/index.html (debian/control). > As the new maintainer it's your right to switch upstream sources, but I > recommend you ask some team members and #debian-mentors on irc or the > mailing list about what the downsides to this may be; the mailing list > archives might have a record of someone else asking a question like > this. I'll support your decision once you let me know you've > investigated and considered. So I did ask around #debian-emacs and #debian-mentors and the replies I got was to better figure out the situation with the upstream. So I opened an issue on the github repo[1] and waiting for response. > > What is your intention here? Are you rebasing our package onto this > fork, or are you using the fork as a code dump, or something else? > Well to be honest I didn't realize the github one was a fork as the d/watch file had been pointing there. Also from your other mail: > I found that this UTF8 issue was already fixed upstream: > > @@ -412,11 +433,11 @@ > > https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?h=externals/muse=be347db7f1ad56f0384f76011bfd148ff3352610 > > and note that it's now an official GNU project (via copyright assignment) > > Copyright (C) 2004-2020 Free Software Foundation, Inc. So it should be clear that the Savannah one should be considered the canonical upstream. I'll update my question on github to ask for whether Alex want to forward the patches in his repo to Savannah as well. Also as a result, I've marked the patch as "Forwarded: not-needed". >> > I'm happy to sponsor from git when you finalise the changelog, but if >> > ever you want to get some hands-on experience with dput (or dput-ng), >> > then practise uploading to https://mentors.debian.net/. >> >> Uploaded using dput. Would be great to have you to take a look as >> well. Thanks! > > The aspects relating to the upload look good to me. > > Oh, there's one more thing that needs to be fixed before we upload: > Bug #1048114 Attempted to fix it in [2] where I just regenerated the changing file in sbuild. I have also rebuilt and reuploaded the source.changes to mentors[3]. PTAL. Thanks! > > Take care, > Nicholas -- Manphiz [1] https://github.com/alexott/muse/issues/16 [2] https://salsa.debian.org/emacsen-team/muse-el/-/commit/f5c217162d9c6f45c971cec2b8c70b2794bb77fe [3] https://mentors.debian.net/package/muse-el/ signature.asc Description: PGP signature
Bug#1016558: O: muse-el
control: retitle -1 ITA: muse-el Nicholas D Steeves writes: > On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: >> Nicholas D Steeves writes: >> >> > Hi, >> > >> > Reply follows inline. Can we move this discussion to #1016558 to not >> > bother Axel with our discussion? > > I guess that's a no? Following up at #1016558 from now on. Also changed #1016558 from O to ITA. > >> > Manphiz writes: >> >> Nicholas D Steeves writes: >> >>>>> Nicholas D Steeves writes: >> > >> > Wonderful! I also see you have a GPG key now. Have you generated >> > revocations certificates yet? >> > >> > >> > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate >> >> Now I have one. Thanks for the tip! > > You're welcome :) > >> > Next, where can I find your key? >> >> I have previously uploaded my GPG key to pgp.mit.edu[1]. > > Ah, that's where it was. I thought everyone had switched to > https://keys.openpgp.org/ these days (this is the default server on > Debian) after the end of the SKS network. Thanks for the reminder to > continue to check pgp.mit.edu as a fallback. Now also uploaded my PGP keys to https://keys.openpgp.org/. pgp.mit.edu has been unstable for a while, so a good alternative is definitely a plus :) > >> Please advise if https://keyserver.ubuntu.com is still recommended for >> prospective DMs. > > This is the first I've heard of that recommendation. I wonder if > people in #debian-mentors (OFTC) will also be surprised? I'd use > keyserver.ubuntu.com if I had a Launchpad account and maintained a > PPA, but honestly wouldn't bother. I started using keys.openpgp.org > since that's where various people expected to find my key haha. Sounds good. I guess keys.openpgp.org is good enough then :) > >> I have a few more commits[2] that should have fixed most of the lintian >> warnings. > > LGTM > >> There is another INFO level warning: >> >> I: muse-el source: patch-not-forwarded-upstream >> [debian/patches/0005-convert-a-muse-init.el-example-to-UTF-8.patch] >> >> I wonder whether you would also like to forward this patch upstream. > > If you really want to, go ahead, but I'm not interested in the FSF's > identity verification for copyright assignment process, so this might > end up as a futile effort. In light of this, a "hey, we have a UTF8 > conversion patch...would you like to convert your copy to UTF8 either > with or without our patch" might be smoother. If you happen to have > have done FSF copyright assignment paperwork, please go ahead and > claim ownership of that trivial patch. Forwarded upstream. As my pull request got merged fairly quickly I'm slightly more optimistic here. > > I'm happy to sponsor from git when you finalise the changelog, but if > ever you want to get some hands-on experience with dput (or dput-ng), > then practise uploading to https://mentors.debian.net/. Uploaded using dput. Would be great to have you to take a look as well. Thanks! > > Best, > Nicholas > > On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: >> >> Nicholas D Steeves writes: >> >> > Hi, >> > >> > Reply follows inline. Can we move this discussion to #1016558 to not >> > bother Axel with our discussion? >> > >> > Manphiz writes: >> > >> >> Nicholas D Steeves writes: >> >>>>> Nicholas D Steeves writes: >> >>>>> >> >> Thanks! Though I'm not really a user of muse-el, I'd like to keep it in >> >> a good shape as an exercise as an Emacs addon maintainer. It looks like >> >> there is not too much work thanks to Elisp being a fairly stable >> >> language :) >> > >> > That's fine, thank you once again for adopting it, and yes, generally >> > everything is ok :) >> > >> >>>> [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 >> >>> >> >> Thanks for the tips! I checked the Debian Policy Upgrading Checklist[1] >> >> and agreed with Debian Janitor on the "no changes are needed" bit. And >> >> to avoid having to wait for the bot to do the rebase I've manually >> >> resolved the conflicts and rebased my MR on top of it as well. >> >> >> > >> > You're welcome, and good call. >> > >> >>> Let me know when your done, and we can talk about the next steps. >> >> >> >> Now all MRs are merged. Please advise the next steps. Thanks
Bug#1016558: Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Nicholas D Steeves writes: > On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: >> Nicholas D Steeves writes: >> >> > Hi, >> > >> > Reply follows inline. Can we move this discussion to #1016558 to not >> > bother Axel with our discussion? > > I guess that's a no? Ah sorry totally missed this part. This will be the last message to #1042911. Will follow-up the rest in #1016558. > >> > Manphiz writes: >> >> Nicholas D Steeves writes: >> >>>>> Nicholas D Steeves writes: >> > >> > Wonderful! I also see you have a GPG key now. Have you generated >> > revocations certificates yet? >> > >> > >> > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate >> >> Now I have one. Thanks for the tip! > > You're welcome :) > >> > Next, where can I find your key? >> >> I have previously uploaded my GPG key to pgp.mit.edu[1]. > > Ah, that's where it was. I thought everyone had switched to > https://keys.openpgp.org/ these days (this is the default server on > Debian) after the end of the SKS network. Thanks for the reminder to > continue to check pgp.mit.edu as a fallback. > >> Please advise if https://keyserver.ubuntu.com is still recommended for >> prospective DMs. > > This is the first I've heard of that recommendation. I wonder if > people in #debian-mentors (OFTC) will also be surprised? I'd use > keyserver.ubuntu.com if I had a Launchpad account and maintained a > PPA, but honestly wouldn't bother. I started using keys.openpgp.org > since that's where various people expected to find my key haha. > >> I have a few more commits[2] that should have fixed most of the lintian >> warnings. > > LGTM > >> There is another INFO level warning: >> >> I: muse-el source: patch-not-forwarded-upstream >> [debian/patches/0005-convert-a-muse-init.el-example-to-UTF-8.patch] >> >> I wonder whether you would also like to forward this patch upstream. > > If you really want to, go ahead, but I'm not interested in the FSF's > identity verification for copyright assignment process, so this might > end up as a futile effort. In light of this, a "hey, we have a UTF8 > conversion patch...would you like to convert your copy to UTF8 either > with or without our patch" might be smoother. If you happen to have > have done FSF copyright assignment paperwork, please go ahead and > claim ownership of that trivial patch. > > I'm happy to sponsor from git when you finalise the changelog, but if > ever you want to get some hands-on experience with dput (or dput-ng), > then practise uploading to https://mentors.debian.net/. > > Best, > Nicholas > > On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: >> >> Nicholas D Steeves writes: >> >> > Hi, >> > >> > Reply follows inline. Can we move this discussion to #1016558 to not >> > bother Axel with our discussion? >> > >> > Manphiz writes: >> > >> >> Nicholas D Steeves writes: >> >>>>> Nicholas D Steeves writes: >> >>>>> >> >> Thanks! Though I'm not really a user of muse-el, I'd like to keep it in >> >> a good shape as an exercise as an Emacs addon maintainer. It looks like >> >> there is not too much work thanks to Elisp being a fairly stable >> >> language :) >> > >> > That's fine, thank you once again for adopting it, and yes, generally >> > everything is ok :) >> > >> >>>> [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 >> >>> >> >> Thanks for the tips! I checked the Debian Policy Upgrading Checklist[1] >> >> and agreed with Debian Janitor on the "no changes are needed" bit. And >> >> to avoid having to wait for the bot to do the rebase I've manually >> >> resolved the conflicts and rebased my MR on top of it as well. >> >> >> > >> > You're welcome, and good call. >> > >> >>> Let me know when your done, and we can talk about the next steps. >> >> >> >> Now all MRs are merged. Please advise the next steps. Thanks! >> >> >> > >> > Wonderful! I also see you have a GPG key now. Have you generated >> > revocations certificates yet? >> > >> > >> > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate >> >> Now I have one. Thanks for the tip! >> >> > >> > Next, where can I
Bug#1042900: Breaks Emacs 29.1 upgrade: pointback.el:34:2: Error: Cannot open load file: No such file or directory, assoc
control: tags -1 patch Hi, I have prepared a merge request[1] that migrates from assoc.el as well as other minor fixes. PTAL. Thanks! [1] https://salsa.debian.org/emacsen-team/pointback/-/merge_requests/4 -- Manphiz signature.asc Description: PGP signature
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Nicholas D Steeves writes: > Hi, > > Reply follows inline. Can we move this discussion to #1016558 to not > bother Axel with our discussion? > > Manphiz writes: > >> Nicholas D Steeves writes: >>>>> Nicholas D Steeves writes: >>>>> >> Thanks! Though I'm not really a user of muse-el, I'd like to keep it in >> a good shape as an exercise as an Emacs addon maintainer. It looks like >> there is not too much work thanks to Elisp being a fairly stable >> language :) > > That's fine, thank you once again for adopting it, and yes, generally > everything is ok :) > >>>> [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 >>> >> Thanks for the tips! I checked the Debian Policy Upgrading Checklist[1] >> and agreed with Debian Janitor on the "no changes are needed" bit. And >> to avoid having to wait for the bot to do the rebase I've manually >> resolved the conflicts and rebased my MR on top of it as well. >> > > You're welcome, and good call. > >>> Let me know when your done, and we can talk about the next steps. >> >> Now all MRs are merged. Please advise the next steps. Thanks! >> > > Wonderful! I also see you have a GPG key now. Have you generated > revocations certificates yet? > > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate Now I have one. Thanks for the tip! > > Next, where can I find your key? I have previously uploaded my GPG key to pgp.mit.edu[1]. > I'm assuming that you're committed to > maintaining this identity for the foreseeable future, and that you'd > like to build reputation for future involvement in Debian. It's not > required at the stage you're at, but it's recommended. > > https://wiki.debian.org/Keysigning#Step_3:_Make_your_public_key_public Please advise if https://keyserver.ubuntu.com is still recommended for prospective DMs. > > The subkey that I was able to download didn't include any identities. > > Other than that, this package isn't quite ready to upload, because there > are three unaddressed lintian warnings. > > https://wiki.debian.org/Lintian I have a few more commits[2] that should have fixed most of the lintian warnings. There is another INFO level warning: I: muse-el source: patch-not-forwarded-upstream [debian/patches/0005-convert-a-muse-init.el-example-to-UTF-8.patch] I wonder whether you would also like to forward this patch upstream. The rest warnings/infos are taken care of. PTAL. > > Best, > Nicholas > [1] http://pgp.mit.edu/pks/lookup?op=get=0x2DE965ED63825C93 [2] https://salsa.debian.org/emacsen-team/muse-el/-/commits/master -- Manphiz signature.asc Description: PGP signature
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Nicholas D Steeves writes: > Hello, > > Manphiz writes: > >>> Nicholas D Steeves writes: >>> >> >> Hi Nicholas, >> >> I have now prepared a merge request to migrate away from assoc.el[1] and >> also forwarded the patch upstream. Also set the package as team >> maintained and add myself as an upload. PTAL. Thanks! > > Wow, that was fast! LTGM, with one caveat: You are an Uploader for this > package now, so please drop the "Team upload" line entirely. This makes > you the human maintainer for the package, so I have sent you an invitation > for salsa/gitlab maintainer permissions for muse-el. Thanks! Though I'm not really a user of muse-el, I'd like to keep it in a good shape as an exercise as an Emacs addon maintainer. It looks like there is not too much work thanks to Elisp being a fairly stable language :) > >> [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 > > You will notice that there are two other MRs. Please double-check that > the bot did its work correctly, and please manually go through the > Debian Policy upgrade checklist, starting with the version muse-el uses, > and each version up to and including the one the bot proposed. If you > would like to take credit for this work, I recommend adding "and your > name" to the changelog entries the bot proposes. > > [ The name of the bot and your name ] > > In other words, I would like to give you permission to write to this > repo! Bots will often rebase their MRs to save you time, and I will > leave the decision of what gets merged first, and what gets rebased up > to you. Thanks for the tips! I checked the Debian Policy Upgrading Checklist[1] and agreed with Debian Janitor on the "no changes are needed" bit. And to avoid having to wait for the bot to do the rebase I've manually resolved the conflicts and rebased my MR on top of it as well. > > Let me know when your done, and we can talk about the next steps. Now all MRs are merged. Please advise the next steps. Thanks! > > Cheers, > Nicholas > [1] https://www.debian.org/doc/debian-policy/upgrading-checklist.html -- Manphiz signature.asc Description: PGP signature
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
control: tags -1 patch Manphiz writes: > Nicholas D Steeves writes: > >> Hello, >> >> Would you like to fix this RC bug and adopt the package? >> >> https://bugs.debian.org/1042911 >> >> and the orphan bug is here: #1016558 >> >> Best, >> Nicholas >> > > Hi Nicolas, > > Thanks for reaching out! Looks like this was caused by the removal of > the obsolete "assoc" package in Emacs 29.1 which had been deprecated > since 24. I'll try to work on a fix later this week. Hi Nicholas, I have now prepared a merge request to migrate away from assoc.el[1] and also forwarded the patch upstream. Also set the package as team maintained and add myself as an upload. PTAL. Thanks! [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 -- Manphiz
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Nicholas D Steeves writes: > Hello, > > Would you like to fix this RC bug and adopt the package? > > https://bugs.debian.org/1042911 > > and the orphan bug is here: #1016558 > > Best, > Nicholas > Hi Nicolas, Thanks for reaching out! Looks like this was caused by the removal of the obsolete "assoc" package in Emacs 29.1 which had been deprecated since 24. I'll try to work on a fix later this week. -- Manphiz signature.asc Description: PGP signature
Bug#1041824: src:volume-el: Enable merge request on salsa
control: reopen -1 control: retitle -1 src:volume-el: repair d/watch to track upstream head Manphiz writes: > Sean Whitton writes: > >> control: tag -1 + wontfix >> >> Hello, >> >> Thank you for these submissions. >> >> On Sun 23 Jul 2023 at 08:48pm -07, Manphiz wrote: >> >>> * Sync to latest head version, which basically just incorporated Sean's >>> patch upstream so that we don't need to host the patch anymore. >> >> Patches don't really work for merging new upstream releases -- in this >> case, pushing a branch somewhere and inviting me to merge it is better. >> For proposed new changes rather than merges, I do indeed prefer patches, >> so thank you for preparing those. >> >> In this case, I would prefer not to merge the new upstream, because it >> doesn't actually change the package. It's not a problem carrying the >> patch, and I think it's preferable. >> >> As for your first patch, I don't follow -- I think I already fixed that >> a while ago? Indeed, the patch does not apply to our team's repository. >> >> I would prefer not to apply the final patch until the QA team come and >> tell us that we should disable watch files like that. > > Hi Sean, > > Thanks for the comments and I understand your reasons. Actually I am > also unsure about how to deal with uscan errors with a watch file that > tracks upstream tags that don't exist, and as you and Nicolas both > suggest against disabling them, I think I may need to rethink how to > approach this. I'll probably ask in emacsen-team@ for comments later. Hi Nicolas, Sean, After consulting #debian-mentors I'm more convinced that tracking upstream head is the way to go. So I've done that and attached the patch. PTAL. Thanks! -- Manphiz >From f55b026f42f2887a370b7c1eca821129bf06151b Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Thu, 27 Jul 2023 16:54:38 -0700 Subject: [PATCH] Repair d/watch to track HEAD as no tag is available. --- debian/changelog | 7 +++ debian/watch | 6 +++--- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/debian/changelog b/debian/changelog index cc07223..0beb9aa 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +volume-el (1.0+git.20201002.afb75a5-4) UNRELEASED; urgency=medium + + * Team upload. + * Repair d/watch to track HEAD as no tag is available. + + -- Xiyue Deng Thu, 27 Jul 2023 16:53:26 -0700 + volume-el (1.0+git.20201002.afb75a5-3) unstable; urgency=medium * Pass correct number of arguments to define-obsolete-variable-alias. diff --git a/debian/watch b/debian/watch index dab1a60..4e31c99 100644 --- a/debian/watch +++ b/debian/watch @@ -1,4 +1,4 @@ version=4 -opts="filenamemangle=s/(?:.*?)?v?(\d[\d.]*)\.tar\.gz/volume.el-$1.tar.gz/" \ -https://github.com/dbrock/volume.el/tags \ -(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate +opts="mode=git, pgpmode=none, dversionmangle=s/^1.0\+git\./0.0~git/" \ +https://github.com/dbrock/volume.el \ +HEAD -- 2.39.2
Bug#1042289: magit: FTBFS: Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or directory" "compat")
tags 1042289 patch
thanks
Lucas Nussbaum writes:
> Source: magit
> Version: 3.3.0-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230726 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
>> make[2]: Entering directory '/<>'
>> Loading /<>/t/magit-tests.el (source)...
>> Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such
>> file or directory" "compat")
>> require(compat)
>>
>> load-with-code-conversion("/usr/share/emacs/site-lisp/elpa-src/with-editor-3"
>> "/usr/share/emacs/site-lisp/elpa-src/with-editor-3" nil t)
>> require(with-editor)
>> load-with-code-conversion("/<>/lisp/magit-process..."
>> "/<>/lisp/magit-process..." nil t)
>> require(magit-process)
>> load-with-code-conversion("/<>/lisp/magit-transie..."
>> "/<>/lisp/magit-transie..." nil t)
>> require(magit-transient)
>> load-with-code-conversion("/<>/lisp/magit-margin"
>> "/<>/lisp/magit-margin" nil t)
>> require(magit-margin)
>> load-with-code-conversion("/<>/lisp/magit-core.el"
>> "/<>/lisp/magit-core.el" nil t)
>> require(magit-core)
>> load-with-code-conversion("/<>/lisp/magit.el"
>> "/<>/lisp/magit.el" nil t)
>> require(magit)
>> load-with-code-conversion("/<>/t/magit-tests.el"
>> "/<>/t/magit-tests.el" nil nil)
>> load-file("t/magit-tests.el")
>> (progn (load-file "t/magit-tests.el") (ert-run-tests-batch-and-exit))
>> command-line-1(("-L" "./lisp" "-L"
>> "/usr/share/emacs/site-lisp/elpa-src/dash-2.19.1" "-L" "./../libgit" "-L"
>> "/usr/share/emacs/site-lisp/elpa-src/transient-0.3" "-L"
>> "/usr/share/emacs/site-lisp/elpa-src/with-editor-3" "--eval" "(progn
>> (load-file \"t/magit-tests.el\")(ert-r..."))
>> command-line()
>> normal-top-level()
>>
>> make[2]: *** [Makefile:111: test] Error 255
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2023/07/26/magit_3.3.0-2_unstable.log
>
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230726;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20230726=lu...@debian.org=1=1=1=1#results
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please mark it as 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
>
This is due to newer with-editor starts to depend on compat while magit
hasn't done it in 3.3.0 yet. I have prepared a merge request[1] that
cherrypicks the necessary upstream commit that fixes the compat
detection, as well as a few lintian fixes. PTAL. Thanks!
[1] https://salsa.debian.org/emacsen-team/magit/-/merge_requests/2
--
Manphiz
Bug#1041824: src:volume-el: Enable merge request on salsa
Sean Whitton writes: > control: tag -1 + wontfix > > Hello, > > Thank you for these submissions. > > On Sun 23 Jul 2023 at 08:48pm -07, Manphiz wrote: > >> * Sync to latest head version, which basically just incorporated Sean's >> patch upstream so that we don't need to host the patch anymore. > > Patches don't really work for merging new upstream releases -- in this > case, pushing a branch somewhere and inviting me to merge it is better. > For proposed new changes rather than merges, I do indeed prefer patches, > so thank you for preparing those. > > In this case, I would prefer not to merge the new upstream, because it > doesn't actually change the package. It's not a problem carrying the > patch, and I think it's preferable. > > As for your first patch, I don't follow -- I think I already fixed that > a while ago? Indeed, the patch does not apply to our team's repository. > > I would prefer not to apply the final patch until the QA team come and > tell us that we should disable watch files like that. Hi Sean, Thanks for the comments and I understand your reasons. Actually I am also unsure about how to deal with uscan errors with a watch file that tracks upstream tags that don't exist, and as you and Nicolas both suggest against disabling them, I think I may need to rethink how to approach this. I'll probably ask in emacsen-team@ for comments later. -- Manphiz
Bug#1041824: src:volume-el: disable d/watch and sync to latest head version
Nicholas D Steeves writes: > Manphiz writes: > >>>> I have been trying to fix uscan error of Emacs addon packages. When >>>> working on volume-el, I found that the repo on salsa didn't accept merge >>>> requests while most other packages did. If it can open up merge request >>>> access it would be great and I have some pending d/watch fixes. Thanks >>>> in advance! >>> >>> This may indicate that the Uploader wants patches rather than MRs, and >>> at the very least may indicate the Uploader doesn't want to monitor >>> Salsa for MRs. >>> >> >> Thanks for the explanation, Nicolas! Totally make sense. > > You're welcome! > >> Done. A little bit of explanation for the changes: >> >> * Upstream never had any tags, so uscan will always fail, so disable >> d/watch for now. This will result in an empty uscan results. > > Why is breaking notification of any future upstream tags better than > using uscan's git mode? Uscan's git mode will notify when upstream > pushes any commit, with or without a tag. Help is available in > #debian-mentors if writing an output format line that is suitable for > volume-el's existing version scheme is too challenging. > Hi Nicolas, Before implementing tracking all upstream commits, I wonder whether this is a good idea. AIUI we use uscan to track upstream tags for releases instead of tracking development activity. If upstream doesn't provide releases or tags, I think it's up to the maintainer whether to use a new upstream head as a new release. However if we use uscan to track that I wonder whether it may cause extra noise like in udd.debian.org or tracker.debian.org as it may notify all upstream activities. What do you think? > Regards, > Nicholas -- Manphiz
Bug#1041824: src:volume-el: Enable merge request on salsa
retitle 1041824 src:volume-el: disable d/watch and sync to latest head version tag 1041824 patch severity 1041824 minor thanks Apparently I misunderstood how "Control:" and cont...@bugs.debian.org work. Hopefully this time it should work.
Bug#1041824: src:volume-el: Enable merge request on salsa
retitle -1 src:volume-el: disable d/watch and sync to latest head version tag -1 patch severity -1 minor thanks Nicholas D Steeves writes: > Xiyue Deng writes: > >> Source: volume-el >> Severity: wishlist >> X-Debbugs-Cc: none, Xiyue Deng >> >> Dear maintainers, >> >> I have been trying to fix uscan error of Emacs addon packages. When >> working on volume-el, I found that the repo on salsa didn't accept merge >> requests while most other packages did. If it can open up merge request >> access it would be great and I have some pending d/watch fixes. Thanks >> in advance! > > This may indicate that the Uploader wants patches rather than MRs, and > at the very least may indicate the Uploader doesn't want to monitor > Salsa for MRs. > Thanks for the explanation, Nicolas! Totally make sense. > You can use git-format-patch to prepare a patch series from your git > history, and can attach those to a bug report here. > Done. > To retitle this bug, but this as the first line in your reply (won't > work with HTML email, of course): > > Control: retitle -1 src:volume-el: Useful subject of choice > Control: tag -1 patch > > If you attach a patch, I recommend updating the metadata with that > second line. > Done. A little bit of explanation for the changes: * Upstream never had any tags, so uscan will always fail, so disable d/watch for now. This will result in an empty uscan results. * Sync to latest head version, which basically just incorporated Sean's patch upstream so that we don't need to host the patch anymore. Please see the patches attached. > Cheers, > Nicholas > -- Manphiz >From 22464e7bee7a9ed7a18401109640a02502478fdb Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Tue, 19 Jan 2021 16:05:45 -0700 Subject: [PATCH 1/4] Pass correct number of arguments to define-obsolete-...-alias Recent Emacs master branch fails to bytecompile volume.el due to this. --- volume.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/volume.el b/volume.el index 35a2614..689bd4a 100644 --- a/volume.el +++ b/volume.el @@ -452,7 +452,7 @@ This corresponds to the `-D' option of amixer." (when (fboundp 'define-obsolete-variable-alias) (define-obsolete-variable-alias 'volume-amixer-control -'volume-amixer-default-channel)) +'volume-amixer-default-channel "1.0")) (defvar volume-amixer-current-channel volume-amixer-default-channel "The name of the ALSA mixer channel to manipulate.") @@ -654,7 +654,7 @@ Return either the new volume or nil, depending on the backend." (when (fboundp 'define-obsolete-function-alias) (define-obsolete-function-alias 'volume-channel-name -'volume-channel-label)) +'volume-channel-label "1.0")) (defun volume-channels () "Return the list of available channels." -- 2.39.2 >From 6ca047fcec9e9e8aeae380c1594cac2c392ce4ac Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Sun, 23 Jul 2023 05:08:05 -0700 Subject: [PATCH 2/4] Sync to current head (050d3e6). --- debian/changelog | 7 +++ 1 file changed, 7 insertions(+) diff --git a/debian/changelog b/debian/changelog index cc07223..65a4e66 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +volume-el (1.0+git.20220904.050d3e6-1) UNRELEASED; urgency=medium + + * Team upload. + * Sync to current head (050d3e6). + + -- Xiyue Deng Sun, 23 Jul 2023 05:06:07 -0700 + volume-el (1.0+git.20201002.afb75a5-3) unstable; urgency=medium * Pass correct number of arguments to define-obsolete-variable-alias. -- 2.39.2 >From 898fa2cdfbd3620f6a81e30f21f5f74cd21f5643 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Sun, 23 Jul 2023 05:09:17 -0700 Subject: [PATCH 3/4] Drop debian-changes. Merged upstream. --- debian/changelog | 1 + debian/patches/debian-changes | 37 --- debian/patches/series | 1 - 3 files changed, 1 insertion(+), 38 deletions(-) delete mode 100644 debian/patches/debian-changes delete mode 100644 debian/patches/series diff --git a/debian/changelog b/debian/changelog index 65a4e66..8cc2f70 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,7 @@ volume-el (1.0+git.20220904.050d3e6-1) UNRELEASED; urgency=medium * Team upload. * Sync to current head (050d3e6). + * Drop debian-changes. Merged upstream. -- Xiyue Deng Sun, 23 Jul 2023 05:06:07 -0700 diff --git a/debian/patches/debian-changes b/debian/patches/debian-changes deleted file mode 100644 index c60df9d..000 --- a/debian/patches/debian-changes +++ /dev/null @@ -1,37 +0,0 @@ -The Debian packaging of volume-el is maintained in git, using the merging -workflow described in dgit-maint-merge(7). There isn't a patch -queue that can be represented as a quilt series. - -A detailed breakdown of the changes is availabl
Bug#1041367: src:emacs: Detect default GCC version instead of hard-coding.
retitle 1041367 Automate GCC version handling. # tag with patch as a merge request is available. tag 1041367 patch thanks Manphiz writes: > Sean Whitton writes: > >> Hello, >> >> On Mon 17 Jul 2023 at 07:26pm -07, Xiyue Deng wrote: >> >>> Currently Emacs hard-codes the GCC version - more specifically the GCC >>> JIT version - for the native compile feature. As the default GCC >>> version may change once in a while, it may be beneficial to avoid >>> hard-coding the version and instead generate it using default GCC. I >>> have prepared a merge request on salsa[1], however as inexperienced as I >>> am this will surely look crude, but may be an okay-ish start of >>> discussion. Thanks! >> >> Thank you for looking into this. Unfortunately, I think it's unlikely >> that we'd want to apply this change: typically things like this are done >> manually in Debian. It's similar to debhelper compat level bumps. > > Thanks Sean! I understand. Would it be acceptable to have things > slightly automated while still make the GCC version hard-coded? Like > having a variable "default_gcc_version" which is manually changed and > the rest auto-generated? On further testing, it look like the automatic GCC version detection I proposed is indeed problematic: as the file regeneration happens before a buildd is involved, the generated version depends on the system that the people tries to build it. So as I'm currently using a stable system, when I run `gbp buildpackage` it will detect the GCC version as 12 while on sid it's 13 which is a nightmare. So, I've reworked the MR a bit now that it still hard-code the GCC version but at a single location[1] and all versions at other places are generated so that it's less like to make mistakes. Please help take another look. Thanks! [1] https://salsa.debian.org/rlb/deb-emacs/-/merge_requests/3/diffs#8756c63497c8dc39f7773438edf53b220c773f67_74_75 -- Manphiz
Bug#1040676: elpa-debian-el: Documentation fixes.
Nicholas D Steeves writes: > manp...@gmail.com writes: > >> I have a merge request on salsa[1] for documentation fixes for the >> package elpa-debian-el. The first commit has typo fixes only, the >> second one has some proposed wording fixes. Please review. Thanks! >> >> [1] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/10 > > Thank you for these fixes! I've started a review. If for some reason I > seem to take too long to notice that you've resolved all issues (when > you've resolved them), please ping me at this bug. > > Cheers, > Nicholas > Hi Nicolas, Friendly ping for comments :) If I missed your comments please help point me to them and I'll address them soon. -- Manphiz
Bug#1040903: elpa-zenburn-theme: Backport 2.8.0-1 for bookworm
Package: elpa-zenburn-theme Version: 2.7.0-2 Severity: wishlist X-Debbugs-Cc: none, Manphiz Hi, Recently elpa-zenburn-theme 2.8.0-1 hits trixie. It would be great to have it backported to bookworm as well. Thanks in advance! -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-zenburn-theme depends on: ii dh-elpa-helper 2.0.16 ii emacs 1:28.2+1-15 ii emacs-gtk [emacs] 1:28.2+1-15 ii emacsen-common 3.0.5 Versions of packages elpa-zenburn-theme recommends: ii emacs 1:28.2+1-15 ii emacs-gtk [emacs] 1:28.2+1-15 elpa-zenburn-theme suggests no packages. -- no debconf information
Bug#1040676: elpa-debian-el: Documentation fixes.
Package: elpa-debian-el Version: 37.10 Severity: normal X-Debbugs-Cc: none, Manphiz Dear Maintainers, I have a merge request on salsa[1] for documentation fixes for the package elpa-debian-el. The first commit has typo fixes only, the second one has some proposed wording fixes. Please review. Thanks! [1] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/10 -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-debian-el depends on: ii bzip2 1.0.8-5+b1 ii dh-elpa-helper 2.0.16 ii dpkg1.21.22 ii emacsen-common 3.0.5 ii reportbug 12.0.0 ii xz-utils5.4.1-0.2 Versions of packages elpa-debian-el recommends: ii emacs 1:28.2+1-15 ii emacs-gtk [emacs] 1:28.2+1-15 ii wget 1.21.3-1+b2 elpa-debian-el suggests no packages. -- no debconf information OpenPGP_signature Description: OpenPGP digital signature
Bug#836443: ocserv: Request for Jessie backport
Package: ocserv Version: 0.11.4-0.1 Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** I'd like to request a backport of ocserv to current stable release (Jessie). Ocserv is a very good alternative to contemporary VPN servers. Given that the next stable release is still months away, and more importantly, my current system is Yeeloong-based which is not getting the next stable support, it will be great to have it available to Jessie. Personally I have grabbed the current package from testing and compiled using a local stable cowbuilder setup (with backports) and it worked out-of-the-box, so I'd assume the backport effort to be minimum. Thanks in advance. -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: mipsel (mips64) Kernel: Linux 3.16.0-4-loongson-2f 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 ocserv depends on: ii dbus 1.8.20-0+deb8u1 ii init-system-helpers 1.22 ii libc62.19-18+deb8u4 ii libev4 1:4.15-3 ii libgnutls-deb0-283.3.8-6+deb8u3 ii libgssapi-krb5-2 1.12.1+dfsg-19+deb8u2 ii libhttp-parser2.12.1-2 ii liblz4-1 0.0~r122-2 ii libnettle4 2.7.1-5+deb8u1 ii libnl-3-200 3.2.24-2 ii libnl-route-3-2003.2.24-2 ii liboath0 2.4.1-1 ii libopts251:5.18.4-3 ii libpam0g 1.1.8-3.1+deb8u1+b1 ii libpcl1 1.6-1 ii libprotobuf-c1 1.0.2-1 ii libreadline6 6.3-8+b3 ii libseccomp2 2.2.3-3~bpo8+1 ii libsystemd0 230-7~bpo8+2 ii libtalloc2 2.1.2-0+deb8u1 ii libtasn1-6 4.2-3+deb8u2 ii libwrap0 7.6.q-25 ii ssl-cert 1.0.35 Versions of packages ocserv recommends: ii ca-certificates 20141019+deb8u1 ocserv suggests no packages. -- Configuration Files: /etc/ocserv/ocserv.conf changed [not included] -- no debconf information
Bug#598234: emacs23-nox: emacs fails to install on mipsel
Package: emacs23 Version: 23.3+1-1.1 Followup-For: Bug #598234 Hi, I just tried rebuilding emacs23 in my loongson box, and both emacs23 and emacs23-nox of the custom build install without problem. It might be related to my custom kernel or an updated binutils version (2.21.90.20111004-2). I'd like to help further testing this issue if more information is needed. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (350, 'unstable'), (300, 'experimental') Architecture: mipsel (mips64) Kernel: Linux 3.0.0-loongson-2f (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages emacs23 depends on: ii emacs23-bin-common 23.3+1-1.1 ii libasound2 1.0.24.1-4 ii libatk1.0-0 2.2.0-1 ii libc6 2.13-21 ii libcairo2 1.10.2-6.1 ii libdbus-1-3 1.4.16-1 ii libfontconfig1 2.8.0-3 ii libfreetype62.4.6-2 ii libgconf2-4 2.32.4-1 ii libgdk-pixbuf2.0-0 2.24.0-1 ii libgif4 4.1.6-9 ii libglib2.0-02.28.6-1 ii libgpm2 1.20.4-4 ii libgtk2.0-0 2.24.4-3 ii libice6 2:1.0.7-2 ii libjpeg88c-2 ii libm17n-0 1.6.2-3 ii libncurses5 5.9-2 ii libotf0 0.9.12-1 ii libpango1.0-0 1.28.4-3 ii libpng12-0 1.2.46-3 ii librsvg2-2 2.34.0-1 ii libsm6 2:1.2.0-2 ii libtiff43.9.5-2 ii libtinfo5 5.9-2 ii libx11-62:1.4.4-2 ii libxft2 2.2.0-3 ii libxpm4 1:3.5.9-1 ii libxrender1 1:0.9.6-2 ii zlib1g 1:1.2.5.dfsg-1 emacs23 recommends no packages. Versions of packages emacs23 suggests: ii emacs23-common-non-dfsg 23.3+1-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629351: on startup (Loongson2F mipsel system)
Package: gnome-settings-daemon Version: 2.30.2-4 Followup-For: Bug #629351 It seems that by rebuilding the package without ld flag -Wl,-z,defs fixes this problem. This shows much resemblance with bug#537572. Though the relation of such breakage and the ld flag is unclear, it is helpful to temporarily disable the flag before the true problem is found and resolved. Thanks. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (350, 'unstable'), (300, 'experimental') Architecture: mipsel (mips64) Kernel: Linux 3.0.0-loongson-2f (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-settings-daemon depends on: ii gconf22.32.4-1 GNOME configuration database syste ii libc6 2.13-16Embedded GNU C Library: Shared lib ii libcairo2 1.10.2-6.1 The Cairo 2D vector graphics libra ii libdbus-1-3 1.4.14-1 simple interprocess messaging syst ii libdbus-glib-1-2 0.94-4 simple interprocess messaging syst ii libfontconfig12.8.0-3generic font configuration library ii libgconf2-4 2.32.4-1 GNOME configuration database syste ii libgdk-pixbuf2.0-02.23.5-3 GDK Pixbuf library ii libglib2.0-0 2.28.6-1 The GLib library of C routines ii libgnome-desktop-2-17 2.30.2-2 Utility library for loading .deskt ii libgnome2-common 2.32.1-1 The GNOME library - common files ii libgnomekbd4 2.30.2-2 GNOME library to manage keyboard c ii libgstreamer-plugins-base0.10 0.10.35-1 GStreamer libraries from the base ii libgstreamer0.10-00.10.35-1 Core GStreamer libraries and eleme ii libgtk2.0-0 2.24.4-3 The GTK+ graphical user interface ii libnotify40.7.3-2sends desktop notifications to a n ii libx11-6 2:1.4.4-1 X11 client-side library ii libxi62:1.4.3-3 X11 Input extension library ii libxklavier16 5.1-2 X Keyboard Extension high-level AP gnome-settings-daemon recommends no packages. Versions of packages gnome-settings-daemon suggests: ii gnome-screensaver 2.30.0-3 GNOME screen saver and locker ii metacity [x-window-manager] 1:2.34.1-1 lightweight GTK+ window manager ii x11-xserver-utils 7.6+3 X server utilities -- 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
Bug#629351: Segfault on startup (Loongson2F mipsel system)
Package: gnome-settings-daemon Version: 2.30.2-3 Severity: grave The daemon segmentation fault on loading the plugins of /usr/lib/gnome-settings-daemon-2.0/*.so. The log of running gnome-settings-daemon --no-daemon --debug is attached. Please note that it segfaults on any *.so loading, not just libxrandr.so, which is verified by disabling each *.so file that causes the segfault. Also, the system is a Loongson2F based laptop running on mipsel. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (600, 'testing'), (300, 'unstable'), (200, 'experimental') Architecture: mipsel (mips64) Kernel: Linux 2.6.38-loongson-2f (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-settings-daemon depends on: ii gconf22.32.3-2 GNOME configuration database syste ii libc6 2.13-4 Embedded GNU C Library: Shared lib ii libcairo2 1.10.2-6 The Cairo 2D vector graphics libra ii libdbus-1-3 1.5.0-2simple interprocess messaging syst ii libdbus-glib-1-2 0.92-1 simple interprocess messaging syst ii libfontconfig12.8.0-2.2 generic font configuration library ii libgconf2-4 2.32.3-2 GNOME configuration database syste ii libgdk-pixbuf2.0-02.23.3-3 GDK Pixbuf library ii libglib2.0-0 2.28.6-1 The GLib library of C routines ii libgnome-desktop-2-17 2.30.2-2 Utility library for loading .deskt ii libgnome2-common 2.32.1-1 The GNOME library - common files ii libgnomekbd4 2.30.2-2 GNOME library to manage keyboard c ii libgstreamer-plugins-base0.10 0.10.34-1 GStreamer libraries from the base ii libgstreamer0.10-00.10.34-1 Core GStreamer libraries and eleme ii libgtk2.0-0 2.24.4-3 The GTK+ graphical user interface ii libnotify1 [libnotify1-gtk2.1 0.5.0-2sends desktop notifications to a n ii libx11-6 2:1.4.3-1 X11 client-side library ii libxi62:1.4.2-1 X11 Input extension library ii libxklavier16 5.1-1 X Keyboard Extension high-level AP gnome-settings-daemon recommends no packages. Versions of packages gnome-settings-daemon suggests: ii gnome-screensaver 2.30.0-3 GNOME screen saver and locker ii metacity [x-window-manager] 1:2.34.0-1 lightweight GTK+ window manager ii x11-xserver-utils 7.6+2 X server utilities -- no debconf information GNU gdb (GDB) 7.2-debian Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as mipsel-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/gnome-settings-daemon...(no debugging symbols found)...done. (gdb) set args --no-daemon --debug (gdb) run Starting program: /usr/bin/gnome-settings-daemon --no-daemon --debug [Thread debugging using libthread_db enabled] ** (gnome-settings-daemon:3190): DEBUG: Successfully connected to D-Bus ** (gnome-settings-daemon:3190): DEBUG: Starting settings manager ** (gnome-settings-daemon:3190): DEBUG: Loading settings plugins from dir: /usr/lib/gnome-settings-daemon-2.0/ ** (gnome-settings-daemon:3190): DEBUG: Loading plugin: /usr/lib/gnome-settings-daemon-2.0/font.gnome-settings-plugin ** (gnome-settings-daemon:3190): DEBUG: GnomeSettingsPluginInfo: name='Font' file='/usr/lib/gnome-settings-daemon-2.0/font.gnome-settings-plugin' location='font' ** (gnome-settings-daemon:3190): DEBUG: Loading plugin: /usr/lib/gnome-settings-daemon-2.0/keyboard.gnome-settings-plugin ** (gnome-settings-daemon:3190): DEBUG: GnomeSettingsPluginInfo: name='Keyboard' file='/usr/lib/gnome-settings-daemon-2.0/keyboard.gnome-settings-plugin' location='keyboard' ** (gnome-settings-daemon:3190): DEBUG: Loading plugin: /usr/lib/gnome-settings-daemon-2.0/mouse.gnome-settings-plugin ** (gnome-settings-daemon:3190): DEBUG: GnomeSettingsPluginInfo: name='Mouse' file='/usr/lib/gnome-settings-daemon-2.0/mouse.gnome-settings-plugin' location='mouse' ** (gnome-settings-daemon:3190): DEBUG: Loading plugin: /usr/lib/gnome-settings-daemon-2.0/xrandr.gnome-settings-plugin ** (gnome-settings-daemon:3190): DEBUG: GnomeSettingsPluginInfo: name='XRandR' file='/usr/lib/gnome-settings-daemon-2.0/xrandr.gnome-settings-plugin' location='xrandr' ** (gnome-settings-daemon:3190): DEBUG: Loading plugin: /usr/lib/gnome-settings-daemon-2.0/sound.gnome-settings-plugin ** (gnome-settings-daemon:3190): DEBUG: GnomeSettingsPluginInfo: name='Sound'
Bug#626024: Crash if the download URL contains non-ascii characters
Package: amule-daemon Version: 2.2.6+debian0-9+b1 Severity: important File: /usr/bin/amuled As subject says, if a URL contains unicode other than ascii characters, the daemon will crash. Removing those characters in the URL let it get processed without problem. IIRC this problem showed up before and got fixed, but I can't find the archived bug. HTH. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (300, 'unstable'), (200, 'experimental') Architecture: mipsel (mips64) Kernel: Linux 2.6.38-loongson-2f (PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages amule-daemon depends on: ii amule-common2.2.6+debian0-9 common files for the rest of aMule ii libc6 2.11.2-11Embedded GNU C Library: Shared lib ii libcrypto++95.6.1-4 General purpose cryptographic libr ii libgcc1 1:4.6.0-2GCC support library ii libpng12-0 1.2.44-2 PNG library - runtime ii libreadline66.1-3GNU readline and history libraries ii libstdc++6 4.6.0-2 The GNU Standard C++ Library v3 ii libupnp31:1.6.6-5Portable SDK for UPnP Devices, ver ii libwxbase2.8-0 2.8.10.1-3+b2wxBase library (runtime) - non-GUI ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages amule-daemon recommends: ii amule-utils 2.2.6+debian0-9+b1 utilities for aMule (command-line ii unzip 6.0-4 De-archiver for .zip files amule-daemon suggests no packages. -- Configuration Files: /etc/default/amule-daemon changed [not included] -- 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
Bug#625523: New upstream development version available.
Package: cairomm Severity: wishlist Version 1.9.8 is available upstream. As gtkmm3.0 requires at lease cairomm 1.9.2, it will be good to have it in Debian. Thanks. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (300, 'unstable'), (200, 'experimental') Architecture: mipsel (mips64) Kernel: Linux 2.6.38-lemote2f (PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#442828: glibmm: new patch for 2.14.1
retitle 442828 glibmm: new upstream version 2.14.1 available thanks A new .diff.gz . The one in my last mail contains unnecessary changes, which are rolled-back in this one. glibmm2.4_2.14.1-0.1.diff.gz Description: GNU Zip compressed data
Bug#442828: glibmm2.4: Patch for new version
Package: glibmm2.4 Followup-For: Bug #442828 I've attached the .diff.gz file for the new 2.14.1 version. Further more, according to the source code, #415464 has already been handled, so it can be closed. Hope some one can provide a NMU for it. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash glibmm2.4_2.14.1-0.1.diff.gz Description: GNU Zip compressed data --- glibmm2.4_2.12.10-0.1.diff 2007-07-04 18:47:03.0 +0800 +++ glibmm2.4_2.14.1-0.1.diff 2007-10-06 00:31:08.0 +0800 @@ -1,400 +1,237 @@ glibmm2.4-2.12.10.orig/scripts/config.sub -+++ glibmm2.4-2.12.10/scripts/config.sub -@@ -1,9 +1,10 @@ - #! /bin/sh - # Configuration validation subroutine script. - # Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, --# 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc. -+# 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, -+# Inc. - --timestamp='2005-12-11' -+timestamp='2007-01-18' - - # This file is (in principle) common to ALL GNU software. - # The presence of a machine in this file suggests that SOME GNU software -@@ -240,15 +241,16 @@ - | alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \ - | alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | alpha64pca5[67] \ - | am33_2.0 \ -- | arc | arm | arm[bl]e | arme[lb] | armv[2345] | armv[345][lb] | avr \ -+ | arc | arm | arm[bl]e | arme[lb] | armv[2345] | armv[345][lb] | avr | avr32 \ - | bfin \ - | c4x | clipper \ - | d10v | d30v | dlx | dsp16xx \ -- | fr30 | frv \ -+ | fido | fr30 | frv \ - | h8300 | h8500 | hppa | hppa1.[01] | hppa2.0 | hppa2.0[nw] | hppa64 \ - | i370 | i860 | i960 | ia64 \ - | ip2k | iq2000 \ -- | m32r | m32rle | m68000 | m68k | m88k | maxq | mcore \ -+ | m32c | m32r | m32rle | m68000 | m68k | m88k \ -+ | maxq | mb | microblaze | mcore | mep \ - | mips | mipsbe | mipseb | mipsel | mipsle \ - | mips16 \ - | mips64 | mips64el \ -@@ -268,26 +270,25 @@ - | mn10200 | mn10300 \ - | mt \ - | msp430 \ -+ | nios | nios2 \ - | ns16k | ns32k \ - | or32 \ - | pdp10 | pdp11 | pj | pjl \ - | powerpc | powerpc64 | powerpc64le | powerpcle | ppcbe \ - | pyramid \ -- | sh | sh[1234] | sh[24]a | sh[23]e | sh[34]eb | shbe | shle | sh[1234]le | sh3ele \ -+ | score \ -+ | sh | sh[1234] | sh[24]a | sh[23]e | sh[34]eb | sheb | shbe | shle | sh[1234]le | sh3ele \ - | sh64 | sh64le \ -- | sparc | sparc64 | sparc64b | sparc86x | sparclet | sparclite \ -- | sparcv8 | sparcv9 | sparcv9b \ -- | strongarm \ -+ | sparc | sparc64 | sparc64b | sparc64v | sparc86x | sparclet | sparclite \ -+ | sparcv8 | sparcv9 | sparcv9b | sparcv9v \ -+ | spu | strongarm \ - | tahoe | thumb | tic4x | tic80 | tron \ - | v850 | v850e \ - | we32k \ -- | x86 | xscale | xscalee[bl] | xstormy16 | xtensa \ -+ | x86 | xc16x | xscale | xscalee[bl] | xstormy16 | xtensa \ - | z8k) - basic_machine=$basic_machine-unknown - ;; -- m32c) -- basic_machine=$basic_machine-unknown -- ;; - m6811 | m68hc11 | m6812 | m68hc12) - # Motorola 68HC11/12. - basic_machine=$basic_machine-unknown -@@ -317,18 +318,18 @@ - | alpha64-* | alpha64ev[4-8]-* | alpha64ev56-* | alpha64ev6[78]-* \ - | alphapca5[67]-* | alpha64pca5[67]-* | arc-* \ - | arm-* | armbe-* | armle-* | armeb-* | armv*-* \ -- | avr-* \ -+ | avr-* | avr32-* \ - | bfin-* | bs2000-* \ - | c[123]* | c30-* | [cjt]90-* | c4x-* | c54x-* | c55x-* | c6x-* \ - | clipper-* | craynv-* | cydra-* \ - | d10v-* | d30v-* | dlx-* \ - | elxsi-* \ -- | f30[01]-* | f700-* | fr30-* | frv-* | fx80-* \ -+ | f30[01]-* | f700-* | fido-* | fr30-* | frv-* | fx80-* \ - | h8300-* | h8500-* \ - | hppa-* | hppa1.[01]-* | hppa2.0-* | hppa2.0[nw]-* | hppa64-* \ - | i*86-* | i860-* | i960-* | ia64-* \ - | ip2k-* | iq2000-* \ -- | m32r-* | m32rle-* \ -+ | m32c-* | m32r-* | m32rle-* \ - | m68000-* | m680[012346]0-* | m68360-* | m683?2-* | m68k-* \ - | m88110-* | m88k-* | maxq-* | mcore-* \ - | mips-* | mipsbe-* | mipseb-* | mipsel-* | mipsle-* \ -@@ -350,29 +351,28 @@ - | mmix-* \ - | mt-* \ - | msp430-* \ -+ | nios-* | nios2-* \ - | none-* | np1-* | ns16k-* | ns32k-* \ - | orion-* \ - | pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \ - | powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \ - | pyramid-* \ - | romp-* | rs6000-*
Bug#444386: glade-3: new upstream version 3.4.0 available
Package: glade-3 Version: 3.2.2-1 Severity: wishlist It can be found at http://ftp.gnome.org/pub/GNOME/sources/glade3/3.4/ . Despite that it still doesn't provide GtkBuilder support for gtk+2.12, it has several bug fixes, such as the notorious Input Dialog bug. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430142: libxml++2.6: new version 2.20.0 available
retitle 430142 libxml++2.6: new version 2.20.0 available thanks Now 2.20.0 can be found at: http://ftp.gnome.org/pub/GNOME/sources/libxml++/2.20/ http://ftp.gnome.org/pub/GNOME/sources/libxml++/2.18/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443651: libsigc++-2.0: new upstream version 2.0.18 available
Package: libsigc++-2.0 Severity: wishlist It can be found at http://ftp.gnome.org/pub/GNOME/sources/libsigc++/2.0/ Note that libsigc++ 2.1.1 has also been release, which however is in the unstable branch. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443395: gtkmm2.4: new upstream version 2.12 available
Package: gtkmm2.4 Severity: wishlist gtkmm 2.12.0 has showed up at http://ftp.gnome.org/pub/GNOME/sources/gtkmm/2.12/ which provide many new features with gtk+ 2.12. Since gtk+ 2.12 has entered sid, it'll be great to have gtkmm 2.12 as well. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434701: flac: new upstream version 1.2.1 available
retitle 434701 flac: new upstream version 1.2.1 available thanks Now 1.2.1 was out on Sep 17th, which can be found at http://sourceforge.net/project/showfiles.php?group_id=13478 Hope it'll enter sid soon :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442822: kqemu-source: Fatal trap 9 when running freebsd
Package: kqemu-source Version: 1.3.0~pre11-6.1 Severity: normal I tried to virtualize freebsd using qemu with kqemu but failed, both 6.2 release and 7.0 current, and both w/ and w/o acpi. The failure log said: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc00fa3d4 stack pointer = 0x28:0xc1420cfc frame pointer = 0x28:0xc1420d28 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 () [thread pid 0 tid 0 ] Stopped at 0xc00fa3d4: lret db However it works fine without kqemu. I've been encountering the same problem since qemu 0.8.2 and kqemu 1.3.0~pre9. The current qemu version is 0.9.0+20070816-1. Surprisingly, the same qemu and kqemu version under gentoo and LFS works fine, and works under Windows as well. So as a first look the problem probably sits in Debian side. I can provide further information if necessary. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kqemu-source depends on: ii bzip2 1.0.3-7high-quality block-sorting file co ii debhelper 5.0.54 helper programs for debian/rules ii dpatch2.0.27 patch maintenance system for Debia ii make 3.81-3 The GNU version of the make util ii module-assistant 0.10.11tool to make module package creati kqemu-source recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442828: glibmm2.4: new upstream version 2.14.0 available
Package: glibmm2.4 Severity: wishlist It can be found at http://ftp.gnome.org/pub/GNOME/sources/glibmm/2.14/ gtkmm 2.12.0 is available as well, which, however, have to wait for gtk 2.12.0 to enter first. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402289: -kernel-kqemu still causes freebsd guest fatal trap 9
Current qemu, kqemu and bochsbios from sid still causes freebsd guest failure, which is described in detail in #442822[1]. [1] http://bugs.debian.org/442822 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442822: Acknowledgement (kqemu-source: Fatal trap 9 when running freebsd)
reassign 442822 qemu merge 442822 402289 thanks Oops, I should really scrutinize the qemu BTS carefully. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442379: libstdc++6-4.2-dev: Missing /usr/include/c++/4.2.1/bits/atomicity.h
Hristo Hristov wrote: Package: libstdc++6-4.2-dev Version: 4.2.1-4 Severity: important The file /usr/include/c++/4.2.1/bits/atomicity.h is missing, so any program using it cannot be compiled. It has been moved to ext/atomicity.h since 4.2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433064: wine: upstream version 0.9.43 available
retitle 433064 wine: upstream version 0.9.43 available severity 433064 wishlist thanks Since 0.9.41 has entered sid, there's no scim conflict currently, so knock down severity to wishlist, and retitle for new upstream version. if you skip releases, the damage is greater if it does happen. If you don't, users always have something to fall back on. Sounds reasonable. Though old binaries are deleted from repository when new version enters, their sources are saved for this purpose I believe. Thanks Ove for your work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438921: bmpx: new upstream version 0.40.1 is available
Package: bmpx Version: 0.40.0~rc3-1 Followup-For: Bug #438921 And, since 0.40.1 version is available[1], it'll be better to fix this bug with the new version :) [1] http://bmpx.beep-media-player.org/site/Downloads -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438921: bmpx: Currently uninstallable because of depending on non-exist boost version
Package: bmpx Version: 0.40.0~rc3-1 Severity: grave Justification: renders package unusable Current bmpx version is built against boost 1.34.0, which is now superseded by boost 1.34.1. As it is depending on libboost-filesystem1.34.0, libboost-iostreams1.34.0, libboost-regex1.34.0, it is currently uninstallable, so I set severity grave. However, a rebuilt against current boost 1.34.1 should be sufficient to eliminate this glitch. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438925: libxmmsclient++1: uninstallable due to depending on superseded boost version
Package: libxmmsclient++1 Version: 0.2DrJekyll-4 Severity: grave Justification: renders package unusable Currently libxmmsclient++1 is uninstallable because it is depending on libboost-signals1.34.0, which is part of boost 1.34.0 and is superseded by boost 1.34.1, which causes the uninstallable situation. A rebuilt against boost 1.34.1 should be sufficient to fix it. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406239: gnochm: new version 0.9.10 available
retitle 406239 gnochm: new version 0.9.10 available Oops, wrong command... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438194: stardict: new version 3.0.0 available
Package: stardict Version: 2.4.8-1 Severity: wishlist New upstream version 3.0.0 is available for Download: http://sourceforge.net/project/showfiles.php?group_id=80679 But currently there are several impediments for it to be included in Debian because: (1) It contains some nonportable configuration in configure script, and a minor miscoding problem when compiled with --disable-gnome-support. However, the fixes are trivial, and a patch from Gentoo BTS already handled them: http://bugs.gentoo.org/show_bug.cgi?id=188684 and maybe upstream is going to address them soon; (2) It depends on festival version 1.96 and speech-tools 1.2.96 for festival-plugin, which are not available in Debian yet. According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327541 these 2 versions are about to upload to experimental, which hasn't happened yet. I'll keep tracking the situation. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (995, 'testing'), (500, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages stardict depends on: ii gconf2 2.18.0.1-3 GNOME configuration database syste ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.18.0-2 The ATK accessibility toolkit ii libaudiofile0 0.2.6-7 Open-source version of SGI's audio ii libavahi-client30.6.20-2 Avahi client library ii libavahi-common30.6.20-2 Avahi common library ii libavahi-glib1 0.6.20-2 Avahi glib integration library ii libbonobo2-02.18.0-2 Bonobo CORBA interfaces library ii libbonoboui2-0 2.18.0-5 The Bonobo UI library ii libc6 2.6-2GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libdbus-1-3 1.1.1-3 simple interprocess messaging syst ii libesd-alsa0 [libesd0] 0.2.36-3 Enlightened Sound Daemon (ALSA) - ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libgcc1 1:4.2.1-4GCC support library ii libgconf2-4 2.18.0.1-3 GNOME configuration database syste ii libgcrypt11 1.2.4-2 LGPL Crypto library - runtime libr ii libglib2.0-02.12.13-1The GLib library of C routines ii libgnome-keyring0 0.8.1-2 GNOME keyring services library ii libgnome2-0 2.18.0-4 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-3 A powerful object-oriented display ii libgnomeui-02.18.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.18.1-2 GNOME Virtual File System (runtime ii libgnutls13 1.6.3-1 the GNU TLS library - runtime libr ii libgpg-error0 1.4-2library for common error values an ii libgtk2.0-0 2.10.13-1The GTK+ graphical user interface ii libice6 2:1.0.3-3X11 Inter-Client Exchange library ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii liborbit2 1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.16.5-1 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-2 PNG library - runtime ii libpopt01.10-3 lib for parsing cmdline parameters ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libstdc++6 4.2.1-4 The GNU Standard C++ Library v3 ii libtasn1-3 0.3.9-1 Manage ASN.1 structures (runtime) ii libx11-62:1.1.3-1X11 client-side library ii libxcursor1 1:1.1.8-2X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 2:1.1.2-1X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxml2 2.6.29.dfsg-1GNOME XML library ii libxrandr2 2:1.2.1-1X11 RandR extension library ii libxrender1 1:0.9.2-1X Rendering Extension client libra ii stardict-common 2.4.8-1 International dictionary - data fi ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime stardict recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe.
Bug#437682: libestools1.2-dev: Error-prone macro-inclusion in some header files
Package: libestools1.2-dev Version: 1:1.2.3-11 Severity: important Some of the header files contains a macro guarded inclusion which includes a non-existing file named est_string_config.h. Here's some snips: // /usr/include/speech_tools/EST_String.h 37 #ifdef HAVE_CONFIG_H 38 #include est_string_config.h 39 #endif As you can see, the non-existing est_string_config.h will be included if HAVE_CONFIG_H is defined, which is very common with autotools generated packages. Currently it causes FTBFS with new stardict version 3.0.0, and possibly a majority of rdepends. It is said that the new 2.0beta version 1.96 of festival and version 1.2.96 of speech-tools has fixed this glitch already, which is binary compatible with 1.4.3. It is highly appreciated if the new version is packaged for Debian. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (995, 'testing'), (500, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libestools1.2-dev depends on: ii libc6-dev 2.6-2 GNU C Library: Development Librari ii libesd0-dev 0.2.36-3 Enlightened Sound Daemon - Develop ii libestools1.2 1:1.2.3-11 Edinburgh Speech Tools Library ii libncurses5-dev 5.6+20070716-1 Developer's libraries and docs for Versions of packages libestools1.2-dev recommends: pn speech-tools-doc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434180: scim: sporadic lockup in varies programs
Ming Hua wrote: Hi manphiz, Thanks for the quick reply。 On Sun, Aug 12, 2007 at 10:27:47AM +0800, manphiz wrote: Ming Hua wrote: I've been using scim 1.4.7-1, with /FrontEnd/X11/Dynamic as false, XIM mode, and over-the-spot style for quite some time. In the past few weeks, I've only encountered one keyboard input lock-up, and I'm not even sure it's scim's fault. So I got curious (since there are many Ubuntu bug reports saying the lock-up is quite frequent) and started playing with my scim settings. I finally found out that such lock-up seems to happen much often with on-the-spot style. This seems also related to the Nautilus breaks on several places and can't input anything bugs (for example [1]), as I've never had problem before with nautilus, but seem to be able to reproduce them with on-the-spot style. So manphiz, have you been experiencing this bug with 1.4.7-1? And what input style are you using? You can check in the scim-setup window, by FrontEnd - Global Setup - Embed Preedit String into client window item. Can you test the other style to confirm my conclusion? 1. https://bugs.launchpad.net/ubuntu/+source/scim/+bug/90043 I tried with /FrontEnd/X11/Dynamic set to false, and tweaking the Embed Preedit String into client window in scim 1.4.7-1. The lock up did disappeared for a lot of normal usage said to trigger the problem, but still showed up in some of them, one of which is the massive new tabs in gnome-terminal, which still resulted in lockup and changing the spot setting didn't help but can be resolved by setting /FrontEnd/X11/Dynamic to true. The nautilus one mentioned in your link to launchpad is still reproducible at my place too, which really compromises daily use. There may be other way to trigger the lock up as well. After some more testing, I realized that the Embed Preedit String into client window thing in scim-setup doesn't seem to change the scim setting properly. After you unset this option, i.e., using over the spot style, what is the result of the command grep OnTheSpot ~/.scim/config on your system? If you get /FrontEnd/OnTheSpot as false but /FrontEnd/X11/OnTheSpot as true, can you manually change /FrontEnd/X11/OnTheSpot to false (make sure scim isn't running when you edit ~/.scim/config file) and do some more testing? Changing both to false seems to fix the lock-up problem for me in XIM mode with /FronEnd/X11/Dynamic = false. You are right. The Embed settings only change /FrontEnd/OnTheSpot and left /FrontEnd/X11/OnTheSpot intact. I manually set the latter to false, which unfortunately still causes the problem. It seems currently the only way to cover the hole temporarily is still changing /FrontEnd/X11/Dynamic to true. I agree that maybe scim is not the only culprit, I'll keep testing with /FronEnd/X11/Dynamic set to false. Based on the current information, maybe it is reasonable to reassign this bug to libX11. Yes, I do suspect this is a libX11 bug (since Redhat people say so), but as there aren't many people familiar with both input methods and X (evident by the fact the X.org upstream bug has been silent for quite a while), I want to find out the exact procedure to reproduce this bug before reassign/clone this bug to libX11. Thanks again, Ming 2007.08.12 I'll try to get a backtrace, which I hope might be more helpful :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434180: scim: sporadic lockup in varies programs
Ming Hua wrote:
I agree that maybe scim is not the only culprit, I'll keep testing with
/FronEnd/X11/Dynamic set to false. Based on the current information, maybe
it is reasonable to reassign this bug to libX11.
Yes, I do suspect this is a libX11 bug (since Redhat people say so), but
as there aren't many people familiar with both input methods and X
(evident by the fact the X.org upstream bug has been silent for quite a
while), I want to find out the exact procedure to reproduce this bug
before reassign/clone this bug to libX11.
Following this lead, I grabbed the patch from
https://bugs.freedesktop.org/show_bug.cgi?id=7869
and applied to the experimental version of libX11 whose unpatched
version is still confirmed susceptible. After the patched libX11
compiled and installed, all the malfunctions are gone now! I believe
this can be treated as a confirmation of libX11's culpability. The patch
is attached, and please reassign/clone this bug to libX11.
--- libX11-1.1.3/modules/im/ximcp/imDefLkup.c.bug-201284 2006-10-30 23:58:41.0 -0500
+++ libX11-1.1.3/modules/im/ximcp/imDefLkup.c 2006-10-30 23:58:41.0 -0500
@@ -216,8 +216,13 @@
Xic ic,
BITMASK16 mode)
{
-if (mode XimSYNCHRONUS) /* SYNC Request */
- MARK_NEED_SYNC_REPLY(ic);
+if (mode XimSYNCHRONUS) /* SYNC Request */ {
+ if (IS_FOCUSED(ic))
+ MARK_NEED_SYNC_REPLY(ic);
+ else
+ _XimProcSyncReply(ic-core.im, ic);
+}
+
return True;
}
--- libX11-1.1.3/modules/im/ximcp/imDefIc.c.bug-201284 2006-06-22 17:22:22.0 -0400
+++ libX11-1.1.3/modules/im/ximcp/imDefIc.c 2006-10-30 23:58:41.0 -0500
@@ -949,6 +949,8 @@
(void)_XimWrite(im, len, (XPointer)buf);
_XimFlush(im);
+MARK_FOCUSED(ic);
+
_XimRegisterFilter(ic);
return;
}
@@ -994,6 +996,8 @@
(void)_XimWrite(im, len, (XPointer)buf);
_XimFlush(im);
+UNMARK_FOCUSED(ic);
+
_XimUnregisterFilter(ic);
return;
}
--- libX11-1.1.3/src/xlibi18n/XimintP.h.bug-201284 2006-06-22 17:22:23.0 -0400
+++ libX11-1.1.3/src/xlibi18n/XimintP.h 2006-10-31 00:01:30.0 -0500
@@ -244,6 +244,7 @@
#define IC_CONNECTED (1L)
#define FABLICATED (1L 1)
#define NEED_SYNC_REPLY (1L 2)
+#define FOCUSED (1L 3)
/*
* macro for the flag of XICPrivateRec
@@ -269,6 +270,13 @@
#define UNMARK_NEED_SYNC_REPLY(ic) \
(((Xic)ic)-private.proto.flag = ~NEED_SYNC_REPLY)
+#define IS_FOCUSED(ic) \
+ (((Xic)ic)-private.proto.flag FOCUSED)
+#define MARK_FOCUSED(ic) \
+ (((Xic)ic)-private.proto.flag |= FOCUSED)
+#define UNMARK_FOCUSED(ic) \
+ (((Xic)ic)-private.proto.flag = ~FOCUSED)
+
/*
* macro for the filter_event_mask of XICPrivateRec
*/
Bug#436125: gnome-netstatus-applet: failed to update statistics after reconnection
Seems it is indeed forsaken upstream. Is it possible for Debian team to include this patch on its own and provide an update? :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434180: scim: sporadic lockup in varies programs
Ming Hua wrote: As I've said on IRC, version 1.4.7 is supposed to fix a big part of this problem. Yes, the situation *is* improved quite a lot, but not all of them. I've been using scim 1.4.7-1, with /FrontEnd/X11/Dynamic as false, XIM mode, and over-the-spot style for quite some time. In the past few weeks, I've only encountered one keyboard input lock-up, and I'm not even sure it's scim's fault. So I got curious (since there are many Ubuntu bug reports saying the lock-up is quite frequent) and started playing with my scim settings. I finally found out that such lock-up seems to happen much often with on-the-spot style. This seems also related to the Nautilus breaks on several places and can't input anything bugs (for example [1]), as I've never had problem before with nautilus, but seem to be able to reproduce them with on-the-spot style. So manphiz, have you been experiencing this bug with 1.4.7-1? And what input style are you using? You can check in the scim-setup window, by FrontEnd - Global Setup - Embed Preedit String into client window item. Can you test the other style to confirm my conclusion? 1. https://bugs.launchpad.net/ubuntu/+source/scim/+bug/90043 Thanks, Ming 2007.08.11 I tried with /FrontEnd/X11/Dynamic set to false, and tweaking the Embed Preedit String into client window in scim 1.4.7-1. The lock up did disappeared for a lot of normal usage said to trigger the problem, but still showed up in some of them, one of which is the massive new tabs in gnome-terminal, which still resulted in lockup and changing the spot setting didn't help but can be resolved by setting /FrontEnd/X11/Dynamic to true. The nautilus one mentioned in your link to launchpad is still reproducible at my place too, which really compromises daily use. There may be other way to trigger the lock up as well. I agree that maybe scim is not the only culprit, I'll keep testing with /FronEnd/X11/Dynamic set to false. Based on the current information, maybe it is reasonable to reassign this bug to libX11. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406239: gnochm: new version 0.9.10 available
retitle 406239 new version 0.9.10 available GnoCHM version 0.9.10 is out on May 2007. Maybe Carlos is too busy currently, but I can wait patiently. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436125: gnome-netstatus-applet: failed to update statistics after reconnection
Package: gnome-netstatus-applet Version: 2.12.1-1 Severity: normal Tags: patch gnome-netstatus-applet currently fails to update its statistics after disconnection and reconnection. An investigation within the source revealed it was because the status determination between current and previous state is based on packets field, which, according to an investigation in /proc/net/dev, will be reset to 0 after reconnection, which in turn resulted in the status will be determined as Idle until the new packets data is larger than the previously saved one. Whilst the bytes field won't be reset to 0 and will continue to accumulate. Changing the comparison criterion to bytes-based eliminates this glitch. The patch is attached below. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (800, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-netstatus-applet depends on: ii gconf2 2.18.0.1-3 GNOME configuration database syste ii gksu2.0.0-4 graphical frontend to su ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.18.0-2 The ATK accessibility toolkit ii libbonobo2-02.18.0-2 Bonobo CORBA interfaces library ii libbonoboui2-0 2.18.0-5 The Bonobo UI library ii libc6 2.6-2GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libgconf2-4 2.18.0.1-3 GNOME configuration database syste ii libglade2-0 1:2.6.1-1library to load .glade files at ru ii libglib2.0-02.12.13-1The GLib library of C routines ii libgnome-keyring0 0.8.1-2 GNOME keyring services library ii libgnome2-0 2.18.0-4 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-3 A powerful object-oriented display ii libgnomeui-02.18.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.18.1-2 GNOME Virtual File System (runtime ii libgtk2.0-0 2.10.13-1The GTK+ graphical user interface ii libice6 2:1.0.3-3X11 Inter-Client Exchange library ii liborbit2 1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB ii libpanel-applet2-0 2.18.3-1 library for GNOME Panel applets ii libpango1.0-0 1.16.5-1 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-2 PNG library - runtime ii libpopt01.10-3 lib for parsing cmdline parameters ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1:1.1.8-2X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 2:1.1.1-1X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxml2 2.6.29.dfsg-1GNOME XML library ii libxrandr2 2:1.2.1-1X11 RandR extension library ii libxrender1 1:0.9.2-1X Rendering Extension client libra ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime gnome-netstatus-applet recommends no packages. -- no debconf information --- gnome-netstatus-2.12.1.orig/src/netstatus-iface.c 2007-02-13 17:39:19.0 +0800 +++ gnome-netstatus-2.12.1/src/netstatus-iface.c2007-08-05 22:52:54.0 +0800 @@ -524,8 +524,8 @@ in_bytes, out_bytes, iface-priv-stats.in_bytes, iface-priv-stats.out_bytes); - rx = in_packets iface-priv-stats.in_packets; - tx = out_packets iface-priv-stats.out_packets; + rx = in_bytes iface-priv-stats.in_bytes; + tx = out_bytes iface-priv-stats.out_bytes; if (!tx !rx) state = NETSTATUS_STATE_IDLE;
Bug#436125: gnome-netstatus-applet: failed to update statistics after reconnection
Sven Arvidsson wrote: but I'm not sure if gnome-netstatus is actively maintained these days. Unfortunately I believe so, since it is still staying at version 2.12.x while gnome is looking forward to 2.20. However, it is nonetheless still widely used throughout gnome desktop users as network status indicator, and this bug is quite annoying for wireless users as I am who are often suffering from unstable connection. Wish it'll draw some attention from upstream maintainer, and thanks a lot for your quick response :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427406: metacity: No more mouse/keyboard-input possible, after closing crashed application
I somehow resist the possibility of making my system unstable again, since everything else works fine with Testing and upgrading to 2.18.3 didn't help. Additionally, I noticed no hint showing that this problem was solved with never versions. Some search work at http://bugzilla.gnome.org shows no similar report, and as it is unreproducible anywhere, there's no reason for the upstream or Debian maintainer to address such bug, which doesn't prevent the possibility for the bug's silent disappearance either. Moreover, there's no difficulty to downgrade back to 2.14.5 if something still goes wrong. Finally, as the only one encountering this bug, only you can tell whether 2.18.5 is ok. So why not give it a shot? :) P.S.: No offense, but I really doubt such a problem is necessary to be set as grave severity. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434180: scim: sporadic lockup in varies programs
Package: scim Version: 1.4.7-1 Severity: normal Already discussed in https://bugs.launchpad.net/ubuntu/+source/scim/+bug/66104 And the problem showed up from version 1.4.6. Current transitional solution is changing the value of /FrontEnd/X11/Dynamic in /etc/scim/config or ~/.scim/config from false to true, which is known to unfortunately break deadkeys usage in European keyboard layouts. So this walk around is only recommend when such problem shows up. Seems further investigation is required. -- Package-specific info: Related packages: ii libscim8c2a1.4.7-1library for SCIM platform ii scim 1.4.7-1smart common input method platform ii scim-bridge0.4.12-1 Another gtk-immodule of SCIM (transitional p ii scim-bridge-ag 0.4.12-1 IME server of scim-bridge communicate with S ii scim-bridge-cl 0.4.12-1 IME server of scim-bridge communicate with S ii scim-gtk2-immo 1.4.7-1GTK+2 input method module with SCIM as backe ii scim-modules-s 1.4.7-1socket modules for SCIM platform ii scim-pinyin0.5.0-3smart pinyin IM engine for SCIM platform Related environment variables: [EMAIL PROTECTED] $GTK_IM_MODULE=xim Installed SCIM components: /usr/lib/scim-1.0: 1.4.0 scim-helper-launcher scim-helper-manager scim-launcher scim-panel-gtk /usr/lib/scim-1.0/1.4.0: Config Filter FrontEnd Helper IMEngine SetupUI /usr/lib/scim-1.0/1.4.0/Config: simple.so socket.so /usr/lib/scim-1.0/1.4.0/Filter: sctc.so /usr/lib/scim-1.0/1.4.0/FrontEnd: socket.so x11.so /usr/lib/scim-1.0/1.4.0/Helper: setup.so /usr/lib/scim-1.0/1.4.0/IMEngine: pinyin.so rawcode.so socket.so /usr/lib/scim-1.0/1.4.0/SetupUI: aaa-frontend-setup.so aaa-imengine-setup.so panel-gtk-setup.so pinyin-imengine-setup.so -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (800, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages scim depends on: ii libatk1.0-0 1.18.0-2 The ATK accessibility toolkit ii libc6 2.6-2GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2generic font configuration library ii libgcc1 1:4.2-20070712-1 GCC support library ii libglib2.0-02.12.12-1+b1 The GLib library of C routines ii libgtk2.0-0 2.10.13-1The GTK+ graphical user interface ii libpango1.0-0 1.16.4-1 Layout and rendering of internatio ii libscim8c2a 1.4.7-1 library for SCIM platform ii libstdc++6 4.2-20070712-1 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1:1.1.8-2X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 2:1.1.1-1X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxrandr2 2:1.2.1-1X11 RandR extension library ii libxrender1 1:0.9.2-1X Rendering Extension client libra Versions of packages scim recommends: ii im-switch 1.14 Input method switch framework ii scim-gtk2-immodule1.4.7-1GTK+2 input method module with SCI -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427406: metacity: No more mouse/keyboard-input possible, after closing crashed application
Thanks to curiosity, I updated my metacity from 1:2.14.5-4(testing) to current unstable 1:2.18.5-1, and when encountering Force Quit situation, everything works fine at my place: no lockup, no non-responding, everything is fine. Maybe you were still staying at 2.18.3? Try the newer version. Or maybe something else is culpable on your particular system? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427406: metacity: No more mouse/keyboard-input possible, after closing crashed application
According to the partial backtrace provided by Claudius Hubig, in which the backtrace got lost when encountered libc6-i686 stuff, I've got a Deja Vu with a recent bug reported toward aptitude(#431054) reporting keyboard handling lost when lib6-i686 was installed under kernel 2.6.18, and the symptom mysteriously got away when testing kernel had been updated to 2.6.21. I hope the same situation applies here too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433064: wine: New upstream version 0.9.41 available
Package: wine Version: 0.9.34-1 Severity: normal Wine 0.9.41 was released on July 13, wrt previous requests #421510 and #420680. However I use normal severity instead of wishlist to indicate that a conflict between scim and wine was supposed to be fixed since 0.9.35, and all new versions henceforth will be helpful to solve this incompatibility. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (800, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages wine depends on: ii debconf [debconf-2.0]1.5.13 Debian configuration management sy ii libwine 0.9.34-1Windows API Implementation (Librar ii xbase-clients1:7.2.ds2-2 miscellaneous X clients Versions of packages wine recommends: ii msttcorefonts 2.2Installer for Microsoft TrueType c pn wine-utilsnone (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433064: Further information
Here's the upstream bug link in which the problem was discussed: http://bugs.winehq.org/show_bug.cgi?id=6547 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431054: aptitude doesn't respond to keyboard after installing/upgrading a package
Upgrading the kernel to 2.6.21 seems to have fixed this. Same here. The thread backtraces look sane now :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431054: aptitude: possible culprit found
Daniel Burrows wrote: Well, that eliminates the processor variable. I don't think it's the testing libc6-i686 either -- I've tried this on some testing machines and they work just fine, and nothing in the changelog suggests that it would impact this bug. Yeah, you're right. I installed glibc 2.5-11 from unstable and the same thing happened as well. So the glibc version seems irrelevant. And some people I know don't suffer from this either, even if they have libc6-i686 installed. It looks to me like the problem is that the input thread isn't being restarted. Either that, or that curses isn't reinitializing the terminal for some reason, but the code to bring curses back up is 'obviously right' and hasn't changed recently, whereas the input thread was rewritten recently. Daniel I've rebuilt aptitude without being stripped and got 2 backtraces when 'g' is finished, one is the bad one with lib6-i686 and the other is the good one without it. I've attached them below. The first 2 threads are basically identical despite the corrupted stack, whilst the last 2 in the bad seems indicating something was wrong after calling pthread_mutex_lock(), which looks like a race condition or something. I guess that could be a lead of why the inputs from the keyboard were kept in buffer until aptitude is SIGINT-ed and then put through, and an evidence of the input-thread-issue you've mentioned. Hope these could help. (gdb) info threads 4 Thread -1231754352 (LWP 12871) 0xb7c1e897 in select () from /lib/libc.so.6 3 Thread -1223365744 (LWP 12872) 0xb7dc1d09 in do_sigwait () from /lib/libpthread.so.0 2 Thread -1255924848 (LWP 12874) 0xb7dbe351 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 1 Thread -1212877104 (LWP 12806) 0xb7dbe351 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) thread 1 [Switching to thread 1 (Thread -1212877104 (LWP 12806))]#0 0xb7dbe351 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0xb7dbe351 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x08199ff7 in vscreen_mainloop (synch=0) at ../../src/generic/util/threads.h:454 #2 0x0810c128 in ui_main () at ui.cc:2630 #3 0x08053ca9 in main (argc=Cannot access memory at address 0x0 ) at main.cc:581 (gdb) thread 2 [Switching to thread 2 (Thread -1255924848 (LWP 12874))]#0 0xb7dbe351 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0xb7dbe351 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x08235329 in resolver_manager::background_thread_execution ( this=0x85ab328) at ../../../src/generic/util/threads.h:454 #2 0x082568dc in threads::thread::bootstrapresolver_manager::background_thread_bootstrap (p=0x84523f8) at resolver_manager.cc:232 #3 0xb7dba183 in start_thread () from /lib/libpthread.so.0 #4 0xb7c25a7e in clone () from /lib/libc.so.6 (gdb) thread 3 [Switching to thread 3 (Thread -1223365744 (LWP 12872))]#0 0xb7dc1d09 in do_sigwait () from /lib/libpthread.so.0 (gdb) bt #0 0xb7dc1d09 in do_sigwait () from /lib/libpthread.so.0 #1 0xb7dc1daf in sigwait () from /lib/libpthread.so.0 #2 0x0819bc83 in threads::thread::bootstrapsignal_thread (p=0x843f4f8) at vscreen.cc:456 #3 0xb7dba183 in start_thread () from /lib/libpthread.so.0 #4 0xb7c25a7e in clone () from /lib/libc.so.6 (gdb) thread 4 [Switching to thread 4 (Thread -1231754352 (LWP 12871))]#0 0xb7c1e897 in select () from /lib/libc.so.6 (gdb) bt #0 0xb7c1e897 in select () from /lib/libc.so.6 #1 0x0819bd4d in threads::thread::bootstrapthreads::bootstrap_proxyinput_thread (p=0x841efa8) at vscreen.cc:370 #2 0xb7dba183 in start_thread () from /lib/libpthread.so.0 #3 0xb7c25a7e in clone () from /lib/libc.so.6 (gdb) info threads 4 Thread -1231680624 (LWP 13071) 0xb7f0a410 in ?? () 3 Thread -1223287920 (LWP 13072) 0xb7f0a410 in ?? () 2 Thread -1255822448 (LWP 13074) 0xb7f0a410 in ?? () 1 Thread -1212795184 (LWP 12982) 0xb7f0a410 in ?? () (gdb) thread 1 [Switching to thread 1 (Thread -1212795184 (LWP 12982))]#0 0xb7f0a410 in ?? () (gdb) bt #0 0xb7f0a410 in ?? () #1 0xbfc7e1a8 in ?? () #2 0x011d in ?? () #3 0x0810c128 in ui_main () at ui.cc:2630 #4 0x08053ca9 in main (argc=Cannot access memory at address 0x0 ) at main.cc:581 (gdb) thread 2 [Switching to thread 2 (Thread -1255822448 (LWP 13074))]#0 0xb7f0a410 in ?? () (gdb) bt #0 0xb7f0a410 in ?? () #1 0xb525a3a8 in ?? () #2 0x0001 in ?? () #3 0xb7dd25d6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #4 0x08235329 in resolver_manager::background_thread_execution ( this=0x83cce48) at ../../../src/generic/util/threads.h:454 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) thread 3 [Switching to thread 3 (Thread -1223287920 (LWP 13072))]#0 0xb7f0a410 in ?? () (gdb) bt #0 0xb7f0a410 in ?? () #1 0xb71612f4 in ?? () #2 0x in ?? () (gdb) thread 4 [Switching to thread 4
Bug#431054: aptitude: possible culprit found
Daniel Burrows wrote: On Sun, Jul 08, 2007 at 04:21:35PM +0800, manphiz [EMAIL PROTECTED] was heard to say: Here it is the backtrace of optimization-free aptitude with libc6-i686, and I don't think it can be much helpful, as it doesn't provide more information than the optimized one. (Forgotten to CC to BTS, however the previous information is helpless) Yeah, that was disappointing. I wonder what happens if you run aptitude in valgrind? Install valgrind and run valgrind --log-file=/tmp/aptitude.log /path/to/your/aptitude/compile If something really is smashing the stack, it should (hah, *should*) show up there. Daniel I tried valgrind with libc6-i686 installed, and it completely confused me: when aptitude was run with valgrind, it mysteriously regained focus after 'g'! I double checked with(without) valgrind, and it definitely losted focus without valgrind, and worked fine with valgrind! I can't tell why and, as it actually ran fine, I don't know if this valgrind log can be helpful. I've also got a verbose log, which is over 20k, which I don't think will be helpful either, but if it's needed please let me know. ==9477== Memcheck, a memory error detector. ==9477== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==9477== Using LibVEX rev 1732, a library for dynamic binary translation. ==9477== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==9477== Using valgrind-3.2.3-Debian, a dynamic binary instrumentation framework. ==9477== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==9477== For more details, rerun with: -v ==9477== ==9477== My PID = 9477, parent PID = 6214. Prog and args are: ==9477==aptitude ==9477== ==9477== ==9477== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 37 from 2) ==9477== malloc/free: in use at exit: 8,353,081 bytes in 147,590 blocks. ==9477== malloc/free: 3,954,768 allocs, 3,807,178 frees, 140,699,107 bytes allocated. ==9477== For counts of detected errors, rerun with: -v ==9477== searching for pointers to 147,590 not-freed blocks. ==9477== checked 16,109,412 bytes. ==9477== ==9477== LEAK SUMMARY: ==9477==definitely lost: 14,122 bytes in 655 blocks. ==9477== possibly lost: 4,280,746 bytes in 73,529 blocks. ==9477==still reachable: 4,058,213 bytes in 73,406 blocks. ==9477== suppressed: 0 bytes in 0 blocks. ==9477== Rerun with --leak-check=full to see details of leaked memory.
Bug#431054: aptitude: possible culprit found
Package: aptitude Version: 0.4.5.4-1 Followup-For: Bug #431054 I'm using testing, and the problem is 100% reproducable here as well. Fortunately, with some experiments, it seems the culprit, as least in my case, has been found - libc6-i686, whose removal finally makes aptitude gain response again. And I reattached aptitude and check all 4 threads, and there's no corrupt stack report any more(so I believe they are needless now :). Hope this information can be useful, and please inform me if any further information is required. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (900, 'testing-proposed-updates'), (800, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.5 0.7.3Advanced front-end for dpkg ii libc6 2.5-9+b1 GNU C Library: Shared libraries ii libgcc1 1:4.2-20070627-1 GCC support library ii libncursesw55.6-3Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.17-2 type-safe Signal Framework for C++ ii libstdc++6 4.2-20070627-1 The GNU Standard C++ Library v3 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-do none (no description available) ii libparse-debianchangelog-perl 1.0-1 parse Debian changelogs and output -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431054: aptitude: possible culprit found
Daniel Burrows wrote: Hm, well, I have libc6-i686 installed and I've never noticed this problem. What CPU do you have? (what does /proc/cpuinfo say?) Daniel My /proc/cpuinfo is attached below. I hope it'll be helpful. Moreover, my conjecture is, as I'm using testing, which has glibc version 2.5-9, there is a possibility that glibc 2.5-11 as in unstable may has the problem solved, which might makes the symptom sporadic. And, of course, this requires further information too. processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.50GHz stepping: 6 cpu MHz : 1500.000 cache size : 2048 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up est tm2 bogomips: 2992.40
Bug#431660: glibmm2.4: new upstream version 2.12.10 available
Package: glibmm2.4 Severity: wishlist A new upstream version 2.12.10 can be found at http://ftp.gnome.org/pub/GNOME/sources/glibmm/2.12/ which fixed a linkage error. Hope this will get built on mips(el) and get into testing along with gtkmm 2.10. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (900, 'testing-proposed-updates'), (800, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373091: What's the status of this bug
How's this bug going? As many libraries are packaged with separate debug packages currently(e.g. related packages as glib, gtk, and glibmm as well), I really wish gtkmm can be consistant with them, and there's no downside to have a dbg packages for a libraries which will help debugging significantly, and there also seems no technical difficulty :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430142: libxml++2.6: New version 2.18.1 available
Package: libxml++2.6 Severity: wishlist New upstream version is available at http://ftp.gnome.org/pub/GNOME/sources/libxml++/2.18/ which contains several bug fixes. It'll be great to have it in Debian anyway. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429901: xfonts-wqy: New version 0.8.1
Package: xfonts-wqy Severity: wishlist The new release is available at http://wqy.sourceforge.net/cgi-bin/index.cgi?BitmapSong and the team has provided a debian packages with a different name. After all it'll be great to become an official package. And, wrt to #384149, it'd better not to be gzipped to achieve better performance. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
