Bug#1052674: ITS: mu-editor

Package: mu-editor Version: 1.2.1-1 Severity: important X-Debbugs-Cc: ni...@debian.org I'd like to get an updated version of this application into the archive; it's been a year since the last upload and upstream has moved from version 1.0 to version 1.2 with significant improvements and bug

Bug#1023020: cmark-gfm: FTBFS on s390x

Scott Talbert writes: > On Wed, 30 Nov 2022, Keith Packard wrote: > >> Scott Talbert writes: >> >>> @Keith, do you have time to upload this patch? Unfortunately, this is >>> blocking a large number of packages from migrating to testing. >>> Alternat

Bug#1023020: cmark-gfm: FTBFS on s390x

Scott Talbert writes: > @Keith, do you have time to upload this patch? Unfortunately, this is > blocking a large number of packages from migrating to testing. > Alternatively, any objections to an NMU? Thanks for the NMU! Did you happen to create a git repo with this change? I just noticed

Bug#1023020: cmark-gfm: FTBFS on s390x

Scott Talbert writes: > @Keith, do you have time to upload this patch? Unfortunately, this is > blocking a large number of packages from migrating to testing. > Alternatively, any objections to an NMU? I didn't get to this today, and might not until thursday or friday. Happy for your to NMU

Bug#1021193:

I looked for exactly this bug as I fixed the same issue in binutils-riscv-unknown-elf today, but somehow I missed it. This should be fixed in version 18 by using dpkg-query instead of hand-hacked shell bits: upstream_version := $(shell dpkg-query -W -f="\$${source:Upstream-Version}\n"

Bug#1014619: libstdc++-arm-none-eabi: dpkg-buildflags leak into target build

> One way to solve this would be to set DEB_BUILD_OPTIONS=optimize=-lto, to > exclude the LTO flags specifically so that they don't leak into the target > builds. Another thought I had was to use the dpkg-buildflags for armhf as a > target architecture, since there could be other per-arch flags

Bug#1010175: ITP: ruby-prawn-templates -- Prawn::Templates allows using PDFs as templates in Prawn

Package: wnpp Severity: wishlist Owner: Keith Packard X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Ruby Extras Maintainers * Package name: ruby-prawn-templates Version : 0.1.2 Upstream Author : Gregory Brown * URL : https://github.com/prawnpdf/prawn

Bug#1004058: RM: libnewlib-nano -- ROM; Obsoleted by picolibc. Has numerous open security and RC issues.

Package: ftp.debian.org Severity: normal

Bug#979542: gcc-riscv64-unknown-elf: Unable to use stdint.h

Joel Stanley writes: > Package: gcc-riscv64-unknown-elf > Version: 8.3.0.2019.08+dfsg-1 > Severity: normal > > Dear Maintainer, > > I am trying to use the riscv toolchain to build a bare metal > application. It appears to have a broken stdint.h: You might try using picolibc instead of newlib;

Bug#981220: gcc-xtensa-lx106: libgcc doesn't contain soft float functions

Package: gcc-xtensa-lx106 Version: 10.2.1-3+8 Severity: normal X-Debbugs-Cc: kei...@keithp.com It seems that libgcc built for this toolchain is missing the soft float emulation functions? This program fails to link: cat > test.c << EOF #include #include #include int main(void) {

Bug#978636: move to merged-usr-only?

Simon McVittie writes: > Should we be more specific than this in what we vote on, to avoid > later having to adjudicate between developers who say that a particular > implementation is or isn't merged-usr? I think that and a transition plan are both key to this project. I recently installed

Bug#980086: broken autopkg test, no aarch64 cross targets on armhf.

Matthias Klose writes: > This blocks migration of gcc-defaults, there is no aarch64 cross > target on armhf. Suggestions on how to work around this welcome; I really don't know what to do. I want to continue providing the generated binaries on all architectures, but we appear to need to

Bug#974011: xmille: Incorrect license/copyright for xmille

Adrian Bunk writes: > I am just a normal user enjoying the game, and looking at the number of > uploads in the past decade two maintainers might be sufficient to handle > the load. ;-) I've uploaded 'kgames' to the new queue :-) Thanks for playing. -- -keith signature.asc Description:

