Bug#979443: chromium: desktop GUI locks up as Xorg process goes to 100%
Michel and I just prepared an security update for unstable and buster-security which changes the default to "desktop". This should be soon in the archive. Best, Jan Am 11.01.21 um 15:14 schrieb Steve A.: > After three full days of use, the desktop has not frozen again, and the > Xorg process has remained below 7% CPU use. Should I modify the menu to > include the alternate launch command, or is there a beta version of > chromium you would like me to try? > > Steve > > > Steve A. wrote on 1/8/21 6:32 AM: >> Thanks, Jan. I killed chromium, upgraded to 87* again, and >> re-launched with the recommended command last night. The user is back >> on this morning and I'm monitoring from another machine. >> >> Steve >> >> >> Jan Luca Naumann wrote on 1/7/21 2:30 AM: >>> Dear Steve, >>> >>> with the upgrade to 87.* we included the ANGLE library which manages the >>> OpenGL access of chromium. Maybe this is the cause of your problem. >>> >>> Could you try to launch "$ chromium --use-gl=desktop"? This should >>> disable the usage of ANGLE. >>> >>> Best, >>> Jan >>> OpenPGP_signature Description: OpenPGP digital signature
Bug#979533: chromium: New 87.0.4280.141 (CVE-2020-15995 CVE-2020-16043 CVE-2021-21106 CVE-2021-21107 CVE-2021-21108 CVE-2021-21109 CVE-2021-21110 CVE-2021-21111 CVE-2021-21112 CVE-2021-21113 CVE-2021-
Michel is preparing an new version and I update the buster branch as soon as the unstable version is uploaded. Best, Jan On Thu, 07 Jan 2021 21:01:43 +0100 Salvatore Bonaccorso wrote: > Source: chromium > Version: 87.0.4280.88-0.4 > Severity: grave > Tags: security upstream > Justification: user security hole > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > Control: found -1 87.0.4280.88-0.4~deb10u1 > > Hi > > Please see > https://chromereleases.googleblog.com/2021/01/stable-channel-update-for-desktop.html > here is a new round of CVE fixes for chromium accordingly. > > CVE-2020-15995 seems a bit unclear, it was previously marked to affect > only Chrome on Android, but now appears to affect as well us. > > Regards, > Salvatore > > OpenPGP_signature Description: OpenPGP digital signature
Bug#979443: chromium: desktop GUI locks up as Xorg process goes to 100%
Dear Steve, with the upgrade to 87.* we included the ANGLE library which manages the OpenGL access of chromium. Maybe this is the cause of your problem. Could you try to launch "$ chromium --use-gl=desktop"? This should disable the usage of ANGLE. Best, Jan On Wed, 6 Jan 2021 11:00:00 -0800 "Steve A." wrote: > Package: chromium > Version: 87.0.4280.88-0.4~deb10u1 > Severity: grave > Tags: a11y > Justification: renders package unusable > > Dear Maintainer, > > Subsequent to an upgrade from 83.0.4103.116-1~deb10u3 to > 87.0.4280.88-0.4~deb10u1, the desktop GUI randomly freezes, including > the clock. This occurred three times over the course of two days. > Doing a ssh from another machine, and then running top, showed the Xorg > process pegged at 100%. Killing just the chromium process did not > resolve the locking problem, and the only way to recover was to kill all > processes for the GUI user. Chromium was rolled back to > 83.0.4103.116-1~deb10u3 and there have been no freezes in over two days. > > > -- System Information: > Debian Release: 10.7 >APT prefers stable-updates >APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-13-amd64 (SMP w/16 CPU cores) > Kernel taint flags: TAINT_WARN > 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 /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages chromium depends on: > ii chromium-common 87.0.4280.88-0.4~deb10u1 > ii libasound2 1.1.8-1 > ii libatk-bridge2.0-0 2.30.0-5 > ii libatk1.0-0 2.30.0-2 > ii libatspi2.0-02.30.0-7 > ii libavcodec58 7:4.1.6-1~deb10u1 > ii libavformat587:4.1.6-1~deb10u1 > ii libavutil56 7:4.1.6-1~deb10u1 > ii libc62.28-10 > ii libcairo21.16.0-4 > ii libcups2 2.2.10-6+deb10u4 > ii libdbus-1-3 1.12.20-0+deb10u1 > ii libdrm2 2.4.97-1 > ii libevent-2.1-6 2.1.8-stable-4 > ii libexpat12.2.6-2+deb10u1 > ii libflac8 1.3.2-3 > ii libfontconfig1 2.13.1-2 > ii libfreetype6 2.9.1-3+deb10u2 > ii libgbm1 18.3.6-2+deb10u1 > ii libgcc1 1:8.3.0-6 > ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 > ii libglib2.0-0 2.58.3-2+deb10u2 > ii libgtk-3-0 3.24.5-1 > ii libharfbuzz0b2.3.1-1 > ii libicu63 63.1-6+deb10u1 > ii libjpeg62-turbo 1:1.5.2-2+deb10u1 > ii libjsoncpp1 1.7.4-3 OpenPGP_signature Description: OpenPGP digital signature
Bug#973848: security update of chromium in Debian stable?
Hey, I have got a successful buster build half an hour ago :) As soon as [1] is fixed or at least worked around (so we do not release a version with a regression), I think we could do the update. I will contact the security team now to discuss the update. Best, Jan [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977870 Am 28.12.20 um 12:37 schrieb Tomas Pospisek: > Hi Jan Luca, > > are you working on or respectively are you planing to do the stable build? > > (I am not sure if I would be able to get access to a powerful enough > machine to do the build and get up to speed within reasonable time on how > to build chromium and on how to do it efficiently so that I do not have > to wait 24 hours for the build to proceed and fail again before I > apply the next fix...?) > > Greetings! > *t OpenPGP_signature Description: OpenPGP digital signature
Bug#973848: security update of chromium in Debian stable?
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_token.h:121:40: note: in instantiation of template class 'std::underlying_type >' 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 OpenPGP_signature Description: OpenPGP digital signature
Bug#973848: chromium: Unsupported version, many security bugs unfixed
Hey, I have uploaded my stuff to https://salsa.debian.org/janluca-guest/chromium We can meet in IRC or Matrix. I am janluca on irc.oftc.net. Best, Jan On Mon, 14 Dec 2020 13:59:53 +0100 Michel Le Bihan wrote: > 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 >
Bug#973848: chromium: Unsupported version, many security bugs unfixed
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#966922: libnitrokey: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Hey Scott, since nitrokey-app has been kickout of testing today, I want to ask about the update? Do you need some help I could offer? Best, Jan Am 21.08.20 um 00:01 schrieb Scott Kitterman: > I will take care of it. The removal isn't scheduled for almost a month, so > there is plenty of time. > > Scott K > > On Thursday, August 20, 2020 12:28:17 PM EDT Jan Luca Naumann wrote: >> Hey Scott, >> >> could you update the package? Since this is marked as RC bug, >> libnitrokey and all depending packages are kicked out of testing. >> >> Best, >> Jan >> >> On Mon, 03 Aug 2020 13:54:57 + Scott Kitterman >> >> wrote: >>> This is probably a result of a new GCC version. C++ symbols can be >>> painful to manage. This will be trivial to update the next time I update >>> the package. >>> >>> Scott K >>> >>> On August 3, 2020 9:15:16 AM UTC, Szczepan Zalega | Nitrokey > wrote: >>>> On 8/3/20 10:41 AM, Lucas Nussbaum wrote: >>>>> (optional=templinst|arch=!amd64 !arm64 !x32) >>>>> (optional=templinst) >>>> >>>> Hi! >>>> >>>> As far as I see the problem comes from the listing format difference, >>>> not the actual symbol change. >>>> >>>> E.g.: >>>> ``` >>>> - (optional=templinst|arch=!amd64 !arm64 >>>> !x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14Dev >>>> iceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx1 >>>> 1Ei@Base 3.5 >>>> + >>>> (optional=templinst)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandID >>>> E65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translat >>>> e_commandB5cxx11Ei@Base 3.5 >>>> ``` >
Bug#966922: libnitrokey: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Hey Scott, could you update the package? Since this is marked as RC bug, libnitrokey and all depending packages are kicked out of testing. Best, Jan On Mon, 03 Aug 2020 13:54:57 + Scott Kitterman wrote: > This is probably a result of a new GCC version. C++ symbols can be painful > to manage. This will be trivial to update the next time I update the package. > > Scott K > > On August 3, 2020 9:15:16 AM UTC, Szczepan Zalega | Nitrokey > wrote: > >On 8/3/20 10:41 AM, Lucas Nussbaum wrote: > >> (optional=templinst|arch=!amd64 !arm64 !x32) > >> (optional=templinst) > > > >Hi! > > > >As far as I see the problem comes from the listing format difference, > >not the actual symbol change. > > > >E.g.: > >``` > >- (optional=templinst|arch=!amd64 !arm64 > >!x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx11Ei@Base > >3.5 > >+ > >(optional=templinst)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx11Ei@Base > >3.5 > >``` > > signature.asc Description: OpenPGP digital signature
Bug#948087: future of aufs in Debian.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear all, I have create a RFH since I have currently no time due to personal issue s: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963191 I hope somebody can help with the maintaining. Best, Jan Am 26.05.20 um 16:33 schrieb Jan Luca Naumann: > Dear Peter, > > I am in general still active but due to private stuff I was quite > bad maintaining aufs the last months, I am really sorry. I will try > to take a look into the package at the weekend. Additionally, I > will create a RFH bug, maybe somebody wants to help me so there is > no single point of failure in the future. > > Best, Jan > > On 26.05.20 15:18, peter green wrote: >> The aufs package last saw a maintainer upload in September 2019 >> and was last-updated (by a NMU) in October 2019. It has had >> broken build-dependencies in testing for half a year now (since >> Linux 5.3.9-3 migrated to testing in November 2019). >> >> According to dak rm the aufs source-package has two >> reverse-dependencies, aufs-tools and fsprotect neither of which >> has any reverse-dependencies. >> >> Adrian filed a rc bug in November 2019 which received no >> maintainer response, however the package was not autoremoved from >> testing due to aufs and aufs-tools being considered a "key >> packages" due to high popcon. This popcon actually seems to be >> growing in both absolute and percentage terms. I presume the high >> popcon is due to some deriviative (hence debian-derivatives and >> debian-live in cc) using aufs in their live image builds (as far >> as I can tell debian's own live images seem to use overlayfs >> instead nowadays). >> >> aufs does seem to still be maintained upstream with upstream >> claiming support for Linux 5.6. >> >> According to contributors.debian.net Jan Luca Naumann (the aufs >> maintainer) was last active in September 2019. Jan: are you >> still around? and if so do you still intend to maintain the aufs >> package? if not is someone else going to step up to the plate? or >> should these packages be removed from testing? -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAl7t5xkACgkQfhHX8Rn5 cbtQIRAAoOQXpteSVFE/ssF81zS80AqOTSTCjLzh76oXc7/az6eHUZpdVrNkPqd/ Cbz+iZiO2NDdpfw0APPA3bKoC9s9R+J9EpOxx7zS5eb87R7xJDAvTk5oskHl8lYH V2oXcZvai8Rzf+l+sLKG2k3c4WRuoli/QxLZP8TnE0ySVqmtYOZCUUSeCRYwjLed qAT6vW/5mgCaIIynZMXwYNW5889h8AVIt+n9WOHYCYEtltRTDkJU+n6ZpNx2VhbE HdDS98T/RWhwNq2oZEIkQlfZfYp7yNP0MtThvCnPRML1dSZwuMTLd4/nrNaL3ITK MBjt0/IZ6wlp1E18kePfpaHFLX7ekqhBqTr5PmCiQzyPorcgCaEq6rTkwfReuLWR g58wQmx/8GkrYh4HcCziETSoODGscicskBkzipk6yT9lA9JDROFMqnu8mudUc5B5 /VocELuPiQaEql4h1G/tkoZ/KSkZterDFZ72ssYoYzLgJQxLLY1wSlVKovtKaMcX 5kJ3dzHjmjEO1IRfpbPyFJ5HaFlfTHAbkXx3Ll5saz08KiX+isHr6JGU+ZEt4O3R P4+rc8Z+gjTURY/2xHo8XRvehEyuoRYfHDaXOmR3a7pazt6e4TZ0bR1uyOsbJWhy StTmrl72U6dTEXk20IhJdMlG1pp7I0aMfoW85nl182TJwnhxFWc= =W+Dn -END PGP SIGNATURE-
Bug#948087: Please report state
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have create a RFH since I have no time due to personal issues: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963191 I hope somebody can help with the maintaining. Jan On Mon, 1 Jun 2020 16:25:28 +0200 Eduard Bloch wrote: > Hello, > > I was notified by a prominent user who is seriouly worried about > the state of this package. > > Please let us know whether it will be in releasable shape in the > next weeks, or whether you need any support or a sponsored upload. > Thank you. > > And in case that you no longer wish to maintain it, plesae follow > the regular procedures (see policy) of orphaning, or at least > consider raising a Request-For-Help, if appropriate. > > Best regards, Eduard. > > -- man the AMD64 camp is not helped by the list of > people supporting it when nerode is on your side, you know > you're doing something wrong > > -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAl7t5QEACgkQfhHX8Rn5 cbsScxAAj9M3uKxiINX7DqhUlFeWUtIg5lvSQplt0SyNVMfpaAU77Ea5WN2qUktz TkQ8sdOc+0NRrcG+YxGxf/kd+TEtnov/KMXoZFOnq30LUaC1ph02maEZyM56RhNL +CfmTrRVlWnIxjnrZaJCIzoIKaysWt9+UpGpHhWlfEOR9S9plogLdfOfhxpNraQ0 3n7xCUWU60+6DhKl4Lg7iGf3mVgyEndWZXBM9OArwDuQ4ieZ8jI4tBpi88eEsGlD QZf3CQ3COtwYXLb2TIbN6yvfZZnA+Vax5uCnTE4Xj3wtxtoy13rjh50kjnuKUjrS 5DcZVlMF2KEKaHjeE1EPws2eomVgEcL7GxT/qXr2CK81DMkYtqD5HPQ0w8Zy6fK+ usi1MU1WU3trV6/edlYe+ZmX5XPuMatDQUAXzZEwKNN9NNfUOsgZQlUlb86Ms0e4 al0aysOrN6OwOgxOo8ep/YCBFHwTVLfELeBI5n6afdSW3qoga6DVMo1IvDjCIRv8 6vDw57eNMCY+0i1Ve/SW+sWpAHTQBsGTFNNO8CX3R1RGr+WTWw1srt5/j6ITopgE bWRMh4u4SsJeKvW/BiEXr8oS4naZhxlGVoZTIgPJQMiMC8FqReamMuxFHz1eSTHZ PJ90666yZ9ybt3aFfkrbHjQ/4PpuIa8hgori5u3z0YYrOFLIRcc= =d9yC -END PGP SIGNATURE-
Bug#948087: future of aufs in Debian.
Dear Peter, I am in general still active but due to private stuff I was quite bad maintaining aufs the last months, I am really sorry. I will try to take a look into the package at the weekend. Additionally, I will create a RFH bug, maybe somebody wants to help me so there is no single point of failure in the future. Best, Jan On 26.05.20 15:18, peter green wrote: > The aufs package last saw a maintainer upload in September 2019 and was > last-updated (by a NMU) in October 2019. It has had broken > build-dependencies in testing for half a year now (since Linux 5.3.9-3 > migrated to testing in November 2019). > > According to dak rm the aufs source-package has two > reverse-dependencies, aufs-tools and fsprotect neither of which has any > reverse-dependencies. > > Adrian filed a rc bug in November 2019 which received no maintainer > response, however the package was not autoremoved from testing due to > aufs and aufs-tools being considered a "key packages" due to high > popcon. This popcon actually seems to be growing in both absolute and > percentage terms. I presume the high popcon is due to some deriviative > (hence debian-derivatives and debian-live in cc) using aufs in their > live image builds (as far as I can tell debian's own live images seem to > use overlayfs instead nowadays). > > aufs does seem to still be maintained upstream with upstream claiming > support for Linux 5.6. > > According to contributors.debian.net Jan Luca Naumann (the aufs > maintainer) was last active in September 2019. Jan: are you still > around? and if so do you still intend to maintain the aufs package? if > not is someone else going to step up to the plate? or should these > packages be removed from testing?
Bug#938961: aufs: needs update for new linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I will take care of the update next week. This week I'm on holidays without a real computer. Sorry for the delay and best Jan Am 30.08.19 um 17:26 schrieb Ivo De Decker: > package: aufs severity: serious tags: bullseye sid > > Hi, > > The version of aufs in testing and unstable build-depends on > linux-kbuild-4.19, which is no longer availabe in testing. > > Thanks, > > Ivo > -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAl1pZfgACgkQfhHX8Rn5 cbvOpw//WnObpPyNiJXd9UmIoC6eLI8MNDc/tGrwhWOyssR05sEOM56o4JkyaohF tIkjHYHhypsCxkLtoETkfJjjhpxTxQVHs2NiDjGmo/S4zEwk/OTKZMOp8wyWNRhP j8PvhcBz4jplGwF3RSsIt4wqXdygIgjG7mogzXtsbg+T6WOzQE583xZ3syUs/dbH jJ4Jo2/BuZKO54tEd8WvDHDsL9v0fZlhv6wATCe9buMAlmSPtAaYp986nDLsvZIr Gc7TXf02+CVqZ4GsuUNBIIHLuvP6zf6mryIIk5UsyCfQNRAZca4qH/UR1+bd5ZI3 NRJmYuUqtODwW6oh3p3ckoZ2ZY7gdljmAAiciWPxtkXpJAootlS39TmCePbK08CG FecA2nSO8AxIAP5cm79lXkiUA7MRlwAvWmDfUcpxvjWosynsERy0Jp1b5zDv/yRY bo4wnHopQHOcPwMsUdIoGWMjjRO6pp53I/nZM5TjHpnLFNoW8KJKd8udfbQCSvXx m2dpbCX/QFFd7vQNeaXWM5YsiUvc6EHyFPCOaucxvu/W5IALL6mAqSGbnrtBvYKq tn4bbyuOkLfvi/5aesEPpClWGUL+W9u6seStYqjOiuvFa7yG2LUBiV3iyJa+7zlL Mo2JS8lpibru7Ue0VcgEIUpdzQTRfjfWFqtvDKqoEzt7AD+J2Ts= =hISk -END PGP SIGNATURE-
Bug#913820: [Pkg-freeipa-devel] Bug#913820: cockpit-389-ds: Debian-packaged JS libs not sufficient to run cockpit-plugin
Hey, the fix of this bug is not complete, the installation of the JS-stuff is still excluded in debian/rules. Could you please take another look into the bug? Best regards, Jan On Fri, 16 Nov 2018 11:20:44 +0200 Timo Aaltonen wrote: > On 15.11.2018 18.22, Jan Luca Naumann wrote: > > Package: cockpit-389-ds > > Version: 1.4.0.18-1 > > Severity: grave > > Justification: renders package unusable > > > > At the momenent the package cockpit-389-ds applies a patch to use the Debian > > packaged JS libraries. In contrast to the vendored libraries the Debian > > versions > > do not work with the current version of the cockpit-389-plugin, c.f. the > > backtrace attached. Removing the Debian-specific patch and installing the > > vendored JS libs resolves the issue. > > yeah, and all the minified stuff is already in debian/missing-sources, > so it should be fine to just drop the patch.. Thanks for the bug! > > > -- > t > >
Bug#917857: NMU diff for aufs 4.19+20181217-0.1
Hey, thank you for the upload and your work. I am sorry that I did not manage to upload the new version due to too much other workload. I have seen that your delete the dependency on linux-kbuild. I have added it to avoid transition of the aufs-packages to testing before the linux package is available in the requested version. One time there was the problem that the aufs-package already migrated but the linux package had some RC-bug. Jan Am 07.01.19 um 20:08 schrieb Ben Hutchings: > I made an NMU to fix this bug (and related ones). I also fixed some > more minor issues with the packaging that I noticed. > > The attached debdiff is restricted to the debian/ directory. I created > the new orig tarball from upstream git commit > dc68432bc8fed5faf20f2a0889739a13110abdc1. > > Ben. >
Bug#913820: cockpit-389-ds: Debian-packaged JS libs not sufficient to run cockpit-plugin
Package: cockpit-389-ds Version: 1.4.0.18-1 Severity: grave Justification: renders package unusable At the momenent the package cockpit-389-ds applies a patch to use the Debian packaged JS libraries. In contrast to the vendored libraries the Debian versions do not work with the current version of the cockpit-389-plugin, c.f. the backtrace attached. Removing the Debian-specific patch and installing the vendored JS libs resolves the issue. Uncaught SyntaxError: Unexpected token < dataTables.select.min.js:1 Uncaught SyntaxError: Unexpected token < moment.min.js:1 Uncaught SyntaxError: Unexpected token < dataTables.datetime-moment.js:27 Uncaught ReferenceError: moment is not defined at dataTables.datetime-moment.js:27 at dataTables.datetime-moment.js:29 jstree.min.js:1 Uncaught SyntaxError: Unexpected token < bootstrap.min.js:1 Uncaught SyntaxError: Unexpected token < c3.min.js:1 Uncaught SyntaxError: Unexpected token < d3.min.js:1 Uncaught SyntaxError: Unexpected token < plugins.js:3 Uncaught TypeError: $(...).DataTable is not a function at HTMLDivElement. (plugins.js:3) at HTMLDivElement. (jquery-3.3.1.min.js:2) at Function.each (jquery-3.3.1.min.js:2) at w.fn.init.each (jquery-3.3.1.min.js:2) at Object. (jquery-3.3.1.min.js:2) at u (jquery-3.3.1.min.js:2) at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2) at k (jquery-3.3.1.min.js:2) at XMLHttpRequest. (jquery-3.3.1.min.js:2) replication.js:244 Uncaught TypeError: $(...).DataTable is not a function at HTMLDivElement. (replication.js:244) at HTMLDivElement. (jquery-3.3.1.min.js:2) at Function.each (jquery-3.3.1.min.js:2) at w.fn.init.each (jquery-3.3.1.min.js:2) at Object. (jquery-3.3.1.min.js:2) at u (jquery-3.3.1.min.js:2) at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2) at k (jquery-3.3.1.min.js:2) at XMLHttpRequest. (jquery-3.3.1.min.js:2) monitor.js:156 Uncaught TypeError: $(...).jstree is not a function at HTMLDivElement. (monitor.js:156) at HTMLDivElement. (jquery-3.3.1.min.js:2) at Function.each (jquery-3.3.1.min.js:2) at w.fn.init.each (jquery-3.3.1.min.js:2) at Object. (jquery-3.3.1.min.js:2) at u (jquery-3.3.1.min.js:2) at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2) at k (jquery-3.3.1.min.js:2) at XMLHttpRequest. (jquery-3.3.1.min.js:2) servers.js:405 Uncaught TypeError: $(...).DataTable is not a function at HTMLDivElement. (servers.js:405) at HTMLDivElement. (jquery-3.3.1.min.js:2) at Function.each (jquery-3.3.1.min.js:2) at w.fn.init.each (jquery-3.3.1.min.js:2) at Object. (jquery-3.3.1.min.js:2) at u (jquery-3.3.1.min.js:2) at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2) at k (jquery-3.3.1.min.js:2) at XMLHttpRequest. (jquery-3.3.1.min.js:2) security.js:60 Uncaught TypeError: $(...).DataTable is not a function at HTMLDivElement. (security.js:60) at HTMLDivElement. (jquery-3.3.1.min.js:2) at Function.each (jquery-3.3.1.min.js:2) at w.fn.init.each (jquery-3.3.1.min.js:2) at Object. (jquery-3.3.1.min.js:2) at u (jquery-3.3.1.min.js:2) at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2) at k (jquery-3.3.1.min.js:2) at XMLHttpRequest. (jquery-3.3.1.min.js:2) backend.js:148 Uncaught TypeError: $(...).jstree is not a function at load_jstree (backend.js:148) at HTMLDivElement. (backend.js:210) at HTMLDivElement. (jquery-3.3.1.min.js:2) at Function.each (jquery-3.3.1.min.js:2) at w.fn.init.each (jquery-3.3.1.min.js:2) at Object. (jquery-3.3.1.min.js:2) at u (jquery-3.3.1.min.js:2) at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2) at k (jquery-3.3.1.min.js:2) at XMLHttpRequest. (jquery-3.3.1.min.js:2)
Bug#880387: [Filesystems-devel] Bug#880387: aufs-dkms: the module is not built for Linux 4.14
Hey, I have already prepared an upload but there was a seg fault on my test system I want to investigate before uploading. Best regards, Jan Am 04.12.2017 um 10:44 schrieb intrigeri: > Control: severity -1 serious > >> Linux 4.14-rc7 was uploaded to experimental; we're getting close to >> the 4.14 final release and its upload to sid. How about uploading >> a version of aufs-dkms that's compatible with Linux 4.14 (to sid, or >> to experimental if that's impractical or not feasible) so that we're >> ready when 4.14 reaches sid? > > Linux 4.14 is now in sid so I think this makes this bug RC. > > Cheers, >
Bug#875620: aufs-dkms: Please enable compilation with kernel 4.13
I have uploaded the new version, sorry for the delay. The Git repo is up-to-date as well now, I forgot to push the last changes. Best regards, Jan On Thu, 05 Oct 2017 11:37:02 +0200 intrigeri wrote: > Control: severity -1 serious > > Hi, > > > I tried aufs with kernel 4.13-rc7 from experimental and it seems to > > compile and work well. Please consider enabling this kernel in > > dkms.conf. > > Too bad this didn't happen before 4.13 reached sid and gets > depended on by linux-image-amd64 ⇒ bumping severity to RC. > > I wanted to propose a Git branch ready to merge, but the latest tag > pushed to Vcs-Git is debian/4.11+20170703-1 (and the master branch > matches), which makes it harder to help than I would like. > > Cheers, > -- > intrigeri > >
Bug#865614: [Filesystems-devel] Bug#865614: Bug#865614: Bug#865614: aufs-dkms: aufs-dkms does not support Linux 4.11
Hey, I have seen that there is the updated kernel today, I will take a look into aufs later this day. Best regards, Jan Am 14.08.2017 um 14:43 schrieb intrigeri: > Jan Luca Naumann: >> I have prepared a version for 4.11 and upload it as soon as I have >> tested it (at the moment I'm blocked by https://bugs.debian.org/869511 ) > > Now 4.12 is in sid and I believe there's no blocker anymore :) > … assuming there's an updated aufs patchset for 4.12. > > ___ > Filesystems-devel mailing list > filesystems-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/filesystems-devel >
Bug#865614: [Filesystems-devel] Bug#865614: Bug#865614: aufs-dkms: aufs-dkms does not support Linux 4.11
Control: tag -1 pending Hey, I have prepared a version for 4.11 and upload it as soon as I have tested it (at the moment I'm blocked by https://bugs.debian.org/869511 ) Best regards, Jan Am 18.07.2017 um 18:55 schrieb David R. Hedges: > Hi! > > Jan Luca Naumann: >> I will try to package a new version as soon as 4.11.7+ is uploaded. > > I'm sorry to be a bother, but 4.11.11 is in unstable, and 4.12.2 is in the > NEW queue awaiting FTP master review. Could you please push the new version > to unstable when you have a chance (and/or NEW, to catch 4.12 when that > makes its way in)? > > Thanks! > -David > > ___ > Filesystems-devel mailing list > filesystems-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/filesystems-devel
Bug#854880: Fwd: firmware-atheros ships binary ath9k_htc firmwares containing GPL code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Linux-Firmware-Maintainers, as reported in the Debian bug report #854880[1] (mail attached below), the firmware files ath9k_htc/htc_7010-1.4.0.fw, ath9k_htc/htc_9271-1.4.0.fw has been created using GPL components and thus the source code has to be included. Can you please take a look on the issue? IMHO it is the best to fix this directly in the upstream linux-firmware repository. Thank you, Jan [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854880 On Sat, 11 Feb 2017 15:09:30 +0100 Julian Andres Klode wrote: > The binary files > > Files: ath9k_htc/htc_7010-1.4.0.fw, ath9k_htc/htc_9271-1.4.0.fw > > were created from files that include GPL components according to > the copyright file, specially, the eCos files: > > eCos is free software; you can redistribute it and/or modify it > under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2 or (at your option) > any later version. . As a special exception, if other files > instantiate templates or use macros or inline functions from this > file, or you compile this file and link it with other works to > produce a work based on this file, this file does not by itself > cause the resulting work to be covered by the GNU General Public > License. However the source code for this file must still be made > available in accordance with section (3) of the GNU General Public > License. . This exception does not invalidate any other reasons why > a work based on this file might be covered by the GNU General > Public License. > > These need to be either added to the package or the firmware needs > to be removed from the archive. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlixzOsACgkQfhHX8Rn5 cbtJ2RAAlpx4cKAO7Quu4hAy6NrmdbC1l29Yq3f5gYlA+wWZFs0TXOaubYy4E5ay K9JixISdu3jgnZInlwkyFKAXX7L7jta6DowdoMDOKjcXCN9djy1meWfbVGEmqepe eBOCyxetKIrnx5Sp2Fp/GNwpdRKX913vusmR1iSsYRss8S3YgJ6oAPYpYyc5SyWj qA/pExt6f59fi7MfAVxMrJsW6eq0gmZiEIjEGMoQfVDZRAe8fJUo5cQI3hukRWLd zlmVoMgPfTyfoc1GdDICg8sW39+TjWxoYXLwELZkhfaGPo2OUsTyjQeI4a9aP1Hb WPONEiBMY2OYBr5w2wvFTDNFY9UPMZ46W3qVCGGuTPy8yV46DyD0rhgq7qP3Z2zj kKq24ONmfjrdFVzj+h7SQWyQKcSfaB3bIKJfB44fSzNCmw35hAVTF+pwDOOB0+p9 /NkQ7KUfczksatMUg9IWvsuZT/nR2MimwyP+wB0U/sxjnNbVNH3m9KBuACbZ2+4M bCSze7gVdPPa83T9i/pQH+R/nQoVBeb4TT6IWhQHIYasFV+3at2Rb57SCHKvt8E+ E1LjY4CdhCfnFjK5tGrfCtvHrPYHFooDDcArgMpHTjoGLleT9gMx4hP+oI3NViGK vNbrwnf0eIOtJcPBLG5zVNV+6otuWbiMTxTADPeegs6SAhJ4lPw= =KS0/ -END PGP SIGNATURE-
Bug#808463: ntfs-3g: non-free code in boot.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Control: tags -1 + patch Hey, I have created a NMU to fix this issue. It would be nice if someone can sponsor it: https://mentors.debian.net/package/ntfs-3g The debdiff is attached. Best regards, Jan -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlixr9QACgkQfhHX8Rn5 cbuXthAAxqVwQ2O4gXQWEU22EXSF5kNREwphSySvWhi2vmQU16T6PlcwpfY+A7oB 0PxY7Yw5qExV6CYdtDOCmp3Rbc4h07FInyXDcISHLLXaShzbbz0zYHTUzRreeXMV qIUgF9HanhYiBPpLaBxK224hwqYONMIATXjQ5xlW9JdUF09gOWaK9ibl1vhld/Eu evtx1DPlzCyPyK9JG2/wySCEsW8h7hbmyXl1DjXhovxQBAOLjGKSBIP2hG+1texn jACHB3L7vZ9ZPEr2qYLttN8G/mATeaHKhCSVPIHzYmYGgJibumBZqdGYjnCsN+dC E+mVcOp4FChX/Y+/wn3FAlCGoLN++O0rlWne7O1foOf5Hiq47ojhxhgrsVaNmCVu Eb62UUAkqWARbwjZSnqVbt719/mBnxELfY93FRHde9n4N6IFLFVE2evZSCfJ9OBi e4jK2/FPVOFJ64aseIPcqKTW+ybUgTLXcXoE+tl4gY5qkDz4IcTZV9+FPlbyF7eX oej/fTkusxi7ELDymslboPgCOS/duoiKELJjNoaQ393KdIRQ2+8WS8KfGWP0xkRz HsQFnnKyd/ULZsNtQd/tXw482OPusZWFylXokhtrWkEnRH1Ym042pDIFPp1xM+QP HlemI0XJ9rpY9PlvrtbX/RowjkE/j1cfR7/d2CMZUq88fDea27o= =ubz4 -END PGP SIGNATURE- diff -Nru ntfs-3g-2016.2.22AR.1/debian/changelog ntfs-3g-2016.2.22AR.1+dfsg.1/debian/changelog --- ntfs-3g-2016.2.22AR.1/debian/changelog 2017-02-01 07:23:28.0 +0100 +++ ntfs-3g-2016.2.22AR.1+dfsg.1/debian/changelog 2017-02-25 16:09:45.0 +0100 @@ -1,3 +1,12 @@ +ntfs-3g (1:2016.2.22AR.1+dfsg.1-0.1) unstable; urgency=medium + + * Non-maintainer upload. + * Repack of source tar file: +Backport ntfsprogs/boot.c file from version 2016.2.22AR.2 (Closes: #808463) + * Update debian/copyright to match boot.c backported to this version. + + -- Jan Luca Naumann Sat, 25 Feb 2017 16:09:45 +0100 + ntfs-3g (1:2016.2.22AR.1-4) unstable; urgency=high * Fix CVE-2017-0358: modprobe influence vulnerability via environment diff -Nru ntfs-3g-2016.2.22AR.1/debian/copyright ntfs-3g-2016.2.22AR.1+dfsg.1/debian/copyright --- ntfs-3g-2016.2.22AR.1/debian/copyright 2016-04-02 18:18:49.0 +0200 +++ ntfs-3g-2016.2.22AR.1+dfsg.1/debian/copyright 2017-02-25 16:09:45.0 +0100 @@ -17,6 +17,16 @@ 2006-2010 Adam Cecile License: GPL-2+ +Files: ntfsprogs/boot.c +Copyright: 1991 Linus Torvalds + 1992-1993 Remy Card + 1993-1994 David Hudson + 1998 H. Peter Anvin + 1998-2005 Roman Hodek + 2008-2014 Daniel Baumann + 2015 Andreas Bombe +License: GPL-3.0+ + License: GPL-2+ This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -50,3 +60,20 @@ . The complete text of the GNU Lesser General Public License can be found in /usr/share/common-licenses/LGPL-2 file. + +License: GPL-3.0+ + This program is free software: you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation, either version 3 of the License, or + (at your option) any later version. + . + This package is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + . + You should have received a copy of the GNU General Public License + along with this program. If not, see <https://www.gnu.org/licenses/>. + . + On Debian systems, the complete text of the GNU General + Public License version 3 can be found in "/usr/share/common-licenses/GPL-3". diff -Nru ntfs-3g-2016.2.22AR.1/ntfsprogs/boot.c ntfs-3g-2016.2.22AR.1+dfsg.1/ntfsprogs/boot.c --- ntfs-3g-2016.2.22AR.1/ntfsprogs/boot.c 2016-02-22 08:34:33.0 +0100 +++ ntfs-3g-2016.2.22AR.1+dfsg.1/ntfsprogs/boot.c 2016-10-01 08:41:58.0 +0200 @@ -1,268 +1,103 @@ -#include "boot.h" +/* + * NTFS bootsector, adapted from the vfat one. + */ -/** - * boot_array - the first 4136 bytes of $Boot +/* mkfs.fat.c - utility to create FAT/MS-DOS filesystems + * Copyright (C) 1991 Linus Torvalds + * Copyright (C) 1992-1993 Remy Card + * Copyright (C) 1993-1994 David Hudson + * Copyright (C) 1998 H. Peter Anvin + * Copyright (C) 1998-2005 Roman Hodek + * Copyright (C) 2008-2014 Daniel Baumann + * Copyright (C) 2015 Andreas Bombe * - * The first 4136 bytes of $Boot. The rest is just zero. Total 8192 bytes. + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * You should have received a copy of the GNU General Public License + * along with this
Bug#844205: [Filesystems-devel] Bug#844205: aufs-dkms: I can't load the kernel module after upgrade from Jessie to Stretch.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hey, 1. In the Debian archive there can be only one version of a package at one time so there will be always only the version compatible to the current kernel version. The upgrades are needed since there are new development in the module and changes in the kernel interfaces. Normally the linux kernel should be already be 4.8. in testing, too, but it seems that there are problems with the package so the aufs was unfortunately faster in testing. 2. There is a snapshot of the version 4.7+20160912-2: http://snapshot.debian.org/package/aufs/4.7%2B20160912-2/ Jan Am 13.11.2016 um 14:06 schrieb Leo: > Hi Jan, thanks a lot for your response! :) > > 2016-11-13 13:34 GMT+01:00 Jan Luca Naumann > mailto:j.naum...@fu-berlin.de>>: > > The current version is packaged for the current unstable kernel, > the problem in this case is that the kernel 4.8 is not migrated to > testing yet. Please wait for the migration (see > https://tracker.debian.org/pkg/linux > <https://tracker.debian.org/pkg/linux> ) and upgrade then to the > kernel 4.8, then the module should be available. > > > I suspected that the problem was this one.. XD > > I don't know exactly how the process "unstable -> testing" works, > but I'd like to make some question: > > 1. why the aufs was upgraded before the kernel? Was the version > for kernel 4.7 broken? > > 2. It's possible to be able to find in the repository also the > previous version (for 4.7)? In order to be able to install the > correct version for the kernel currently available in repository. > > What do you think? Thanks again for your help. > > Best regards, Leonardo Rossi > > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJYKGxHAAoJEH4R1/EZ+XG7YBAQAKnIFCC8vGCuVchZcpYakItu lKYfDz88L1QxunrSyYXAgxl0GsBWZGsG/QBog56Z730EQyPwqn5KkwUNSyTm2Zv8 O1T4anwXKq2hJR92oBnzLtg3+/fOdacdZpwgTXuMjHHw5d50xcAJdfVGPnDBgiq6 YLV8nRzmNResPIXyX5v4/xS/R+tvqY3wSt4hDryRLVuuHgnpMgAeZI9GB29armQY akjwtlt5SAbmXaUa3pcXCAUTD8UFGftQVTI5MDrgwZjBL5wjrPYxpP5ZCK1UHTU9 HuqgCWme6eCcLXLLWyDBQBWW0syqg+nzgcA1MFO8Sh3oPK+8+tZGo/j2d958UmZN UPbH7ga6VscjQom75GdImbDhPXXAYsX7+NaSStbhE2agFAauEVG+vnxKeI5jgWw8 pn8CGcK6yFDy0CR4xFH0iWRxXCDlwj1urf7BLpeokWzoyGhqaa4E9Rc2Fm6cRof3 oxKVpssLeFZmd8XsYOIblXHP4fGDwoxF1vcWKvGq5ymTPXmFNINzJQgvfL3l7R0b qoTtysp5caOzKVVSpHnhocAleFc1d3T+BP8WaNfo8E8rMw3zDvuWdHYcVslXfNa7 XI3mZCiWmawcRVMaXNzno/MkuXeTHrTQ0K+EYFpO7CaU6mg2W40Q5AKTnaWzxAx/ wzotDax8VH6JshoI5dtH =pnWF -END PGP SIGNATURE-
Bug#842682: mp3splt: depending libmp3splt version not available yet (0.7.3 vs 0.9.2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Sorry, forgot to add a description in the message before: The bug should be closed in version 2.6.2-0.1 Best regards, Jan On Mon, 31 Oct 2016 11:39:10 +0100 der_...@opentrash.com wrote: > Package: mp3spltVersion: 2.4.2-2mp3splt in sid depends on version > of libmp3splt0 (<<0.7.3~) that is not longer available in sid > (0.9.2-0.1):#LANG=C apt install -s mp3spltReading package lists... > DoneBuilding dependency tree > Reading state information... DoneSome packages could not be > installed. This may mean that you haverequested an impossible > situation or if you are using the unstabledistribution that some > required packages have not yet been createdor been moved out of > Incoming.The following information may help to resolve the > situation:The following packages have unmet > dependencies: mp3splt : Depends: libmp3splt0 (< 0.7.3~) but > 0.9.2-0.1 is to be installedE: Unable to correct problems, you have > held broken packages. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJYGy/DAAoJEH4R1/EZ+XG7wWsQAI8cYe23AZWj4OZw5enNZ/yp BHqJcJAsOuiEZMfEsYmlO6lUuAD3HZ0rnacvVfSoa4ewmbdPdNAvg5gqNLlNSZdp rkryIRf6PNgDy6YRoSJSgWiWcRdxmB5JAaknfD6nnDtjzE+vda2vsO3eITTjCyt8 hhXekb2wVj/OTUQUpcTJWM0aaAsIim/LbnOI40UfaFiVkutkT4ME0COZJIVVONcT IdLTfrpDIjhA5N7UvrQMrT4E0cQn/Icmj8eezSEA6/fLlSk5E6TeGEYpXXcdLWEv /46h0ZIGcHA5hDE+2VLIWCnHDh+DKWRco0Xwck1jaQ3d1pGjtdnUcAihXP5/GOwZ 0zbRUNUkuqk4VpfhSP4hO1B3rdPeYi74RBOnYbZ0Lm62ab22smvUVYexQXenEGLn a7OOuplhYSc1X2HOTG04gkmN5GpyQnlR+v2B5NzFEVbLkM9JBMvUwG58h4+GsABl Mk/6kaYsD3ANPywhxBsR37Y1pISebYvdE+6U3CYXZCN69r7I2/R8YGrYpXl1Y8NM KlgrYpLnzBCBXl7N9wWxM8X7oMgQttv86LYhzQK8kK6lZFJM9qDREi7HAz0ZPMgk HyrMxSawfSTAoiRFPz6GgJcOwnQUrci8dC9EDfBRESneK9r3ZbP41SqZttC3tRrZ RieLMUIRrBNqfP1a7QR0 =Nz8q -END PGP SIGNATURE-
Bug#842682: closing 842682
close 842682 2.6.2-0.1 thanks
Bug#788513: aufs-tools: FTBFS: linux/aufs_type.h: No such file or directory
Hey. there is already another bug about this topic: https://bugs.debian.org/838632 I already started to prepare a upload to fix this issue. Best regards, Jan > Hey. > > Is it really necessary that the userland tools binary package depends > on the kernel driver package? > > That seems to be rather uncommon among similar packages... > > Cheers, > Chris.
