Re: Moving /tmp to tmpfs is fine
2012/5/30 Thomas Goirand wrote: >> You mean you know some real applications becoming noticeably faster >> having /tmp on tmpfs? > > No, I mean that writing "nobody can notice that on real applications" > is a bit too extreme, that's all I'm saying. Right, sorry. Of course, I may be wrong, there can be such applications. It's just nobody had suggested them yet. -- Just trying to make the world better, Serge -- 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/caovenepexlsxzgvqabqqd-1mr-exryqh4c1kddhno3ppfxw...@mail.gmail.com
Re: Bug#675106: ITP: pgbulkload -- A high speed data loading utility for PostgreSQL
> Alexander Kuznetsov writes: […] (Some wording fixes and suggestions.) > Description : A high speed data loading utility for PostgreSQL > pg_bulkload is designed to load huge amount of data to a database. > You can choose whether database constraints are checked and how many errors > are If “You can…” here starts a new paragraph, there's ought to be an empty (“.”) line. And if not, the linebreak here came a bit too early than necessary. > ignored during the loading. For example, you can skip integrity checks for > performance when you copy data from another database to PostgreSQL. On the > other hand, you can enable constraint checks when loading unclean data. > . Are “constraint checks” different to “integrity checks” in the above? Unless they are, it should rather be, e. g.: … For example, you can skip integrity checks for performance when you copy data from another database to PostgreSQL, or have them in place when loading potentially unclean data. > The original goal of pg_bulkload was an faster alternative of COPY command in … was /a/ faster… Or, perhaps: … was to provide a faster… > PostgreSQL, but version 3.0 or later has some ETL features like input data > validation and data transformation with filter functions. > . … but as of version 3.0 some ETL features… were added. And what's ETL, BTW? > In version 3.1, pg_bulkload can convert the load data into the binary file > which can be used as an input file of pg_bulkload. If you check whether Perhaps: As of version 3.1, pg_bulkload can dump the preprocessed data into a binary file, allowing for… (Here, the purpose should be mentioned. Is this for improving the performance of later multiple “bulkloads”, for instance?) > the load data is valid when converting it into the binary file, you can skip > the check when loading it from the binary file to a table. Which would reduce > the load time itself. Also in version 3.1, parallel loading works > more effectively than before. s/effectively/efficiently/. But the whole sentence makes little sense, as the earlier versions weren't packaged for Debian. -- FSF associate member #7257 -- 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/86wr3ujphk@gray.siamics.net
Re: Packaging on GitHub ?
> Thorsten Glaser writes: > Charles Plessy dixit: >> upstream source moved to GitHub, and we would like to try to >> maintain the Debian package there as well. > This is not a good idea: http://mako.cc/writing/hill-free_tools.html That's why I tend to advocate for the use of Gitorious instead. --cut: http://en.wikipedia.org/wiki/Gitorious -- CAPTION: Gitorious Developer(s) Shortcut AS Written inRuby Operating system Cross-platform Available in English Type Project management software License GNU Affero General Public License Website https://gitorious.org/gitorious/ --cut: http://en.wikipedia.org/wiki/Gitorious -- PS. An RFP, perhaps? -- FSF associate member #7257 -- 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/861um2l4w9@gray.siamics.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/30/2012 03:51 AM, Jonas Smedegaard wrote: > I strongly object to this as a general principle: Debian freezing is no > excuse for hijacking! > That's not the reason, the reason is that we've been working on tools to improve PHP package quality, and recently noticed that php-codesniffer was left largely unmaintained since 2008. > Seems you had several years of solving this issue, yet you waited until > just before freeze No, me and Luis Uribe just recently found interest in it, and thought it'd be great to have it in Wheezy too. > and the option you came up with was to kick a > maintainer. > We aren't kicking him, we want to have the package team maintained. He's fine to come and join! > Did you consider an NMU? > Yes, but the issue is that there's lots of invasive changes that we would like to make to the packaging. Having a look to the current state of the package, it'd be nearly totally re-written. There's not a single line in the debian/control file that satisfies me, I'd like to move from dh_php_make to pkg-php-tools (that implies, from CDBS to dh 8 sequencer), etc. This doesn't really qualify for an NMU, nor does the upgrade to the latest upstream version. On 05/30/2012 07:45 AM, Charles Plessy wrote: > I concur. It is socially and technically safer to give about two week-ends to > answer, keeping time zones in mind. My reasoning over the one week only was that the package hasn't been maintained since 2008, so that anyways, it feels like the package isn't well enough maintained to be left to Jack sole responsibility. Again, he would be free to join the PKG PEAR team. But I'll wait one more week as you suggest then, this doesn't mater much... > If after this delay you have no news, my > opinion is that hijacking is the best solution. The maintainer's other > packages have already attracted three NMUs in total, and I have not seen a bug > report with his answer after 2009 (although got some packages sponsored in > 2011). By the way, perhaps you can keep his sponosor (rmgolbeck) in the loop, > maybe he knows other ways to contact the maintainer ? > rmgolbeck is Cc: to this mail. Cheers, Thomas Goirand (zigo) -- 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/4fc59455.9060...@goirand.fr
Re: Moving /tmp to tmpfs is fine
On 05/30/2012 10:07 AM, Serge wrote: > 2012/5/28 Thomas Goirand wrote: > > >>> The truth is that tmpfs IS FASTER in some cases. The problem is that >>> *nobody* can notice that on *real* applications. >>> >> Serge, I'm on your side of the discussion, but the above is simply >> not truth. >> > You mean you know some real applications becoming noticeably faster > having /tmp on tmpfs? > No, I mean that writing "nobody can notice that on real applications" is a bit too extreme, that's all I'm saying. 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/4fc5905b.3090...@debian.org
Re: Moving /tmp to tmpfs is fine
2012/5/27 Ben Hutchings wrote: >> then /tmp using tmpfs *will* lead to issues that many wont understand. > As will /tmp on a small root partition. > As will a small dedicated /tmp partition. True. But debian does not have small root partition *by default*. And it does not install with a small dedicated /tmp partition *by default* as well. Then why does it installs with /tmp on tmpfs *by default*? Users don't like thinking about partitions size, and they don't care much about fragmentation or number of I/O. The most common configuration would probably be entire system on a single partition, optionally in dual-boot with other OSes (i.e. there could be other FAT/NTFS partitions there). TMPDIR on a root partition is the best and only option there. It's good for large files, isn't limited by memory size, don't cause system swapping and is as fast as cached local storage can be. > A shared /tmp also results in various security problems Agree, having a shared /tmp may sometimes be an interesting idea, but it is also bad to have it *by default* > We should be thinking about implementing per-user temporary directories There're a lot of other places where TMPDIR can be. Let's consider all of them. Where else we can put tmp directory: 1. /tmp (TMPDIR on a root partition) Good for systems of regular users. But bad for systems with read-only or small root partition (rare, *never* happens in default install, but still happens). 2. /home/tmp (TMPDIR on a home partition) Good for systems that want users to obey /home quotas or having read-only root. But bad for shared (NFS) /home (not that rare, but still possible). Also bad for users with separate /home partition, who care about their data: when / dies you can recover data from your /home, and tmp on /home will just increase chances of /home death. 3. /home/USER/tmp Same as above, but in addition it's also bad for ssh servers where users share files over /tmp directory (they just don't have a choice there). 4. /bin/tmp Not really useful. But if we name it /bin/trash... hey, we have a trash in a bin! ;) 5. /var/tmp Oh, we already have that. 6. /tmp on a separate partition Common for servers, eats no RAM, have all the limits/quotas working. But needs some brain work and complex in resizing, so it's bad for regular users. 7. /OTHERDIR/tmp Same as above, if OTHERDIR on a separate partition. And same as #1 if OTHERDIR is on a root partition. 8. /tmp on tmpfs Bad for large files. Bad for low-memory systems (i.e. routers, cheap netbooks, tablet PCs, mobiles), which are more and more common nowadays. But still the only option for systems that have slow (network-mounted) /home and /var partitions, and read-only root, and need to work FAST with a lot of small files (I've never seen such case myself, but it is still possible anyway). As you can see each of them have problems. So the one, that causes the fewest problems in default setup should be the default. Isn't it? People, with some unusual installations are customizing their defaults anyway, so they can change /tmp location themselves as well (i.e. do a `mount --bind /tmp /home/tmp` for read-only setup). > We should be thinking about implementing per-user temporary directories > and making sure that programs respect $TMPDIR. That's not enough. Applications need a special temporary directory. The one that is cleaned on reboot. Of course apps should clean their files themselves, but they should not worry about cleaning files after i.e. an unexpected power outage. That's what /tmp is good for. So if you click on a few files in firefox and then your lights turn off, on next reboot firefox should not look through $TMPDIR and delete files that were created by it on last boot. Of course we can write an additional init-script that will automatically clean all user-specific TMPDIRs, it would have to be a very smart script, it should work for local /home as well as i.e. NFS /home, and must not clean all the directories when one of machines reboots. It should probably support things like LDAP, or unusual home-directories like /var/guest. It will surely require a lot of work and probably will cause a lot of problems. But it is possible... I don't see what for, but it's possible. Or maybe we can just leave /tmp as a part of / partition *by default*, since by default it's large enough, cleaned on boot, works for all programs and causes no worries? ;) > I'm not sure whether that's compatible with historical use of /tmp by > the X window system.) I guess it's not. Because when X starts you don't know what user will log in there. PS: see also idea about on-demand mount of /tmp to tmpfs for systems with disk space check. It would make the defaults working even for small and read-only root fs. -- Serge -- 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/caovenerwrhneye0tbktzr58myipege+75xqrf
Re: Moving /tmp to tmpfs is fine
2012/5/28 Thomas Goirand wrote: >> The truth is that tmpfs IS FASTER in some cases. The problem is that >> *nobody* can notice that on *real* applications. > > Serge, I'm on your side of the discussion, but the above is simply > not truth. You mean you know some real applications becoming noticeably faster having /tmp on tmpfs? > And by the way, that's not the issue. The issue is potential > breakage, which we want to avoid *at all costs*. That does not work. I tried that. When I say "Hey, a lot of software breaks because of your change", I get the answer "It's not my change in fault, it's the software, go fix it". This is exactly what I got in that thread, by the way. But when I say "Hey, your change have broken a lot of software and brought nothing good", then people start thinking, why should they mess with fixing a lot of software, if they get nothing in return anyway. This is what we have with "/tmp on tmpfs" change. -- Serge -- 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/CAOVenErJhn54esbuqxn6HHARXPJMeDj4WzxCuSf3KXm=n=_...@mail.gmail.com
Bug#675131: ITP: vpnc-scripts -- Network configuration scripts for vpnc and openconnect
Package: wnpp Severity: wishlist Owner: Mike Miller * Package name: vpnc-scripts Version : 20120526 Upstream Author : David Woodhouse * URL : http://www.infradead.org/openconnect/vpnc-script.html * License : GPL-2+ Programming Lang: Shell Description : Network configuration scripts for vpnc and openconnect This package contains scripts to configure routing and name services when invoked by the vpnc or openconnect Cisco VPN clients. The primary script is derived from the vpnc source but provides hooks for user customization. Alternate scripts that keep the VPN configuration in its own network namespace are also provided. -- 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/20120530020039.12455.15427.report...@ohm.home.local
Re: Moving /tmp to tmpfs makes it useless
On Mon, May 28, 2012 at 08:26:52AM -0400, Weldon Goree wrote: > at some point). Much better developers than me seem to have formed > this opinion too (cf browsers' behavior while it waits for you to tell > it what to do with an unknown content-type: it's a disk-based pipe to > whatever program you pick to open it, except now it's a memory-based > pipe, and I think /tmp on tmpfs is breaking those developers' > expectations). As for Iceweasel, there is a bug in Mozilla's database that addresses exactly this problem. In the overwhelming number of cases of people downloading large files via their web browser, these files are going to end up somewhere in their homes, anyway, so the initial downloaded fragments should be stored there. Although I haven't paid attention to that bug as of late, I do remember seeing some activity going on there, and I think the Mozilla developers have been finally convinced to adopt a different strategy. > I'd be more comfortable with tmpfs if it could be quota'd with > standard quota tools. If this part goes to your home, it's automatically quota'ed. > > Having /var/run on a tmpfs may be a good idea, though. > Gah! I want *somewhere* I can park stuff on disk. Why are people so > against that? Nobody is against that, only that you insist on using /tmp for it, which is imho not a good assumption to make. > we going to do? Right now on my Squeeze laptop I have /lib/init/rw, > /dev/shm, and /tmp. Do we really need more things that look like > on-disk directories but aren't? (Then again I'm still grumpy about > sysfs.) Though actually /var/run makes more sense than /tmp, since > it's pretty much just for pids and sockets. Without doing much (that I can remember) to my box, I see this on Testing: $ mount|grep tmpfs udev on /dev type devtmpfs (rw,relatime,size=4018332k,nr_inodes=205757,mode=755) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=804880k,mode=755) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=307200k) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,relatime,size=1609760k) $ Enjoy! > dropping arbitrarily large files into it (I'm looking at you, > Iceweasel...) and as long as there's *some* section of actual disk > somewhere that's 1777. As I said, there was /usr/tmp, but I think it was shot down. But I suggest /srv/tmp or something like that. Kind regards, --Toni++ -- 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/20120530002030.ga32...@spruce.wiehl.oeko.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Le Tue, May 29, 2012 at 10:54:32PM +0200, Arno Töll a écrit : > > Having that said, 5 days of (private) conversation is perhaps really a > bit too short to hijack a package. I'd expect that process to include > several weeks of waiting time for an answer at least. I concur. It is socially and technically safer to give about two week-ends to answer, keeping time zones in mind. If after this delay you have no news, my opinion is that hijacking is the best solution. The maintainer's other packages have already attracted three NMUs in total, and I have not seen a bug report with his answer after 2009 (although got some packages sponsored in 2011). By the way, perhaps you can keep his sponosor (rmgolbeck) in the loop, maybe he knows other ways to contact the maintainer ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120529234522.ga...@falafel.plessy.net
Bug#675106: ITP: pgbulkload -- A high speed data loading utility for PostgreSQL
Package: wnpp Severity: wishlist Owner: Alexander Kuznetsov * Package name: pgbulkload Version : 3.1.1 Upstream Author : Takahiro Itagakiitagaki.takahiro @nospam@ gmail.com Masao Fujii masao.fujii @nospam@ gmail.com Mitsuru Hasegawahasegawa @nospam@ metrosystems.co.jp Masahiko Sakamoto sakamoto_masahiko_b1 @nospam@ lab.ntt.co.jp Toru SHIMOGAKI shimogaki.toru @nospam@ oss.ntt.co.jp * URL : http://pgfoundry.org/projects/pgbulkload/ * License : BSD Programming Lang: C, SQL Description : A high speed data loading utility for PostgreSQL pg_bulkload is designed to load huge amount of data to a database. You can choose whether database constraints are checked and how many errors are ignored during the loading. For example, you can skip integrity checks for performance when you copy data from another database to PostgreSQL. On the other hand, you can enable constraint checks when loading unclean data. . The original goal of pg_bulkload was an faster alternative of COPY command in PostgreSQL, but version 3.0 or later has some ETL features like input data validation and data transformation with filter functions. . In version 3.1, pg_bulkload can convert the load data into the binary file which can be used as an input file of pg_bulkload. If you check whether the load data is valid when converting it into the binary file, you can skip the check when loading it from the binary file to a table. Which would reduce the load time itself. Also in version 3.1, parallel loading works more effectively than before. -- 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/20120529222006.19901.16867.reportbug@assa103.local
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi, On 29.05.2012 21:51, Jonas Smedegaard wrote: > Seems you had several years of solving this issue, yet you waited until Similarly, the maintainer had 4 years to care about his package. > Did you consider an NMU? That might be an alternative, but looking at the current bug list people will argue about the lacking ground to base a NMU on. It does not really qualify as a typical NMU candidate. People shouldn't be (so) afraid to hijack and NMU packages if they take care of virtually unmaintained packages. There is nothing to apologize or feel sorry about when improving Debian's overall quality. Having that said, 5 days of (private) conversation is perhaps really a bit too short to hijack a package. I'd expect that process to include several weeks of waiting time for an answer at least. Therefore I can see good reasons to hijack such a package. But not in such a hurry. If you really care enough, do a minimally invasive but clearly hostile NMU to start with and give the maintainer a reasonable time frame to respond. Do also CC the MIA team in your conversations, there are other packages Jack maintains which are long outdated and were NMUed already. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-30 at 02:49am, Thomas Goirand wrote: > Jack Bates is supposed to maintain php-codesniffer, [snip] > this package last upload was from 2008-10-05, [snip] > we'd like to see the latest version in Wheezy [snip] > We sent a mail 5 days ago to Jack Bates, and he didn't reply. It's > currently obvious that there's very few chances that Jack Bates will > upload a new version of php-codesniffer before Wheezy freezes. > > So, we'd like to have php-codesniffer orphaned, then taken over by us > (eg: the PKG-PHP Pear team). Jack Bates would anyway be very welcome > to join the team, and continue to do his packaging (we can add him to > the Uploaders: list if he wishes), even after this procedure. > > So, if nobody objects within the next following 2 or 3 days, and if > Jack doesn't show up and oppose to this procedure, we'll do that. I strongly object to this as a general principle: Debian freezing is no excuse for hijacking! Seems you had several years of solving this issue, yet you waited until just before freeze, and the option you came up with was to kick a maintainer. Did you consider an NMU? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: bitbucket is lock in? (was: Re: Packaging on GitHub ?)
* Martin Bagge / brother [2012-05-29 21:01 +0200]: > On Tue, 29 May 2012, Brian May wrote: > > >I don't see the problem, github is just a hosting provider. Unlike, > >say Bitkeeper, ... > > Can you elaborate on the bitbucket case there? How am I not allowed > to do a git clone from my git repo on bitbucket ... "Bitkeeper" is proprietary software, "Bitbucket" is a hosting service. Besides the "Bit" in their name, they have not much in common. Carsten -- 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/20120529193418.ga...@furrball.stateful.de
Re: bitbucket is lock in? (was: Re: Packaging on GitHub ?)
On 2012-05-29 21:01:24 +0200 (+0200), Martin Bagge / brother wrote:
> On Tue, 29 May 2012, Brian May wrote:
>
> >I don't see the problem, github is just a hosting provider. Unlike,
> >say Bitkeeper, you are free to make git clones anywhere, entirely with
> >open source software, and are in no way locked down to using github.
>
> Can you elaborate on the bitbucket case there? How am I not allowed
> to do a git clone from my git repo on bitbucket account? Where the
> same just works in github?
Bitbucket is not BitKeeper:
http://en.wikipedia.org/wiki/Bitbucket
http://en.wikipedia.org/wiki/BitKeeper
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
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/20120529193034.gn...@yuggoth.org
Re: bitbucket is lock in? (was: Re: Packaging on GitHub ?)
On Tue, May 29, 2012 at 09:01:24PM +0200, Martin Bagge / brother wrote: > On Tue, 29 May 2012, Brian May wrote: > > >I don't see the problem, github is just a hosting provider. Unlike, > >say Bitkeeper, you are free to make git clones anywhere, entirely with > >open source software, and are in no way locked down to using github. > > Can you elaborate on the bitbucket case there? How am I not allowed > to do a git clone from my git repo on bitbucket account? Where the > same just works in github? He was talking about BitKEEPER not BitBUCKET. Cheers, Michael -- Michael Hanke http://mih.voxindeserto.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/20120529192603.GA17658@meiner
bitbucket is lock in? (was: Re: Packaging on GitHub ?)
On Tue, 29 May 2012, Brian May wrote: I don't see the problem, github is just a hosting provider. Unlike, say Bitkeeper, you are free to make git clones anywhere, entirely with open source software, and are in no way locked down to using github. Can you elaborate on the bitbucket case there? How am I not allowed to do a git clone from my git repo on bitbucket account? Where the same just works in github? -- /brother http://martin.bagge.nu Whitfield Diffie and Martin Hellman use only their surnames out of fear of Bruce Schneier -- 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/alpine.deb.2.00.1205292058060.13...@salyut.bsnet.se
Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi, Jack Bates is supposed to maintain php-codesniffer, available from: http://pear.php.net/package/PHP_CodeSniffer Unfortunately, the PTS for this package shows that this package last upload was from 2008-10-05, few months after version 1.1.0 was released upstream (on the 2008-07-14). Upstream has been releasing every 3 to 6 months since, but none of the upstream versions have been released. PHPUnit has been uploaded to SID, and will soon migrate to testing. This PHP_CodeSniffer is a good QA tool as well, and we'd like to see the latest version in Wheezy as well. We sent a mail 5 days ago to Jack Bates, and he didn't reply. It's currently obvious that there's very few chances that Jack Bates will upload a new version of php-codesniffer before Wheezy freezes. So, we'd like to have php-codesniffer orphaned, then taken over by us (eg: the PKG-PHP Pear team). Jack Bates would anyway be very welcome to join the team, and continue to do his packaging (we can add him to the Uploaders: list if he wishes), even after this procedure. So, if nobody objects within the next following 2 or 3 days, and if Jack doesn't show up and oppose to this procedure, we'll do that. If anyone doesn't agree, please raise your concern *now* (including you, Jack). Cheers, Thomas Goirand (zigo) -- 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/4fc51a32.2020...@debian.org
Bug#675078: ITP: overlay-scrollbar -- scrollbar overlay
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: overlay-scrollbar Version : 0.2.16 Upstream Author : Andrea Cimitan * URL : http://launchpad.net/ayatana-scrollbar * License : LGPL-2.1+ Programming Lang: C Description : scrollbar overlay Overlay scrollbar is a GtkModule enabling a dynamic overlay behavior It strives in providing the user with more screen space -- 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/20120529184022.16498.64333.report...@champaran.researchut.com
Bug#675066: ITP: fonts-moe-standard-song -- Chinese TrueType font, standard Song (non-free)
Package: wnpp Severity: wishlist Owner: "Kan-Ru Chen" * Package name: fonts-moe-standard-song Version : 1.00 Upstream Author : mandr _at_ mail.moe.gov.tw * URL : http://www.edu.tw/mandr/content.aspx?site_content_sn=3786 * License : CC-BY-ND 3.0 Programming Lang: truetype font Description : Chinese TrueType font, standard Song (non-free) MOE Std Song is released by Taiwan Ministry of Education. It covers the characters plane 1 to 7 defined by CNS11643. -- 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/20120529164151.13676.74285.report...@isil.kanru.info
Bug#675065: ITP: fonts-moe-standard-kai -- Chinese TrueType font, standard Kaiti (non-free)
Package: wnpp Severity: wishlist Owner: "Kan-Ru Chen" * Package name: fonts-moe-standard-kai Version : 3.00 Upstream Author : mandr _at_ mail.moe.gov.tw * URL : http://www.edu.tw/mandr/content.aspx?site_content_sn=31322 * License : CC-BY-ND 3.0 Programming Lang: truetype font Description : Chinese TrueType font, standard Kaiti (non-free) MOE Std Kai is released by Taiwan Ministry of Education. It covers the characters plane 1 and 2 defined by CNS11643. -- 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/20120529163706.12723.89616.report...@isil.kanru.info
Re: Packaging on GitHub ?
On 05/29/2012 08:07 AM, Yao Wei (魏銘廷) wrote: > I am thinking about a more general topic like: > Managing packaging on VCS services other than Alioth The other way rounds works well, too - package wherever you like to and mirror it on Alioth, for example in your personal git folder in your home. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc4f13a.1070...@bzed.de
Re: Bug#675033: ITP: kgraphviewer -- KGraphViewer is a GraphViz dot graph viewer for KDE 4.
On Tuesday, May 29, 2012 02:54:40 PM w.goesgens wrote: ... > Already packaged for ubuntu by Scott Kitterman; compiles on debian wheezy. > https://launchpad.net/ubuntu/+source/kgraphviewer/4:2.1.1-0ubuntu1 For the record, it is already packaged in Ubuntu, but not by me. I touched it there to do some fix ups, but it's most certainly not my package. Scott K signature.asc Description: This is a digitally signed message part.
Re: Moving /tmp to tmpfs makes it useful
On 26 May 2012 19:20, Carlos Alberto Lopez Perez wrote: > *Important*: use "df -h /tmp" NOT "du -hs /tmp", since the flash player > deletes the file entry from /tmp as soon as it gets the inode allocated. > I believe this a measure to "prevent" piracy (people ripping the video > from /tmp) I think you're too willing to assume bad faith. If I were writing similar software, that's exactly what I'd do: create a temporary file, which will be in /tmp except in the marginal corner-case that the user has set another $TMPDIR, then unlink it and continue using it. This means that you don't need to worry about deleting it afterwards, even if your application crashes or is killed, and has no obvious downsides. -- 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/cahb+spdrxfpd1e6dovwfg8pttbezduqgchskcwb0l+oc3p3...@mail.gmail.com
Bug#675033: ITP: kgraphviewer -- KGraphViewer is a GraphViz dot graph viewer for KDE 4.
Package: wnpp Severity: wishlist Owner: Wilfried Goesgens * Package name: kgraphviewer Version : 2.1.1 Upstream Author : Gaël de Chalendar * URL : http://extragear.kde.org/apps/kgraphviewer/ * License : (GPL2) Programming Lang: (C, C++, QT) Description : KGraphViewer is a GraphViz dot graph viewer for KDE 4. Already packaged for ubuntu by Scott Kitterman; compiles on debian wheezy. https://launchpad.net/ubuntu/+source/kgraphviewer/4:2.1.1-0ubuntu1 -- 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/20120529125440.11867.71483.report...@o3sis.com
Bug#675032: ITP: iipmooviewer -- Ajax-based Internet Imaging Protocol (IIP) client
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: iipmooviewer Version : 1.0 Upstream Author : Ruven Pillay * URL : http://iipimage.sourceforge.net/ * License : GPL Programming Lang: JavaScript Description : Ajax-based Internet Imaging Protocol (IIP) client IIPMooViewer is a high performance Ajax-based javascript image streaming and zooming client for the IIPImage system compatible with Firefox / Mozilla (and other gecko-based browsers), Internet Explorer versions 6 & 7, Safari and Opera. It is based on the Mootools javascript framework. Version 1.1 of IIPMooViewer requires Mootools version 1.2. The distribution contains all the necessary library files in both compressed and uncompressed formats. Modify the parameters in the iipmooviewer.html example file provided. -- 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/20120529125849.9303.14698.report...@maester.malat.net
Bug#675018: ITP: python-pycalendar -- iCalendar/vCard Library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: python-pycalendar Version: 0.2~svn188 Upstream Author: Cyrus Daboo URL: http://svn.mulberrymail.com/repos/PyCalendar/ License: Apache 2.0 Description: iCalendar/vCard Library This package is needed for Darwin Calendarserver 3.2.0 (currently in process of packaging). -- 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/4fc48f48.6080...@users.sourceforge.net
Processed: merge
Processing commands for cont...@bugs.debian.org: > merge 601455 661496 Bug #601455 [general] can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo Bug #661496 [general] multiple, annoyingly different ways to disable an init script Merged 601455 661496 > thanks Stopping processing here. Please contact me if you need assistance. -- 601455: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601455 661496: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661496 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13382809822686.transcr...@bugs.debian.org
Bug#480925: marked as done (support for playing blu-ray discs)
Your message dated Tue, 29 May 2012 10:01:02 +0200 with message-id <201205291001.03726.hol...@layer-acht.org> and subject line closing, supported as much as we can has caused the Debian Bug report #480925, regarding support for playing blu-ray discs to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 480925: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480925 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: wishlist I'm creating this bug to track support for playing blu-ray discs in Debian's default desktop install. I'll add related bugs as blockers to this one (and welcome others to do the same). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) --- End Message --- --- Begin Message --- Hi, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480914#32 thus closing. cheers, Holger --- End Message ---
Processed: downgrading
Processing commands for cont...@bugs.debian.org: > severity 637232 important Bug #637232 [general] general: Multiarch breaks support for non-multiarch toolchain Bug #639214 [general] eglibc: changes to paths concerning crt1.o, crti.o and crtn.o breaks building LLVM Trunk Bug #644986 [general] i386: Compiling gcc-snapshots from upstream with multiarch-toolchain? Bug #648889 [general] /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h" Severity set to 'important' from 'critical' Severity set to 'important' from 'critical' Severity set to 'important' from 'critical' Severity set to 'important' from 'critical' > # this bug is mainly ment to document a decission, so why critical? > severity 652011 important Bug #652011 [debian-policy] general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib Severity set to 'important' from 'serious' > # this is mainly disagreeing with the status-quo, so I dont think thats > # serious either > thanks Stopping processing here. Please contact me if you need assistance. -- 637232: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637232 639214: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639214 644986: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644986 648889: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648889 652011: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652011 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13382783597.transcr...@bugs.debian.org
Bug#669108: marked as done (general: assorted segfault)
Your message dated Tue, 29 May 2012 09:38:44 +0200 with message-id <201205290938.44884.hol...@layer-acht.org> and subject line not a bug has caused the Debian Bug report #669108, regarding general: assorted segfault to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 669108: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669108 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: normal Hi there, I'm using debian testing. Lately I've been experiences frequent segfaults with eventual complete freeze. I attach evidence found in kern.log. Is there anybody out there who could guide me to collect further information to investigate the problem? So far I've done a complete disk scan using smarttools, but the disk seems ok. Thank you anyway, Carlo. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Apr 15 11:55:13 Uranus kernel: [ 7811.496368] gnome-shell[2831]: segfault at 2c41eb008 ip 7fe95070b618 sp 7fff05951020 error 4 in libglib-2.0.so.0.3000.2[7fe9506a9000+f6000] Apr 15 11:58:15 Uranus kernel: [ 7993.284366] gnome-shell[14406]: segfault at 2acc04008 ip 7f09d2731618 sp 7fffa776bb40 error 4 in libglib-2.0.so.0.3000.2[7f09d26cf000+f6000] Apr 15 12:03:00 Uranus kernel: [ 8278.234638] gnome-shell[14591]: segfault at 38f481008 ip 7f3cbc453618 sp 7fffe71da900 error 4 in libglib-2.0.so.0.3000.2[7f3cbc3f1000+f6000] Apr 15 12:03:33 Uranus kernel: [ 8310.267483] gnome-shell[14735]: segfault at 441790008 ip 7f97dbf07618 sp 7fffc73dce10 error 4 in libglib-2.0.so.0.3000.2[7f97dbea5000+f6000] Apr 15 12:03:37 Uranus kernel: [ 8314.168806] eclipse[14252]: segfault at 18 ip 7fbc8d48168e sp 7fff6b7246c0 error 4 in libgdk-x11-2.0.so.0.2400.10[7fbc8d40d000+af000] Apr 15 12:09:24 Uranus kernel: [ 8661.053917] gnome-shell[14956]: segfault at 257726008 ip 7f8cab08a618 sp 7fff71a34e80 error 4 in libglib-2.0.so.0.3000.2[7f8cab028000+f6000] Apr 15 12:09:56 Uranus kernel: [ 8692.919917] gnome-shell[15288]: segfault at 43886d107 ip 7f2faaf01618 sp 7fff1d200520 error 4 in libglib-2.0.so.0.3000.2[7f2faae9f000+f6000] Apr 15 12:10:01 Uranus kernel: [ 8697.826674] eclipse[15082]: segfault at 18 ip 7fcbd766f68e sp 7fff8a2c6550 error 4 in libgdk-x11-2.0.so.0.2400.10[7fcbd75fb000+af000] Apr 15 12:20:24 Uranus kernel: [ 9319.582410] colord-sane[2541]: segfault at 48 ip 7f18f220a54c sp 7f18f21e0b78 error 6 in libdbus-1.so.3.7.0[7f18f21e2000+44000] Apr 15 12:28:04 Uranus kernel: [ 359.145923] colord-sane[2568]: segfault at 28 ip 7f8e8996f54c sp 7f8e89945b78 error 6 in libdbus-1.so.3.7.0[7f8e89947000+44000] Apr 15 14:21:19 Uranus kernel: [ 6756.627363] gnome-shell[3291]: segfault at 272610008 ip 7f74eca328fc sp 7fff0c8b3df0 error 6 in libglib-2.0.so.0.3000.2[7f74ec9d+f6000] Apr 15 14:33:18 Uranus kernel: [ 7474.194557] gnome-shell[6935]: segfault at 2afaf3008 ip 7fa09f200618 sp 7fff7c5d9640 error 4 in libglib-2.0.so.0.3000.2[7fa09f19e000+f6000] Apr 15 14:46:38 Uranus kernel: [ 8271.319739] gnome-shell[7196]: segfault at 399fac008 ip 7f229be22618 sp 7fff01ef0df0 error 4 in libglib-2.0.so.0.3000.2[7f229bdc+f6000] Apr 15 15:29:11 Uranus kernel: [ 396.505177] gnome-shell[2676]: segfault at 40e3c4008 ip 7f2adf2ee618 sp 7fff4710f9a0 error 4 in libglib-2.0.so.0.3000.2[7f2adf28c000+f6000] Apr 15 15:31:00 Uranus kernel: [ 504.643880] gnome-settings-[2593]: segfault at 7f8ef4849040 ip 7f8efcba0630 sp 7fffab382eb0 error 4 in libglib-2.0.so.0.3000.2[7f8efcb5a000+f6000] Apr 15 15:31:12 Uranus kernel: [ 516.305883] colord-sane[2451]: segfault at 28 ip 7f2e4a6ba54c sp 7f2e4a690b78 error 6 in libdbus-1.so.3.7.0[7f2e4a692000+44000] Apr 15 15:32:31 Uranus kernel: [ 65.084537] gnome-panel[2721]: segfault at 7f3a599b130f ip 7f3a56b89f0f sp 7fff971d0960 error 7 in libglib-2.0.so.0.3000.2[7f3a56b27000+f6000] Apr 15 15:39:36 Uranus kernel: [ 196.276033] colord-sane[2424]: segfault at 8 ip 7ffc0462054c sp 7ffc045f6b78 error 6 in libdbus-1.so.3.7.0[7ffc045f8000+44000] Apr 15 15:43:05 Uranus kernel: [ 191.206854] gnome-shell[2897]: segfault at 3cee58008 ip 7f6485577618 sp 7fff10e8c7f0 error 4 in libglib-2.0.so.0.3000.2[7f6485515000+f6000] Apr 15 15:43:52 Uranus
Bug#672147: marked as done (general: restart desktop when i press cdrom icon)
Your message dated Tue, 29 May 2012 09:41:23 +0200 with message-id <201205290941.24260.hol...@layer-acht.org> and subject line crystal ball is broken has caused the Debian Bug report #672147, regarding general: restart desktop when i press cdrom icon to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 672147: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672147 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: normal When i want play a cdrom mounted and ready for use , my desktop is restarted and this operation does not have any effect. Is not a serious problems, the totem program can play music with your graphical interface, but is some tedious. -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- Hi, sorry, but Debians crystal ball to magically gather missing information in bug reports is broken, so we cannot help you with this bugreport. Feel free to provide more information (like used desktop environment...) and we might reopen the bugreport. cheers, Holger --- End Message ---
Processed: debian-policy is the place to discuss this
Processing commands for cont...@bugs.debian.org: > reassign 652011 debian-policy Bug #652011 [general] general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib Bug reassigned from package 'general' to 'debian-policy'. Ignoring request to alter found versions of bug #652011 to the same values previously set Ignoring request to alter fixed versions of bug #652011 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 652011: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652011 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.133827707514826.transcr...@bugs.debian.org