Bug#978412: src:picolibc: fails to migrate to testing for too long: maintainer built arch:all binaries

Paul Gevers writes: > Your package is only blocked because the arch:all binary package(s) > aren't built on a buildd. Unfortunately the Debian infrastructure > doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will > shortly do a no-changes source-only upload to DELAYED/15,

Bug#974011: xmille: Incorrect license/copyright for xmille

Steven Robbins writes: > On Saturday, December 26, 2020 12:50:58 A.M. CST Keith Packard wrote: > >> I've tagged version '1.0' of this repository and created some (not >> finished) debian packaging for it. This version has imported the mille >> sources from 'upstream'

Bug#974011: xmille: Incorrect license/copyright for xmille

Keith Packard writes: > This package includes a bunch of games using a shared widget library, > including a raft of solitaire, another (not terribly good) reversi > implementation and even a version of dominoes. Having this build only > xmille would be fairly easy. If tha

Bug#974011: xmille: Incorrect license/copyright for xmille

Adrian Bunk writes: > On Mon, Dec 07, 2020 at 09:12:23AM -0800, Keith Packard wrote: >> Adrian Bunk writes: >> > >> > Keith, do you remember the copyright history of this code? >> >> I may have copied the underlying mille sources *before* copyrights wer

Bug#974011: xmille: Incorrect license/copyright for xmille

Ryan Armstrong writes: > I just did a bit of digging, since I previously had a 2.11 BSD VM set up > in SIMH (fun!). It looks like the version of mille in that release was > indeed from about the 1985/1986 time frame, and the copyright headers > were not yet added. So that makes much more

Bug#974011: xmille: Incorrect license/copyright for xmille

Adrian Bunk writes: > On Sun, Nov 08, 2020 at 07:06:52PM -0500, Ryan Armstrong wrote: >>... >> I have been researching old terminal and X games recently, and realized >> that much of the code from 'xmille' orignated from the terminal game >> 'mille', which is part of bsdgames. >> >>

Bug#976405: Bug#976535: Bug#976495: also happens on amd64, should be worked around by 1.8.20-5 but the real fix will come with 1.8.20-6

Lucas Nussbaum writes: > There was a texlive update in the meantime. Here are the versions of > packages that differ. I explored this a bit today -- there's something quite amiss with the docbook toolchain. I'm seeing a lot of this error: ! Undefined control sequence.

Bug#958110: nickle: please make the build reproducible

"Chris Lamb" writes: > Dear Maintainer, > >> Source: nickle >> Version: 2.77-1 >> Tags: patch > > There hasn't seem to be any update on this bug in 135 days, in which > time the Reproducible Builds effort has come on a long way. > > Would you consider applying this patch and uploading? So sorry

Bug#956253: mu-editor 1.0.3 packaged (with bonus features)

Nick Morrott writes: > There is a bug report asking for 1.1.alpha to be packaged [1], so I > think a sensible plan might be to get a mildly-patched 1.0.3 into > unstable and then consider uploading the current alpha into > experimental? I had packaged 1.1.alpha, which has a number of useful

Bug#960866: libnewlib-nano FTBFS with meson 0.54.2-1

Adrian Bunk writes: > Source: libnewlib-nano > Version: 2.11.2-1 > Severity: serious > Tags: ftbfs bullseye sid > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libnewlib-nano.html The correct fix is to get picolibc out of the new queue so I can finish removing this

Bug#952637: Close bug 952637

Pirate Praveen writes: > On Mon, 09 Mar 2020 12:41:41 -0700 kei...@keithp.com ("Keith Packard") wrote: >> >> Source: ruby-asciidoctor-pdf >> Version: 1.5.3-1 >> >> Updated gemspec dependency on concurrent-ruby to ~> 1.1.0 which matches

Bug#951306: snek: unsatisfiable b-d on picolibc-arm-none-eabi

Ralf Treinen writes: > snek build-depends on picolibc-arm-none-eabi which does not exist (yet) > in sid. Yup. It's been stuck in the 'new' queue for several months now. -- -keith signature.asc Description: PGP signature

Bug#925202: Keep calypso out of testing/buster

