Bug#955482: mutter aborts with "clutter-offscreen-effect.c:261:clutter_offscreen_effect_pre_paint: code should not be reached"
Package: mutter Version: 3.34.4-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I was using gnome-shell, on wayland, with a terminal, emacs and epiphany (playing a youtube video). Out of the blue, the session broke and got the gdm login screen. I checked the journal and found this Mar 31 15:33:10 miau gnome-shell[1503]: Clutter:ERROR:../clutter/clutter/clutter-offscreen-effect.c:261:clutter_offscreen_effect_pre_paint: code should not be reached Mar 31 15:33:10 miau gnome-shell[1503]: Bail out! Clutter:ERROR:../clutter/clutter/clutter-offscreen-effect.c:261:clutter_offscreen_effect_pre_paint: code should not be reached Mar 31 15:33:10 miau gnome-shell[1503]: == Stack trace for context 0x5627fc97c330 == Mar 31 15:33:10 miau systemd[1]: Created slice system-systemd\x2dcoredump.slice. Mar 31 15:33:10 miau systemd[1]: Started Process Core Dump (PID 21845/UID 0). * What exactly did you do (or not do) that was effective (or ineffective)? I looked for error in mutter's gitlab and found this report which is similar: https://gitlab.gnome.org/GNOME/mutter/-/issues/808 And this merge request that fixes it https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1147 I rebuild the mutter package with this patch, which applied without problems, and now I'm running it. It seems to solve the problem. * What was the outcome of this action? * What outcome did you expect instead? I guess, for debian testing I would either add this patch in the build, or upgrade to 1.36. Thanks :) vmjl *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (500, 'testing-debug'), (500, 'stable'), (102, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mutter depends on: ii gnome-settings-daemon-common 3.36.0-1 ii gsettings-desktop-schemas 3.36.0-1 ii libc6 2.30-2 ii libgles2 1.3.1-1 ii libglib2.0-0 2.64.1-1 ii libmutter-5-0 3.34.4-1 ii libwayland-server01.18.0-1 ii libx11-6 2:1.6.9-2 ii libxcomposite11:0.4.4-2 ii mutter-common 3.34.4-1 ii zenity3.32.0-5 mutter recommends no packages. Versions of packages mutter suggests: ii gnome-control-center 1:3.36.0-1 ii xdg-user-dirs 0.17-2 -- no debconf information
Bug#825833: libkms
On 07/16/16 at 09:46pm, Julien Cristau wrote: > Where can I see that code? Why can't it use libdrm directly? > "embedded" is not an explanation. kmssink in upstream has done that [1] so this action is not required anymore. Thus I'm closing the bug. 1. https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=12e82aac28d0467844233f3cbc9d8ae7c08cd05c
Bug#825833: libkms
On 07/16/16 at 09:46pm, Julien Cristau wrote: > On Sat, Jul 16, 2016 at 10:20:12 +0200, Víctor M. Jáquez L. wrote: > > > On 07/15/16 at 10:33pm, Julien Cristau wrote: > > > On Wed, Jul 6, 2016 at 18:46:32 +0200, ydir...@free.fr wrote: > > > > > > > In fact, it looks like libkms was built in the past, but is explicitely > > > > disabled now. There is probably a reason for this, but there is no more > > > > information than that in the changelog, and no README.Debian. > > > > > > > > Could we please have more insight about why this decision was made ? > > > > > > > libkms wasn't used/useful then, I'd need some convincing to re-enable > > > it. > > > > Perhaps it won't be useful in desktop systems or servers, but, as far as I > > see, it is useful in embedded, if you want to draw without any display > > server. > > > > But I agree, I only have one modest example: kmssink, a simple GStreamer > > video > > sink, targeted precisely to embedded systems. > > > Where can I see that code? Why can't it use libdrm directly? > "embedded" is not an explanation. Here's the code of gstkmssink https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/kms libkms API is used mostly by the buffer allocator: https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/kms/gstkmsallocator.c vmjl
Bug#825833: libkms
On 07/15/16 at 10:33pm, Julien Cristau wrote: > On Wed, Jul 6, 2016 at 18:46:32 +0200, ydir...@free.fr wrote: > > > In fact, it looks like libkms was built in the past, but is explicitely > > disabled now. There is probably a reason for this, but there is no more > > information than that in the changelog, and no README.Debian. > > > > Could we please have more insight about why this decision was made ? > > > libkms wasn't used/useful then, I'd need some convincing to re-enable > it. Perhaps it won't be useful in desktop systems or servers, but, as far as I see, it is useful in embedded, if you want to draw without any display server. But I agree, I only have one modest example: kmssink, a simple GStreamer video sink, targeted precisely to embedded systems. Recently I ended up installing Fedora because it ships libkms. Thanks vmjl signature.asc Description: PGP signature
Bug#825821: ITP: neomutt -- NeoMutt is a place to gather all the patches against Mutt.
On 05/30/16 at 05:53pm, Alberto Garcia wrote: > (I forgot to Cc debian-devel in my previous e-mail) > > > > >NeoMutt is a sophisticated text-based Mail User Agent > > > >supporting MIME, GPG, PGP and threading. > > > >. > > > >NeoMutt was created when Richard Russon (FlatCap) took all > > > >the old Mutt patches, sorted through them, fixed them up and > > > >documented them. > > > > > > Apart from the standard 'mutt' package, there's at least two > > > other packages in Debian with additional patches: 'mutt-kz' and > > > 'mutt-patched'. From the description of this NeoMutt package it > > > looks like it would be a superset of both of them. > > > > > > Is that the case? If so, would you see neomutt replacing mutt-kz > > > and mutt-patched at some point? > > > > I would see that neomutt is a good successor for mutt-patched. As > > far as I understood Richard correct, neomutt includes the notmuch > > feature from mutt-kz and superseded mutt-kz more or less. There will > > be a git branch at neomutt where all Debian specific patches will > > be incoperated and therefor both mutt and neomutt packages will be > > much easier to maintain. Bugs introduced from neomutt's additional > > features can be handled directly, because we don't have to maintain > > a patch. We have to maintain a feature. > > Ok, thanks. I don't know the opinion of the mutt-kz and mutt-patched > maintainers but if this one can be the successor of both I guess it > can make sense to have them replaced by neomutt at some point. I agree. If neomutt is packaged, mutt-patched and mutt-kz packages should be deprecated. vmjl > > I put them in Cc in case they want to say something before neomutt is > packaged. > > Regards, > > Berto >
Bug#822810: mutt-kz: pgp_decryption_okay: unknown variable
On 04/27/16 at 11:31pm, Jakub Wilk wrote: > Control: tags -1 + fixed-upstream > > * Víctor M. Jáquez L. <vjaq...@igalia.com>, 2016-04-27, 22:11: > > > I'm getting these errors every time I run mutt-kz: > > > > > > Error in /etc/Muttrc.d/gpg.rc, line 15: pgp_decryption_okay: unknown > > > variable > > > Error in /usr/lib/mutt/source-muttrc.d|, line 4: source: errors in > > > /etc/Muttrc.d/gpg.rc > > > Error in /etc/Muttrc.d/smime.rc, line 71: smime_sign_digest_alg: unknown > > > variable > > > Error in /usr/lib/mutt/source-muttrc.d|, line 5: source: errors in > > > /etc/Muttrc.d/smime.rc > > > Error in /etc/Muttrc, line 133: source: errors in > > > /usr/lib/mutt/source-muttrc.d| > > > source: errors in /etc/Muttrc > > > > > > > > > Apparently the new mutt (1.6.0) added some configuration variables > > > that mutt-kz doesn't grok. > > > > Can you grab my latest upload from mentors? > > > > http://mentors.debian.net/package/mutt-kz > > > > Would be great if you can test it. > > Thanks, 1.6.0.1-1 fixed it for me. > > Although I wonder if dependency on mutt shouldn't be stricter, e.g.: > > mutt (>= 1.6.0), mutt (<< 1.6.1) I'm not sure since right now I'm using mutt-kz 1.6 while keeping mutt 1.5.24 and works. vmjl
Bug#822810: mutt-kz: pgp_decryption_okay: unknown variable
On 04/27/16 at 08:37pm, Jakub Wilk wrote: > Package: mutt-kz > Version: 1.5.23.1-7 > > I'm getting these errors every time I run mutt-kz: > > Error in /etc/Muttrc.d/gpg.rc, line 15: pgp_decryption_okay: unknown variable > Error in /usr/lib/mutt/source-muttrc.d|, line 4: source: errors in > /etc/Muttrc.d/gpg.rc > Error in /etc/Muttrc.d/smime.rc, line 71: smime_sign_digest_alg: unknown > variable > Error in /usr/lib/mutt/source-muttrc.d|, line 5: source: errors in > /etc/Muttrc.d/smime.rc > Error in /etc/Muttrc, line 133: source: errors in > /usr/lib/mutt/source-muttrc.d| > source: errors in /etc/Muttrc > > > Apparently the new mutt (1.6.0) added some configuration variables that > mutt-kz doesn't grok. Can you grab my latest upload from mentors? http://mentors.debian.net/package/mutt-kz Would be great if you can test it. vmjl
Bug#821951: mutt-kz: text/plain attachment output truncated after null byte
On 04/20/16 at 08:32pm, Jakub Wilk wrote:
> Package: mutt-kz
> Version: 1.5.23.1-7
> Tags: security
>
> The attached program calls "apt-get moo", but when viewed in mutt's builtin
> pager, it looks like a hello world program:
The very same happens with the original mutt (mutt-org). Thous, this issue
belongs to mutt and all its flavors.
>
> #include
> #include
>
> int main(int argc, char **argv)
> {
> /* Copyright © 2016 Jakub Wilk
>*/
> printf("Hello world!\n");
> return 0;
> }
>
>
> Curiously, AFAICS this doesn't happen for other text/* media types.
>
>
> -- System Information:
> Debian Release: stretch/sid
> APT prefers unstable
> APT policy: (990, 'unstable'), (500, 'experimental')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
>
> Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages mutt-kz depends on:
> ii libassuan02.4.2-3
> ii libc6 2.22-7
> ii libcomerr21.43~WIP.2016.03.15-2
> ii libgnutls30 3.4.11-3
> ii libgpg-error0 1.21-2
> ii libgpgme111.6.0-1
> ii libgssapi-krb5-2 1.13.2+dfsg-5
> ii libidn11 1.32-3
> ii libk5crypto3 1.13.2+dfsg-5
> ii libkrb5-3 1.13.2+dfsg-5
> ii libncursesw5 6.0+20160319-1
> ii libnotmuch4 0.21-3+b1
> ii libsasl2-22.1.26.dfsg1-15
> ii libtinfo5 6.0+20160319-1
> ii libtokyocabinet9 1.4.48-10
> ii mutt 1.5.24-1+b1
> #include
> #include
>
> int main(int argc, char **argv)
> {
> /* Copyright © 2016 Jakub Wilk
>*/
> printf("Hello world!\n");
> return 0;
> }
Bug#812953: Include complete patch list in -v output
On 03/06/16 at 11:08pm, Alberto Garcia wrote: > On Sat, Mar 05, 2016 at 01:32:32PM +0100, Alberto Garcia wrote: > > > > CVE-2014-9116 is already fixed in in mutt-kz since release > > > 1.5.23.1-2 > > > > Ok, thanks. > > > > I think the package looks good, I would just ask you to edit the > > changelog add a brief description of the new patches and/or the ones > > that changed. > > Never mind, it looks like Micha already uploaded the package :) Indeed. Thanks Micha. I have in my todo for the next release ;) Thanks! vmjl
Bug#812953: Include complete patch list in -v output
Hi Berto, Sorry for the late reply On 02/26/16 at 12:37pm, Alberto Garcia wrote: > On Tue, Feb 09, 2016 at 02:45:37PM +0100, Víctor M. Jáquez L. wrote: > > > > Package: mutt-kz > > > Version: 1.5.23.1-6+b1 > > > Severity: wishlist > > > > > > The -kz version's -v output contains *less* patches than the > > > corresponding mutt-proper binary. Could you please ensure that the > > > list of patches in -v output corresponds with reality? > > > > > > > Thanks for reporting this. > > > > I already fixed it: > > > > https://gitlab.com/vjaquez-misc/mutt-kz/commit/de32bdc4b7d16b25dae5a41298fcd4cdbafb2132 > > In this release you also include a patch for CVE-2014-9116: > > https://gitlab.com/vjaquez-misc/mutt-kz/commit/19b08ac7f62f5925e832b8fdb396a1a08d824668 > > Can you clarify the situation with this? Is mutt-kz vulnerable to that > security bug? > CVE-2014-9116 is already fixed in in mutt-kz since release 1.5.23.1-2 $ git describe 2fe19d5 v1.5.23.1-rc1-25-g2fe19d5 The included patch for mutt in jessie is interesting too because it can block other possible attacks of this type as far as I understand. vmjl
Bug#812953: Include complete patch list in -v output
On 01/28/16 at 03:41pm, martin f krafft wrote: > Package: mutt-kz > Version: 1.5.23.1-6+b1 > Severity: wishlist > > The -kz version's -v output contains *less* patches than the > corresponding mutt-proper binary. Could you please ensure that the > list of patches in -v output corresponds with reality? > Thanks for reporting this. I already fixed it: https://gitlab.com/vjaquez-misc/mutt-kz/commit/de32bdc4b7d16b25dae5a41298fcd4cdbafb2132 And uploaded a new version to debian-mentors: http://mentors.debian.net/package/mutt-kz vmjl signature.asc Description: PGP signature
Bug#794124: mutt-kz: F1 - /usr/share/doc/mutt/manual.txt.gz: No such file or directory
On 08/02/15 at 03:45pm, Jakub Wilk wrote: * Víctor M. Jáquez L. vjaq...@igalia.com, 2015-08-02, 15:28: I can't use the help function (F1), because it tries to open nonexistent file: gzip: /usr/share/doc/mutt/manual.txt.gz: No such file or directory I'm not sure, but I think this bug belongs to mutt package, I don't think so. :) mutt manages /usr/share/doc/mutt/manual.txt.gz via alternatives: Ouch! Very true! Thanks! update-alternatives --install /usr/bin/mutt mutt /usr/bin/mutt-org 50 \ --slave /usr/share/man/man1/mutt.1.gz mutt.1.gz /usr/share/man/man1/mutt-org.1.gz \ --slave /usr/share/man/man5/muttrc.5.gz muttrc.5.gz /usr/share/man/man5/muttrc-org.5.gz \ --slave /usr/share/doc/mutt/html mutt-doc-html /usr/share/doc/mutt/html-org \ --slave /usr/share/doc/mutt/manual.txt.gz mutt-doc-manual /usr/share/doc/mutt/manual-org.txt.gz But mutt-kz doesn't have --slave for this file: update-alternatives --install /usr/bin/mutt mutt /usr/bin/mutt-kz 60 \ --slave /usr/share/man/man1/mutt.1.gz mutt.1.gz /usr/share/man/man1/mutt-kz.1.gz \ --slave /usr/share/man/man5/muttrc.5.gz muttrc.5.gz /usr/share/man/man5/muttrc-kz.5.gz vmjl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794124: mutt-kz: F1 - /usr/share/doc/mutt/manual.txt.gz: No such file or directory
On 07/30/15 at 09:35pm, Jakub Wilk wrote: Package: mutt-kz Version: 1.5.23.1-5 I can't use the help function (F1), because it tries to open nonexistent file: gzip: /usr/share/doc/mutt/manual.txt.gz: No such file or directory I'm not sure, but I think this bug belongs to mutt package, since that macro is defined in /etc/Muttrc and the manual is in /usr/share/doc/mutt/manual-org.txt.gz, and both files are part of the mutt package. How do I reassign bugs to another package? vmjl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794124: mutt-kz: F1 - /usr/share/doc/mutt/manual.txt.gz: No such file or directory
On 07/30/15 at 09:35pm, Jakub Wilk wrote: Package: mutt-kz Version: 1.5.23.1-5 I can't use the help function (F1), because it tries to open nonexistent file: gzip: /usr/share/doc/mutt/manual.txt.gz: No such file or directory https://gitlab.com/vjaquez-misc/mutt-kz/commit/11c40365909e65e5f321da8929b7c43f8bf7ad88 Does it look good? vmjl -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mutt-kz depends on: ii libassuan0 2.2.1-1 ii libc6 2.19-19 ii libcomerr2 1.42.13-1 ii libgnutls-deb0-28 3.3.16-1 ii libgpg-error0 1.19-2 ii libgpgme11 1.5.5-3 ii libgssapi-krb5-2 1.13.2+dfsg-2 ii libidn11 1.31-1 ii libk5crypto3 1.13.2+dfsg-2 ii libkrb5-3 1.13.2+dfsg-2 ii libncursesw5 5.9+20150516-2 ii libnotmuch40.20.2-1 ii libsasl2-2 2.1.26.dfsg1-13 ii libtinfo5 5.9+20150516-2 ii libtokyocabinet9 1.4.48-3 ii mutt 1.5.23-3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793497: mutt-kz: Package description far too similar to the one of mutt
Thanks a lot for your review. I have a question: Shall I upload to mentors again the modified package? o shall I attach the patches here? vmjl On 07/24/15 at 06:00pm, Axel Beckert wrote: Package: mutt-kz Version: 1.5.23.1-5 Severity: normal Hi, the long package description of mutt-kz only differs by one added list item from the one from mutt (* Not much integration). Please explain explicitly what's the difference to mutt and maybe also what's the difference to notmuch-mutt. I also suggest to change the first line of the long package description from Mutt is a sophisticated text-based Mail User Agent to Mutt-KZ is fork of Mutt, a sophisticated text-based Mail User Agent, which additionally provides ... or similar. Please also use a different short package description. It's currently _identical_ to the one from mutt. Additionally you should write the name of notmuch without a blank: Use Notmuch integration instead of Not much integration. See also the package description of the package notmuch. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mutt-kz depends on: ii libassuan0 2.2.1-1 ii libc6 2.19-19 ii libcomerr2 1.42.13-1 ii libgnutls-deb0-28 3.3.16-1 ii libgpg-error0 1.19-2 ii libgpgme11 1.5.5-3 ii libgssapi-krb5-2 1.13.2+dfsg-2 ii libidn11 1.31-1 ii libk5crypto3 1.13.2+dfsg-2 ii libkrb5-3 1.13.2+dfsg-2 ii libncursesw5 5.9+20150516-2 ii libnotmuch40.20.2-1 ii libsasl2-2 2.1.26.dfsg1-13 ii libtinfo5 5.9+20150516-2 ii libtokyocabinet9 1.4.48-3 ii mutt 1.5.23-3 mutt-kz recommends no packages. mutt-kz suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695878: new mutt-kz package
On 06/16/15 at 02:12pm, Alberto Garcia wrote: On Tue, Jun 16, 2015 at 11:40:03AM +0200, Víctor M. Jáquez L. wrote: Following Berto's recommendation, I repackaged mutt-kz as a mutt's alternative. I had to rebase several patches applied to mutt and it seems to work OK. Last Saturday I uploaded the package again: http://mentors.debian.net/package/mutt-kz The checksums don't match, you need to create and upload again all files every time you change something. The dscverify tool will help you with that. OK. My opinion is that some of the headers should not be included: Recommends: default-mta | mail-transport-agent, locales, mime-support, libsasl2-modules Suggests: urlview, aspell | ispell, gnupg, mixmaster, openssl, ca-certificates Conflicts: mutt-utf8 Replaces: mutt-utf8 Provides: imap-client, mail-reader mutt-kz has a hard dependency on mutt, and mutt already includes those headers, so there's no need to duplicate them here. Yes. It makes sense. Other than that, the package looks much better now. I still haven't checked all little details, though, but I think this is almost ready for uploading. Do we have an ITP bug for mutt-kz? I haven't found it. I haven't posted a ITP bug. I'll do it. Thanks Berto! vmjl Berto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695878: new mutt-kz package
Following Berto's recommendation, I repackaged mutt-kz as a mutt's alternative. I had to rebase several patches applied to mutt and it seems to work OK. Last Saturday I uploaded the package again: http://mentors.debian.net/package/mutt-kz vmjl On 06/11/15 at 09:46am, Alberto Garcia wrote: On Mon, Jun 08, 2015 at 11:03:09AM -0400, Antoine Beaupré wrote: The problem I see, and I'm not sure how to solve it, is that mutt and mutt-kz are mutually exclusive, they cannot be both installed. What is the problem exactly here? Shared libraries? As far as I can see there's several duplicate files (/usr/bin/mutt_dotlock, /usr/bin/smime_keys, /usr/lib/mutt/*, ...) If they are the same as in the original mutt package, I guess the solution is to do what the mutt-patched package does: ship only the main executable, register it using the alternatives method and make the package depend on mutt: https://packages.debian.org/sid/amd64/mutt-patched/filelist Berto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695878: new mutt-kz package
On 05/19/15 at 09:02pm, Antoine Beaupré wrote: That you do! :) A good way to start is to upload your package to mentors.debian.net and check the results there: https://mentors.debian.net/ Finally I did it last weekend: Your upload of the package 'mutt-kz' to mentors.debian.net was successful. Others can now see it. The URL of your package is: http://mentors.debian.net/package/mutt-kz We could argue about using upstream/debian mutt instead of a different package. I did it for a while, but at some point both projects diverged so much, that it was easier for me to make a new package rather than keeping an humongous list of patches. Nonetheless, I'm open to any alternative. well, i think the point here is more to consult with the current mutt maintainer and the ftp masters. the contact for the current maintainer is Antonio Radici (in CC). Antonio, what do you think about this package? The problem I see, and I'm not sure how to solve it, is that mutt and mutt-kz are mutually exclusive, they cannot be both installed. vmjl The ftp masters can be reached at ftpmas...@debian.org or #debian-ftp on irc.debian.org (OFTC). cheers! a. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695878: new mutt-kz package
On 05/14/15 at 08:09am, Antoine Beaupré wrote: Also I will sync to v1.5.23.1 I expect to do it this weekend. Done! Great! Did you mean gitlab though? There's already this: https://gitlab.com/vjaquez-misc/mutt-kz gitorious can migrate to gitlab automatically and gitlab open sources at least *part* of its production software, which i think makes it good alternative to the proprietary github... Thanks for the heads-up. Finally I used gitlab: https://gitlab.com/vjaquez-misc/mutt-kz vmjl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695878: new mutt-kz package
On 05/15/15 at 08:18am, Antoine Beaupré wrote: On 2015-05-15 07:27:04, Víctor M. Jáquez L. wrote: Thanks for the heads-up. Finally I used gitlab: https://gitlab.com/vjaquez-misc/mutt-kz That's great! :) So what's the next step here... do you need someone to sponsor the package? Should more communication be done with upstream/debian mutt? a. I don't know what's next. I'm a total newbie. Do I need a sponsor to upload a new package? If so, yes, I need one :) We could argue about using upstream/debian mutt instead of a different package. I did it for a while, but at some point both projects diverged so much, that it was easier for me to make a new package rather than keeping an humongous list of patches. Nonetheless, I'm open to any alternative. vmjl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695878: new mutt-kz package
On 05/13/15 at 10:19pm, anar...@debian.org wrote: On Sun, Sep 07, 2014 at 10:43:26PM +0200, Stefano Zacchiroli wrote: Heya, +1 as well on the desire of having mutt-kz in Debian. +1 as well... Has anyone verified with the security team if either approach would be acceptable for them? What's the opinion of the Mutt maintainer on the two approaches? No idea about either, but either upload should probably close #698672 (the RFP for mutt-kz I opened without knowing about this bug) when done. I'd be curious to hear if there is any progress here as well now... I'm going to migrate the repository into github since gitorious is going to disappear. Also I will sync to v1.5.23.1 I expect to do it this weekend. vmjl Cheers! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762579: gstreamer1.0-vaapi: Does not work at all (with totem)
On Tue, 2014-09-23 at 12:50 +0200, Julian Andres Klode wrote:
Package: gstreamer1.0-vaapi
Version: 0.5.9-2
Severity: important
Trying to play back a simple MP4 movie with H.264 video and AAC audio,
does not work at all. Only displays an error.
I found that running
$ gst-launch-1.0 playbin uri=file://location of the file
video-sink=cluttersink audio-filter=scaletempo flags=0x17
which is the pipeline handled by totem[1] but with no de-interlace and no
color balance by software, it works fairly OK.
Sadly, it is not straightforward to set this flags in totem.
I cooked a hackish patch for this use-case, which modifies the playbin
(gst-plugins-base1.0 source package), enabling the flags setting through the
environment variable GST_PLAYBIN_FLAGS
Then you could run the
$ GST_PLAYBIN_FLAG=0x17 totem location of the file
vmjl
1. https://wiki.gnome.org/Apps/Videos/BugReporting
--- a/gst/playback/gstplaysink.c
+++ b/gst/playback/gstplaysink.c
@@ -3786,8 +3786,23 @@ no_chain:
gboolean
gst_play_sink_set_flags (GstPlaySink * playsink, GstPlayFlags flags)
{
+ const gchar *env;
+
g_return_val_if_fail (GST_IS_PLAY_SINK (playsink), FALSE);
+ env = g_getenv (GST_PLAYBIN_FLAGS);
+ if (env) {
+gulong newflags;
+int olderrno;
+
+olderrno = errno;
+errno = 0;
+newflags = strtoul (env, NULL, 0);
+if (errno == 0 newflags = ((1 12) - 1))
+ flags = (GstPlayFlags) newflags;
+errno = olderrno;
+ }
+
GST_OBJECT_LOCK (playsink);
playsink-flags = flags;
GST_OBJECT_UNLOCK (playsink);
Bug#748657: [bug #42390] fopen-fail fails on Debian GNU/Linux unstable
The problem is, if I understand it correctly, the timeout value: By default the test timeout (tests/test_driver.pl) is 5 seconds, but in this particular test, the timeout is reached before hitting the too many open files error, which is the expected error. This is the case when the computer is not under a heavy load. I changed the variable $test_timeout from 5 to 300 and I could build the package smoothly. # Timeout in seconds. If the test takes longer than this we'll fail it. $test_timeout = 300; The proper fix would be to run the fopen-fail test without timeout. vmjl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695878: new mutt-kz package
I used to maintain a fork of the mutt debian package[1], handling the mutt-kz patches with quilt. Trying to resync this weekend the patches, I found that the sources have diverted so much, that this strategy is not practical anymore. So, I've setup a debian packaging for mutt-kz using git-buildpackage[2]. You can build it with this command: DEB_BUILD_OPTIONS=parallel=4 gbp buildpackage --git-upstream-tree=v1.5.22.1-rc1 1. https://gitorious.org/vjaquez-misc/mutt 2. https://gitorious.org/vjaquez-misc/mutt-kz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
