Re: CIA going down: KGB wants your commits!
]] Martín Ferrari > You can either run your own bot (debian package kgb-bot), or use ours. As > for the client, alioth does not have it installed, but you can run it off > /home/groups/kgb. It's installed now. -- 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/877gren1df@xoog.err.no
Re: Bug#688994: CIA going down: KGB wants your commits!
On Fri, 28 Sep 2012 03:01:46 +0200, gregor herrmann wrote:
> 1) Client side (i.e. vasks):
>
> 1a) /home/groups/pkg-perl/meta/pkg-perl-post-receive
>
> BASE=/home/groups/pkg-perl
> KGB=/home/groups/kgb/trunk
> CONF=$BASE/kgb-client.conf
> PKG=${DIR%.git}
cat > hooks/reflog
> if [ -e $BASE/KGB-notifications-disabled ]; then
> echo "KGB notifications disabled"
> else
> cat hooks/reflog | \
> PERL5LIB=$KGB/lib $KGB/script/kgb-client --conf $CONF \
> --repository git --git-reflog - --module $PKG
> fi
Cheers,
gregor, adding a missing line, thanks Tincho
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Johnny Shines: Too Wet To Plow
signature.asc
Description: Digital signature
Re: CIA going down: KGB wants your commits!
On Thu, 27 Sep 2012 20:48:23 -0400, Joey Hess wrote:
> > For KGB the concept of a repository is a bit fuzzy. It is just the
> > unit it uses to separate access control (password), channels to
> > broadcast to, and a word in the commit notification. But you can use
> > one of these for hundreds of repos, like pkg-perl does: all the git
> > repos (one per package) use the same client config, and just add a
> > module parameter derived from the path.
> > Would that be enough for you?
> If the module parameter is displayed on IRC, then yes.
> I must be missing how to do that for git, as I just filed a bug about it. :/
That works fine for pkg-perl.
1) Client side (i.e. vasks):
1a) /home/groups/pkg-perl/meta/pkg-perl-post-receive
BASE=/home/groups/pkg-perl
KGB=/home/groups/kgb/trunk
CONF=$BASE/kgb-client.conf
PKG=${DIR%.git}
if [ -e $BASE/KGB-notifications-disabled ]; then
echo "KGB notifications disabled"
else
cat hooks/reflog | \
PERL5LIB=$KGB/lib $KGB/script/kgb-client --conf $CONF \
--repository git --git-reflog - --module $PKG
fi
1b) /home/groups/pkg-perl/kgb-client.conf
---
repo-id: 'pkg-perl'
# first capture is branch name, second capture is module name
branch-and-module-re:
- "/(trunk|tags|apps|attic)/([^/]+)"
- "/branches/([^/]+)/([^/]+)"
- "/()(scripts)/"
ignore-branch: trunk
timeout: 7
password: 12345
servers:
# dam, KGB-0
- uri: http://dam.homelinux.net:9418/
# gregoa, KGB-2
- uri: http://colleen.colgarra.priv.at:8080/
# Tincho, KGB-1
- uri: http://abhean.mine.nu:9418/
status-dir: /home/groups/pkg-perl/kgb-client-status
2) Server side:
[..]
repositories:
# just a name to identify it
pkg-perl:
# needs to be the same on the client
password: 12345
channels:
- name: '#debian-perl'
network: oftc
repos:
- pkg-perl
[..]
And in #debian-perl this looks like:
20:12 joostvb upstream b19ebac eekboek debian/ TODO changelog * update
TODO-list
(last commit in one of our repos, in this case eekboek)
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Ryan Adams: Gimme A Sign
signature.asc
Description: Digital signature
Re: CIA going down: KGB wants your commits!
Martín Ferrari wrote: > (you have a really weird reply-to :)) I do? I see no such header.. > For KGB the concept of a repository is a bit fuzzy. It is just the > unit it uses to separate access control (password), channels to > broadcast to, and a word in the commit notification. But you can use > one of these for hundreds of repos, like pkg-perl does: all the git > repos (one per package) use the same client config, and just add a > module parameter derived from the path. > > Would that be enough for you? If the module parameter is displayed on IRC, then yes. I must be missing how to do that for git, as I just filed a bug about it. :/ -- see shy jo signature.asc Description: Digital signature
Re: CIA going down: KGB wants your commits!
(you have a really weird reply-to :)) On Fri, Sep 28, 2012 at 1:35 AM, Joey Hess wrote: > d-i would like to use your bots, but we have an ever-changing list of > repositories. It'd be wrong to centralize the list of them in a bot's > config file. Any thoughts? For KGB the concept of a repository is a bit fuzzy. It is just the unit it uses to separate access control (password), channels to broadcast to, and a word in the commit notification. But you can use one of these for hundreds of repos, like pkg-perl does: all the git repos (one per package) use the same client config, and just add a module parameter derived from the path. Would that be enough for you? -- Martín Ferrari -- 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/cal60pd8_+ghw83tgcjhnq0oozjc09t8h9vhogdgkkgi7eci...@mail.gmail.com
Work-needing packages report for Sep 28, 2012
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 470 (new: 22) Total number of packages offered up for adoption: 137 (new: 0) Total number of packages requested help for: 66 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: airport-utils (#688537), orphaned 4 days ago Description: configuration and management utilities for Apple AirPort base stations Installations reported by Popcon: 106 arcload (#688555), orphaned 4 days ago Description: bootloader for SGI/ARCS machines cldump (#688535), orphaned 4 days ago Description: Clarion database files extractor Installations reported by Popcon: 20 eikazo (#688536), orphaned 4 days ago Description: graphical frontend for SANE designed for mass-scanning Installations reported by Popcon: 134 forked-daapd (#688538), orphaned 4 days ago Description: media server with support for RSP, DAAP, DACP and AirTunes Installations reported by Popcon: 222 libantlr3c (#688541), orphaned 4 days ago Description: ANTLR v3 parser generator C runtime [development files] Installations reported by Popcon: 292 libieee1284 (#688539), orphaned 4 days ago Description: cross-platform library for parallel port access [development files] Installations reported by Popcon: 63764 lptools (#688916), orphaned yesterday Description: Tools for working with Launchpad Installations reported by Popcon: 50 mcelog (#688540), orphaned 4 days ago Description: x86 Machine Check Exceptions collector and decoder Installations reported by Popcon: 2186 oflib (#688545), orphaned 4 days ago Description: OpenFirmware device-tree parsing library [development files] Installations reported by Popcon: 23 pyrite-publisher (#688442), orphaned 5 days ago Description: Convert html and text documents to palm DOC format Installations reported by Popcon: 32 refit (#688530), orphaned 4 days ago Description: graphical boot menu for ia32 and x64 EFI systems Installations reported by Popcon: 322 sane-backends (#688531), orphaned 4 days ago Description: API library for scanners -- utilities Installations reported by Popcon: 63501 sane-backends-extras (#688532), orphaned 4 days ago Description: API library for scanners -- documentation and support files Installations reported by Popcon: 61849 sane-frontends (#688556), orphaned 4 days ago Description: scanner graphical frontends Installations reported by Popcon: 4598 tkdesk (#688443), orphaned 5 days ago Description: Tk/tcl based X11 Desktop/File manager Installations reported by Popcon: 105 vamp-plugin-sdk (#688625), orphaned 3 days ago Description: audio analysis and feature extraction plugins (SDK) Installations reported by Popcon: 10317 vrb (#688624), orphaned 3 days ago Description: Virtual Ring Buffer library Installations reported by Popcon: 21 wmacpi (#688533), orphaned 4 days ago Description: ACPI battery monitor for WindowMaker Installations reported by Popcon: 150 wmbatppc (#688553), orphaned 4 days ago Description: Battery monitor for Apple G3/G4 ibooks/powerbooks Installations reported by Popcon: 10 wmclock (#688534), orphaned 4 days ago Description: dockable clock applet for Window Maker Installations reported by Popcon: 227 xsane (#688542), orphaned 4 days ago Description: featureful graphical frontend for SANE (Scanner Access Now Easy) Installations reported by Popcon: 42111 448 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 137 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 969 days ago Description: maintenance tools for a Xapian index of Debian packages Installations reported by Popcon: 57498 asymptote (#517342), requested 1308 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 3291 athcool (#278442), requested 2893 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 73 balsa (#642906), requested 368 days ago Description: An e-mail client for GNO
Re: CIA going down: KGB wants your commits!
Martín Ferrari wrote: > If you rather use our bots, we'll need you to provide: a project/repository > name, an IRC channel, and a password (used to avoid spam, not really > secure). d-i would like to use your bots, but we have an ever-changing list of repositories. It'd be wrong to centralize the list of them in a bot's config file. Any thoughts? -- see shy jo signature.asc Description: Digital signature
Re: CIA going down: KGB wants your commits!
On Fri, Sep 28, 2012 at 6:52 AM, Martín Ferrari wrote: > Not to "to knock 'em when they're down", but since it seems that the CIA.vc > service has officially closed recently (cannot find exactly when did that > happen), I think it's worthwhile offering this little project we (dam@, > gregoa@, and me) have since a few years ago, called KGB (ha-ha). Seems like ESR has been working on a less centralised replacement for a while: http://esr.ibiblio.org/?p=4540 http://esr.ibiblio.org/?p=4612 http://esr.ibiblio.org/?p=4607 http://esr.ibiblio.org/?p=4538 -- 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/caktje6gdykqqpfv9u5hqgkx9zu2w_je1djo0kjlanwhhuny...@mail.gmail.com
Re: CIA going down: KGB wants your commits!
On Thu, Sep 27, 2012 at 11:52:52PM +0100, Martín Ferrari wrote: > Not to "to knock 'em when they're down", but since it seems that the CIA.vc > service has officially closed recently (cannot find exactly when did that > happen) http://shadowm.rewound.net/blog/archives/245-CIA.vc-is-dead.html http://pastebin.com/9RBBniM1 -- WBR, wRAR signature.asc Description: Digital signature
CIA going down: KGB wants your commits!
Hi there! Not to "to knock 'em when they're down", but since it seems that the CIA.vc service has officially closed recently (cannot find exactly when did that happen), I think it's worthwhile offering this little project we (dam@, gregoa@, and me) have since a few years ago, called KGB (ha-ha). It's a very simple and dumb client-server architecture: IRC bots running in our personal servers listen for SOAP messages sent by kgb-clients called from post-commit hooks in repos out there. The bot just relays and formats a message, nothing fancier than that. So, if you're looking for a simple IRC notification of your commits, this might be of help. You can either run your own bot (debian package kgb-bot), or use ours. As for the client, alioth does not have it installed, but you can run it off /home/groups/kgb. There's a sample configuration there too. In /home/groups/pkg-perl/meta/pkg-perl-post-receive you can see how to use it from a post-commit hook. If you rather use our bots, we'll need you to provide: a project/repository name, an IRC channel, and a password (used to avoid spam, not really secure). -- Martín Ferrari -- 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/cal60pd_7zopk4w4rta49-jymxzkou+k7ddqzuiqsp32kz9b...@mail.gmail.com
Re: ${HOME} vs. g_get_home_dir ()
On Thu, Sep 27, 2012 at 11:53:36PM +0200, Josselin Mouette wrote: > Le jeudi 27 septembre 2012 à 14:39 -0700, Josh Triplett a écrit : > > Agreed entirely. In particular, it breaks the very common use case of > > running a program with sudo. "sudo foo" leaves $HOME set to the user's > > home directory rather than root, so that foo will use the same > > configuration either way. > > This is a bug in sudo. There can be very dangerous things in $HOME (such > as scriptable application configuration files), and they should clearly > be ignored in favor of those of root. Since the user has already ran sudo, I don't see a problem. If you can add a scriptable config file, you can arrange for that "sudo" to be a wrapper over "/usr/bin/sudo". > > A user can then use sudo -H or sudo -i if > > they want a more rootish environment. Other programs that don't respect > > $HOME include ssh, which forces ugly workarounds like this: > > sudo ssh -o UserKnownHostsFile=$HOME/.ssh/known_hosts ... > > This is desired. Allowing to use another user’s known_hosts, which can > have been fiddled with, is dangerous. YOUR known_hosts? What Josh mentioned is using /home/you rather than /root; if someone else can fiddle with your known_hosts and you can run arbitrary commands through sudo, you're screwed already as files in .ssh tend to be more secure than most other files. -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- 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/20120927221652.ga8...@angband.pl
Re: ${HOME} vs. g_get_home_dir ()
Le jeudi 27 septembre 2012 à 14:39 -0700, Josh Triplett a écrit : > Agreed entirely. In particular, it breaks the very common use case of > running a program with sudo. "sudo foo" leaves $HOME set to the user's > home directory rather than root, so that foo will use the same > configuration either way. This is a bug in sudo. There can be very dangerous things in $HOME (such as scriptable application configuration files), and they should clearly be ignored in favor of those of root. > A user can then use sudo -H or sudo -i if > they want a more rootish environment. Other programs that don't respect > $HOME include ssh, which forces ugly workarounds like this: > sudo ssh -o UserKnownHostsFile=$HOME/.ssh/known_hosts ... This is desired. Allowing to use another user’s known_hosts, which can have been fiddled with, is dangerous. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1348782816.21951.93.camel@pi0307572
Re: ${HOME} vs. g_get_home_dir ()
Ivan Shmakov wrote: > I do remember filing a bug or two against packages that refer to > the getent () data to find the user's “home” directory instead > of using the HOME environment variable. > > The environment is the preferred place to check for this kind of > things: it's (usually) under the full control of the user, and > it's quite possible to run several instances of a single program > using different environments (with different executable file > search PATH's, locales, time zones, etc.), which occasionally > turns to be an immense aid to debugging. (Want to use the > all-defaults configuration for a program? Just start it like: > $ HOME="$(mktemp -dt -- foo.)" foo) > > Now, Glib has g_get_home_dir (), whose description reads [1]: > > --cut-- > Gets the current user's home directory as defined in the password > database. > > Note that in contrast to traditional UNIX tools, this function > prefers passwd entries over the HOME environment variable. > --cut-- > > I believe that this behavior is buggy. Agreed entirely. In particular, it breaks the very common use case of running a program with sudo. "sudo foo" leaves $HOME set to the user's home directory rather than root, so that foo will use the same configuration either way. A user can then use sudo -H or sudo -i if they want a more rootish environment. Other programs that don't respect $HOME include ssh, which forces ugly workarounds like this: sudo ssh -o UserKnownHostsFile=$HOME/.ssh/known_hosts ... - Josh Triplett -- 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/20120927213859.GA7282@jtriplet-mobl1
Bug#688979: ITP: python-doublex -- doublex is a test doubles framework for the Python platform
Package: wnpp Severity: wishlist Owner: "Miguel Ángel García" * Package name: python-doublex Version : 0.6.1 Upstream Author : David Villa Alises * URL : https://bitbucket.org/DavidVilla/python-doublex * License : GPL Programming Lang: Python Description : doublex is a test doubles framework for the Python platform doublex is a test doubles framework for the Python platform. Test doubles frameworks are also called mocking or isolation frameworks. doublex can be used as a testing tool or as a Test Driven Development tool. . It generates stubs, spies, and mock objects using a minimal interface. It support hamcrest matchers both stub definitions and spy checking. All assertions are done using hamcrest assert_that(). Moreover, it’s been designed to make your tests less fragile when possible. -- 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/20120927192206.15653.92011.reportbug@nightcrawler
Re: ${HOME} vs. g_get_home_dir () [and 1 more messages]
Josselin Mouette writes:
> Le mercredi 26 septembre 2012 à 23:17 +0100, Ian Jackson a écrit :
>> Josselin Mouette writes ("Re: ${HOME} vs. g_get_home_dir () [and 1 more
>> messages]"):
>> > Maybe you should try and obtain a CTTE decision to patch that in glib.
>>
>> Surely it would be better to try to fully understand the problem, and
>> discuss it politely and constructively with the various people
>> involved. There is no need to even consider escalation at this stage.
>
> Yes, good idea! How about trying to understand why upstream does things
> in a certain way, and looking at past discussions of how they came to
> such decisions, instead of asking maintainers to override these
> decisions because you know better?
That is exactly what Ian suggested. Maybe you should read his mail
again.
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
--
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/87d317s8k6@inspiron.ap.columbia.edu
Re: ${HOME} vs. g_get_home_dir () [and 1 more messages]
Le jeudi 27 septembre 2012 à 10:06 +0200, Bjørn Mork a écrit : > This is not a technical issue at all. It is about breaking user > expectations by breaking conventions. No, this is about breaking YOUR expectations. But what former SunOS 5.6 users expect is not necessarily what other users expect. I expect programs to use my real home, regardless of whatever crap could have been put in the environment (and there are really too many things that fiddle with $HOME incorrectly). > Is it OK for Debian to break user expectations? This question can be turned around against you in the same way. > I believe changing XAUTHORITY from default is part of the same upstream > problem. Moving XAUTHORITY was part of avoiding issues on network homes. > Although that change can be claimed to be within the limits of > the documentation, bug reports like http://bugs.debian.org/614972 > clearly demonstrates that it breaks user expectations. Thanks for pointing to this bug, which shows that user expectations are not necessarily “XAUTHORITY=~/.Xauthority” but “my X server is accessible from the outside provided I have the permissions”. Which was solved in a much better way than just going back to the previous set of bugs. > There seems to be an upstream problem here which goes a lot deeper than > a few weird defaults... To me this looks like a classical change management problem. Just because we did things in a certain way for 30 years doesn’t mean this way is best. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1348764073.21951.90.camel@pi0307572
Re: assumptions about the build environment.
On Thu, Sep 27, 2012 at 01:14:49PM +0100, Wookey wrote: > In general I'm in favour of agreeing what can be relied upon and > then only providing that in buildds. But you are quite right that for > the purposes of buildds doing native building this improves your > success rate by glossing over potentially-dubious checks, with little > cost. I guess the question here is whether we write policy on how to build a package in support of buildd machines, or whether things are the other way around, that is, we use buildd machines to verify packages' compliance to policy. If we were doing the latter, we should probably also do things like run lintian on a package after it built, or run it through piuparts, or do any number of other time-consuming things that would improve the quality of our distribution overall. We are, however, not doing that, because this is not the primary focus of the buildd network. Instead, the primary focus of the buildd network is to build our packages for their architecture in a timely manner. Now I'm not saying that I'm opposed, in principle, to such testing if it provided a net benefit; and to some extent, we are in fact already doing that (since maintainers are encouraged to enable test suites as part of the regular build of their packages). However, when the buildd network is backlogged because of broken or ageing hardware, or because of other issues not directly under the control of the buildd admins, these admins should have the ability to cut some corners (while still producing correct packages) so that they can cut down on the time required when things are getting tight. To be able to do this, the amount of things the hosts in the buildd network absolutely must do should be a list that is shorter rather than longer. In essense, the buildd network is not a QA resource; and while it is okay to use it as such if buildd hosts have time to spare, I believe we should ensure that our QA team's primary resources for archive-wide tests should be found elsewhere, so that buildd admins have the liberty to do what they need to do: ensure that an architecture can still be part of the next release, by building the packages that we need to build. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a signature.asc Description: Digital signature
Re: assumptions about the build environment.
On Thu, 2012-09-27 at 13:14:49 +0100, Wookey wrote: > But the case of uname _is_ easy to deal with - use dpkg-architecture. Well, not really if the patch is supposed to go upstream, given that dpkg-architecture is not a distribution-neutral interface. In most of the cases uname is wrong because the build system should be checking for features instead of hardcoded lists of architectures and because its output is not really normalized across different operating systems, or as mentioned on this thread the detection should really be delayed until run-time. But if the architecture is needed for whatever reason then using something like config.guess/sub's output and a way to distinguish between host and build architectures is probably better. > And on the original point, anything checking /sys for HOST arch stuff > is likely to be getting it wrong too - fine for BUILD arch checks. Right. regards, guillem -- 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/20120927135557.ga...@gaara.hadrons.org
Re: ${HOME} vs. g_get_home_dir ()
* Russ Allbery [120926 21:42]:
> > The documentation for g_get_home_dir[1] also documents what a proper
> > program can do, it's a simple:
>
> > const char *homedir = g_getenv ("HOME");
> >if (!homedir)
> > homedir = g_get_home_dir ();
>
> > instead of using get_get_home_dir directly.
>
> Oh, I'm glad that they at least document this. But it would still be nice
> if the default did the right thing.
Though I guess changing the default upstream is hard, given the feedback
I got in tha past and the general tendency in gtk/gnome world to
consider anything not in their primary picture as obsolete and/or legacy
and thus not worth to support.
So users outside Debian would profit more to push patches to all
programs to properly prefer HOME instead of hoping to persuade upstream
of the library (and Debian would profit from having a smaller diff).
Bernhard R. Link
--
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/20120927124400.ga13...@server.brlink.eu
Re: assumptions about the build environment.
+++ Wouter Verhelst [2012-09-24 13:14 +0200]: > On Sat, Sep 22, 2012 at 07:06:57PM +0200, Adam Borowski wrote: > > > > That it breaks multiarch builds. > > Multiarch builds are not done on our buildd machines. Yet. They very likely will be soon, for partial architectures and cross-toolchains. And we still want them to work, in cross-compiling configurations, too, at least for core stuff. > [...] > > As for complex "hard to patch" build systems, could you give me an example? apache/apr :-) But the case of uname _is_ easy to deal with - use dpkg-architecture. And on the original point, anything checking /sys for HOST arch stuff is likely to be getting it wrong too - fine for BUILD arch checks. > > I can't quite think of a case where patching references to uname could be > > tricky. > > I can't give you an example of *this* particular issue; but given the > amount of complex build systems I've seen, I don't think it's too > unreasonable to assume they exist. > > I'm not saying we should change policy to mandate that i386 builds in > i386 chroots should be done with linux32 running or something similar. > But I also do happen to think that tuning buildd machines to do a bit > more than what policy requires them to do is usually a good thing. For I > used to keep debhelper installed in my buildd chroots, even though it's > not part of build-essential; but since almost all packages use it in > some form or another, it was being installed and deinstalled enough that > I could gain some time by having it installed by default. The result > was of course that packages who mistakenly failed to add debhelper to > their build-depends would successfully build on my buildd hosts, but I > didn't think that was much of a problem. > > Similarly, if adding linux32 to the environment on amd64 hosts building > inside a chroot means the success rate for packages built will go up, I > don't think we should refrain from doing so -- unless, of course, doing > so would cause more problems than it would solve, which was the point of > my question. Well, this is indeed exactly the point. If we specify what can be assumed by packages, but then actually don't test that, we test something slightly different (by putting extra stuff int he environment by default) then bugs will not be found. It's a simple tradeoff between rigour and build success/hassle. In general I like the rigour in Debian and have spent the last year or so being rigourous in cross-building/multiarch stuff which has found an awful lot of (expected) breakage. (You an gloss over a lot of stuff by installing qemu in chroots when cross-building, for example, and often it's the best thing to do) In general I'm in favour of agreeing what can be relied upon and then only providing that in buildds. But you are quite right that for the purposes of buildds doing native building this improves your success rate by glossing over potentially-dubious checks, with little cost. > After all, the autobuilder network is not meant to do QA; we have > resources for doing full-archive rebuilds for that purpose. Instead, the > autobuilder network is meant to make sure we build as many packages as > possible. If we can avoid some issues in building packages that isn't > really worth spelling out in policy by just doing some minor > configuration tweak on a buildd host, I think we should do so -- and > this certainly qualifies, IMO. I only run cross-buildds, not native ones, so this isn't my call. Just bear in mind that every such choice of providing more than is strictly mandated will be hiding bugs in other circumstances. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.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/20120927121449.gp24...@stoneboat.aleph1.co.uk
Re: Changes to Debian Maintainer upload permissions
On 23/09/2012 17:49, Joachim Breitner wrote: Hi, Am Sonntag, den 23.09.2012, 15:59 +0200 schrieb Joerg Jaspert: The DM flag (and in future ACL) shows that one trusts that one DM to do a good job on that one package. Extending it like "this DM may upload all packages of [whateverbiglist]" is just wrong. (Of course this is just convenience and can already be achieved by a small script that generates the list of packages.) Yeah, but please don't. Sillyness like "all of our team packages are always for all DMs of us" is really working against the system, IMO. If you want people to have upload rights for such large sets, make them DD. DM is for people interested in small(er) style maintenance. I wouldn’t say it is plain wrong; there are certainly exceptions. All (library )packages by the DHG have identical packaging issues – if someone is able to do a good job on one of them, he is able to do a good job of all of them. Also, the real time-consuming work for us is when we need to upload all>450 packages with no source change, or a trivial one. I am certainly looking forward to distribute the load not only on the DDs but also on the DMs. FWIW, I also think it is the wrong approach for the following reason: The DM status (as I understand it) wasn't created to easily give people upload rights. It is used to give upload rights for people that don't want to become DD (for some reason) but yet want to contribute/maintain a small set of packages ; or for people waiting to become DD. If some person has a need to upload 450 packages, then that person should become DD. Your idea simply abuses the DM status. My 2 cents, -- Mehdi Dogguy مهدي الدڤي -- 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/5064410e.2010...@dogguy.org
Re: Changes to Debian Maintainer upload permissions
On 23/09/2012 17:49, Joachim Breitner wrote: we need to upload all>450 packages with no source change That's called a binNMU and is very simple to schedule, as you already know ;) In the OCaml team, we have the very same issue and we try to avoid arch:all packages for libraries and applications because it makes transitions harder for no good reason. Regards, -- Mehdi Dogguy مهدي الدڤي -- 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/50643f8e.7090...@dogguy.org
Re: Mini Debconf in Paris - November 24 & 25th 2012
This is an english speaking mailing-list. Minux is asking how to register for the event. Registration is done on the wiki. It is not mandatory to register, but will helps us to have an approximation of the number of attendees. On 23/09/2012 00:44, Minux wrote: Je suis personnellement ravi d'apprendre la réédition cette année de la minidebconf à Paris. Aurons nous besoin de s'y inscrire comme l'an dernier pour y assister ? Si oui comment ? Il te suffit d'aller sur la page wiki et de t'y inscrire, simplement. La page en question est : http://wiki.debconf.org/wiki/Miniconf-Paris/2012 L'inscription n'est pas obligatiore cette année mais cela nous est utile pour avoir une approximation du nombre de participants. Cordialement, -- Mehdi -- 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/50643d1b.6050...@debian.org