Ivo De Decker writes: > I added a removal hint to get it out of testing. I saw that after I uploaded 2.0-1... I'd been meaning to get back to calypso for quite a while but got stuck because the various Python2 dependencies were no longer supported and yet some were not yet available for

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Alexander Larsson writes: > Yeah, assuming there is no global default salt that messes this up. It sounds like having 'salt' values in dir and remap-dir elements is what we want then -- no need for separate salt elements. -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Alexander Larsson writes: > We don't want a global salt for everything in the container. I guess I wonder why not? Salt + dir inside the container will always be unique. The place where you want to have different salt is for directories mapped from the host; I think those will always be in

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Alexander Larsson writes: > As I said in an earlier email, it needs to be in the individual dir > elements, because a global salt is not right. Do you want it in the elements directly? That would be more straightforward in many ways and could avoid troubles with separate salt declarations that

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH writes: > Yep, that looks good to me. I don't time this week to hack on the code, and it looks like you're doing great anyways; let me know if you need help in any way with the implementation work. -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH writes: > Hm, to deal with more complicated cases, I guess we may need to have > one global salt to affect everything and a path-specific salt for > remapped path. Or, more likely, no salt at all for the outermost layer as it doesn't really add anything here. > for flatpak case,

Bug#920956: ITP: fonts-recommended -- set of recommended fonts

Adam Borowski writes: > Fonts people: as the first stab, I'll upload my picks with Fabian's input, > then let's have a flamewar. Can you point us at the proposed list? -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH writes: > Hi, > > We are still missing a piece of a salt to deal with a directory name > separately where possibly have different fonts in sandbox etc. my tree > based on Keith's previous implementation works and passed test cases > except this salt thing: > >

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH writes: > Sure. I started to implement it based on Keith's branch. Awesome. I'll be back home "tomorrow" and able to spend some time on this next week. -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Alexander Larsson writes: $ cat /run/host/font-dirs.xml > > > > /run/host/fonts > /run/host/user-fonts > > > Is this format acceptable? Its mostly about naming the nodes and the > attributes, so its basically trivial. If you want i can rename things > or change orders, but I'd really

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH writes: > Keith, > > I'm fine with it. do you have a time to work on it? or already started > working? > If not, please let me know. I've been at a conference all week, but hope to have time next week. Would be happy to see others get this started, or collaborate in any way. If I

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Alexander Larsson writes: > Ugh. Sorry about that! Thanks. Bugs happen, fortunately I was able to track this one down and fix it (we all love free software!) > Yes:ish. It should not *normally* happen. But you may run into it in > uncommon situations like e.g. chrome using a statically linked

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Alexander Larsson writes: >> I also fought with fontconfig for about a week when the release >> including them was installed on my machine as firefox would spin >> whenever it found a directory with no fonts. At the time, I felt injured >> by this change. > > Hmm, why was it doing that though?

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Alexander Larsson writes: > I'd like to repeat that this is not really flatpak specific as such. > The issue can happen in multiple cases like nfs mounts, multi-boot > systems, docker containers, etc. Sure, any place where path names are not the same would cause the same issue. I think your

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH writes: > Indeed, that would be able to accomplish both with the minimal efforts > for us at least. though they might came up with this but they didn't > do it that way. so there might be some reason why they didn't do so. > packaging issue perhaps? flatpak appears to change many

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH writes: > As of the discussion on the list, Keith's changes doesn't address the > original purpose - allow sharing caches on bind-mounts in flatpaks. > particularly for the case where flatpaks uses same location in > sandbox. I'm probably forgetting a bunch of context here, but I

Bug#906785: version warping patch is overly aggressive

Markus Koschany writes: > I'm waiting for Emmanuel to chime in now. Maybe I missed something > important. Otherwise I think we can resolve this issue rather quickly. > Since Ant isn't the only build system for Java, we probably should > change this for Maven too. We haven't implemented the same

Bug#864082: fontconfig: please make the cache files reproducible

Chris Lamb writes: > Chris Lamb wrote: > >> This was merged into the upstream Git repository - would it be >> possible to make another Debian release with this change? :) > > Gentle ping on this? :) Would love to see this Tails-related work > in Debian! I was stalling for an upstream release

Bug#882444: xrandr doesn't select DoubleScan modes by name without refresh rate

