Re: Bug#622931: libav: pkg-config files implies possible static linkage
On Sun, 17 Apr 2011 23:30:34 +0200 Tollef Fog Heen wrote: > ]] Reinhard Tartler > > | Neil, thank you very much for your insightful summary of the matter. Now > | it seems pretty clear that this issue cannot be handled in the libav > | package, but needs to be solved at the pkg-config level. I'm therefore > | reassigning this bug to pkg-config. > > Just to make it clear, what you want is a way for a package (libA) to > say «you can't build this statically»? If so, there's no way to do that > with pkg-config and unless you can convince me what the use case is and > why this is worth supporting, I'm not going to add it. Perhaps a little statement in pkg-config (1) in the section on --static which makes it clear that pkg-config (just as with the default '--dynamic' output) does not check this data and whether it works or not is undetermined? "Not all libraries support static linking and some libraries may still require other steps to allow programs to statically link using the output of pkg-config --static." Maybe also a statement in the main description that pkg-config does not (cannot) check whether the data in the .pc file(s) will actually allow programs to link against the libraries specified. That is the job of the build system using pkg-config. pkg-config is, after all, a config tool, not a QA or checking tool. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpCUBJ4VlXKc.pgp Description: PGP signature
Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo
2011/4/18 Thomas Goirand : > On 04/18/2011 05:29 AM, Soren Hansen wrote: >> 2011/4/16 Thomas Goirand : >>> On 04/16/2011 01:32 PM, Lucas Nussbaum wrote: On 16/04/11 at 10:43 +0800, Thomas Goirand wrote: What the state of collaboration with the upstream packagers? >>> Replied more extensively privately to that one. >> >> This, even more than your constant lecturing on Debian policy, frankly >> pisses me off. > What are you referring about for the policy? I've lost count of the times you've tried to lecture me on what is forbidden, how this or that absolutely must be, etc. Even if you were always correct, it's extremely frustrating and disrespectful that you always assume ignorance. I'm well aware that all our executables should have man pages. I'm well aware that we can't ship a patched ajaxterm in our packages. I'm well aware of what should go in a package's description. I'm well aware of the meaning of a dependency vs. a recommended package. I also have a pretty good idea which of those things are blockers (like, say, shipping a patched ajaxterm instead of using the system one) and which ones aren't (e.g. a missing dependency). I consider myself a rather experienced packager, but I feel you're treating me like a rookie packager who as never read the Debian Policy. > All I've been fixing aren't *my* lecture of the policy, but the ones > of *lintian*. There's no way I'm going to upload something in the > Debian archive if lintian warns me about anything. That's fine. Making the package lintian is a great goal! It really is. Personally, I subscribe to the idea that perfect is the enemy of good enough. Had I spent a couple of extra days fixing every tiny little detail about the packaging, there'd 27 other bugs in OpenStack itself that wouldn't have been fixed. That doesn't mean that I don't know that there's more work to be done, just like I know the same is true for OpenStack. At the end of the day, I need to decide what is more critical. Our packages worked, and aside from not cleaning up very thoroughly after themselves on removal, I don't think any of the issues with the packages would be considered RC problems. > Now, you are telling 2 things that are opposing each other. You are > saying that my "constant lecturing on Debian policy" above, and below > that you need more discussions about my proposed merges with you. Most > of my changes are to be policy compliant. So, please choose one of the > two and stick to it. "most" being the operative word. You've proposed a bunch of changes, all of them in the same branch. You've asked me to review and pull that branch. I've found changes I disagree with, so I ask you to fix them before I pull. I'd be happy to review and merge your changes piecemeal if you would simply propose them that way. Also, even though I asked you not to, you went and rebased your branch, so I had to start over with my review. That cost me quite a bit of time. >> If you have something to say, at the very least have the guts to say >> it in public > I did. What I added privately to Lucas was mostly that I had bad > feelings for the future, If you think there are problems with our collaboration, *we* are the people you should be discussing with. How else are we going to address it? > because of reactions like this: >> otherwise this collaboration ends right here. > which I wanted to avoid, knowing already how quick you can be to > react. Admittedly, I get upset and extremely frustrated when people have issues with me or my work, but instead of confronting me, discuss it with other people. It's exactly how our collaboration started (instead of discussing changes with me, you posted on debian-devel to find other people who wanted to help fix my work). It's disrespectful and it's frustrating that we can't move past that sort of workflow. > What I wrote as well, is that it seemed to me that Debian was not your > priority. Am I wrong with that? I'm not sure how to answer that. Getting Openstack into Debian is on my list of goals. It's not at the top, because, you know, there can only be one thing at the top. I'm not sure whether that amounts to a "yes" or "no" to your question. >>> But in short: my patches were not pulled, and I hope to get more >>> feedback and reactivity from upstream packagers in the future. >> It would be quite helpful if you'd either a) follow the same process >> as everyone else and submit a merge proposal when you have something >> ready for review or at least b) let me know whenever you expect me to >> review your stuff. > I did b), multiple times, on both IRC and email. You agreed on the > discussed changes, which is why I didn't get why my proposed changes > were not pulled. Because I disagree with some of them, and you've proposed them as one, great big branch. >> Every once in a while, I've gone and looked and have given you >> feedback. > I agree I had the feedback 2 weeks ago, yes. I can even add that I was > quite happy to discuss my ch
Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo
On 04/17/2011 01:05 PM, Charles Plessy wrote: > Le Sat, Apr 16, 2011 at 10:43:43AM +0800, Thomas Goirand a écrit : >> >> Again, if other DDs want to participate to this packaging effort, you'd >> be welcome. Especially, it seems that the current version of euca tools >> are broken (uec-publish-tarball got me stuck on my work for a week), and >> would need debugging. > > Hi Thomas, > > Debian's euca2ools package is definitely outdated. Is the problem with > uec-publish-tarball fixed in upstream's version 1.3.1 ? > > I will be mostly unavailable for the next three weeks, with two business trips > followed by vacations. So if you or anybody else would like to go ahead and > update the package, you are most welcome ! I can add you to the > pkg-eucalyptus > group any time. > > Cheers, My mistake, euca2ools don't have uec-publish-tarball, it's "cloud-utils" that does, and euca2ools are working ok, I believe. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dabe413.3050...@goirand.fr
Re: Bug#622931: libav: pkg-config files implies possible static linkage
Am 17.04.2011 12:43, schrieb Reinhard Tartler: Neil, thank you very much for your insightful summary of the matter. Now it seems pretty clear that this issue cannot be handled in the libav package, but needs to be solved at the pkg-config level. I'm therefore reassigning this bug to pkg-config. Couldn't we simply drop the *.private fields in the .pc files to signalize we don't support static linking? - Fabian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dac6531.60...@greffrath.com
Re: Bug#622931: libav: pkg-config files implies possible static linkage
On Mon, 18 Apr 2011 09:22:09 -0700 Fabian Greffrath wrote: > Am 17.04.2011 12:43, schrieb Reinhard Tartler: > > Neil, thank you very much for your insightful summary of the matter. Now > > it seems pretty clear that this issue cannot be handled in the libav > > package, but needs to be solved at the pkg-config level. I'm therefore > > reassigning this bug to pkg-config. > > Couldn't we simply drop the *.private fields in the .pc files to > signalize we don't support static linking? It's the dependency of the dependency of one of the Requires fields which causes the breakage, not the Requires.private. i.e. the Requires.private can be right but the static linkage can still fail. Lack of Requires.private is no indicator of a lack of support for --static. There are many libraries which could link statically but which have no need for any data in Requires.private. Dropping the Requires.private in libav doesn't signify anything - it merely hides the real problem in the dependency chain. (A problem which does not necessarily *have* a fix because static linkage is a corner case.) I appreciate that pkg-config and libav can both document this issue a bit more usefully but nobody in this thread has so far given a robust use case for changes in the code for either libav or pkg-config. The original package (libav) doesn't link statically - fine, it isn't explicitly supported so it doesn't have to work and the only problem that has been described lies outside the remit of the libav package itself. Equally, pkg-config is not the place to go around checking whether the supplied configuration actually works. pkg-config makes no pretence at being the "one-stop-solution" for all your linking requirements, although it can do most of the work most of the time - even for dynamic linking there are times when it's not just the lack of a .pc file which causes developers to need to add other stuff to the output of pkg-config. The problem simply has to lie with the build system which is trying to generate a static linkage. i.e. the problem isn't in libav, it isn't in pkg-config. Those two can *document* possible reasons why static linkage might not work in all cases but it isn't their problem when it does fail. Static just isn't universally supported / supportable. That puts the burden firmly on those who want to link statically. There will be hacks and changes needed in the build system of whatever is trying to generate a static build and that is where these problems need to be fixed. Maybe those hacks will include parsing the output of pkg-config --static to make allowances for those dependencies which cannot link statically. It won't be the last time that's going to be needed. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpuPFnqwRcWl.pgp Description: PGP signature
Bug#623188: ITP: haskell-crypto -- Haskell library with cryptographical algorithms
Package: wnpp Severity: wishlist Owner: Joachim Breitner -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: haskell-crypto Version : 4.2.3 Upstream Author : Dominic Steinitz * URL : http://hackage.haskell.org/package/Crypto * License : partly BSD, partly GPL Programming Lang: Haskell Description : Haskell library with cryptographical algorthm This is a dependency of the next version of git-annex. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk2r9FYACgkQ9ijrk0dDIGx+6QCeLsgGfbj4s8zHUI01/Wtjcbtu PIcAoKgsEJ3Z+URv1fBPpKiRijDFOPXa =WMTF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418082038.6192.87011.reportbug@ip6-localhost
Bug#623191: ITP: haskell-hs3 -- S3 interace for Haskell
Package: wnpp Severity: wishlist Owner: Joachim Breitner -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: haskell-hs3 Version : 0.5.5 Upstream Author : Greg Heartsfield * URL : http://hackage.haskell.org/package/hS3 * License : BSD Programming Lang: Haskell Description : S3 interace for Haskell This is a dependency for the next git-annex release. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk2r+YQACgkQ9ijrk0dDIGyM7ACgpQOcvi6kvhkiiYyaKwkpnNvW R2AAn35fa5dMFeV5Qbe1kzR64ABzt6oV =KX3A -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418084244.7003.50460.reportbug@ip6-localhost
ITP: arakoon -- A simple consistent distributed key/value store
Package: wnpp Version: N/A Severity: wishlist Arakoon tries to be a consistent distributed key value store. Technically, it's a ocaml implementation of multipaxos on top of Tokyo Cabinet homepage: http://www.arakoon.org -- System Information: Debian Release: squeeze/sid APT prefers lucid-updates APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-30-generic (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages arakoon depends on: ii libbz2-1.0 1.0.5-4ubuntu0.1 high-quality block-sorting file co ii libc6 2.11.1-0ubuntu7.8 Embedded GNU C Library: Shared lib arakoon recommends no packages. arakoon suggests no packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303122994.2130.29.camel@romain-laptop
Re: Bug#622931: libav: pkg-config files implies possible static linkage
On Mon, 2011-04-18 at 09:05 +0100, Neil Williams wrote: > On Mon, 18 Apr 2011 09:22:09 -0700 > Fabian Greffrath wrote: > > > Am 17.04.2011 12:43, schrieb Reinhard Tartler: > > > Neil, thank you very much for your insightful summary of the matter. Now > > > it seems pretty clear that this issue cannot be handled in the libav > > > package, but needs to be solved at the pkg-config level. I'm therefore > > > reassigning this bug to pkg-config. > > > > Couldn't we simply drop the *.private fields in the .pc files to > > signalize we don't support static linking? > > It's the dependency of the dependency of one of the Requires fields > which causes the breakage, not the Requires.private. i.e. the > Requires.private can be right but the static linkage can still fail. > > Lack of Requires.private is no indicator of a lack of support for > --static. There are many libraries which could link statically but > which have no need for any data in Requires.private. [...] Libs.private = -fstatic-linking-is-not-supported ;-) Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
Hi, DPL asked us to increase traffic on devel - so I'd like to warm up a recent discussion On Sat, Mar 05, 2011 at 04:22:01PM -0800, Manoj Srivastava wrote: > > Fair enough. Would you, then, be satisfied by my answer that > they are used? I am a current real life user of fvwm, and I am on the > mailing lists for the fvwm project with other real life users and > developers; and my expeirnces, and the chatter on the list, do not lead > me to believe that menus are unused. As far as I understood [1] fvwm 2.6 now can use XDG menus. So it might be that even fvwm users will be happy about desktop files. Can we now come back to the discussion whether it might make sense to have desktop files for desktop applications? Kind regards Andreas. [1] http://lwn.net/Articles/438781/ -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418133316.gg18...@an3as.eu
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
* Andreas Tille [110418 15:33]: > As far as I understood [1] fvwm 2.6 now can use XDG menus. So it might > be that even fvwm users will be happy about desktop files. Can we now > come back to the discussion whether it might make sense to have desktop > files for desktop applications? As I said in multiple other discussions about this: Please write a policy how .desktop files in Debian should look like and some documentation for maintainers what the categories means and some documentation for users how to do the basic things like overriding a menu entry. Currently there is none of this[1]. I think it makes no sense to discuss if things should have desktop files or whether it makes sense to remove the old working system. Bernhard R. Link P.S.: While icewm does support XDG menu the first I do is disable it so that users are not confused by it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418135029.gb24...@pcpool00.mathematik.uni-freiburg.de
Bug#623225: ITP: proftpd-mod-msg -- allows system users to send messages
Package: wnpp Severity: wishlist Owner: Fabrizio Regalli * Package name: proftpd-mod-msg Version : 0.4.1 Upstream Author : TJ Saunders * URL : http://www.castaglia.org/proftpd/modules/mod_msg.html * License : GPL-2 Description : The mod_msg module allows system users to send messages to connected clients via the ftpdctl program. The module works by creating a SysV message queue, which is used to pass messages from the daemon process to session processes. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418141253.32389.14476.reportbug@debianfab
Re: Bug#622931: libav: pkg-config files implies possible static linkage
]] Ben Hutchings (Cc list trimmed) | On Mon, 2011-04-18 at 09:05 +0100, Neil Williams wrote: | | > Lack of Requires.private is no indicator of a lack of support for | > --static. There are many libraries which could link statically but | > which have no need for any data in Requires.private. | [...] | | Libs.private = -fstatic-linking-is-not-supported Yeah, something like that is really what you'd end up with. People aren't going to read the docs anyway, but if somebody sends me a patch for the man page or guide wording, I'll be happy to apply it. Not sure I care enough about static linking to write it myself, as I think static linking is an uninteresting corner case and people should just stop doing it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o5v4oc4@qurzaw.varnish-software.com
Bug#623228: ITP: proftpd-mod-fsync -- attempts to prevent such bottlenecks by forcibly flushing to disk
Package: wnpp Severity: wishlist Owner: Fabrizio Regalli * Package name: proftpd-mod-fsync Version : 0.2 Upstream Author : TJ Saunders * URL : http://www.castaglia.org/proftpd/modules/mod_fsync.html * License : GPL-2 Description : On some kernels and/or filesystems, if there are files opened simultaneously for reading and writing, the buffer cache algorithms may cause the write I/O to swamp the read I/O, causing processes that are reading files to slow down because of buffer cache misses. The Linux 2.4 kernel, for example, suffers from this problem. The mod_fsync module attempts to prevent such bottlenecks by forcibly flushing to disk the buffers used for files open for writing after a certain number of bytes have been written (for example, after 128 KB has been written to a file). This prevents the buffer cache from being dominated by data from files being written, freeing up space for data for files being read. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418144655.776.19142.reportbug@debianfab
Bug#623236: RFP: libapache2-mod-wsgi-py3 -- [SHORT DESCRIPTION]
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: libapache2-mod-wsgi-py3 Version: 3.3-2+b1 Description: Broken symlink /usr/lib/apache2/modules/mod_wsgi.so -> mod_wsgi.so-3.2-2 . After correction to mod_wsgi.so -> mod_wsgi.so-3.2 apache2 restart produces the following error message: apache2: Syntax error on line 203 of /etc/apache2/apache2.conf: Syntax error on line 1 of /etc/apache2/mods-enabled/wsgi.load: Cannot load /usr/lib/apache2/modules/mod_wsgi.so into server: /usr/lib/apache2/modules/mod_wsgi.so: undefined symbol: PyCObject_FromVoidPtr[DESCRIPTION] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1302456643.23157.2.camel@silverstone
Bug#623237: ITA: gtkpod -- manage songs and playlists on an Apple iPod
Package: wnpp Severity: normal * New maintainer (Closes: #621910) I intend to adopt the gtkpod package, but I'll surely need some help. Thanks for your support. The package description is: gtkpod is a platform independent GUI for Apple's iPod using GTK2. It allows you to upload songs and playlists to your iPod. It supports ID3 tag editing, multiple charsets for ID3 tags, detects duplicate songs, allows offline modification of the database with later synchronisation, and more. -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418153204.11740.45420.report...@vps-sid.revese.it
Palestras na Expo Direito 2011
EXPO DIREITO - Feira & Congressos 27, 28 e 29 de abril de 11h às 21h FIRJAN - Av. Graça Aranha, 1 - Centro - RJ www.expodireito.com.br - 3 Auditórios simultâneos - Gestão de Escritórios de Advocacia - Encontro de Departamentos Jurídicos - Grandes Mestres do Direito - Área de exposição com estandes de produtos e serviços CONFIRA ABAIXO A PROGRAMAÇÃO E COMPRE JÁ SEU INGRESSO!!! _ AUDITÓRIO 3 - ENCONTRO DE DEPARTAMENTOS JURÍDICOS 27 DE ABRIL José Nilton - Presidente do FDJUR - Relação Dep. Jur. e Escritórios Fernando Curio - Sócio do Berbat Curio Adv -Benefícios Fiscais Déborah Meirelles - Dir. Jurídica da Ampla - Gestão da Diretoria Jurídica Alexandre Mellão - Dir. Jurídico da Estácio - Avaliação de Terceirizados 28 DE ABRIL Luiz Xavier Borges - Dir. Jur.da APA/FAPES/BNDES - Gestão do Conhecimento Sandro Gomes - Gerente do Contencioso da Petros - Contencioso de Massa Antonio Ricardo - Dir. Jur. da Carvalho Hosken - Estratégia do Dep. Jur. Henrique Freire - Diretor Jurídico da Amil - Gestão da Qualidade 29 DE ABRIL Victor Rizzo - Sócio da E-xyon - Gestão de Riscos Jurídicos Leonardo Barém Leite - Consultor - Novo Perfil do Advogado Corporativo Marcelo Souccar - Consultor da Totvs - Novas Soluções Luis Almeida - Diretor Jurídico da Nextel - Sistemas de Controle AUDITÓRIO 2 - GESTÃO DE ESCRITÓRIOS DE ADVOCACIA 27 DE ABRIL Marco A. Gonçalves - Ger. Campos Mello - O Novo Cenário da Advocacia Flávia Cançado - Sócia da Selem & Bertozzi - Controladoria Jurídica Rodrigo Bertozzi - Sócio da Selem & Bertozzi - Marcas Jur.de Sucesso Fabiane Turisco - Sócia do Martinelli Advocacia - Responsabilidade Social 28 DE ABRIL Joaquim Gonçalves - Administrador do BBCR - Avaliação de Desempenho Adnílson Hipólito - Sócio da Selem & Bertozzi - Gestão Financeira Alexandre Lima - Sócio do Grupo Four - Novas Tecnologias para Advogados Luciano Faggiano- Adm. do Siqueira Castro - Administrando o maior 29 DE ABRIL Alexandre Motta - Sócio da Inrise Consultores - Marketing Jurídico Felipe Adaime Consultor - Gestão do Contencioso de Massa Simone Salomão Consultora - Soluções para Escritórios de Advocacia Marcos Cancella - Dir. Jur. Merck - Como a empresa contrata? __ AUDITÓRIO 1 - GRANDES MESTRES DO DIREITO 27 DE ABRIL Sérgio Cavalieri - Des. do TJ/RJ - Curso de Direito e Oportunidades Flavia Bahia Advogada - Controle de Constitucionalidade Juliana / Artur Gueiros - Juíza de Direito / Procurador da República Cooperação Jur. Internacional Claudia Barros - Promotora de Justiça - Homofobia, Racismo e Preconceito. 28 DE ABRIL Marco Aurélio Bezerra - Des. do TJ - Abuso do Direito Ilícito Funcional Rodolfo Hartmann - Juiz Federal - Tendências no Processo Civil EXAME DA OAB - Tire suas dúvidas com os melhores professores do Brasil Diogo Hudson - Consultor - Qual Carreira Jurídica Seguir? 29 DE ABRIL Painel OAB/RJ - Direitos Humanos e Política de Combate às Drogas Humberto Dalla - Promotor de Justiça - Mediação no Novo CPC Elaine Ribeiro - Advogada - Direito do Petróleo, Gás e Energia -- Para se descadastrar, por favor utilize o endereço abaixo: http://teclamailmkt.com.br/dmm/u/7X8m7Be1988N -- Para cancelar seu cadastro, por favor utilize o endereço abaixo: http://teclamailmkt.com.br/dmm/x/7X8m7Be1988N -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/zmd.7x8m7be1988n...@zartana.com
Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo
On 04/18/2011 03:03 PM, Soren Hansen wrote: > Making the package lintian is a great goal! It's not a goal, it's a requirement for any DD before uploading to the archive. > I don't think any of the issues > with the packages would be considered RC problems. Missing (build-)dependencies are considered RC issues in Debian, blocking the release of Debian itself. As for the fact that you had to release it with a schedule date, I *guessed* it myself. Only, saying it explicitly would have helped communication. > "most" being the operative word. You've proposed a bunch of changes, all > of them in the same branch. Can't you just pull each individual patches that you feel ok with? Is it simply not technically possible with bzr? Or is it that with bzr, you can only do a big merge of a given branch? With Git, I'd send a bunch of patches, and you'd pick-up the one one want, and reject the one with issues. That's what I was expecting, sorry if I didn't get it. So, in the future, I should do one branch per proposed merge, for each individual topic, right? That's really not convenient, but I can do that if it is a bzr requirement, so that we can work faster this way... Note that I am *not* discussing git vz bzr (I'm not interested in such a waste of time), I'm just trying to find a work-flow solution. > Also, even though I asked you not to, you went and rebased your branch, > so I had to start over with my review. That cost me quite a bit of time. I did it, because I thought it would *ease* your work, with each individual patch being one a single commit, so that you would cherry-pick the one that you would feel ok with. Now, I do understand that doesn't fit the work-flow of bzr, and that I have to deal with so many small branches. Right? > Admittedly, I get upset and extremely frustrated when people have issues > with me or my work, but instead of confronting me, discuss it with other > people. It's exactly how our collaboration started (instead of > discussing changes with me, you posted on debian-devel to find other > people who wanted to help fix my work). No, that's a bad interpretation. I've been trying to motivate others to work on Openstack packaging for Debian. That isn't in opposition with working with upstream. Let's hope such threads will not definitively push people away from contributing. >> [...] > > [...] and you've proposed them as one, great big branch. I do now understand what you want/need. Many tiny little branches. I'll do that in the future. I hope you can bare with that (first and last) big one. >>> If you expect more than that, I suggest you discuss it with me >> What more do you think we have to discuss, since last week? > > You seem dissatisfied with the process. If that's the case, that's > something we should discuss. I'm really happy you replied to me (privately) so that we can go forward. This goes on the right direction, and I was looking for it. >>> instead of being passive aggressive in other fora about it. >> I reread myself 3 times to make sure I wasn't aggressive, and made >> sure I wouldn't hurt you. Where was I? > > For instance, when you say: > >> My package is lintian clean (the Ubuntu package, really, is not), > > and > >> I have done loads of patches to have the package to fit in Debian, >> comply with the policy, and be lintian clean This is only reality: lintian -Ii through multiple pages of issues at me. I didn't say: hooou, so bad Debian packaging... I just wrote that there was issues lintian showed me, and I fixed them. Reviewing what I did, there's 14 entries that I added in debian/changelog. 9 of them are absolute necessity, and maybe 7 are Debian specific (eg: wouldn't be needed in Ubuntu). That makes only 2 misses in your packaging (some missing dependencies like adduser orpython-amqplib), which is a quite decent score for such a complex package. Never the less, that didn't make it a fit for Debian considering we've hit hard differences between the 2 Unix, especially with the init scripts which needed rewrite. Do you feel more comfortable with the above? > ..along with your above mentioned lecturing on Debian Policy, I feel > you're degrading the work we put into the packages. I'd appreciate if you tried not to take anything as personal attacks. I will try even harder to only write about technical things only. I *have* to stick with the Debian policy. My point isn't to do "lecturing on Debian policy", but to explain what I'm doing and why. > [...] > > Also, pointing out that you've replied to part of it in private seems > passive aggressive or at least disrespectful to me. I sincerely hope, your master god of Openstack and Ubuntu packaging highness, that I wont hurt you again. :) Let's move forward. Thomas P.S: I'm already really tired of this kind of waste of time. I hope it is the last time that I have to reply on non-technical issues, and I wish you restful (deserved) holidays. -- To UNSUBSCRIBE, email to debian-devel-requ...@
Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo
On Tue, Apr 19, 2011 at 02:14:27AM +0800, Thomas Goirand wrote: > On 04/18/2011 03:03 PM, Soren Hansen wrote: > > Making the package lintian [clean] is a great goal! > It's not a goal, it's a requirement for any DD before uploading to the > archive. No, it's not. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo
2011/4/18 Thomas Goirand : > As for the fact that you had to release it with a schedule date, I > *guessed* it myself. Only, saying it explicitly would have helped > communication. Sorry, I don't understand what you're saying here. >> "most" being the operative word. You've proposed a bunch of changes, >> all of them in the same branch. > Can't you just pull each individual patches that you feel ok with? Is > it simply not technically possible with bzr? Short answer: no. Longer answer: Of course it's possible to extract individual patches and apply them elsewhere, but it's tedious, manual and throws away history. We bzr users care deeply about history :) > Or is it that with bzr, you can only do a big merge of a given branch? That's the common workflow. > So, in the future, I should do one branch per proposed merge, for each > individual topic, right? That's really not convenient, It's really not very complicated. "bzr branch trunk some-branch-name", hack, "bzr push lp:~soren/nova/some-branch-name". Done. > but I can do that if it is a bzr requirement, so that we can work > faster this way... That would be great, thanks. >> Also, even though I asked you not to, you went and rebased your >> branch, so I had to start over with my review. That cost me quite a >> bit of time. > I did it, because I thought it would *ease* your work, with each > individual patch being one a single commit, so that you would > cherry-pick the one that you would feel ok with. > > Now, I do understand that doesn't fit the work-flow of bzr, and that I > have to deal with so many small branches. Right? Branches are by far the most convenient way to provide patches, yes. That's how we handle everything else in Openstack. > I do now understand what you want/need. Many tiny little branches. > I'll do that in the future. I hope you can bare with that (first and > last) big one. Yeah, I think we're pretty close on that one now. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=y0b6joSWtq4+LCRnr=qg+jep...@mail.gmail.com
Bug#623274: ITP: chipmunk -- fast and lightweight 2D rigid body physics library in C
Package: wnpp Severity: wishlist Owner: Miriam Ruiz * Package name: chipmunk Version : 5.3.4 Upstream Author : Scott Lembcke * URL : https://code.google.com/p/chipmunk-physics/ * License : MIT Programming Lang: C Description : fast and lightweight 2D rigid body physics library in C Chipmunk is a simple, lightweight, fast and portable 2D rigid body physics library written in C. It's licensed under the unrestrictive, OSI approved MIT license. Its aim is to give 2D developers access the same quality of physics you find in newer 3D games. -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011041800.24748.65707.report...@alioth.debian.org
