Bug#722451: Adoption
Hi, I think your Compiz packaging will be in Debian before next Sunday or 20th. I plan to add yourself from possible uploaders, because I really hope we'll be able to work together on the package itself. I'm sure your work is directly importable in Debian and does what's needed. I've an usage question (personally I cannot test due to my blindness): I was said that Emerald was useful to add icons to minimize, restore, close, etc top right of the window. But other users tell me metacity does that too, via gtk-window-decorator. So far I uploaded Emerald, so that once frozen, we can test Emerald and Metacity and see the results. I prefer having a useless package than a useful missing package after freeze. But anyway: do you confirm that Metacity provides what's needed or is Emerald useful? My purpose is to make Compiz work with Orca too, so with Meta-tab etc. Other point: if Metacity is enough, how do you set it to have gtk-window-decorator enabled and how is it shipped in Compiz? Finally, 9hat's the Metacity status: maintained upstream? will it be linked to gnome3 (it'd justify Emerald to have less useless deps to install)? Thanks for your feedback. Regards, Le 30/09/2014 13:43, Prof. Dipl.-Ing. Klaus Knopper a écrit : Hello Jean-Philippe, On Tue, Sep 30, 2014 at 07:05:42AM +0200, MENGUAL Jean-Philippe wrote: Le 30/09/2014 03:46, Prof. Dipl.-Ing. Klaus Knopper a écrit : Hello, Hi, About amd64 packages and Debian: Since Knoppix has a 32bit as well as a 64bit kernel, but userspace is always 32bit in both cases, I personally only need to build the i386 versions, these I provided at http://debian-knoppix.alioth.debian.org/packages/compiz together with the package sources. The source should build on plain Debian testing and sid, regardless of bitness (i386 or amd64) on your system, I removed the Ubuntu specials in the original debian/control dependencies and debian/rules which would otherwise fail to build on Debian. Knoppix is based on Debian testing+unstable. Ok so you did a major part of the work, Well, I just added the changes that I needed in Knoppix. They are small compared to the frequent upstream work on the Ubuntu launchpad. On the other hand, my version is probably better tested because of inclusion in Knoppix (with around 8000-2 downloads per day), compared to the upstream compiz version that Ubuntu seems to maintain last but not least as a testcase for their own unity desktop. The main development work is done on launchpad, whereas I just pull the sources once or twice a year when there is a major upgrade, and include them in Knoppix since compiz is one of the main features there. Adopting the upstream launchpad version with its frequent changes from bzr, may cause you more work, but would be closer to the original authors of the software. It would also in my interest because if you are maintaining compiz in Debian officially, I can stop creating a fork of the upstream compiz version. If you choose my version, we have a packaging chain like this: launchpad-based development from upstream authors - Knoppers testing distribution - Debians official packaging Should be OK, too, then I will function as a proxy. It's your decision, of course. Just tell me the final result, so that I won't accidentially switch back to the official Debian package while the official Debian package just uses Knoppix packages as upstream, so we have a loop which is likely not being synchronized with upstream development again. ;-) and it's excellent given the few time before freeze and the complexity of the package. So I think I'll put in Debian what you do for Knoppix, it seems relevant. True, there are time constraints, and once the packages are in Debian before feature freeze, you can probably still change the upstream source later, so adopting the packages that work for Debian-based Knoppix right now is probably the quickest way to do it. You may want to recheck if my preference for using file-based settings in $HOME/.config/compiz-1/compizconfig/* instead of using gsettings, is suitable for Debian. I think a file-based configuration has less hidden dependencies to gnome, though, while in Ubuntu, they keep everything inside the gnome configuration scheme by default so it's configurable with the central configuration GUI instead of needing its own compiz configuration settings manager (ccsm). If not, change the backend = ini parameter in /etc/compizconfig/config back to gsettings accordingly. I just uploaded the 0.9.12.0 compiz version based on https://launchpad.net/compiz/+milestone/0.9.12.0, which features two IMHO important accessibility patches (that I also attached here). They fix the erraneous transparency on first usage of the ezoom and annotate plugin (mouse curser and writing on screen were almost invisible unless you activated the magnify plugin temporarily). I already suggested the patches on the compiz bugtracker: https://bugs.launchpad.net/compiz/+bug/1362005
Bug#722451: Adoption
Hello Jean-Philippe,
On Tue, Oct 14, 2014 at 01:35:38AM +0200, MENGUAL Jean-Philippe wrote:
Hi,
I think your Compiz packaging will be in Debian before next Sunday
or 20th. I plan to add yourself from possible uploaders, because I
really hope we'll be able to work together on the package itself.
I'm sure your work is directly importable in Debian and does what's
needed.
I've an usage question (personally I cannot test due to my
blindness):
You did not tell me that detail before, though I should probably have
guessed. Maybe you have heared that my wife is blind, too
(http://en.wikipedia.org/wiki/Knoppix#Adriane_Knoppix), she does not use
the graphical desktop at all even with the usual orca+compiz
combination, but a text-based interface instead with sbl as
screenreader, and is working way faster using this method than any
seeing person I know working on the graphical interface including
myself.
I was said that Emerald was useful to add icons to
minimize, restore, close, etc top right of the window.
I should explain what it does. For the effect part like zooming, window
overview by moving mouse top right, moving windows with key
combinations, the plain compiz composite manager as add-on to a desktop
like LXDE, GNOME, KDE, openbox ... is sufficient, but people working
graphically will most likely want to use the mouse for grabbing windows
at a title bar, using minimize and maximize as buttons in the title bar
and so on. That's where the window decorator comes in, it's the part
of the GUI that draws window borders, title bar, buttons and menus
aroung the window. Since the window management has to closely work
together with compiz, it is not possible to use openbox, metacity etc.
directly for this together with compiz. The window decorator has to work
together with compiz special handling of transparency and effects. On
the other side, a compiz-aware window decorator will ONLY work together
with compiz and will not start without compiz having started prior. So
the two, effect manager compiz and window decorators, make sense at
least as a recommends field in each other package.
The only three window decorators that are compatible with compiz which I
am aware of, are in fact emerald (which is probably the oldest from the
time when compiz was forked as compiz-fusion), gtk-window-decorator and
kde(4)-window-decorator. All three have the same function, by drawing
borders around windows so they can be resized and moved using the mouse,
plus icons for maximize, minimize, close, and a menu button on the left
(which is configurable by either gconf/dconf in GTK or KDE settings in
KDE). The users choice of window decorator can also be called by a
script compiz-decorator.
I use gtk-window-decorator in Knoppix, which regularly resides inside
the package compiz-gnome built from the compiz source, because it
depends only on compiz and common GTK and metacity libraries, is
relatively lightweight, and shares lookfeel with the metacity window
manager which is what I also use for graphics cards that are unable to
run compiz, so the windows will look the same in compiz or without
compiz. It is possible to switch between compiz and a 2D non-effect
desktop by calling
compiz --replace
vs.
metacity --replace
compiz would call the window-decorator that had been set forth in its
configuration plugin window decoration, where compiz-decorator is the
default alias, which then calls either gtk-window-decorator or
kde-window-decorator.
I hope this clears up the relation between compiz and the window
decorator.
Which one works better with orca, may depend on whether you prefer KDE
or GNOME accessibility. From my experience, orca works well nowadays
with GTK as well as QT based applicatione, provided that the at-spi and
atk packages are installed for both versions. Concerning the decorator,
this plays only a role in reading the window menu from the title bar and
the window title itself, which will most likely not being used by a
blind user who works more with keyboard hotkeys defined in compiz
directly instead of clicking somewhere near the top 10 pixels of a
window.
But other
users tell me metacity does that too, via gtk-window-decorator.
Again, metacity itself cannot be used as window decorator in compiz,
since it replaces compiz when being started with --replace. But
gtk-window-decorator, which is built with metacity libraries for
configuration, lookfeel, works together with compiz.
So
far I uploaded Emerald, so that once frozen, we can test Emerald and
Metacity and see the results.
The script /usr/bin/compiz-decorator contains these lines:
73 # start a decorator
74 if [ -x ${COMPIZ_BIN_PATH}emerald ] [ $USE_EMERALD = yes ]; then
75 DECORATOR=emerald
76 elif [ -x ${COMPIZ_BIN_PATH}gtk-window-decorator ] [ -n
$GNOME_DESKTOP_SESSION_ID ]; then
77 DECORATOR=gtk-window-decorator
78 elif [ -x ${COMPIZ_BIN_PATH}kde4-window-decorator ] [
x$KDE_SESSION_VERSION = x4 ]; then
79
Bug#722451: Adoption
Well, I just added the changes that I needed in Knoppix. They are small compared to the frequent upstream work on the Ubuntu launchpad. On the other hand, my version is probably better tested because of inclusion in Knoppix (with around 8000-2 downloads per day), compared to the upstream compiz version that Ubuntu seems to maintain last but not least as a testcase for their own unity desktop. The main development work is done on launchpad, whereas I just pull the sources once or twice a year when there is a major upgrade, and include them in Knoppix since compiz is one of the main features there. Adopting the upstream launchpad version with its frequent changes from bzr, may cause you more work, but would be closer to the original authors of the software. It would also in my interest because if you are maintaining compiz in Debian officially, I can stop creating a fork of the upstream compiz version. If you choose my version, we have a packaging chain like this: launchpad-based development from upstream authors - Knoppers testing distribution - Debians official packaging But what changes do you do that imply a Knoppix step instead of maintaining directly in Debian? Why couldn't your work be done directly in Debian? I ask because: 1. I think we want in Debian a Compiz more similar as you do than this from Ubuntu, given they try to make it work for Unity, not us. 2. Do you do code patches? Important code patches? Why couldn't the string be: upstream - Debian (with you as co-maintainer and your release). It matches to Debian philosophy: stability, safety; it gives a cleaner package without Unity integration, etc. Why would we need, between upstream and Debian, a step in Knoppix instead of applying directly your work in Debian? Again, due to Unity integration and not priority for a11y, I don't think Debian has interest to use upstream release if you patch it in the direction we hope. Should be OK, too, then I will function as a proxy. It's your decision, of course. Just tell me the final result, so that I won't accidentially switch back to the official Debian package while the official Debian package just uses Knoppix packages as upstream, so we have a loop which is likely not being synchronized with upstream development again. ;-) Well I really think we could use directly your work, which is a kind of filter with upstream, directly in Debian instead of creating a knoppix-step. and it's excellent given the few time before freeze and the complexity of the package. So I think I'll put in Debian what you do for Knoppix, it seems relevant. True, there are time constraints, and once the packages are in Debian before feature freeze, you can probably still change the upstream source later, so adopting the packages that work for Debian-based Knoppix right now is probably the quickest way to do it. You may want to recheck if my preference for using file-based settings in $HOME/.config/compiz-1/compizconfig/* instead of using gsettings, is suitable for Debian. I think a file-based configuration has less hidden dependencies to gnome, though, while in Ubuntu, they keep everything inside the gnome configuration scheme by default so it's configurable with the central configuration GUI instead of needing its own compiz configuration settings manager (ccsm). If not, change the backend = ini parameter in /etc/compizconfig/config back to gsettings accordingly. Ok I'll check. I hope to use ccsm yes, but shipped typically in settings. I'll think of this. I just uploaded the 0.9.12.0 compiz version based on https://launchpad.net/compiz/+milestone/0.9.12.0, which features two IMHO important accessibility patches (that I also attached here). They fix the erraneous transparency on first usage of the ezoom and annotate plugin (mouse curser and writing on screen were almost invisible unless you activated the magnify plugin temporarily). I already suggested the patches on the compiz bugtracker: https://bugs.launchpad.net/compiz/+bug/1362005 https://bugs.launchpad.net/compiz/+bug/1362009 They have not been reviewed that, though. But are these changes packaged in http://debian-knoppix.alioth.debian.org/packages/compiz Yes, they are included in my packages and well tested in Knoppix 7.4.1 and 7.4.2. I had sent the patches to upstream, but they have not looked at them yet. ? What's the status of your patch above (in launchpad) in debian-knoppix (uploaded? waiting for acceptation on launchpad before shipping in debian-knoppix, etc)? Waiting to be reviewed. But due to the technical context, these changes should be considered harmless, i.e. compiz wll not crash just because I changed the color settings before drawing, which is already done in other stable plugins, too. Nevertheless, if you plan to adopt compiz in Debian again, I'd suggest using the upstream sources on https://launchpad.net/compiz rather than my modified version on
Bug#722451: Adoption
Hello,
About amd64 packages and Debian: Since Knoppix has a 32bit as well as a
64bit kernel, but userspace is always 32bit in both cases, I personally
only need to build the i386 versions, these I provided at
http://debian-knoppix.alioth.debian.org/packages/compiz together with
the package sources. The source should build on plain Debian testing and
sid, regardless of bitness (i386 or amd64) on your system, I removed the
Ubuntu specials in the original debian/control dependencies and
debian/rules which would otherwise fail to build on Debian. Knoppix is
based on Debian testing+unstable.
I just uploaded the 0.9.12.0 compiz version based on
https://launchpad.net/compiz/+milestone/0.9.12.0, which features two
IMHO important accessibility patches (that I also attached here). They
fix the erraneous transparency on first usage of the ezoom and annotate
plugin (mouse curser and writing on screen were almost invisible unless
you activated the magnify plugin temporarily). I already suggested the
patches on the compiz bugtracker:
https://bugs.launchpad.net/compiz/+bug/1362005
https://bugs.launchpad.net/compiz/+bug/1362009
They have not been reviewed that, though.
Nevertheless, if you plan to adopt compiz in Debian again, I'd suggest
using the upstream sources on https://launchpad.net/compiz rather than
my modified version on
http://debian-knoppix.alioth.debian.org/packages/compiz and coordinate
with the project maintainers, which is just what Jean-Philippe Mengual
suggested. Once compiz is officially back in Debian, I will happily use
that version rather than my forked version. I do need at least the ezoom
patch included in Knoppix, though, since ezoom (Super+Mousewheel) is an
important accessibility feature for users with low vision and is also
practival for presentations where the mousepointer should be visible.
Regards
-Klaus Knopper
On Tue, Sep 30, 2014 at 01:36:43AM +0200, MENGUAL Jean-Philippe wrote:
Hi,
I'm going to package before freeze, on the top of 0.9.12 from
Ubuntu. I don't have enough info about Knoppix packages
(Debian-based, release, where they rely on, etc)..
I wonder if I should create from scratch in pkg-a11y group, or
request for forwarding compiz from X to pkg-a11y before updating
the git repo and so on.
I probably will go from scratch in pkg-a11y, if you have no problems
with that.
Regards,
Le 13/09/2014 03:00, José Silva a écrit :
Hello,
Please find the source binary packaging here:
http://debian-knoppix.alioth.debian.org/packages/compiz/
There are only packages for knoppix i386.
1. Could you please also package for amd64?
2. My system is debian jessie/sid xfce4 amd64. Once your packages
are for debian/knoppix, will I be able to install your packages if
build to amd64?
Regards,
jss
--
Jean-Philippe MENGUAL
accelibreinfo, votre partenaire en informatique adaptée aux déficients visuels
Mail: te...@accelibreinfo.eu
Site Web: http://www.accelibreinfo.eu
=== modified file 'plugins/ezoom/src/ezoom.cpp'
--- plugins/ezoom/src/ezoom.cpp 2013-07-21 22:14:38 +
+++ plugins/ezoom/src/ezoom.cpp 2014-09-09 02:49:19 +
@@ -1164,6 +1164,7 @@
GLfloattextureData[8];
GLfloatvertexData[12];
GLVertexBuffer *streamingBuffer = GLVertexBuffer::streamingBuffer ();
+const GLWindowPaintAttrib attrib = { OPAQUE, BRIGHT, COLOR, 0, 0, 0, 0 }; /* -KK */
sTransform.toScreenSpace (output, -DEFAULT_Z_CAMERA);
convertToZoomed (out, mouse.x (), mouse.y (), ax, ay);
@@ -1186,6 +1187,7 @@
glBindTexture (GL_TEXTURE_2D, cursor.texture);
streamingBuffer-begin (GL_TRIANGLE_STRIP);
+streamingBuffer-colorDefault (); /* -KK */
vertexData[0] = x;
vertexData[1] = y;
@@ -1214,7 +1216,7 @@
streamingBuffer-addTexCoords (0, 4, textureData);
streamingBuffer-end ();
- streamingBuffer-render (sTransform);
+ streamingBuffer-render (sTransform, attrib /* -KK */);
glBindTexture (GL_TEXTURE_2D, 0);
glDisable (GL_BLEND);
@@ -1743,6 +1745,7 @@
CompAction::State state,
CompOption::Vector options)
{
+
zoomIn (action, state, options);
if (state CompAction::StateInitKey)
@@ -1753,6 +1756,7 @@
toggleFunctions (true);
+
return true;
}
=== modified file 'plugins/annotate/src/annotate.cpp'
--- plugins/annotate/src/annotate.cpp 2013-07-19 03:04:12 +
+++ plugins/annotate/src/annotate.cpp 2014-09-09 03:35:33 +
@@ -615,6 +615,7 @@
if (status)
{
GLVertexBuffer *streamingBuffer = GLVertexBuffer::streamingBuffer ();
+const GLWindowPaintAttrib attrib = { OPAQUE, BRIGHT, COLOR, 0, 0, 0, 0 }; /* -KK */
GLfloat vertexData[18];
GLfloat textureData[12];
CompRectrect;
@@ -640,6 +641,7 @@
tex-enable (GLTexture::Fast);
streamingBuffer-begin (GL_TRIANGLES);
+ streamingBuffer-colorDefault (); /* -KK */
while (numRect--)
{
@@ -697,7 +699,7 @@
}
streamingBuffer-end ();
- streamingBuffer-render
Bug#722451: Adoption
Hi, I'm going to package before freeze, on the top of 0.9.12 from Ubuntu. I don't have enough info about Knoppix packages (Debian-based, release, where they rely on, etc).. I wonder if I should create from scratch in pkg-a11y group, or request for forwarding compiz from X to pkg-a11y before updating the git repo and so on. I probably will go from scratch in pkg-a11y, if you have no problems with that. Regards, Le 13/09/2014 03:00, José Silva a écrit : Hello, Please find the source binary packaging here: http://debian-knoppix.alioth.debian.org/packages/compiz/ There are only packages for knoppix i386. 1. Could you please also package for amd64? 2. My system is debian jessie/sid xfce4 amd64. Once your packages are for debian/knoppix, will I be able to install your packages if build to amd64? Regards, jss -- Jean-Philippe MENGUAL accelibreinfo, votre partenaire en informatique adaptée aux déficients visuels Mail: te...@accelibreinfo.eu Site Web: http://www.accelibreinfo.eu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5429ed0b.50...@accelibreinfo.eu
Bug#722451: Adoption
Le 30/09/2014 03:46, Prof. Dipl.-Ing. Klaus Knopper a écrit : Hello, Hi, About amd64 packages and Debian: Since Knoppix has a 32bit as well as a 64bit kernel, but userspace is always 32bit in both cases, I personally only need to build the i386 versions, these I provided at http://debian-knoppix.alioth.debian.org/packages/compiz together with the package sources. The source should build on plain Debian testing and sid, regardless of bitness (i386 or amd64) on your system, I removed the Ubuntu specials in the original debian/control dependencies and debian/rules which would otherwise fail to build on Debian. Knoppix is based on Debian testing+unstable. Ok so you did a major part of the work, and it's excellent given the few time before freeze and the complexity of the package. So I think I'll put in Debian what you do for Knoppix, it seems relevant. I just uploaded the 0.9.12.0 compiz version based on https://launchpad.net/compiz/+milestone/0.9.12.0, which features two IMHO important accessibility patches (that I also attached here). They fix the erraneous transparency on first usage of the ezoom and annotate plugin (mouse curser and writing on screen were almost invisible unless you activated the magnify plugin temporarily). I already suggested the patches on the compiz bugtracker: https://bugs.launchpad.net/compiz/+bug/1362005 https://bugs.launchpad.net/compiz/+bug/1362009 They have not been reviewed that, though. But are these changes packaged in http://debian-knoppix.alioth.debian.org/packages/compiz ? What's the status of your patch above (in launchpad) in debian-knoppix (uploaded? waiting for acceptation on launchpad before shipping in debian-knoppix, etc)? Nevertheless, if you plan to adopt compiz in Debian again, I'd suggest using the upstream sources on https://launchpad.net/compiz rather than my modified version on http://debian-knoppix.alioth.debian.org/packages/compiz and coordinate with the project maintainers, which is just what Jean-Philippe Mengual suggested. But given details you gave, it's useless. It seems much more relevant to use your package, put them in Debian, and work you and us in order to stay synchronoous with Canonical. I don't think 2 branches should exist, I would prefer Debian + knoppix merge sfnce the base is similar. Once compiz is officially back in Debian, I will happily use that version rather than my forked version. I do need at least the ezoom patch included in Knoppix, though, since ezoom (Super+Mousewheel) is an important accessibility feature for users with low vision and is also practival for presentations where the mousepointer should be visible. Just to be sure: can we take your package, ship the patch, upload in Debian? Or do you prefer to wait some Canonical's feedback? I really would like to merge Debian and you, so that your maintainance work is automatically shipped in Debian. It'll improve Debian+knoppix a11y, and will represent less work for me with low dev skills. Last question: does Compiz magnify know to follow the focus now? Regards, Regards -Klaus Knopper On Tue, Sep 30, 2014 at 01:36:43AM +0200, MENGUAL Jean-Philippe wrote: Hi, I'm going to package before freeze, on the top of 0.9.12 from Ubuntu. I don't have enough info about Knoppix packages (Debian-based, release, where they rely on, etc).. I wonder if I should create from scratch in pkg-a11y group, or request for forwarding compiz from X to pkg-a11y before updating the git repo and so on. I probably will go from scratch in pkg-a11y, if you have no problems with that. Regards, Le 13/09/2014 03:00, José Silva a écrit : Hello, Please find the source binary packaging here: http://debian-knoppix.alioth.debian.org/packages/compiz/ There are only packages for knoppix i386. 1. Could you please also package for amd64? 2. My system is debian jessie/sid xfce4 amd64. Once your packages are for debian/knoppix, will I be able to install your packages if build to amd64? Regards, jss -- Jean-Philippe MENGUAL accelibreinfo, votre partenaire en informatique adaptée aux déficients visuels Mail: te...@accelibreinfo.eu Site Web: http://www.accelibreinfo.eu -- Jean-Philippe MENGUAL accelibreinfo, votre partenaire en informatique adaptée aux déficients visuels Mail: te...@accelibreinfo.eu Site Web: http://www.accelibreinfo.eu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542a3a26.1070...@accelibreinfo.eu
Bug#722451: Adoption
Hello, Please find the source binary packaging here: http://debian-knoppix.alioth.debian.org/packages/compiz/ There are only packages for knoppix i386. 1. Could you please also package for amd64? 2. My system is debian jessie/sid xfce4 amd64. Once your packages are for debian/knoppix, will I be able to install your packages if build to amd64? Regards, jss -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/blu436-smtp842c3eb042cc2536042bf0d0...@phx.gbl
Bug#722451: Adoption
On 27/08/14 06:31, Prof. Dipl.-Ing. Klaus Knopper wrote: Hello, On Tue, Aug 26, 2014 at 11:56:48PM +0200, Carlos Alberto Lopez Perez wrote: On 11/08/14 23:50, MENGUAL Jean-Philippe wrote: Hi, Do you plan still to package Compiz? Do you have a problem which prevents this? Do you need help? Otherwise, can I adopt it so that someone and I can package it before freeze? Our work to prepare has now good improvement. Thanks, Regards, Hi, This bug is marked as RFP = Request For Package. This means that the reporter is asking for someone to package this software, but no one has still offered to package and maintain it. If you want to package/maintain it yourself, please retitle the bug to ITP = Intend To Package, assign the bug to yourself, and start working on it. Find here help about packaging for Debian: https://wiki.debian.org/DebianMentorsFaq#Packaging And here help about using the BTS (Bug Tracking System): https://wiki.debian.org/HowtoUseBTS https://www.debian.org/Bugs/server-control Thanks! Actually, I do package the compiz git from launchpad regularly for using it in Debian/Knoppix as the main window manager. Please find the source binary packaging here: http://debian-knoppix.alioth.debian.org/packages/compiz/ However, I'm not am official Debian Package Maintainer and thus the packages won't show up anywhere else than in Knoppix currently. You don't need to be a Debian Maintainer (DM) to maintain packages in Debian. Anyone can maintain packages in Debian. The only difference is that DM are allowed to upload directly to the archive, while not-DM people need that some DD (Debian Developer) review and sponsor the package. Once you are maintaining one or more packages in Debian you can apply to become a DM if you want, so you can upload further updates of your packages directly to the archive. We have a clear process defined for this. Once you have your package ready, you can upload it to mentors.debian.net (or to other site if you prefer) and you ask on the mailing list debian-ment...@lists.debian.org (subscribe yourself to the list) for someone to review and upload your package. Probably you will have to trim the Changelog for the initial upload to Debian, and include a line on it closing this bug #722451. But first you should retitle this bug to ITP and assign it to yourself, to show your intention of packaging Compiz for Debian. So anyone else that could be interested in doing the work is aware that you are already working on this. So we avoid duplicating work. signature.asc Description: OpenPGP digital signature
Bug#722451: Adoption
Carlos Alberto Lopez Perez, le Wed 27 Aug 2014 11:54:57 +0200, a écrit : We have a clear process defined for this. Once you have your package ready, you can upload it to mentors.debian.net (or to other site if you prefer) and you ask on the mailing list debian-ment...@lists.debian.org (subscribe yourself to the list) for someone to review and upload your package. I'm willing to review upload under the debian-accessibility umbrella. Best would probably be to maintain the packaging on alioth.debian.org (so we can both get to commit to it), you just need to get an account there and ask for joining the pkg-a11y group. Samuel -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827231532.ga1...@type.youpi.perso.aquilenet.fr
Bug#722451: Adoption
On 11/08/14 23:50, MENGUAL Jean-Philippe wrote: Hi, Do you plan still to package Compiz? Do you have a problem which prevents this? Do you need help? Otherwise, can I adopt it so that someone and I can package it before freeze? Our work to prepare has now good improvement. Thanks, Regards, Hi, This bug is marked as RFP = Request For Package. This means that the reporter is asking for someone to package this software, but no one has still offered to package and maintain it. If you want to package/maintain it yourself, please retitle the bug to ITP = Intend To Package, assign the bug to yourself, and start working on it. Find here help about packaging for Debian: https://wiki.debian.org/DebianMentorsFaq#Packaging And here help about using the BTS (Bug Tracking System): https://wiki.debian.org/HowtoUseBTS https://www.debian.org/Bugs/server-control Thanks! signature.asc Description: OpenPGP digital signature
Bug#722451: Adoption
Hello, On Tue, Aug 26, 2014 at 11:56:48PM +0200, Carlos Alberto Lopez Perez wrote: On 11/08/14 23:50, MENGUAL Jean-Philippe wrote: Hi, Do you plan still to package Compiz? Do you have a problem which prevents this? Do you need help? Otherwise, can I adopt it so that someone and I can package it before freeze? Our work to prepare has now good improvement. Thanks, Regards, Hi, This bug is marked as RFP = Request For Package. This means that the reporter is asking for someone to package this software, but no one has still offered to package and maintain it. If you want to package/maintain it yourself, please retitle the bug to ITP = Intend To Package, assign the bug to yourself, and start working on it. Find here help about packaging for Debian: https://wiki.debian.org/DebianMentorsFaq#Packaging And here help about using the BTS (Bug Tracking System): https://wiki.debian.org/HowtoUseBTS https://www.debian.org/Bugs/server-control Thanks! Actually, I do package the compiz git from launchpad regularly for using it in Debian/Knoppix as the main window manager. Please find the source binary packaging here: http://debian-knoppix.alioth.debian.org/packages/compiz/ However, I'm not am official Debian Package Maintainer and thus the packages won't show up anywhere else than in Knoppix currently. Regards -Klaus -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827043149.gb26...@knopper.net
Bug#722451: Adoption
Hi, Do you plan still to package Compiz? Do you have a problem which prevents this? Do you need help? Otherwise, can I adopt it so that someone and I can package it before freeze? Our work to prepare has now good improvement. Thanks, Regards, -- Jean-Philippe MENGUAL accelibreinfo, votre partenaire en informatique adaptée aux déficients visuels Mail: te...@accelibreinfo.eu Site Web: http://www.accelibreinfo.eu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e93aae.2070...@accelibreinfo.eu
Bug#722451: Adoption
Hi, Do you plan still to package Compiz? Do you have a problem which prevents this? Do you need help? Otherwise, can I adopt it so that someone and I can package it before freeze? Our work to prepare has now good improvement. Thanks, Regards, -- Jean-Philippe MENGUAL accelibreinfo, votre partenaire en informatique adaptée aux déficients visuels Mail: te...@accelibreinfo.eu Site Web: http://www.accelibreinfo.eu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e914ba.8030...@accelibreinfo.eu