This bug is caused by a change made in 2009 where xrandr ignores DoubleScan modes unless the user has specified a refresh rate. I don't know what this wanted to fix, so I'm hesitant to fix it. However, a reasonable workaround for the user is to simply specify a non-zero refresh rate. -- -keith

Bug#864082: fontconfig: please make the cache files reproducible

Chris Lamb writes: > Hi Keith, > >> > +source_date_epoch = getenv("SOURCE_DATE_EPOCH"); >> >> Could this work as a build-time value in the library instead of a >> run-time environment variable? > > Unfortunately not. Imagine the situation where we are installing > font

Bug#864082: fontconfig: please make the cache files reproducible

Chris Lamb writes: > +source_date_epoch = getenv("SOURCE_DATE_EPOCH"); Could this work as a build-time value in the library instead of a run-time environment variable? -- -keith signature.asc Description: PGP signature

Bug#894271: ITP: cmark-gfm -- GitHub enhanced version of cmark, the common markdown parser

Package: wnpp Severity: wishlist Owner: Keith Packard <kei...@debian.org> * Package name: cmark-gfm Version : 0.28.3.gfm.12 Upstream Author : John MacFarlane <j...@berkeley.edu> * URL : https://ithub.com/github/cmark * License : BSD, MIT/X Program

Bug#890973: ITP: xorgproto -- X11 extension protocols and auxiliary headers

Timo Aaltonen writes: > Package: wnpp > Severity: wishlist > Owner: Timo Aaltonen > > * Package name: xorgproto > Version : 2018.3 > Upstream Author : X.Org > * URL : http://www.x.org/ > * License : MIT/X >

Bug#880014: #880014: Call for Votes for new TC member

Didier 'OdyX' Raboud writes: > ===BEGIN > The Technical Committee recommends that Gunnar Wolf be > appointed by the Debian Project Leader to the Technical Committee. > > G: Recommend to Appoint Gunnar Wolf > F: Further Discussion > ===END I

Bug#877024: Modemmanager probing of unknown Devices

Ian Jackson writes: > I intend to carry on and try to help do the Debian part of this, with > NMUs as seem appropriate. My earlier email suggesting an upload to > experimental is part of that. If the modemmanager maintainers would > like to step in then that

Bug#877024: modemmanager should ask before messing with serial ports

Sam Hartman writes: > Have I got that right? Yes, I think you have summarized the issue accurately. > However, for Debian and for the Technical committee, we need to consider > what experience we want to give all our users and as a result value > damage caused by false

Bug#877024: modemmanager should ask before messing with serial ports

Ian Jackson writes: > This has gone far enough. I would like to remind you of Constitution > 6.3(5) Here's what I prefaced my first remark with: (speaking as a Debian user, not as a TC member) Perhaps I should have added this to each message I sent? --

Bug#877024: modemmanager should ask before messing with serial ports

Ian Jackson writes: > But I should be able to use the same laptop to (1) control my machine > tools or talk to my rpi or whatever (2) go online with a usb mobile > modem when I'm out of the house. Possibly even simultaneously. That requires fixing the package

Bug#877024: modemmanager should ask before messing with serial ports

Ian Jackson writes: > Also, AIUI modemmanager contains code to do things with the new-style > MBIM dongles (which can also be done with the cli tools in > mbim-utils). But I definitely wouldn't suggest disabling its ability > to work with AT-command modems, as

Bug#877024: modemmanager should ask before messing with serial ports

Ian Jackson writes: (speaking as a Debian user, not as a TC member) > I'm afraid don't really want to do the work of writing a better UI. > But I have provided a simple patch which at least makes the behaviour > safe. Would it be sufficient to simply stop

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

Tollef Fog Heen writes: > R: Approve resolution and repeal the CTTE decision from 2012-07-12. > F: Further Discussion I vote R > F -- -keith signature.asc Description: PGP signature

Bug#865485: Voting for TC Chair

Didier 'OdyX' Raboud <o...@debian.org> writes: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A: Keith Packard > B: Didier Raboud > C: Tollef Fog Heen > D: Sam Hartman > E: Phil Hands > F: Margarita Manterola > G: David

