Bug#998679: firefox-esr freezes shortly after start
I'm using firefox-esr from the Debian repo and Firefox nightly from Mozilla's website. I experience this issue only in Firefox ESR and stable from the Debian repos. All browsers are used under Wayland. I think that it might be an issue with the Debian build. On Mon, 22 Nov 2021 09:31:55 -0700 Daniel Blaschke wrote: > Package: firefox-esr > Followup-For: Bug #998679 > X-Debbugs-Cc: blasc...@hep.itp.tuwien.ac.at > > Dear Maintainer, > > for the past two days I've been testing firefox-esr 91.3.0 downloaded directly > from mozilla.org on debian 11 (bullseye) without any problems: no crashes > whatsoever. > gfx.x11-egl.force-disabled is set to its default "false" and mesa version on my > system is 20.3.5. > > I'm running on an intel broadwell gpu (HD Graphics 5500) using the older > xserver-xorg-video-intel driver and gnome-shell on xorg (not wayland). > In fact, wayland crashes randomly after standby on my system (unrelated to > firefox). > > Perhaps, the firefox crashes experienced by others is a bug in either newer > mesa 21.2 or the wayland display server of debian testing and firefox is merely > triggering that bug? > Do people affected by this bug experience it on both xorg and wayland or just > wayland? > > On Debian stable we're now 3 weeks overdue for a security update of firefox, > which too me seems rather important to address; I cannot reproduce the bug > reported here on bullseye. > > Cheers, > Daniel > > > -- Package-specific info: > > > -- Addons package information > > -- System Information: > Debian Release: 11.1 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads) > 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 firefox-esr depends on: > ii debianutils 4.11.2 > ii fontconfig 2.13.1-4.2 > ii libatk1.0-0 2.36.0-2 > ii libc6 2.31-13+deb11u2 > ii libcairo-gobject2 1.16.0-5 > ii libcairo2 1.16.0-5 > ii libdbus-1-3 1.12.20-2 > ii libdbus-glib-1-2 0.110-6 > ii libevent-2.1-7 2.1.12-stable-1 > ii libffi7 3.3-6
Bug#998679: Firefox freezes
Hello, I experience freezes on Debian testing Bookworm (with mesa 21.2.5). They happen very often when I open a link in new tab or open a new tab, enter a URL and press Enter. The proposed workaround of setting `gfx.x11-egl.force-disabled` to `true` didn't solve the issue. Michel Le Bihan
Bug#985754:
Upstream fixed this in https://github.com/dino/dino/commit/9acb54df9254609f2fe4de83c9047d408412de28.patch
Bug#985142:
Hello, This should be fixed in https://salsa.debian.org/mimi8/chromium/-/commit/13d089e2059a8a09bd3d0611826ccc3e43293e0a that is waiting to be sponsored.
Bug#972134: chromium: please, consider moving the package to team-maintenance to properly maintain it
Hello, Thank you for granting me access to the Salsa group. Can I push all my commits to the chromium repo? Will you review my commits and check if everything is OK and I didn't miss anything important or made any mayor mistakes? The window for getting in Bullseye will close soon and this issue is blocking. Will you be able to maintain Chromium in Bullseye? I can help with it if needed. Michel Le Bihan
Bug#979590: libx11-xcb1: Updating to 1.7.0-1 from 1.6.12-1 breaks chromium and google chrome
Hello,
All of your solutions besides downgrading Chromium that I didn't try
work for me.
Michel Le Bihan
Le samedi 09 janvier 2021 à 17:08 +0200, Faidon Liambotis a écrit :
> On Fri, Jan 08, 2021 at 07:30:03PM +0100, Michel Le Bihan wrote:
> > After updating libx11-xcb1 chromium and google chrome UI is not
> > responding to any input and clicking anywhere on the app window
> > causes
> > the GNOME app is not responding dialog to appear. The app actually
> > is
> > not frozen because if you pass a URL with dynamic web content as a
> > parameter, it will be constantly updated. I didn't notice any other
> > affected app, but I didn't test much.
>
> I was experiencing the same. Both Chromium (87.0.4280.88-0.4) and
> Google
> Chrome (87.0.4280.141-1) were entirely unusable for me.
>
> It turned out that for me, the cause was a disparity between libx11-
> xcb1
> and libx11-6 -- the former was at 2:1.7.0-1, while the latter was at
> 2:1.6.12-1 (don't ask why...). Any of the following are addressing
> the
> issue for me:
> * Upgrading libx11-xcb1 + libx11-6 to 2:1.7.0-1 (duh)
> * Downgrading libx11-xcb1 (+ libx11-6) to 2:1.6.12-1
> * Reverting to an older version of Chromium (83.0.4103.116)
> * Google Chrome Beta (88.0.4324.79-1)
>
> Before I realized that the issue was a version disparity, I bisected
> libx11, and found that commit dbb55e1 ("Fix poll_for_response race
> condition") to be the "bad" commit. Reverting that commit on top of
> 1.7.0-1, made the issue disappear as well.
>
> At minimum, it looks like libx11-xcb1 and libx11-6 need to be at the
> same version, so perhaps libx11-xcb1 should have a versioned depends
> on
> libx11-6 (= ${binary:Version}). On that note, libx11-xcb1 doesn't
> seem
> to even Depend on libc6, with libX11-xcb.so.1 being statically
> linked;
> perhaps that's an issue of its own?
>
> #979443 may or may not be a related bug here.
>
> Faidon
Bug#979533: chromium: New 87.0.4280.141
Hello, I'm working on the update, but I encountered an unexpected issue. The update was easy. Patches did not require updating. The problem, is that Chromium IU is frozen. Chromium itself isn't and the globe on https://en.wikipedia.org/wiki/GIF spins, but Chromium doesn't react to any UI input. I'm debugging that, but haven't made much progress. Michel Le Bihan
Bug#960454: chromium: Make Chromium ask before downloading and enabling DRM
Hello, Yes, it won't be updated. If there will be a security issue/vuln, then probably somebody will write about it and we will do something about that. Michel Le Bihan Le vendredi 01 janvier 2021 à 20:34 +0100, Stephen Kitt a écrit : > Hi, > > On Fri, 25 Dec 2020 20:50:04 +0100 Michel Le Bihan > wrote: > > With > > https://salsa.debian.org/mimi8/chromium/-/commit/d21192e70824befdfeed5a5145275139cd6c4ffa > > the Widevine component won't be downloaded automatically. However, > > unlike when `enable_widevine=false` is set, Widevine CDM component > > will > > still be used when found in `~/.config/chromium/WidevineCdm/`. It > > is > > possibly to copy it there, but there is no nice UI to do that. > > > > This resolves the policy issue, while still making it possible to > > use > > that component. This change will be available in the next upload. > > Doesn’t this mean though that users who *do* have the CDM component > installed > will no longer receive updates to it? > > Regards, > > Stephen
Bug#960454: chromium: Make Chromium ask before downloading and enabling DRM
Hello Le vendredi 01 janvier 2021 à 02:53 +0100, Christoph Anton Mitterer a écrit : > Hey. > > > Just wondered: > > > 1) Since this is a binary blob who, by it's nature, is made for > surveillance, it's IMO more a rather serious security issue than just > a > DFSG-policy problem. > No one really knows what exactly Google ships there. > > So maybe people should be told about this more actively in a DSA or > NEWS.Debian entry? > > > > 2) To my great surprise (and shock - due to the compromise) I found > the > binaries downloaded last July, even though I never used chromium on > any > site that uses EME or things like that. > Which makes this behaviour even more suspicious. > > It is downloaded on launch and not when visiting a site that requires DRM. > > 3) AFAIU, now the Debian package no longer downloads it automatically > (with widevine-cdm-cu.patch), but many people will still have it > silently in place (and presumably executed). Which is again kinda a > point for (1). > > That's actually intended. It would be easier to set the build flag that disables it, but some users are still interested in using it. The way it's done currently still allows them to use it. > > 4) This problem of browsers downloading their own closed-source and > possibly compromised stuff has already surfaced in the past. > Wouldn't it be safer to completely remove the code doing at all? > Right now we have widevine-cdm-cu.patch which is fine for just this, > and as soon as Google would add something new it would probably get > downloaded again until someone notices by chance. > > > In general, I think it's pretty bad if software circumvents secure > APT > do download further software: > > - there is no central security support (just imagine an attacked > simply > blocks any time chromium tries to upgrade the binary blobs) and > people will not even notice if upgrades from within the software > fail. > > - it's not taken into account by tools like check_apt either > > - unless someone knows that Chromium puts software in .config it will > stay there forever and not begin removed or so when the chromium > package would be removed > > - an evil Google could just selectively distribute hacked versions of > their binaries - something which is more or less impossible when all > software comes via secure APT > > - doing package upgrade really in a secure way (i.e. preventing > blocking attacks, downgrade attacks, or just not using > outdated/insecure algorithms) is actually not that easy and I've seen > many downloader packages doing it wrong - with secure APT there's one > central place where all this is handled (securely) > > > > Cheers, > Chris. > Michel Le Bihan
Bug#973848: security update of chromium in Debian stable?
Hello, You need to apply https://source.chromium.org/chromium/chromium/src/+/c8fc4f2db9dc636939d98c455ac64e7d275130a3 which I did in https://salsa.debian.org/mimi8/chromium/-/commit/271bf462595b7300037a77f6816a0e4801435286 . I will let you finish work on the stable release. Please let me know if you need any help or when you will be ready, so I will coordinate it with the next patch release for unstable. Michel Le Bihan Le mercredi 23 décembre 2020 à 13:03 +0100, Jan Luca Naumann a écrit : > Hey, > > parallel to Michel's very nice work to get chromium into unstable > (thanks to him!), I tried to build the current version in a buster > chroot. At the moment I struggle that there seems a difference how > SFINAE[1] in a special case [2] is handled different between buster's > and unstable's clang version. Since I had not so much time I have not > found a fix to work around this. > > If people are more experienced with C++ templates than me, I would be > happy to share the problem and the build log ;) > > Best, > Jan > > [1] > https://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error > > [2] > > In file included from > ../../third_party/blink/common/privacy_budget/identifiability_metric_ > builder.cc:5: > In file included from > ../../third_party/blink/public/common/privacy_budget/identifiability_ > metric_builder.h:9: > In file included from > /usr/bin/../lib/gcc/x86_64-linux- > gnu/8/../../../../include/c++/8/vector:60: > In file included from > /usr/bin/../lib/gcc/x86_64-linux- > gnu/8/../../../../include/c++/8/bits/stl_algobase.h:64: > In file included from > /usr/bin/../lib/gcc/x86_64-linux- > gnu/8/../../../../include/c++/8/bits/stl_pair.h:59: > In file included from > /usr/bin/../lib/gcc/x86_64-linux- > gnu/8/../../../../include/c++/8/bits/move.h:55: > /usr/bin/../lib/gcc/x86_64-linux- > gnu/8/../../../../include/c++/8/type_traits:2046:15: > error: only enumeration types > have underlying types > typedef __underlying_type(_Tp) type; > ^ > ../../third_party/blink/public/common/privacy_budget/identifiable_tok > en.h:121:40: > note: in instantiation of template > class 'std::underlying_type 18446744073709551615> >' requested here > typename U = typename std::underlying_type::type, > > Am 23.12.20 um 12:13 schrieb Tomas Pospisek: > > Hi all, > > > > now that sid has seen an update of Chromium to v87 (hooray and > > thanks > > everybody!) does anybody know it there's activity or plans towards > > updating chromium in Debian stable? > > > > Chromium from sid is not installable in Debian stable due to > > > > Depends: libc6 (>= 2.29) > > > > whereas stable has 2.28. > > > > I'm not sure what the correct procedure would be to kickstart the > > Debian > > stable update? > > > > *t >
Bug#960454: chromium: Make Chromium ask before downloading and enabling DRM
Hello, With https://salsa.debian.org/mimi8/chromium/-/commit/d21192e70824befdfeed5a5145275139cd6c4ffa the Widevine component won't be downloaded automatically. However, unlike when `enable_widevine=false` is set, Widevine CDM component will still be used when found in `~/.config/chromium/WidevineCdm/`. It is possibly to copy it there, but there is no nice UI to do that. This resolves the policy issue, while still making it possible to use that component. This change will be available in the next upload. Michel Le Bihan
Bug#977901: chromium: Inconsistent SEGV
Hello, Yes, I gave you the wrong file. Just uploaded the correct one under the same url. Michel Le Bihan Le mercredi 23 décembre 2020 à 23:01 -0600, Boyd Stephen Smith Jr. a écrit : > On Wednesday, December 23, 2020 4:16:19 PM CST Michel Le Bihan wrote: > > Could you please test if you are still getting > > this issue in https://lebihan.pl/files/chromium.tar.gz ? > > Chromium ran for several hours continuously with all my extensions > enabled, > but did eventually crash (attached), with a similar back trace: > ~ServiceWorkerRegistrationObjectHost ... std::_Rb_tree<>::_M_erase > ... > ~ServiceWorkerRegistrationObjectHost > > Note that I'm not sure the link you gave is correct and up-to-date, > as the > version of packages that I downloaded from there and installed (via > dpkg) is > less than the current version in sid: > > ---8<--- > % apt-cache policy chromium > chromium: > Installed: 87.0.4280.88-0.1 > Candidate: 87.0.4280.88-0.1 > Version table: > 87.0.4280.88-0.2 -1 > 500 http://deb.debian.org/debian sid/main amd64 Packages > *** 87.0.4280.88-0.1 100 > 100 /var/lib/dpkg/status > --->8--- > > Let me know what I can do to help.
Bug#957037: biboumi: ftbfs with GCC-10
Hello, I opened a merge request, but merging all branches into your repo might cause issues in the upstream branch in the future due to the merge commits. Instead, it will be best to pull all branches from my repo into branches of your repo, but without adding merge commits or at least without adding them to the upstream and pristine tar branches. Michel Le Bihan Le 23 décembre 2020 04:58:21 GMT+01:00, Vasudev Kamath a écrit : >Michel Le Bihan writes: > >> Le mardi 22 décembre 2020 à 17:35 +0530, Vasudev Kamath a écrit : >>> Jonas Smedegaard writes: >>> >>> > Quoting Michel Le Bihan (2020-12-20 17:15:29) >>> > > Le dimanche 20 décembre 2020 à 16:50 +0100, Jonas Smedegaard a >>> > > écrit : >>> > > > Quoting Michel Le Bihan (2020-12-20 16:06:27) >>> > > > > A quick summary of the differences between both repos: >>> > > > >>> > > > Thanks, that is no doubt helpful! >>> > > > >>> > > > [ beware: commenting without actually having looked at the >>> > > > code! ] >>> > > Please look at it when you will have time. >>> > >>> > Most likely no: Instead, please wait for Vasudev to look at it. >>> >>> I was looking at biboumi repository and did not see any merge >>> requests >>> on it. Jonas do we need to enable something in repo to allow merge >>> requests?. >>> >> Yes. You need to enable merge requests in the repository settings. They >> are currently disabled. > >Done, it took me a while to navigate around the settings. Please raise >MR so I can review. > >Cheers, >Vasudev
Bug#977901: chromium: Inconsistent SEGV
Hello, My build just finished. Could you please test if you are still getting this issue in https://lebihan.pl/files/chromium.tar.gz ? Michel Le Bihan
Bug#977901: chromium: Inconsistent SEGV
Hello, I made https://salsa.debian.org/mimi8/chromium/-/commit/6d21c52698147ca072d223e4e6c2854053319531 and still am waiting for it to build. Is it OK? Michel Le Bihan Le mercredi 23 décembre 2020 à 14:13 -0600, Boyd Stephen Smith Jr. a écrit : > On Wednesday, December 23, 2020 4:30:48 AM CST Boyd Stephen Smith Jr. > wrote: > > On Wednesday, December 23, 2020 4:19:43 AM CST Michel Le Bihan > > wrote: > > > The Debian patch for #963548 > > > https://salsa.debian.org/mimi8/chromium/-/blob/ece23b4ca107cd968ac9a40 > > > 9f > > > 40eb11edf8a0266/debian/patches/fixes/serviceworker-double- > > > destruction.pat > > > ch is clearly in upstream 87.0.4280.88: > > > https://source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88 > > > :c > > > ontent/browser/service_worker/service_worker_container_host.cc;l= > > > 671-679 > > > > Different destructor. The old patch is for > > ServiceWorkerObjectHost, but we > > need a new patch for ServiceWorker*Registration*ObjectHost. > > In particular, just above where you linked to, at line 629 (https:// > source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88:co > ntent/ > browser/service_worker/service_worker_container_host.cc;l=629) is the > crashing > line. > > The fix for the back trace I finally got is to change that line like > so: > https://source.chromium.org/chromium/chromium/src/+/ > f27ad210062f61d06eb782214ee4fc8c19a1725b:content/browser/service_work > er/ > service_worker_container_host.cc;l=623-647 > > The f27ed21 commit does contain the fix for #963548, but lower down > at line > 689: https://source.chromium.org/chromium/chromium/src/+/ > f27ad210062f61d06eb782214ee4fc8c19a1725b:content/browser/service_work > er/ > service_worker_container_host.cc;l=689-697 >
Bug#977901: chromium: Inconsistent SEGV
Hello, The Debian patch for #963548 https://salsa.debian.org/mimi8/chromium/-/blob/ece23b4ca107cd968ac9a409f40eb11edf8a0266/debian/patches/fixes/serviceworker-double-destruction.patch is clearly in upstream 87.0.4280.88: https://source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88:content/browser/service_worker/service_worker_container_host.cc;l=671-679 I also think that it might be an upstream bug, but can't confirm unless tested and reproducible in Google Chrome. Michel Le Bihan Le mercredi 23 décembre 2020 à 04:10 -0600, Boyd Stephen Smith Jr. a écrit : > On Wednesday, December 23, 2020 3:49:06 AM CST Boyd Stephen Smith Jr. > wrote: > > On Wednesday, December 23, 2020 2:38:32 AM CST Boyd Stephen Smith > > Jr. wrote: > > > I got a crash (attached) > > > > Looks like > > https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 to > > me, which has a fix, but I haven't yet figured out what release(s) > > the fix > > made it into. > > Doesn't look to me like it has made it into a release at all, but I'm > just > using the Git tools to navigate the repository, not all the depot > tools. > > ---8<--- > bss@monster % git tag -l --contains > f27ad210062f61d06eb782214ee4fc8c19a1725b > bss@monster % git branch -r --contains > f27ad210062f61d06eb782214ee4fc8c19a1725b --list > origin/HEAD -> origin/master > origin/lkgr > origin/lkgr-android-internal > origin/lkgr-ios-internal > origin/master > --->8--- > > So, I guess it's an "upstream" bug?
Bug#977901: chromium: Inconsistent SEGV
Hello, Installing `chromium-dbgsym` should be enough. Please run Chromium with the `--debug` flag like: `chromium --debug`. You can mix it with your other flags like `chromium --debug --incognito`. In the GDB shell, please enter `run`. Chromium should start then. You can then use Chromium, but it will be very slow. Once a crash occurs, please enter `bt` in the shell and attach the backtrace to this bug. I was not able to reproduce those crashes. Michel Le Bihan
Bug#957037: biboumi: ftbfs with GCC-10
Le mardi 22 décembre 2020 à 17:35 +0530, Vasudev Kamath a écrit : > Jonas Smedegaard writes: > > > Quoting Michel Le Bihan (2020-12-20 17:15:29) > > > Le dimanche 20 décembre 2020 à 16:50 +0100, Jonas Smedegaard a > > > écrit : > > > > Quoting Michel Le Bihan (2020-12-20 16:06:27) > > > > > A quick summary of the differences between both repos: > > > > > > > > Thanks, that is no doubt helpful! > > > > > > > > [ beware: commenting without actually having looked at the > > > > code! ] > > > Please look at it when you will have time. > > > > Most likely no: Instead, please wait for Vasudev to look at it. > > I was looking at biboumi repository and did not see any merge > requests > on it. Jonas do we need to enable something in repo to allow merge > requests?. > Yes. You need to enable merge requests in the repository settings. They are currently disabled. > @Michel/Alberto it would be great if you can raise a merge request. > It > will be easier for me to look at the changes faster. > > > > > > > > Now that you joined the team maintaining the package, it is not > > > > an > > > > NMU. > > > > > > > Should I change that? Somebody would have to add me to > > > debian/control, > > > but I don't want to rebase my fork on that commit for that > > > change. > > > > My point was more general about when that annotation was needed. > > > > I'll leave the details of handling this concrete changeset to > > Vasudev. > > > > You can add yourself to debian/control and commit that changes. No > need > for waiting for some one else to add you there :-). > > Please keep me in Cc I might miss the mails otherwise. > > Cheers, > Vasudev
Bug#972134: chromium: please, consider moving the package to team-maintainance to properly maintain it
Hello, I my NMU 87.0.4280.88-0.2 has just been uploaded to unstable and I'm interested in joining and helping with the package. My work is in https://salsa.debian.org/mimi8/chromium/ . Please also see the discussion under https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973848 . Michel Le Bihan
Bug#965960: chromium: Received signal 11 SEGV_ACCERR 000004c03193. can't load pages and extensions
Hello, Could you please check if this issue is present in version 87.0.4280.88-0.2 from unstable? Michel Le Bihan
Bug#957037: biboumi: ftbfs with GCC-10
Le dimanche 20 décembre 2020 à 16:50 +0100, Jonas Smedegaard a écrit : > Quoting Michel Le Bihan (2020-12-20 16:06:27) > > A quick summary of the differences between both repos: > > Thanks, that is no doubt helpful! > > [ beware: commenting without actually having looked at the code! ] Please look at it when you will have time. > > > 2. Aluaces package might be missing man pages. Upstream is now > > using > > Sphinx instead of Pandoc. I added a patch to build man and updated > > control. They put doc/*.rst in examples and I put it in doc. > > > I also moved the new example config to `/etc/biboumi/biboumi.cfg` > > since most packages install example config directly in their final > > location in `/etc`. > > If "sample" config files are working out of the box then good - > otherwise not. > > > > 3. I updated copyright hints. > > Only update copyright_hints if you update copyright file as needed - > otherwise better that you do *not* update copyright_hints: The hints > file being out of sync is a way to recognize that copyright file is > pending a closer examination. > New doc location, tests added and some source files. In my opinion that does not require an update to the copyright file, but I ack the changes. > > > 4. My release is marked NMU. > > Now that you joined the team maintaining the package, it is not an > NMU. > Should I change that? Somebody would have to add me to debian/control, but I don't want to rebase my fork on that commit for that change. > > - Jonas >
Bug#957037: biboumi: ftbfs with GCC-10
A quick summary of the differences between both repos: 1. Source is imported differently. I tried to import source the same way it was done previously. 2. Aluaces package might be missing man pages. Upstream is now using Sphinx instead of Pandoc. I added a patch to build man and updated control. They put doc/*.rst in examples and I put it in doc. I also moved the new example config to `/etc/biboumi/biboumi.cfg` since most packages install example config directly in their final location in `/etc`. 3. I updated copyright hints. 4. My release is marked NMU. Michel Le Bihan Le dimanche 20 décembre 2020 à 15:30 +0100, Jonas Smedegaard a écrit : > Quoting Vasudev Kamath (2020-12-15 09:35:35) > > > > Hi Alberto, > > > > > I have checked that current upstream (9.0) builds flawlessly, and > > > made my release available at > > > https://salsa.debian.org/aluaces-guest/biboumi . > > > > That is great. > > > > > Can I be sponsored so we can upload to at least experimental? > > > > Sure, please raise a merge request against biboumi and I will try > > to > > review your work and sponsor the upload for you. I would be happy > > if > > you can join us in maintaining biboumi. Both me and Jonas are bit > > busy > > and not getting enough time for maintaining biboumi properly. > > You are following along on this bugreport, right? > > I think it would be helpful if you could give a rough estimate on > when > you expect to find time to review the package update. > > I don't mean to rush it, just suggest to be transparent about the > delay > - I can imagine that Alberto and Michel must be excited to see > progress > on their contributions. > > I must admit that I am a bit confused - seems we now have two > bugfixes > for this issue - first from Alberto and later from Michel who also > wants > to join as co-maintainer - hope you can resolve that, Vasudev :-) > > > - Jonas >
Bug#957037: biboumi: ftbfs with GCC-10
Hello, I'm interested in joining the VoIP team to maintain this package long term. I'm running it on my personal server and using it. I can't become the only maintainer because I'm not a DM and all my uploads will need to be sponsored. Sorry for the delay. It took me some time to understand how source of this package is imported in the Salsa repo, but I think I did it correctly now. https://salsa.debian.org/pkg-voip-team/biboumi I also contacted aluaces who also did some work on that update. Michel Le Bihan
Bug#957037: biboumi: ftbfs with GCC-10
Hello, I updated the sources the same way you did and made a new release. Could you please check if everything is fine and sponsor my NMU? https://salsa.debian.org/mimi8/biboumi Michel Le Bihan On Thu, 17 Dec 2020 15:18:46 +0100 Jonas Smedegaard wrote: > Quoting Michel Le Bihan (2020-12-17 14:37:38) > > > @Michel: If you are interested in joining the VoIP team generally, > > > then please join the mailinglist and request membership to the Salsa > > > group - links are at https://wiki.debian.org/Teams/VoIP > > > > Sorry, but I'm not really interested in VoIP software nor have much > > experience with it. I'm interested in XMPP. Actually, I don't really > > understand why this package is managed by the VoIP team and not by the > > XMPP team. > > Sorry, I expressed that badly: What I meant to say is that if you care > for *this* package more generally (i.e. not only this once) then I > encourage you to join as package maintainer to help look after it. The > VoIP team provides infrastructure - you need not care for other packages > in the VoIP team. > > Reason Biboumi is maintained in the VoIP team is that Vasudev wanted my > help maintaining it, and I - just like you, if I understand correctly - > wanted to limit the amount of teams to attend to. I have an interest in > XMPP but am already involved with 20 other teams. > > I am open to having you and Vasudev move the package to the XMPP team, > but would hate to see the package become badly maintained: Vasudev has > not had a lot of time for packaging lately, and I don't know the level > of your devotion - that's why I suggest to start maintain it at its > current home where I can help keep an eye on it, and then maybe move it > later if you still prefer that after tending to it for some time. > > ...but if you are eager to help and joining the VoIP team is what holds > you back, then maybe it is best to simply hand over the package to you. > Please do share your thoughts on this. > > > Kind regards, > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#957037: biboumi: ftbfs with GCC-10
Hello, I noticed that https://salsa.debian.org/aluaces-guest/biboumi/-/commits/upstream doesn't have upstream imported the same way you have it. I think that I imported it correctly in https://salsa.debian.org/mimi8/biboumi/-/commits/upstream . However, I don't know how you generated the hash in `with Debian dir 49ca567d9a5a72a0874b26f332c3f441ca6783f5` in https://salsa.debian.org/mimi8/biboumi/-/commit/4efa9c854464d9087b673a0ef5ead39b92e6d109 . I would like to continue importing upstream releases the same way it was done before. Michel Le Bihan Le jeudi 17 décembre 2020 à 15:18 +0100, Jonas Smedegaard a écrit : > Quoting Michel Le Bihan (2020-12-17 14:37:38) > > > @Michel: If you are interested in joining the VoIP team > > > generally, > > > then please join the mailinglist and request membership to the > > > Salsa > > > group - links are at https://wiki.debian.org/Teams/VoIP > > > > Sorry, but I'm not really interested in VoIP software nor have much > > experience with it. I'm interested in XMPP. Actually, I don't > > really > > understand why this package is managed by the VoIP team and not by > > the > > XMPP team. > > Sorry, I expressed that badly: What I meant to say is that if you > care > for *this* package more generally (i.e. not only this once) then I > encourage you to join as package maintainer to help look after it. > The > VoIP team provides infrastructure - you need not care for other > packages > in the VoIP team. > > Reason Biboumi is maintained in the VoIP team is that Vasudev wanted > my > help maintaining it, and I - just like you, if I understand correctly > - > wanted to limit the amount of teams to attend to. I have an interest > in > XMPP but am already involved with 20 other teams. > > I am open to having you and Vasudev move the package to the XMPP > team, > but would hate to see the package become badly maintained: Vasudev > has > not had a lot of time for packaging lately, and I don't know the > level > of your devotion - that's why I suggest to start maintain it at its > current home where I can help keep an eye on it, and then maybe move > it > later if you still prefer that after tending to it for some time. > > ...but if you are eager to help and joining the VoIP team is what > holds > you back, then maybe it is best to simply hand over the package to > you. > Please do share your thoughts on this. > > > Kind regards, > > - Jonas >
Bug#957037: biboumi: ftbfs with GCC-10
@Michel: If you are interested in joining the VoIP team generally, > then > please join the mailinglist and request membership to the Salsa group > - > links are at https://wiki.debian.org/Teams/VoIP Sorry, but I'm not really interested in VoIP software nor have much experience with it. I'm interested in XMPP. Actually, I don't really understand why this package is managed by the VoIP team and not by the XMPP team. Michel Le Bihan
Bug#957037: biboumi: ftbfs with GCC-10
Hello, It's not possible to open merge requests against https://salsa.debian.org/pkg-voip-team/biboumi . They seem disabled for that repo. Michel Le Bihan
Bug#973848: chromium: Unsupported version, many security bugs unfixed
Hello, I updated the patch disabling openh264: https://salsa.debian.org/mimi8/chromium/-/blob/master/debian/patches/disable/openh264.patch I was able to build Chromium with proprietary codec support, but without openh264. Michel Le Bihan On Mon, 14 Dec 2020 21:04:00 +0100 Michel Le Bihan wrote: > Hello, > > > I suspect that debian's libvpx might need to be build with > experimental features enabled (similar to a previous bug report), in > order to include the absent header files. > > This will build the lib, but the header isn't correctly exported. They > don't export the header file for that and the internal header used by > Chromium requires many other internal headers. > > > Are you sure that fixes/sequence-point.patch is necessary? I don't > recall getting any warnings related to this when compiling. > > I don't know. I don't see the warning mentioned in the commit without > that patch, but I also don't see the commit in Chromium that could > change that. > > > Looking at the last couple of commits for the file affected by the > ozone problem [1], it appears to be already fixed upstream. > > Great! That will make one less patch to update on next release! > > I'm still missing 4 patches: > buster/icu63: Without that one it might be difficult to get the update > in Buster > system/vpx: It's better to use system libs it it isn't too difficult. > There is one commit in Chromium introducing the usage of that > experimental feature. Maybe the patch could revert it? > system/harfbuzz: I didn't investigate what's wrong with it. Just used > in tree version. > A patch for proprietary codecs + system ffmpeg. > > Maybe more will be needed for Lintian warnings and errors. > > Does anybody have any of the mentioned patches updated/written? It > would avoid duplicate work. I know those are the most difficult patches > to update. > > Michel Le Bihan > > >
Bug#973848: chromium: Unsupported version, many security bugs unfixed
Hello, > I suspect that debian's libvpx might need to be build with experimental features enabled (similar to a previous bug report), in order to include the absent header files. This will build the lib, but the header isn't correctly exported. They don't export the header file for that and the internal header used by Chromium requires many other internal headers. > Are you sure that fixes/sequence-point.patch is necessary? I don't recall getting any warnings related to this when compiling. I don't know. I don't see the warning mentioned in the commit without that patch, but I also don't see the commit in Chromium that could change that. > Looking at the last couple of commits for the file affected by the ozone problem [1], it appears to be already fixed upstream. Great! That will make one less patch to update on next release! I'm still missing 4 patches: buster/icu63: Without that one it might be difficult to get the update in Buster system/vpx: It's better to use system libs it it isn't too difficult. There is one commit in Chromium introducing the usage of that experimental feature. Maybe the patch could revert it? system/harfbuzz: I didn't investigate what's wrong with it. Just used in tree version. A patch for proprietary codecs + system ffmpeg. Maybe more will be needed for Lintian warnings and errors. Does anybody have any of the mentioned patches updated/written? It would avoid duplicate work. I know those are the most difficult patches to update. Michel Le Bihan
Bug#973848: chromium: Unsupported version, many security bugs unfixed
Hello, My work is in this repo: https://salsa.debian.org/mimi8/chromium/-/tree/master I'm updating the commit every time I make a change. Making a new commit for each file doesn't really make sense, since those are separate files anyway. There is another repo from another person that also started work: https://github.com/berkley4/ungoogled-chromium-debian/commits/87.0.4280.88 And another one somebody told me about yesterday: https://www.zap.org.au/git-browser/debian-packages/pkg-chromium-browser.git/ Could you please commit your work to a fork of the Chromium repo on Salsa so we can compare patches? Also, maybe we could meet on IRC/XMPP/Matrix or somewhere? Michel Le Bihan On Mon, 14 Dec 2020 13:12:06 +0100 Jan Luca Naumann wrote: > Hallo everybody, > > I have done some of the work as well since I have not seen your message > about your efforts. I have uploaded a working build for unstable to > mentors including updated version of the patches: > > https://mentors.debian.net/package/chromium/ > > This version is using the vendor-shipped version of libvpx which should > be changed but maybe we can put together the work done so far in a Git > repo and fixes the remaining stuff? > > Best, > Jan > > On Sun, 13 Dec 2020 14:45:01 -0800 David Worsham wrote: > > Hi there, > > > > Thank you for all of the great work on this so far! > > > > I'm interested in helping with this effort, and very familiar with C++ code > > and processes in Google code (though not specifically Chromium). I have > > gotten the 83/84 versions in unstable/experimental building locally in a > > container as a sanity check. I also have a fork on salsa to work from > > now: https://salsa.debian.org/arbreng/chromium > > > > However, I am very new to Debian packaging and so not sure what the "ideal" > > workspace setup and workflow is for this kind of work. I just kinda made > > things up as I went along yesterday. If one of ya'll could walk me through > > it that would be greatly appreciated - I only know what I learned from > > the debian Wiki. I know how to build and hack on Chromium itself -- it's > > just the packaging bits that are still a bit mystifying to me. > > > > Thanks again for all the effort! > >
Bug#973848: chromium: Unsupported version, many security bugs unfixed
Hello, Thank you for your reply. libvpx got updated in Debian, but I can't use it because it's missing a lib. I also had issues with harfbuzz, so I'm using bundled versions of those libs as you are. I also used your ozone patch because it is match cleaner than mine. With that I was able to build Chromium, but with many lint errors and many missing patches. BTW, have you tried opening a bug upstream or submitting your ozone patch upstream? Michel Le Bihan On Wed, 9 Dec 2020 04:34:39 + Jeff Blake wrote: > On Tue, 08 Dec 2020 12:33:57 +0100 Michel Le Bihan wrote: > > Hello, > > > > I started work on updating the chromium package (you can see my work > > here: > > https://salsa.debian.org/mimi8/chromium/-/commit/af70b14701aaf6bdb34e23af01657676e27ba5d4 > > ), but got stuck because `libvpx` is too old in Debian testing. It > > needs to be updated before I can continue work. > > > > Michel Le Bihan > > > > > > > > I've managed to successfully update the ungoogled-chromium debian package > [1], which is based upon > the official debian package. > > Until libvpx is updated (or a new release is made) you could use Chromium's > bundled version of libvpx [2]. > > Feel free to have a look around my repo, as you might well encounter some of > the same problems that > I had in getting things to build. > > > Jeff Blake > > > [1] https://github.com/berkley4/ungoogled-chromium-debian/commits/87.0.4280.88 > > [2] > https://github.com/berkley4/ungoogled-chromium-debian/commit/05ffc529e685817aac8a9c5bb419daba17204a66 > > >
Bug#973848: chromium: Unsupported version, many security bugs unfixed
Hello, I started work on updating the chromium package (you can see my work here: https://salsa.debian.org/mimi8/chromium/-/commit/af70b14701aaf6bdb34e23af01657676e27ba5d4 ), but got stuck because `libvpx` is too old in Debian testing. It needs to be updated before I can continue work. Michel Le Bihan
Bug#975411: meson: autopkgtest arm64
Hello, I implemented this test in https://github.com/mesonbuild/meson/commit/631a7b5a2a8ffa31d0d126608e79841be02ecfea . Please enable it in the next version. Michel Le Bihan
Bug#958497: geoclue-2.0 violates GDPR
Hello, I disagree with your opinion on this. I think that users should be aware that their SSIDs are visible and by deliberately broadcasting it, they agree that anybody can hear it and record it including any bad actors. They can always use the hide SSID feature. I think that in this case it's more like going outside and shouting something and then complaining that somebody heard that and even recorded that. Michel Le Bihan
Bug#944169: open-ath9k-htc-firmware: non-standard gcc/g++ used for build (gcc-8)
Hello, It should be possible to build the package with patched gcc-10 now: https://github.com/qca/open-ath9k-htc-firmware/pull/164 Michel Le Bihan
Bug#970911: gnome-screenshot: does not start: undefined symbol: hdy_init
Hello, Indeed I had a copy in /usr/local/ that I don't remember installing. Sorry for this bug report. Michel Le Bihan Le vendredi 25 septembre 2020 à 13:01 +0100, Simon McVittie a écrit : > Control: tags -1 + moreinfo unreproducible > > On Fri, 25 Sep 2020 at 13:02:20 +0200, Michel Le Bihan wrote: > > When trying to launch gnome-screenshot, I get this error: > > > > michel@debian:~$ gnome-screenshot --interactive > > gnome-screenshot: symbol lookup error: gnome-screenshot: undefined > > symbol: > > hdy_init, version LIBHANDY_1_0 > > What does > > ldd `command -v gnome-screenshot` > > output? > > Do you have a locally-installed copy of libhandy-1.so.0 that is found > before the system copy, perhaps in /usr/local? (If you do, please > remove > it: Debian package dependencies cannot take locally-installed > libraries > into account.) > > > Versions of packages gnome-screenshot depends on: > ... > > ii libhandy-1-0 1.0.0-1 > > This should be sufficient to provide hdy_init, version LIBHANDY_1_0. > > smcv
Bug#970911: gnome-screenshot: does not start: undefined symbol: hdy_init
Package: gnome-screenshot Version: 3.38.0-1 Severity: grave Justification: renders package unusable Hello, When trying to launch gnome-screenshot, I get this error: michel@debian:~$ gnome-screenshot --interactive gnome-screenshot: symbol lookup error: gnome-screenshot: undefined symbol: hdy_init, version LIBHANDY_1_0 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-screenshot depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-1 ii libc62.31-3 ii libcairo21.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.66.0-2 ii libgtk-3-0 3.24.23-1 ii libhandy-1-0 1.0.0-1 ii libx11-6 2:1.6.12-1 ii libxext6 2:1.3.3-1+b2 gnome-screenshot recommends no packages. gnome-screenshot suggests no packages. -- no debconf information
Bug#968106: phosh: Shell doesn't start
Package: phosh Version: 0.4.3-1 Severity: grave Justification: renders package unusable Hello, On a freshly created Debian sid live system: ``` sudo mmdebstrap --include=linux-image-amd64,live-boot,xserver-xorg-video- all,phosh --arch amd64 sid debian-live-root http://ftp.pl.debian.org/debian/ sudo chroot debian-live-root passwd sudo chroot debian-live-root useradd -m -s /bin/bash -p $(openssl passwd -1 123456) user sudo chroot debian-live-root systemctl enable phosh cp debian-live-root/vmlinuz .; cp debian-live-root/initrd.img . sudo mksquashfs debian-live-root root.squashfs -comp lz4 python3 -m http.server -b localhost 8080 qemu-system-x86_64 -machine accel=kvm -m 4G -device virtio-net-pci,netdev=net0 -serial stdio -monitor vc -netdev user,id=net0,hostfwd=tcp::-:22,guestfwd=tcp:10.0.2.252:8080-tcp:localhost:8080,hostname=debian- live -kernel ./vmlinuz -initrd ./initrd.img -append "console=ttyS0 ip=frommedia boot=live nopersistence fetch=http://10.0.2.252:8080/root.squashfs; ``` (last command is to start the test VM) Phosh doesn't start. On the console I see: ``` traps: phoc[362] trap int3 ip:7f684a6d9585 sp:7ffccc2cfe90 error:0 in libglib-2.0.so.0.6400.4[7f684a69f000+81000] ``` When attempting to start it manually: ``` user@debian:~$ phoc (phoc:468): phoc-wlroots-CRITICAL **: 18:03:33.384: [backend/session/logind.c:760] Failed to get seat id: No data available (phoc:468): phoc-wlroots-CRITICAL **: 18:03:33.393: [backend/session/direct- ipc.c:30] Do not have root privileges; cannot become DRM master (phoc:468): phoc-wlroots-CRITICAL **: 18:03:33.396: [backend/session/session.c:96] Failed to load session backend (phoc:468): phoc-wlroots-CRITICAL **: 18:03:33.405: [backend/backend.c:286] Failed to start a DRM session (phoc:468): phoc-server-ERROR **: 18:03:33.407: Could not create backend [ 76.891092] traps: phoc[468] trap int3 ip:7feeea992585 sp:7ffe555d1130 error:0 in libglib-2.0.so.0.6400.4[7feeea958000+81000] Trace/breakpoint trap ``` ``` user@debian:~$ phoc -E '/usr/bin/phosh -U' -C /usr/share/phosh/phoc.ini (phoc:517): phoc-wlroots-CRITICAL **: 18:04:01.976: [backend/session/logind.c:760] Failed to get seat id: No data available (phoc:517): phoc-wlroots-CRITICAL **: 18:04:01.978: [backend/session/direct- ipc.c:30] Do not have root privileges; cannot become DRM master (phoc:517): phoc-wlroots-CRITICAL **: 18:04:01.981: [backend/session/session.c:96] Failed to load session backend (phoc:517): phoc-wlroots-CRITICAL **: 18:04:01.983: [backend/backend.c:286] Failed to start a DRM session (phoc:517): phoc-server-ERROR **: 18:04:01.986: Could not create backend ``` Starting phosh as root doesn't help: ``` root@debian:~# phosh /usr/bin/phosh: 12: gnome-session: not found (phoc:558): phoc-wlroots-CRITICAL **: 18:06:37.488: [backend/session/logind.c:760] Failed to get seat id: No data available (phoc:558): phoc-wlroots-CRITICAL **: 18:06:37.490: [backend/session/direct.c:176] Could not get current tty number: Inappropriate ioctl for device (phoc:558): phoc-wlroots-CRITICAL **: 18:06:37.494: [backend/session/session.c:96] Failed to load session backend (phoc:558): phoc-wlroots-CRITICAL **: 18:06:37.496: [backend/backend.c:195] failed to start a session (phoc:558): phoc-wlroots-CRITICAL **: 18:06:37.498: [backend/backend.c:235] failed to start backend 'drm' (phoc:558): phoc-server-ERROR **: 18:06:37.500: Could not create backend ``` root@debian:~# phoc -E '/usr/bin/phosh -U' -C /usr/share/phosh/phoc.ini (phoc:611): phoc-wlroots-CRITICAL **: 18:07:10.418: [backend/session/logind.c:760] Failed to get seat id: No data available (phoc:611): phoc-wlroots-CRITICAL **: 18:07:10.421: [backend/session/direct.c:176] Could not get current tty number: Inappropriate ioctl for device (phoc:611): phoc-wlroots-CRITICAL **: 18:07:10.425: [backend/session/session.c:96] Failed to load session backend (phoc:611): phoc-wlroots-CRITICAL **: 18:07:10.428: [backend/backend.c:286] Failed to start a DRM session (phoc:611): phoc-server-ERROR **: 18:07:10.431: Could not create backend ``` It's also possible that I missed an important step, but I couldn't find anything related in the doc. Michel Le Bihan -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages phosh depends on: ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii fonts-lato 2.0-2 ii gsettings-desktop-schemas3.36.1-1 ii libc62.31-2 ii libcairo21.16.0-4 pn libfeedback-
Bug#961938: Debootstrap log
You can find my debootstrap log here: https://lebihan.pl/files/debootstrap.log
Bug#961938: libreoffice: Installing Debian with Debootstrap and gnome included results in broken install
Source: libreoffice Version: 6.4.4-1 Severity: grave Justification: renders package unusable Installing Debian with: debootstrap --include=linux-image-amd64,grub-pc,xserver-xorg-video-all,gnome --arch amd64 bullseye /mnt/hd http://ftp.pl.debian.org/debian/ fails at W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /mnt/hd/debootstrap/debootstrap.log for details (possibly the package libreoffice-writer is at fault) W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /mnt/hd/debootstrap/debootstrap.log for details (possibly the package libreoffice-writer is at fault) W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /mnt/hd/debootstrap/debootstrap.log for details (possibly the package libreoffice-writer is at fault) W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /mnt/hd/debootstrap/debootstrap.log for details (possibly the package libreoffice-writer is at fault) W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /mnt/hd/debootstrap/debootstrap.log for details (possibly the package libreoffice-writer is at fault) A quick inspection confirms that libreoffice package caused the issue: chroot /mnt/hd apt --fix-broken install Reading package lists... Done Building dependency tree... Done Correcting dependencies... Done The following additional packages will be installed: libpaper-utils libreoffice-core The following packages will be REMOVED: libreoffice-core-nogui The following NEW packages will be installed: libpaper-utils libreoffice-core 0 upgraded, 2 newly installed, 1 to remove and 0 not upgraded. 6 not fully installed or removed. Need to get 18.3 kB/30.8 MB of archives. After this operation, 5728 kB of additional disk space will be used. Do you want to continue? [Y/n] I have no clue why `libreoffice-core-nogui` was pulled. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData
program/libmergedlo.so #12 0x5624f679207b in () #13 0x7f78d9c8909b in __libc_start_main (main= 0x5624f6792070, argc=1, argv=0x7ffcf8b48fa8, init=, fini=, rtld_fini=, stack_end=0x7ffcf8b48f98) at ../csu/libc-start.c:308 #14 0x5624f67920ba in () Running LibreOffice in an empty home produces the same crash, so it is not a configuration issue. Michel Le Bihan -- System Information: Debian Release: 10.1 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages uno-libs3 depends on: ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 uno-libs3 recommends no packages. uno-libs3 suggests no packages. -- no debconf information
Bug#933368: forcibly merging 933368 923567, closing 933368
I confirm that purging works as expected now. I was asked before deleting the data directory. Michel Le Bihan Le vendredi 09 août 2019 à 10:56 +0200, Christoph Berg a écrit : > forcemerge 933368 923567 > close 933368 9.6.15-0+deb9u1 > thanks > > This has been fixed in yesterdays security release.
Bug#933368: postgresql: Purging postgresql 9.6 removes content of data_directory without any warning
Package: postgresql Version: 11+200+deb10u1 Severity: grave Justification: causes non-serious data loss Dear Maintainer, After updating to Debian Buster and postgresql 11 I purged all postgresql 9.6 packages. Because of this all databases that were in the data directory specified unser data_directory to be deleted without any warning. This is not what I expected to happen and lead to data loss. Apt help message and man page says only that config files are removed, what I wanted to happen, but says nothing about data. When purging other packages like mysql-server/mariadb-server the user is asked whether he wants data to be removed or not. I made an update of MariaDB and other server software some time ago and got that question, so I expected PostgreSQL to also show it to me, but that didn't happen. If it is normal behaviour for packages to remove data when purged, I think that it should be clearly stated in the help and man. Since it isn't and other packages don't do that, I think that it is a very serious issue with the postgresql package. Michel Le Bihan -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postgresql depends on: ii postgresql-11 11.4-1 postgresql recommends no packages. Versions of packages postgresql suggests: pn postgresql-doc -- no debconf information
Bug#922346: Fix for this issue still not available in testing
Hello, I saw that Mesa 18.3.6-2 was accepted into unstable on 2019-05-11. That version still hasn't migrated to testing because of the freeze. Could you please contact the release team to get this release in testing ASAP as I (and probably other users) am still experiencing this issue and it is very critical because opening a media file can cause my DE to crash causing the loss of any unsaved work. Michel Le Bihan
Bug#922346: eog: Opened an image and my display server crashed
Hello, I found a similar bug on Ubuntu's Launchpad: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1815236 The patch for that issue was added in Mesa 18.3.5 released on March 18, 2019. Michel Le Bihan
Bug#922346: eog: Opened an image and my display server crashed
Le jeudi 14 février 2019 à 20:31 +, Simon McVittie a écrit : > Control: reassign -1 libgl1-mesa-dri > Control: tags -1 + moreinfo > > On Thu, 14 Feb 2019 at 21:18:42 +0100, Michel Le Bihan wrote: > > I opened a png file in eog and my display server crashed. > > eog shouldn't be able to cause this, even if it wanted to, so this is > a bug in the display server or some library it uses. > > From the backtrace you provided, I think this is most likely to be an > assertion failure in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so, so > I'm > reassigning this. > > The Mesa maintainers will want to know more details of your system. > The output of `reportbug --template libgl1-mesa-dri` would presumably > be useful information. > > Was the file that you opened in eog particularly large, or otherwise > unusual? No. It was only 1,5MB. It didn't appear to be unusual in any way, but I don't know if it was a fully valid PNG file. Michel Le Bihan
Bug#922346: eog: Opened an image and my display server crashed
Package: eog Version: 3.28.4-2+b1 Severity: critical Justification: breaks the whole system I opened a png file in eog and my display server crashed. Here is the relevant part of my syslog: Feb 14 20:44:45 debian org.gnome.Shell.desktop[1414]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x187 (Visionneur) Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: Xwayland: src/intel/genxml/gen7_pack.h:72: __gen_uint: Assertion `v <= max' failed. Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Backtrace: Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 0: /usr/bin/Xwayland (OsLookupColor+0x139) [0x55b8e2f27e09] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7fba70a3372f] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x10b) [0x7fba708978bb] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x121) [0x7fba70882535] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) unw_get_proc_name failed: no unwind info found [-10] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7fba70882400] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7fba708900f2] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 6: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x416573) [0x7fba6fb6c503] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 7: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x416dd5) [0x7fba6fb6cd95] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 8: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x136b7b) [0x7fba6f402d8b] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 9: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x1370e7) [0x7fba6f403ab7] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 10: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x12f041) [0x7fba6f3f3711] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 11: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x11a2dc) [0x7fba6f3c952c] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 12: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x1ccc7a) [0x7fba6f6d929a] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 13: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x1ccfea) [0x7fba6f6d999a] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 14: /usr/bin/Xwayland (glamor_create_gc+0xd535) [0x55b8e2df1a05] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 15: /usr/bin/Xwayland (DamageRegionAppend+0x19f8) [0x55b8e2e98eb8] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 16: /usr/bin/Xwayland (glamor_pixmap_exchange_fbos+0x7b7) [0x55b8e2deef57] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 17: /usr/bin/Xwayland (glamor_pixmap_exchange_fbos+0x67e) [0x55b8e2dee9be] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 18: /usr/bin/Xwayland (AddTraps+0x3551) [0x55b8e2e8aad1] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 19: /usr/bin/Xwayland (SendErrorToClient+0x35e) [0x55b8e2ef1e6e] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 20: /usr/bin/Xwayland (InitFonts+0x3b6) [0x55b8e2ef5df6] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) [0x7fba7088409b] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 22: /usr/bin/Xwayland (_start+0x2a) [0x55b8e2dc71ea] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: Fatal server error: Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Caught signal 6 (Aborted). Server aborting Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages eog depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii gir1.2-gtk-3.0 3.24.5-1 ii gir1.2-peas-1.0 1.22.0-4 ii gsettings-desktop-schemas
Bug#832626: python-requests: Importing the module fails
Package: python-requests Followup-For: Bug #832626 Hello, Thanks for the tip. `sudo pip uninstall $(pip freeze) -y` resolved my issue. Thanks again and sorry for opening an issue with severity grave when there there was no problem with the package. Michel Le Bihan -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-requests depends on: ii ca-certificates 20160104 ii python-chardet 2.3.0-2 ii python-urllib3 1.15.1-2 pn python:any python-requests recommends no packages. Versions of packages python-requests suggests: ii python-ndg-httpsclient 0.4.2-1 ii python-openssl 16.0.0-2 ii python-pyasn1 0.1.9-1 pn python-socks -- no debconf information
Bug#832626: python-requests: Importing the module fails
Package: python-requests Version: 2.10.0-2 Followup-For: Bug #832626 Hello, michel@debian:~$ python Python 2.7.12 (default, Jun 29 2016, 08:18:26) [GCC 5.4.0 20160609] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.version_info sys.version_info(major=2, minor=7, micro=12, releaselevel='final', serial=0) >>> sys.executable '/usr/bin/python' >>> sys.path ['', '/usr/local/lib/python2.7/dist-packages/pytvmaze-1.4.3-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/pyScss-1.3.4-py2.7-linux-x86_64.egg', '/usr/local/lib/python2.7/dist-packages/pyparsing-2.0.7-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/Flask_Login-0.3.2-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/Flask_Compress-1.3.0-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/cssmin-0.2.0-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/Flask_Assets-0.11-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/CherryPy-4.0.0-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/flask_restplus-0.7.2-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/ordereddict-1.1-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/Flask_RESTful-0.3.5-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/Flask-0.10.1-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/APScheduler-3.0.5-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/guessit-0.10.3-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/path.py-8.1.2-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/tmdb3-0.7.2-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/python_dateutil-2.4.2-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/rpyc-3.3.0-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/progressbar-2.3-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/pynzb-0.1.0-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/PyRSS2Gen-1.1-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/PyYAML-3.11-py2.7-linux-x86_64.egg', '/usr/local/lib/python2.7/dist-packages/SQLAlchemy-1.0.11-py2.7-linux- x86_64.egg', '/usr/local/lib/python2.7/dist- packages/feedparser-5.2.1-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/pathlib-1.0.1-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/webassets-0.11.1-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/pytz-2015.7-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/aniso8601-1.1.0-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/itsdangerous-0.24-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/Werkzeug-0.11.3-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/futures-3.0.3-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/tzlocal-1.2-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/stevedore-1.10.0-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/babelfish-0.5.5-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/urllib3-1.12-py2.7.egg', '/usr/local/lib/python2.7/dist- packages/plumbum-1.6.1.post0-py2.7.egg', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist- packages/gtk-2.0', '/usr/lib/pymodules/python2.7', '/usr/lib/python2.7/dist- packages/wx-3.0-gtk2'] >>> import requests Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 61, in from .packages.urllib3.exceptions import DependencyWarning ImportError: cannot import name DependencyWarning >>> requests.__version__ Traceback (most recent call last): File "", line 1, in NameError: name 'requests' is not defined >>> requests.__file__ Traceback (most recent call last): File "", line 1, in NameError: name 'requests' is not defined >>> exit() -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-requests depends on: ii ca-certificates 20160104 ii python-chardet 2.3.0-2 ii python-urllib3 1.15.1-2 pn python:any python-requests recommends no packages. Versions of packages python-requests suggests: ii python-ndg-httpsclient 0.4.2-1 ii python-openssl 16.0.0-2 ii python-pyasn1 0.1.9-1 pn python-socks -- no debconf information
Bug#832626: python-requests: Importing the module fails
Package: python-requests Version: 2.10.0-2 Severity: grave Justification: renders package unusable >>> import requests Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 61, in from .packages.urllib3.exceptions import DependencyWarning ImportError: cannot import name DependencyWarning -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-requests depends on: ii ca-certificates 20160104 ii python-chardet 2.3.0-2 ii python-urllib3 1.15.1-2 pn python:any python-requests recommends no packages. Versions of packages python-requests suggests: ii python-ndg-httpsclient 0.4.2-1 ii python-openssl 16.0.0-2 ii python-pyasn1 0.1.9-1 pn python-socks -- no debconf information
Bug#832454: virt-manager doesn't open
Package: virt-manager Version: 1:1.4.0-2 Severity: grave Justification: renders package unusable When I run virt-manager or virt-manager --debug --no-fork, virt-manager doesn't open and I get that output in the terminal: Traceback (most recent call last): File "/usr/share/virt-manager/virt-manager", line 33, in from virtinst import util as util File "/usr/share/virt-manager/virtinst/__init__.py", line 89, in from virtinst.distroinstaller import DistroInstaller File "/usr/share/virt-manager/virtinst/distroinstaller.py", line 23, in from . import urlfetcher File "/usr/share/virt-manager/virtinst/urlfetcher.py", line 34, in import requests File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 61, in from .packages.urllib3.exceptions import DependencyWarning ImportError: cannot import name DependencyWarning This issue is also present in the package in testing (1:1.3.2-4) -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages virt-manager depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.0-1 ii gconf2 3.2.6-3 ii gir1.2-gtk-3.0 3.20.6-2 ii gir1.2-gtk-vnc-2.0 0.5.3-1.3+b1 ii gir1.2-libosinfo-1.0 0.3.0-2 ii gir1.2-libvirt-glib-1.0 0.2.3-2 ii gir1.2-vte-2.91 0.44.2-1 ii librsvg2-common 2.40.16-1 ii python-dbus 1.2.4-1 ii python-gi3.20.1-1 ii python-gi-cairo 3.20.1-1 ii python-libvirt 2.0.0-1 ii python-requests 2.10.0-2 pn python2.7:any pn python:any ii virtinst 1:1.4.0-2 Versions of packages virt-manager recommends: ii gir1.2-spice-client-gtk-3.0 0.30-1 ii gnome-icon-theme 3.12.0-2 ii libvirt-daemon-system2.0.0-1 Versions of packages virt-manager suggests: ii gnome-keyring 3.20.0-1 ii ksshaskpass [ssh-askpass] 4:5.7.0-1 pn python-gnomekeyring pn python-guestfs ii virt-viewer3.1-1 -- no debconf information
Bug#789038: jitsi: Unable to install on sid/unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I would love to have Jitsi in Debian. What is the current situation with ftp-masters? I also saw that the latest version of Jitsi is 2.8. It was released 9 months ago. Why it's not yet in sid? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJWnRkCAAoJEJZMH2xih1Jp510IAPXauvqcLb5cFNbteeOEaGJE xzPUiXOzmGyHH+eWkFGRUsjvoody9HDvEXIMgHmOgrMCwk8xQTPYGbj5gJM/4uPZ 7Z94oBs1qPinLippjGIql7sAJ/ttvupKcGPsFqV9YHjhkcg77K8T0FeSoTK8AqlJ tX4DLa5DpVAG1dJr77GSeVJAVmDymscblE/KEvrFu2KA/TLe5ZpSt1tnP4GSeWVr F6csT7GasPn3GwcP0ZwjR8o2wA1t6yKNMlSFK2Mw5kyFAj/HZLj0t8BHCwYO9iBr XQGnB8tZJ0g+g5QlCA5/po2wLFKIwivxuXSLJFHaIUyRsM6XAyFC5ohKRMwQntc= =jQV2 -END PGP SIGNATURE-
