Bug#640885: ITP: ruby-ttfunk -- Ruby library to parse TrueType font metrics
Package: wnpp Severity: wishlist Owner: "Cédric Boutillier" Hi! I would like to package ruby-ttfunk, under the umbrella of Ruby Extras Team. This font metrics parser is a dependency of a newer version of libprawn-ruby (soon to be renamed ruby-prawn). * Package name: ruby-ttfunk Version : 1.0.2 Upstream Author : Gregory Brown and others * URL : https://github.com/sandal/ttfunk * License : Ruby or GPL-2 or GPL-3 Programming Lang: Ruby Description : Ruby library to parse TrueType font metrics TTFunk is a TrueType font parser written in pure Ruby. It gives access to various data included in a .ttf file, including the name, family, subfamily of the font, as well as some metrics information. TTFunk can be used by Ruby PDF generation libraries, like ruby-prawn. Best wishes, Cédric signature.asc Description: Digital signature
Mobile UXes - From the DebConf11 BoF to the stars
Hi all, This is the sumary of the discussion held at DebConf11 during the "Mobile UXes" BoF, on 2011-07-29, at 18h00 in the meeting room. (= tl;dr version =) (Search for "Proposal" down this mail.) (Please answer to debian-devel@lists.debian.org only. ) The point of this mail is to inform people and communities of the content of those discussions and propose a sort-of plan of action. Note that nothing has been clearly decided there but the discussion was really nice and promising so I sort-of hope the consensus acknowledged upon there can be reflected online. = Outline = 0 - Commented overview of the various available stacks 1 - Proposal for future actions and meet-together = 0 - Commented overview of the various available stacks = The initial idea to frame the discussion was to share experiences and opinions about known free software mobile stacks: are they packaged in Debian? What has been the experience so far? If not, why not? The main reference to build up this list has been http://wiki.debian.org/Smartphone, which is still a good reference! Now to the list. == Android == The Canonical effort [0] to port an Android execution environment is currently reported as a dead-end. The most free-software-friendly efforts reported are IcedRobot [1] and Replicant [2]. They don't seem ready enough for inclusion in Debian though but we should keep an eye on them. [0] https://wiki.ubuntu.com/Specs/AndroidExecutionEnvironment [1] http://icedrobot.org [2] http://replicant.us/ == MeeGo == Back when the MeeGo project was launched, some hoped it could be Debian-based. Some persons from the Debian community tried to make that a reality back then but didn't succeed. Then the pkg-meego team [3] was formed to get software produced by the MeeGo project in Debian. This effort has faced a tough reality with regards to project management, interfaces stability, FHS respect, trademark policies, etc; and as a result it is currently stalled. Nowadays, various software pieces produced by or within the MeeGo project are probably interesting to get in Debian: - Maliit [4] it is the input methods solution used in MeeGo (in particular it's the project behind the Harmattan virtual keyboard / input method; also used for the N900/N950 Community Edition) - the Tablet User Experience [5] released by Intel earlier this year. - Handheld UX in the MeeGo CE form [6] As a side-note; the software released with the Nokia N9 (of which the "swipe" user interface [7] is not known to be available as free software) is available as a downloadable qemu image [8]. MeeGo CE [9] is a community effort both to make free MeeGo releases for a few smartphones, and to make MeeGo as a project more transparent by being an example of a contributing "vendor". Since the project aims for a product level quality in the UIs, the packages they've put on top of MeeGo Core and integrate back to the Core are interesting for Debian as well. Timo Jyrinki wrote a very interesting blogpost on this topic [10]. [3] http://pkg-meego.alioth.debian.org/ [4] http://maliit.org [5] https://meego.com/downloads/releases/1.2/meego-tablet-developer-preview [6] https://build.pub.meego.com/project/packages?project=Project%3ADE%3ATrunk [7] http://www.developer.nokia.com/swipe/ux/ [8] http://harmattan-dev.nokia.com/ [9] http://wiki.meego.com/N900 [10] http://losca.blogspot.com/2011/08/meego-ce-and-freesmartphoneorg.html == Maemo == Maemo [11] is the Debian derivative that powers the Nokia N900 that was one branches of the MeeGo merge. Nowadays, both Maemo 6 and Harmattan (software basis of the Nokia N9) are reported to be dead-ends. A Debian team [12] was formed to work on the inclusion of the Maemo software back in Debian, but it decided earlier this year that Maemo is a dead end and removed Maemo related software from Debian [13]. It could still make sense to package some of the Maemo GTK themes to make running unmodified GTK applications easier on mobile devices. Openmoko also produced some. [11] http://maemo.org [12] http://wiki.debian.org/pkg-maemo [13] http://article.gmane.org/gmane.linux.debian.alioth.maemo.maint/1013 == GNOME Mobile & Embedded Initiative == The GNOME Mobile & Embedded Initiative was announced in 2007 for developing and promoting the use of the GNOME platform in mobile devices. It is not packaged in Debian (although the GNOME team might be able to give more insightful information) and doesn't seem to have a home on the Internet. It is part of the Hackable1 distribution (see below). == KDE Plasma Active == From their website: "KDE Plasma Active [14] aims at creating a cross-device user experience for emerging devices such as tablet computers, media centers, smartphones, and more." It is currently not packaged in Debian, but some members of the pkg-qt-kde team could certainly be interested [15]. [14] http://community.kde.org
Re: Bug#640721: ITP: xf86-video-omap -- X.Org X server -- OMAP display driver
Sebastian Reichel (07/09/2011): > I would be glad if you can give the package (available from [0]) a > quick review before I upload it to experimental. You can change > Architecture to any if you want to build it on a x86 system for > testing purposes (OMAP chips are ARM based, but the code can be > compiled on other platforms, too). You may want to expand the “need opendrm” bits. Mentioning the relevant package might help users to get stuff they need. I guess you'll mention that once you have a DKMS-enabled module? You should specify a versioned build-dep on xserver-xorg-dev (>= 2:1.9.4) to use the xsf sequence. That would work without it on wheezy or sid, but would fail on squeeze. You probably want “mkdir -p m4”. If one interrupts the build, and starts it again, running “mkdir m4” again will fail. Looks good otherwise. Mraw, KiBi. signature.asc Description: Digital signature
Bug#640917: ITP: liblog-report-perl -- report a problem, pluggable handlers
Package: wnpp Owner: Fabrizio Regalli Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: liblog-report-perl Version : 0.94 Upstream Author : Mark Overmeer * URL : http://search.cpan.org/dist/Log-Report/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : report a problem, pluggable handlers and language support Handling messages to users can be a hassle, certainly when the same module is used for command-line and in a graphical interfaces, and has to cope with internationalization at the same time; this set of modules tries to simplify this. Log::Report combines gettext features with Log::Dispatch-like features. However, you can also use this module to do only translations or only message dispatching. signature.asc Description: This is a digitally signed message part
Dự Án Elegance Town
Khu Thương Mại ELEGANCE TOWN Khu phố thương mại ELEGANCE TOWN Vị trí của giá trị và tiềm năng Khu phố thương mại ELEGANCE TOWN nằm trong tổng thể quy hoạch Khu đô thị Tam Phước 300ha, tọa lạc ngay mặt tiền đường vành đai Biên Hòa - Sân bay quốc tế Long Thành lộ giới 45m, thuộc Xã Tam Phước, TP. Biên Hòa, Đồng Nai - Cách trung tâm TP. HCM 30km, TP. Biên Hòa 10km - Cách trung tâm hành chính mới Tỉnh Đồng Nai 3km - Ngã ba Thái Lan 2,2km - Chợ An Bình 2km - Sân bay quốc tế Long Thành 8km - TP du lịch sinh thái Sơn Tiên 8km, KDL Thác Giang Điền 6km - Cách trạm dừng chân bò sữa Long Thành 4,5km - Cách trạm dừng chân tập đoàn Trung Thủy 4,7km - Sân golf Long Thành 7km - Cảng Container Đồng Nai 3,5km Liền kề các Khu công nghiệp và Khu dân cư lớn hiện hữu: - Cách KCN Long Thành 4.2 km, KCN Tam Phước 0.4km, KCN Giang Điền 4km - Cách Khu dân cư Thung Lũng Xanh 4,5km, Khu dân cư Tam Phước 0.6km - Cách Khu dân cư Phú Tín 1km, Khu dân cư Phú An 2.5km Tiện ích vượt trội Xứng tầm với một vị trí giá trị đầy tiềm năng, trong bán kính 3km dự án hội tụ tất cả các tiện ích vượt trội của một Khu phố thương mại và dịch vụ. Mang đến cho cư dân nơi đây một cuộc sống đẳng cấp và hoàn hảo. - Trung tâm hành chính - Nhà hàng - Siêu thị, chợ, bệnh viện - Trường mầm non, cấp I-II-III, Trung cấp, Cao Đẳng - Các khu du lịch sinh thái - Công viên cây xanh - Khu thể thao tổng hợp Quy hoạch - Kiến trúc -Nhà liên kế phố: Diện tích: 82 - 112m2 -Ngôi nhà của bạn sẽ được ngự trị ở những vị trí đẹp đẽ, thoáng mát hòa hợp với thiên nhiên và phong thủy tốt.Đặc biệt bạn sẽ thỏa sức sáng tạo cho ngôi nhà của mình những khoảng sân vườn, tiểu cảnh và hòn non bộ đầy nghệ thuật lãng mạn, mát mẻ và đẹp đẽ với không gian riêng đối diện... -Quy hoạch đồng bộ -Cơ sở hạ tầng hoàn chỉnh -Sổ đỏ trao tay -Giá gốc chủ đầu tư -Thanh toán linh hoạt Mọi Chi Tiết Xin Liên Hệ : TRỤ SỞ CTY CỔ PHẦN ĐẤT XANH ĐỒNG NAI 11 Lô C1, Quốc lộ 51, Phường Long Bình Tân, Biên Hòa, Đồng Nai Điện Thoại: (061) 6 266 288 - Fax: (061) 8 826 152 SÀN GIAO DỊCH-CHI NHÁNH BIÊN HÒA 288A, Phạm Văn Thuận, P.Thống Nhất, Biên Hòa, Đồng Nai Điện Thoại: (061) 6 255 266 - Fax: (061) 6 290 690 ĐẤT XANH ĐỒNG NAI - CHI NHÁNH TRẢNG BOM 30B Đường 29/4, KP.5, Thị trấn Trảng Bom, Trảng Bom - Đồng Nai Điện thoại: (061) 6 292 888 - Fax: (061) 6 291 888 Hotline: 0966.59.59.39- Email : an...@datxanh.com.vn - www.chondiaoc.vn
Re: Bug#640721: ITP: xf86-video-omap -- X.Org X server -- OMAP display driver
On Thu, Sep 08, 2011 at 02:23:51PM +0200, Cyril Brulebois wrote: > Sebastian Reichel (07/09/2011): > > I would be glad if you can give the package (available from [0]) a > > quick review before I upload it to experimental. You can change > > Architecture to any if you want to build it on a x86 system for > > testing purposes (OMAP chips are ARM based, but the code can be > > compiled on other platforms, too). > > You may want to expand the “need opendrm” bits. Mentioning the relevant > package might help users to get stuff they need. I guess you'll mention > that once you have a DKMS-enabled module? I will add a Recommends statement and update the description when the DKMS package is ready. > You should specify a versioned build-dep on xserver-xorg-dev (>= 2:1.9.4) > to use the xsf sequence. That would work without it on wheezy or sid, but > would fail on squeeze. > You probably want “mkdir -p m4”. If one interrupts the build, and starts > it again, running “mkdir m4” again will fail. OK. > Looks good otherwise. thanks for the review. -- Sebastian signature.asc Description: Digital signature
Re: Mobile UXes - From the DebConf11 BoF to the stars
Hello, 2011/9/8 Stefano Zacchiroli : > On Thu, Sep 08, 2011 at 10:36:17AM +0200, Didier Raboud wrote: >> c) Create a new Alioth project, 'mobile-ux', with associated >> mailing-lists and a wiki page. > Given you are going to provide a central discussion forum for Debian > "mobile" stuff, you might want to be a bit more bold and request the > "debian-mobile@lists.d.o" mailing list. That might provide some more > visibility to this laudable initiative. "mobile-ux" was proposed instead "mobile", so it makes it more clear, that UX is the primary focus, as low level software is already handled by other debian or upstream mailing lists, i.e. debian-kernel, debian-arm, linux-arm-kernel, ... Debian seems to have all parts needed for mobile world, but a it lacks a mobile GUI, while it has too many desktop oriented GUI, none of those seem to fit the mobile market. With kind regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- 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/CAODfWeF28_C_7BeRKKGoCGurgzr=qy1etdayvbrjrg3gulk...@mail.gmail.com
Re: Maintainers, porters, and burden of porting
On Mon, Aug 29, 2011 at 08:58:34AM +0200, Lucas Nussbaum wrote:
> TL;DR: I think that we should have a discussion about the respective
> roles & responsibilities of maintainers and porters with regard to
> porting.
I've re-read this discussion a couple of times, with the intention of
summarizing it and propose how to proceed. The discussion has been
interesting, and it even seems to me that several of the positions
expressed are in fact in agreement with each other, despite the various
rebuttals on marginal points. My problem is that the *concrete* goal of
this discussion is obscure to me.
Let me recap. The problem raised by Lucas is clearly concrete. There are
hard porting bugs out there and they might hit packages with a lot of
reverse dependencies ("key packages") such as Ruby. Due to incomplete
knowledge, often neither porters nor maintainers working alone will be
able to fix them. That's why collaboration among the two is what we
recommend. But it also happens that some of those bugs are too hard to
fix, maybe temporarily due to manpower shortage, maybe for a long time.
We can clarify responsibilities and push them nearer maintainers or
nearer to porters, but I don't think that would change anything. It's
not like an overworked (or MIA) porter (or maintainer) will be more
likely (or more able) to fix a bug, just because suddenly it's more of
their responsibility to do so than it was before. So, *if* the point of
the discussion is assigning responsibility --- point that seems to be
the most controversial of the thread --- I don't think I see the point.
Still, this kind of discussion is recurrent. We clearly need to do
something about it. Here are a couple of proposals:
- We have an unhealthy asymmetry: a package $pkg who has never been
built (or has never worked without anybody noticing) on $arch don't
get in the way of a maintainer, while if $pkg suddenly stops working
on $arch it will get in the way of the maintainer as it blocks testing
migration.
I think maintainers should be empowered more to fiddle with the
Architecture list of their packages, but also that they should give
some sort of explanation (as simple as bug report pointers) for the
architectures they do not support. In the Ruby example, if the
maintainer has tried to fix the porting issue, asked the porters for
help, and still failed, then he should be allowed to file a "RM: ruby"
request (Pabs' point in this thread).
As observed by Phil, there will be a big fallout for a package like
Ruby. But *if* everything else have been tried by both maintainers and
porters, we don't have many other options. My point is: if the
maintainers were "allowed" not to support $arch for a NEW package in
Debian, they should be "allowed" to do the same for a subsequent
version. The point of the justification is to discourage maintainers
not to support $arch just because they are too lazy to do so.
Hopefully, not having $pkg on $arch would raise the visibility of the
issue and attract attention to fix the issue. In the meantime, the
fact that $pkg is not on $arch (and the justification for that) could
be used by the release team as a basis to decide whether $arch is in a
releasable state or not, exactly as it would be if $pkg were a NEW
package in the archive.
- Being able to judge whether the maintainers have done their part in
reaching out to porters is a requisite for the above. And to do so, we
really need more visibility of those exchanges. According to devref
[1], the contact points we currently recommend are both the
debian-$arch mailing lists and the $a...@buildd.debian.org addresses.
Is there any reason why the latter are not public? Or, conversely, is
there any reason why we cannot expect that people on $arch@buildd.d.o
are also on debian-$arch lists (maybe forcing specific mail
conventions to reduce mail load on people running the buildds)?
[1] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#porting
> Release team, there's a question for you regarding ruby1.9.1 in the
> last paragraph.
Has this one been answered? (unless it was a rhetoric question :))
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Maintainers, porters, and burden of porting
* Stefano Zacchiroli (z...@debian.org) [110908 19:22]: > I think maintainers should be empowered more to fiddle with the > Architecture list of their packages, but also that they should give > some sort of explanation (as simple as bug report pointers) for the > architectures they do not support. In the Ruby example, if the > maintainer has tried to fix the porting issue, asked the porters for > help, and still failed, then he should be allowed to file a "RM: ruby" > request (Pabs' point in this thread). I disagree a bit here, tripple actually. In any case, the package maintainer should ask the porters for help. Just removing an architecture from the list of supported architectures isn't a proper way to deal with it. Failing to get sufficient support, removing then is still an option (and if urgent testing migration is required speaking with the release team helps). Also, if a package doesn't build, changing the architecture list has no impact on the testing migration. The only relevant action is removing the relevant binary packages. The architecture list could be the same - it has no impact at all at the testing migration. And last not least, if a package has many / relevant reverse dependends, the package maintainer should speak with the release team first because the package (e.g. ruby without sparc) won't make it to testing anyways otherwise. > Hopefully, not having $pkg on $arch would raise the visibility of the > issue and attract attention to fix the issue. In the meantime, the > fact that $pkg is not on $arch (and the justification for that) could > be used by the release team as a basis to decide whether $arch is in a > releasable state or not, exactly as it would be if $pkg were a NEW > package in the archive. I disagree with "let's first remove things". If a package like ruby doesn't build on sparc this bug report is RC exactly as long as sparc is a release arch. The release team has (and does) override such bug reports for testing migration if appropriate. Removing the binary package doesn't help at all but just makes things worse. So please don't do it, especially for packages with reverse dependencies. > - Being able to judge whether the maintainers have done their part in > reaching out to porters is a requisite for the above. And to do so, we > really need more visibility of those exchanges. According to devref > [1], the contact points we currently recommend are both the > debian-$arch mailing lists and the $a...@buildd.debian.org addresses. > > Is there any reason why the latter are not public? Yes. Because one of the most frequent users is the security team asking where this and that security build is. We don't want that public for obvious reasons. > Or, conversely, is > there any reason why we cannot expect that people on $arch@buildd.d.o > are also on debian-$arch lists (maybe forcing specific mail > conventions to reduce mail load on people running the buildds)? Yes. The difference is: $arch@buildd is to reach the buildd admins. debian-$arch is to reach the porters. There might be overlaps, but it's definitly not the same. Porting and maintaining a buildd are two different tasks, and the required skills for porting are different than for maintaining a buildd. I know good porters who are bad buildd admins, and good buildd admins who are bad porters. The current setup allows e.g. to shift buildds around as needed for vacations, which would be way more ugly if I would have to subscribe to all porter lists. Andi -- 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/20110908173441.go15...@mails.so.argh.org
Re: Maintainers, porters, and burden of porting
[ No Cc: please ]
On Thu, Sep 08, 2011 at 07:34:41PM +0200, Andreas Barth wrote:
> I disagree a bit here, tripple actually.
Actually, I think we are in agreement:
- I've said that contacting the porters is a prerequisite before
fiddling with the Arch list. RM is the last option.
- With "fiddling with the Arch list" I didn't mean only the Architecture
line, but generally acting on the arch binaries of a given package,
including actions such as RM (my bad for the unclearness)
> And last not least, if a package has many / relevant reverse
> dependends, the package maintainer should speak with the release team
> first because the package (e.g. ruby without sparc) won't make it to
> testing anyways otherwise.
I agree with this as well. FWIW, in this specific case the maintainer
has done exactly so (and is waiting for an answer).
> I disagree with "let's first remove things".
Me too :-) I haven't said "first", but "last".
> Yes. Because one of the most frequent users is the security team
> asking where this and that security build is. We don't want that
> public for obvious reasons.
> The difference is:
> $arch@buildd is to reach the buildd admins.
> debian-$arch is to reach the porters.
Fair enough, but porting issues often appear first as buildd issues and
if we expect maintainers to contact buildd maintainers before proceeding
with other investigations, it would be way better if at least those
exchanges were public.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Maintainers, porters, and burden of porting
* Stefano Zacchiroli (z...@debian.org) [110908 19:53]: > On Thu, Sep 08, 2011 at 07:34:41PM +0200, Andreas Barth wrote: > > Yes. Because one of the most frequent users is the security team > > asking where this and that security build is. We don't want that > > public for obvious reasons. > > > The difference is: > > $arch@buildd is to reach the buildd admins. > > debian-$arch is to reach the porters. > Fair enough, but porting issues often appear first as buildd issues and > if we expect maintainers to contact buildd maintainers before proceeding > with other investigations, it would be way better if at least those > exchanges were public. I wouldn't expect maintainers to contact them first. I would expect them to contact buildd admins if it looks as buildd (e.g. "package is building since a week but no log or upload" or "log says successful but no upload"). However, I wouldn't complain at anybody who contacts porters directly, there is some information flow between porters and buildd admins, and also some porters have access to change wanna-build states. It might just be that contacting porters isn't the fastest way to get it done. Looking at my inbox and the mips porter list, this part seems to work reasonably well. Andi -- 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/20110908193703.gp15...@mails.so.argh.org
Bug#640954: ITA: unclutter -- hides the cursor in X after a period of inactivity
Package: wnpp Severity: normal Daniel Baumann has orphaned unclutter [1] without filing an according "O:" bug, hence this initial ITA. [1] http://packages.qa.debian.org/u/unclutter/news/20110908T084841Z.html He also already removed the previous packaging git repository[2], but I cloned a copy before that and started to continue the packaging at [3]. [2] http://git.debian-maintainers.org/?p=daniel/unclutter.git [3] http://anonscm.debian.org/gitweb/?p=collab-maint/unclutter.git Co-maintainers welcome. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- 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/20110908210557.82ce0896...@sym.noone.org
Re: Mobile UXes - From the DebConf11 BoF to the stars
On Thu, Sep 8, 2011 at 6:44 PM, Hector Oron wrote: > Debian seems to have all parts needed for mobile world, > but a it lacks a mobile GUI E17 is available in Debian and has a mobile GUI, also in Debian. We do need more finger friendly apps and UI themes though, specifically more stuff from SHR. On the non-X11 side of things, getting QtMoko in would be nice. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6f_gnpavnncgpndbfn66+-_bboa5ytl0syszgrrsts...@mail.gmail.com
Re: Mobile UXes - From the DebConf11 BoF to the stars
Hi, Hector Oron wrote: > >> c) Create a new Alioth project, 'mobile-ux', with associated > >> mailing-lists and a wiki page. > > > > Given you are going to provide a central discussion forum for Debian > > "mobile" stuff, you might want to be a bit more bold and request the > > "debian-mobile@lists.d.o" mailing list. Seconded. > "mobile-ux" was proposed instead "mobile", so it makes it more clear, Well, I think "UX" is a uncommon and not very well-known abbreviation I had to google twice since DebConf what it stands for. My first thought always that it's a strange abbreviation for "Unix". > that UX is the primary focus, as low level software is already handled > by other debian or upstream mailing lists, [...] Why then "UX" and not "GUI"? Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- 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/20110908220533.gb7...@sym.noone.org
Bug#640970: ITP: ibus-googlepinyin -- googlepinyin engine for ibus
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: ibus-googlepinyin Version: 0.1.1 Upstream Author : Jiahua Huang URL: http://code.google.com/p/libgooglepinyin/ License: GPLv2+ Programming Lang: python Description: googlepinyin engine for ibus -- YunQiang Su -- 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/cakcpw6ul0ekmhjvsfuaenvohjphlck-utl+xed1jpfre1u0...@mail.gmail.com
Mistake in postrm preventing functioning of newer package (stable/testing/unstable)
Hello fellow developers, recently I uploaded a new version of bpython -- from 0.9.7.1-1 to 0.10.1-1 -- and I switched from dh_pysupport to dh_python2 in the meanwhile. However, I didn't notice a huge upgrade bug: 0.9.7.1-1's postrm inconditionally removed /usr/lib/python*/*-packages/bpython (I can't exactly remember why I put it there in the first place), and this seems to have effect on files installed by 0.10.1-1 as well -- with dh_python2, symlinks are shipped in the package and not created at install-time. The first solution I thought was to re-switch from dh_python2 to dh_pysupport, fixing the postrm and waiting for the package to enter testing. Only then, upload a dh_python2 version to sid. However, the buggy postrm is also present in stable, so the above trick won't work when users will upgrade from stable to new-stable. Since there's a point release coming, I wonder whether the right course of action now is: fixing the package in stable plus what described above. I'm CCing also debian-release, to check if a fix would be ok (I'd just remove the postrm altogether). Here's the buggy postrm (not present anymore in current sid's package): http://anonscm.debian.org/gitweb/?p=collab-maint/bpython.git;a=blob;f=debian/postrm;h=4e4a5210885d193617ead71438f8f36770999835;hb=cb96a5958ebd821e86fcc0cbd69ffb6bafd97380#l26 Thanks for any suggestion, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