Bug#836127: Call for Votes for new TC member

Didier 'OdyX' Raboud writes: > I call for votes on the following ballot to fill a vacant seat in the TC. The > voting period starts immediately and lasts for up to one week, or until the > outcome is no longer in doubt (§6.3.1). > > ===BEGIN > The Technical Committee

Bug#860520: Voting for TC Chair

Didier 'OdyX' Raboud <o...@debian.org> writes: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A: Keith Packard > B: Didier Raboud > C: Tollef Fog Heen > D: Sam Hartman > E: Phil Hands > F: Margarita Manterola > G: David B

Bug#836127: Call for Votes for new CTTE Member

Philip Hands writes: > ===BEGIN > > The Technical Committee recommends that David Bremner be > appointed by the Debian Project Leader to the Technical Committee. > > A: Recommend to Appoint David Bremner > B: Further Discussion > > ===END I vote A > B -- -keith

Bug#858585: unblock: nickle-2.79-2

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package nickle. I believe this was blocked as there were three uploads in the last few days? Let me explain why that was the case: 1. nickle 2.78-1 contained a fix for

Bug#855604: glabels-3-batch segfault on 64-bit architectures (such as amd64)

Package: glabels Version: 3.4.0-1 Severity: normal Tags: patch glabels-3-batch crashes when de-referencing the gl_prefs value constructed in gl_prefs_init_null because there is no prototype provided for gl_prefs_model_new_null and so the pointer returned from that is cast to an int and back to a

Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

Margarita Manterola writes: > I call for votes on the following resolution with regards to #846002: I vote A > FD. -- -keith signature.asc Description: PGP signature

Bug#732443: bip: Bip does not start under systemd because of missing pid dir as well

Package: bip Version: 0.8.9-1+b1 Followup-For: Bug #732443 Dear Maintainer, Under systemd, the unit file doesn't create /var/lib/bip, so the daemon doesn't start correctly. If you use /etc/init.d/bip to start it, the directory is created before invoking systemctl, so it does start at that point.

Bug#828037: fontconfig: font-config should not register .dpkg-tmp files in its cache, users ends up seeing squares instead of expected characters

Raphael Hertzog writes: > (Keith, I would really like if you could step in, fontconfig > is at its fifth NMU in a row and the sources are not even in > a git packaging repo... I find it highly demotivating to contribute > without any reaction from the package maintainer when

Bug#833570: fontconfig: diff for NMU version 2.11.0-6.5

Salvatore Bonaccorso writes: > Control: tags 833570 + pending > > Hi Keith, > > I've prepared an NMU for fontconfig (versioned as 2.11.0-6.5) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. Looks like that patch is already in

Bug#833570: fontconfig: diff for NMU version 2.11.0-6.5

Salvatore Bonaccorso writes: > Control: tags 833570 + pending > > Hi Keith, > > I've prepared an NMU for fontconfig (versioned as 2.11.0-6.5) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. Also, thanks for doing this upload! --

Bug#830978: Browserified javascript and DFSG 2

"Paul R. Tagliamonte" writes: > Traditionally, ftpteam has had to take this role, since it is the body > that decides if an upload is fit for main. Yup. > I haven't talked in-depth with the rest of the ftpteam, but I assume > they agree. CC'ing in case there's an objection.

Bug#830344: How should the TC help with a project roadmap?

Margarita Manterola writes: > For documentation purposes, I list below my summary of the points that were > raised during the Roadmap BOF. These items are separate and may not > necessarily > all (or even any) need to be true in the implementation adopted. During the > BOF >

Bug#830344: How should the TC help with a project roadmap?

Package: tech-ctte User: tech-c...@packages.debian.org Mehdi has proposed that the TC be involved in some fashion with a "project roadmap". Some of the TC members met in person at debconf 16 to talk about how that might work. I will attempt to (badly) summarize some of the ideas brought out in

Bug#829704: Voting for TC Chair

Didier 'OdyX' Raboud <o...@debian.org> writes: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A: Andreas Barth > B: Don Armstrong > C: Keith Packard > D: Didier Raboud > E: Tollef Fog Heen > F: Sam Hartman > G: Phil Hands &

Bug#822803: Call for votes for new TC member

Didier 'OdyX' Raboud writes: > [ Unknown signature status ] > Dear TC members, > > I hereby call for votes on the following ballot to fill the vacancy in > the TC. The voting period starts now and lasts for up to one week, or > until the outcome is no longer in doubt. > >

Bug#741573: [CTTE #741573] Debian Menu System

Vincent Cheng writes: > Does this mean that packages providing both a .desktop and a Debian > menu file are immediately RC-buggy as of now (i.e. is "shall not" > equivalent to "must not" or "should not" in Policy-speak)? Sam Hartman asked this precise question at the

Bug#741573: CFV: Debian Menu Systems

I vote: D>B>A>Z>C -- -keith signature.asc Description: PGP signature

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Sam Hartman writes: > I ask you to retain the following two paragraphs that explain why we > prefer option D should we adopt this: >The Technical Committee has reviewed the underlying technical >issues around this question and has resolved that Debian will be >

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Sam Hartman writes: > I think a bit. > My big question is whether you think we'd still be able to call for a > vote tomorrow if we make this change. I think the change has real benefit beyond simple clarification by immediately adopting Charles' changes to policy without

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Sam Hartman writes: > OK. > I'd really appreciate hearing from anyone now who needs more time before > a CFV. I'd also love to hear back from Charles about the updated D proposal, and whether that helps him understand what it means. -- -keith signature.asc Description:

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Steve Langasek vor...@debian.org writes: 741573_menu_systems/keithp_draft.txt includes further guidance regarding the technical details of how to map between the menu system and .desktop files. Since this is not on the ballot itself, how do we intend to surface this so that it can be useful

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Charles Plessy ple...@debian.org writes: Thanks. I would appreciate if it would be acknowledged, I am a bit academic by training... The proposed ballot tries to clarify the difference between D and AB by noting: 6. The policy change by Charles Plessy in ba679bff76[1] would comply

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Ian Jackson ijack...@chiark.greenend.org.uk writes: * Overall, this would make it possible, therefore, to maintain the menu information primarily in the more sophisticated .desktop format, so that source packages with .desktop files would not need to contain trad menu files too.

Bug#726041: [PATCH] mi: fix typo in warning about overflowing queue

Alan Coopersmith alan.coopersm...@oracle.com writes: Reported-by: Vincent Hobeïka vincent.hobe...@gmail.com Signed-off-by: Julien Cristau jcris...@debian.org Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com Merged. e3624aa..ac94cdb master - master -- -keith signature.asc

Bug#769972: Read before Voting: Note from hartmans about new member ballots

Sam Hartman hartm...@debian.org writes: My hope is that you'll read the note and think we would make a good fit and we can all work together to create the best TC we can. However, if after reading that note TC members decide I'm not the best fit (or decide they'd like to discuss further

Bug#769972: Call for Votes for new CTTE Members

Don Armstrong d...@debian.org writes: A: Recommend to Appoint Sam Hartman (hartmans) B: Further Discussion I vote A B C: Recommend to Appoint Tollef Fog Heen (tfheen) D: Further Discussion I vote C D E: Recommend to Appoint Didier Raboud (odyx) F: Further Discussion I vote E F --

Bug#777656: squeeze update of freetype?

Raphael Hertzog hert...@debian.org writes: Hello dear maintainer(s), the Debian LTS team would like to fix the security issues which are currently open in the Squeeze version of your package: https://security-tracker.debian.org/tracker/source-package/freetype Would you like to take care of

Bug#774308: Explicitly allow zero-height PutImage

Here's a patch that bypasses the INT32_MAX check, allowing zero-height PutImage requests. From 6dc2634aee9023ac9d20dc06a76d9fa1f03ff2cd Mon Sep 17 00:00:00 2001 From: Keith Packard kei...@keithp.com Date: Sat, 3 Jan 2015 08:46:45 -0800 Subject: [PATCH] dix: Allow zero-height PutImage requests

Bug#773709: [PATCH] glamor: Call glamor_pixmap_destroy_fbo from glamor_set_pixmap_private

Michel Dänzer mic...@daenzer.net writes: Fixing Debian bug report address. Merged. 0d37c7e..11b85ab master - master -- keith.pack...@intel.com signature.asc Description: PGP signature

Bug#770789: Draft of option for #770789

Don Armstrong d...@debian.org writes: I call for votes on the following resolution regarding #770789: ==BEGIN== In 770789, the Technical Committee was asked to override the decision of upstream and the maintainer of df to not include i in the units output when asked for IEC output (2^10).

Bug#762194: On automatic init system switching on upgrade

Svante Signell svante.sign...@gmail.com writes: 4. For the moment, we invite concrete proposals for technical changes which would arrange that 1. new jessie installations using Linux would get systemd but 2. existing installations retain their existing init system so far as possible.

Bug#762194: Call for Votes (re automatic switching)

Ian Jackson ijack...@chiark.greenend.org.uk writes: I vote Y, FD -- keith.pack...@intel.com pgpD8PQKLbjBU.pgp Description: PGP signature

Bug#761393: Sends GLX_BufferSwapComplete with no swaps outstanding

Julien Cristau jcris...@debian.org writes: On Sat, Sep 13, 2014 at 16:43:08 +0200, Sjoerd Simons wrote: Package: xserver-xorg-core Version: 2:1.16.0-2+b1 Severity: important Tags: patch Both totem and cheese (3.13.X) crash in cogl due to receiving duplicate GLX_BufferSwapComplete

Bug#761393: Sends GLX_BufferSwapComplete with no swaps outstanding

Julien Cristau jcris...@debian.org writes: Right, that's even simpler... Looks good! Thanks for the backport. -- keith.pack...@intel.com pgpGBFyZDInsf.pgp Description: PGP signature

Bug#681419: Alternative dependencies on non-free packages in main: Call for Votes

Steve Langasek vor...@debian.org writes: As previously agreed in the IRC meeting, I call for votes on this question with the following ballot options: A non-free packages as non-default alternatives should not be prohibited in main B non-free packages should always be prohibited in

Bug#741573: Two menu systems

Russ Allbery r...@debian.org writes: Isn't this the tool that Sune wrote and mentioned earlier in this bug as being incomplete and primarily useful for generating a template that requires subsequent work? The only two gaps I saw were in the assignment of sections from the Categories in the

Bug#741573: Two menu systems

Ian Jackson ijack...@chiark.greenend.org.uk writes: I see Keith has committed a draft to git. As discussed, I disagree with this approach. This amounts to nonconsensually abolishing someone's work when it is still being maintained, and the global cost is minimal. Right, as I said in the

Bug#741573: Two menu systems

Ian Jackson ijack...@chiark.greenend.org.uk writes: Ian Jackson writes (Re: Bug#741573: Two menu systems): But I'd like to make some specific comments too. (I'm reading 24f00b5:741573_menu_systems/keithp_draft.txt, of which I attach a copy.) ... Oh, and: Fourthly: It makes no provision

Bug#741573: Two menu systems

Colin Watson cjwat...@debian.org writes: * There's no reason that has a .desktop file should imply shows up in modern desktop environments, and so I think that the question of coverage is to some extent a red herring; the systems have different coverage because they've always had

Bug#741573: Two menu systems

Cameron Norman camerontnor...@gmail.com writes: I believe the major aspect of .desktop files that makes them harder is the icon handling. Perhaps debian policy should instruct that a certain icon size must always be available in a particular format (e.g. 32x32 png) so that WMs do not have to

Bug#741573: Two menu systems

Russ Allbery r...@debian.org writes: The counterpoint here, which I had missed earlier in this discussion, is the file format for the menus themselves, not the *.desktop files. I agree with you about the *.desktop file format, but the specification for the menus is much more complicated.

Bug#741573: Two menu systems

Josselin Mouette j...@debian.org writes: One of the problems I have with your proposal, compared to Charles’ original patch, is that it encourages maintainers of hundreds of (IMHO useless) menu files to port them to the desktop format. Yeah, there are a lot of inappropriate entries in my

Bug#741573: Two menu systems

Nikolaus Rath nikol...@rath.org writes: Keith Packard kei...@keithp.com writes: 1. Implement .desktop parsing support in the existing 'menu' package so that packages providing only .desktop files would be incorporated into menu programs without further change. FWIW, it seems

  1   2   3   4   >