Re: Debian Developers team in Launchpad
On 8 December 2013 02:50, Tae Wong wrote: > There exists a Debian Developers team in Launchpad: > https://launchpad.net/~debiandevelopers > Sure, it's not directly endorsed by debian-devel@lists.debian.org it's a group of launchpad users that have launchpad accounts and formed a team on launchpad, a clique of a sort. Similar to how there are debian-developer communities on G+, facebook, linked.in and other social networks. > However the account seotaewong40 (https://launchpad.net/~seotaewong40) > has been suspended. It reports an error of 410 Page Gone. > Contact launchpad support. > The following Launchpad users haven't signed the Ubuntu Code of > Conduct according to the Active members list: > László Böszörményi – gcs > Alessandro Ghedini – ghedo > Antti-Juhani Kaijanaho – ajk > Thijs Kinkhorst – kink > Ognyan Kulev – ogi > James McCoy – jamessan > Guilherme de S. Pastore – fatalerror > Marcela Tiznado – mlt-debian > James Troup – elmo > Wouter Verhelst – wouter-debian > And? =) FYI Ubuntu Code of Conduct is not required to join the ~debiandevelopers group on launchpad. > When trying to log on to seotaewong40 under Launchpad you'll get an > error message saying that this account has been suspended. > > Please ask the Launchpad administrators to stop suspending your account. > This is not Launchpad administrators contact address. For launchpad login issues, please try https://forms.canonical.com/lp-login-support/ Regards, Dmitrijs. -- 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/CANBHLUg7-Ut5hoM28=5lfu0butu9fm96ugmeftjf7q5derq...@mail.gmail.com
Re: Bits from ARM porters
On 2 December 2013 23:08, Hector Oron wrote: > 5 arm64 Debian port support > ═══ > > If Debian is unable to find ARM 64-bit hardware before Jessie gets > frozen, it likely won't be Jessie supported. > > What is the opportunity cost here? Are there no machine available within budget? If that's the case, what's the current budget that Debian Project can contribute, and what's the shortage to buy ARM 64-bit hardware *today*? Is the shortage realistically be possible to fill with a targeted fundraiser? During Jessie lifecycle, there will be demand for stable ARM64 port. Regards, Dmitrijs. -- 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/canbhluju9ilxdx0wdf8zpofrqrqwivnvciouhkraqo8xq+j...@mail.gmail.com
Re: sysvinit: moving the contents out of the Essential: yes package?
On 26 November 2013 10:42, Thomas Goirand wrote: > On 11/26/2013 04:19 PM, Russ Allbery wrote: >> Svante Signell writes: >>> On Tue, 2013-11-26 at 00:16 -0600, Steve Langasek wrote: >> The only way to address the Essential conflict for the jessie release seems to be to move the contents of sysvinit to a new package, and make sysvinit a metapackage that depends on an ORed list of the possible providers of /sbin/init. E.g.: >> Package: sysvinit Essential: yes Pre-Depends: sysvinit-core | upstart | systemd-sysv >> >>> What about adding openrc to the list above, at least for some >>> architectures. No decision has been made by the ctte yet, or? >> >> Please correct me if I'm wrong, but I believe OpenRC does not provide >> process 1 or /sbin/init and still relies on sysvinit for that. So the >> above would be correct for OpenRC. > > This is correct, OpenRC uses sysvinit, and replaces only sysv-rc (which > BTW shows that replacing a well working PID 1, or adding any piece of > code in it, is absolutely not needed at all). Currently, it does: > > Package: openrc > Architecture: any > Conflicts: sysv-rc > Replaces: sysv-rc > Provides: sysv-rc > > With the above, it's easy to switch from one to the other. Well, that is > before the mess with the version-depends on sysv-rc introduced by the > debhelper thing for upstart, which messed-up a few things... I hope many > packages have been rebuilt with the new debhelper version since that has > been corrected, especially the essential ones (like ifupdown and the > others (I can't remember)). > > By the way, is there any progress on the porting of Upstart to > kFreeBSD/hurd? I've been very pleased to see that there's been at least > some plans. But is there someone that has started implementing it? > Yes, there have been. I have completed porting libnih to kFreeBSD with full test-suite passing. And upstart compiles on kFreeBSD and passes more than half of the test-suite. I haven't yet got around to booting it. There are still a few FreeBSD specific features to write (e.g. devd bridge/integration & kevent/kqueue bridge/integration). I haven't started looking into Hurd yet, and it would be a platform i'd be discovering completely from scratch. But given how portable libnih actually turned out to be, it should be trivial for someone to start libnih porting on Hurd. The progress updates were sent to Debian Planet, G+ and shared among people at Mini DebConf UK Cambridge. Regards, Dmitrijs. -- 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/CANBHLUjQ=1be3g9npa34u582tg7tjwz3m6kfrgftq1a1a4a...@mail.gmail.com
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On 15 November 2013 12:02, Mark Brown wrote: > Package: wnpp > Severity: wishlist > Owner: Mark Brown > > * Package name: xemacs21 > Version : 21.4.22 > Upstream Author : XEmacs development team > URL : http://www.xemacs.org/ > License : GPL > Programming Lang: C, elisp > Description : highly customizable text editor > > XEmacs is a full fledged programming language with a mail reader, > news reader, info browser, web browser, calendar, specialized editor > for more programming languages and other formats than most people > encounter in a lifetime, and much more. > > While develoment on xemacs is very slow these days I find it much more > visually pleasing than GNU emacs. > Why should Debian carry this package? Which virtual packages are you planning to provide? Regards, Dmitrijs. -- 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/CANBHLUh4fa7+kwoYBtNyw_FOvKEuCBNxBRS9d-ThL=WX6cg=g...@mail.gmail.com
Re: automatically cross-grading lib32nss-mdns to libnss-mdns:i386?
On 1 November 2013 13:28, Simon McVittie wrote:
> If cross-architecture dependencies are allowed in the archive (and don't
> break dak or britney) these days, then it's easy:
>
> Package: libnss-mdns
> Architecture: any
> Multi-Arch: same
>
> Package: lib32nss-mdns
> Architecture: amd64
> Depends: libnss-mdns:i386 (= ${binary:Version})
> Description: ... transitional package ...
>
> I thought I remembered an announcement that cross-arch dependencies were
> OK for jessie, but I couldn't find it, so that might just be wishful
> thinking?
>
This one is allowed:
Depends: python:any
Actually spelling out the arch, is not.
> The only other option I can think of is to imitate Wine:
>
> Package: libnss-mdns
> Architecture: any
> Multi-Arch: same
>
> Package: lib32nss-mdns
> Architecture: amd64
> Depends: libnss-mdns-i386 (= ${binary:Version})
> Description: ... transitional package ...
>
> Package: libnss-mdns-i386
> Architecture: i386
> Depends: libnss-mdns (= ${binary:Version})
> Description: ... transitional package ...
>
> but that requires yet another content-free package, and a trip through
> the NEW queue. So, before I upload that: is there a better way?
>
That's the currently supported way of doing such migration.
Regards,
Dmitrijs.
--
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/CANBHLUiOMaGdfTEa0gNJrLmy1aAcw8w3Zc06P83acmbDmN2=n...@mail.gmail.com
Re: let's split the systemd binary package
On 25 October 2013 13:13, Simon McVittie wrote:
> On 25/10/13 11:52, Dmitrijs Ledkovs wrote:
>> - using XDG_* environment variables, instead of LOGIND_* or SYSTEMD_*
>> variables
>
> I assume you mainly mean XDG_RUNTIME_DIR here, since the rest are
> basically user-level rather than system-level.
>
No, I mean:
XDG_VTNR=7
XDG_SESSION_ID=c1
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SEAT=seat0
Above variables are specific to logind and pollute XDG_* namespace.
And well all logged in graphical user sessions evnironment is polute
which leaks everywhere (e.g. sbuild build-logs). Non-graphical
sessions have less variables, but still there shouldn't be any.
XDG_RUNTIME_DIR is absolutely fine as well as all the other variables
defined in the XDG Base Directory Spec
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> The point of the XDG_* family of variables is that they're intended to
> be a cross-desktop, multi-implementation standard. I think pam_systemd
> and its communication with systemd-logind might be the only
> implementation of XDG_RUNTIME_DIR we have right now, but there'd be
> nothing to stop someone writing a pam_xdgruntime that did it in-process,
> analogous to pam_mkhomedir.
>
XDG_RUNTIME_DIR has also been implemented by
https://launchpad.net/pam-xdg-support project.
The VTNR, SESSION_ID, SESSION_PATH, SEAT_PATH, SEAT are logind
specific at the moment, no standard published by FreeDesktop, nor has
multiple implementations, which kind of comes from not having a
cross-distro spec in the first place.
> The advantage of XDG_RUNTIME_DIR is that it makes any specification that
> refers to it simpler. For instance, if it had existed all along and been
> a prerequisite for D-Bus, we could say "use the Unix socket
> $XDG_RUNTIME_DIR/dbus/session" rather than "There's a socket somewhere,
> probably in /tmp or something, or it might be abstract, who knows? Use
> $DBUS_SESSION_BUS_ADDRESS to find it, and make sure that variable gets
> set correctly, otherwise you lose".
>
> The disadvantage of XDG_RUNTIME_DIR, which sets it apart from the other
> XDG_* variables, is that there's no good default if it isn't set: it
> requires that something on the system creates a suitable directory,
> potentially requiring privileges to do so. In contrast,
> XDG_{CACHE,DATA,CONFIG}_* can all have sensible defaults (a
> dot-directory in $HOME, which applications can create when needed).
>
> The reason that XDG_RUNTIME_DIR potentially requires privileges is that
> unprivileged users can't guarantee to be able to create a directory on a
> fully-featured local Unix filesystem with Unix sockets, fifos, atomic
> rename, etc. (as opposed to NFS or VFAT or something similarly limited).
> systemd-logind guarantees that by using a tmpfs, which has those features.
>
I think above is unnecessory. I am well aware of RUNTIME_DIR benefits
and that's not the issue I am raising.
>> I think from above points you can see, that it's not unreasonable to
>> easily mistake that systemd brings logind, instead of "logind is part
>> of the systemd software collection" & that all of "the systemd daemon
>> collection" somehow is required / endorsed by FreeDesktop project.
>
> To clarify, freedesktop.org is (at least) two things:
>
> * specifications: a set of desktop-agnostic would-be-standards for
> "APIs" that desktop environments benefit from sharing (window manager X
> property conventions, .desktop files to describe applications, XDG_*
> search paths for data/configuration, etc.). I suppose the ideal for
> these could be expressed as "not having a competing standard because
> nobody needs one".
>
Sure, where is the spec for logind specific variables? Or
implementations that is desktop-agnostic, or more specifically for
Debian - OS/kernel agnostic.
> * software: a hosting site for projects that aspire to be used in a
> cross-desktop way, analogous to a more focused
> Sourceforge/Github/Alioth. Some of these remain current (systemd,
> Telepathy, D-Bus, LibreOffice, Xorg, lightdm), some get deprecated as
> their authors realize they had design issues (ConsoleKit, HAL), some
> never really got wide adoption in the first place (Ytstenut, APOC,
> arguably Geoclue). Many of these projects have long-term competitors
> (systemd/Upstart/OpenRC/etc., NM/wicd/ConnMan/etc.,
> lightdm/gdm/kdm/etc., Xorg/Wayland) and that's fine.
>
> With hindsight, it would have probably been better off with two separate
> names for those things, but it's rather too late.
>
yeah, it's a hosting service for a clique of developers, not quite
public open
Re: let's split the systemd binary package
On 25 October 2013 10:00, Olav Vitters wrote: > On Fri, Oct 25, 2013 at 03:33:56PM +0800, Thomas Goirand wrote: >> Seems I misunderstood what logind was about. I thought it would force to >> use specific Xdm implementations that would support it. So you do >> confirm that it's not the case, and that we aren't forced into using >> GDM? Or is it that other Xdm implementations all have logind support >> these days? What exactly Gnome requires? > > logind is basically the replacement of ConsoleKit. However, it also will > do more. It will handle VT switching, something which we want/need for > _optional_ Wayland support[1]. ConsoleKit was mainly maintained and > started by GNOME developers. > > E.g. XFCE either wants ConsoleKit, or logind. If you look at ConsoleKit, > you'll notice it is NOT maintained. For the last 1.5 years, no > development. See http://cgit.freedesktop.org/ConsoleKit/log/ for > details. > > I wrote about logind and systemd in more detail at: > https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/ > > I find it quite sad that on debian-devel the majority seems focussed on > emotional arguments such as conspiracy theories, hidden agendas, etc. > Sure, but it doesn't help "logind" case though when: - it's maintained in "the systemd daemon collection" - it's pam module called "pam_systemd" instead of logind - plently of packages that had to be fixed to check for "logind" presence instead of "init is systemd" presence, when deciding to enable logind support vs consolekit/none - using XDG_* environment variables, instead of LOGIND_* or SYSTEMD_* variables I think from above points you can see, that it's not unreasonable to easily mistake that systemd brings logind, instead of "logind is part of the systemd software collection" & that all of "the systemd daemon collection" somehow is required / endorsed by FreeDesktop project. I don't know if it works on older kernels and/or without cgroups and/or how portable /just/ logind is, or other individual daemons in "the systemd daemon collection". Debian doesn't ship single binary package "GNOME" with all modules and apps build and included in the single binary package, in the same way it is not reasonable to maintain "systemd daemon collection" as a single binary package. It already splits udev into separate library/daemon packages, but at the moment logind is not. Debian is a Universal OS, that supports multiple kernels, and a pleaora of configurations, as one of Debian's core values. It is perfectly acceptable for Debian installations to exclude/include udev, cgroups, consolekit/logind, etc. Preserving that core value is important to Debian. And Debian does take pride it the amount of architectures and kernels it supports. > Simple question: logind is maintained, ConsoleKit is not. I have not > seen anyone raise this. Why? That one is easy. Both are written by the same predominantly mayor author and in some ways one project is superset of the other, and/or compete to provide same feature. It's not unreasonable for one author to pick to work on the superset and stop work on the other one. Then later switching one major desktop environemnt to support new one and not the old one and boom: old one goes from "stable/feature complete" to "dormant/obsolete/unmaintained/legacy" project. Regards, Dmitrijs. -- 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/CANBHLUhdkLSnz1phNHTtWHogT1=9kvitcj42_pwb9qv_p_6...@mail.gmail.com
Re: away_0.9.5+ds-0+nmu2_multi.changes ACCEPTED into unstable
Hello, On 25 October 2013 07:23, Rene Engelhard wrote: > Hi, > > On Fri, Oct 25, 2013 at 01:18:18AM +, Debian FTP Masters wrote: >> Changed-By: Andreas Moog [...] >> away (0.9.5+ds-0+nmu2) unstable; urgency=low >> . >>* Non-maintainer upload >> - d/p/01_fix_makefile: $LIBS need to come after $SRC while linking to >>fix building with ld --as-needed (Closes: #634323) > > A NMU for a MINOR bug is NOT something which should be done. > I quietly accepted the dbs one, but this is over the line. > I sponsored Andreas' patch as NMU, on my own initiative. > It builds fine. When some distro bogusly introduces changes which make > all kind of packages breask they can fix them up; but this is not a reason > for NMUing it in Debian. > You mean Debian right? Cause --as-needed is a linker flag available in Debian's default toolchain and there is a lot of ongoing work done to enable it by default. https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ld-as-needed;users=debian-...@lists.debian.org Bogus or not, it's an upstream linker option which reduces amount of linked libraries, and overwhelming majority of well behaved packages do build with --as-needed in ever increasing amount of distributions, e.g. OpenSuse, Fedora, etc. It's not default in Debian toolchain, but there are no good reasons why it shouldn't be. I understand that "away" package did not even handle CFLAGS, CPPFLAGS, LDFLAGS, and DESTDIR until last nmu, but why not improve a package or at least reply to the bug report? Regards, Dmitrijs. -- 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/canbhlui-x4x0z_rgm-qerglogqsfyluvzapxkgxeybig+td...@mail.gmail.com
Re: Proposal: switch default desktop to xfce
On 24 October 2013 17:38, Svante Signell wrote: > On Thu, 2013-10-24 at 18:31 +0200, Lucas Nussbaum wrote: > >> What's the the status of XFCE regarding accessibility? >> >> That was a big strengh of GNOME for a long time, though I've heard >> rumors (sorry not to be more specific) that gnome-shell has some >> unsolved issues in that regard, which is a problem since GNOME >> classic/fallback mode is gone in 3.8. > > An even stronger reason to move away from Gnome if the classic mode > disappears. > > I thought it was _back in_ 3.8.. E.g. see Classic at https://help.gnome.org/misc/release-notes/3.8/ Regards, Dmitrijs. -- 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/CANBHLUgTSrUDN3v8zBsp8=wh0t283R=bjabbsh0_senamqx...@mail.gmail.com
Re: [ANNOUNCE] git-deb: a Git importer for Debian packages
On 24 October 2013 15:15, Gabriel de Perthuis wrote: > Le 24/10/2013 15:57, Dmitrijs Ledkovs a écrit : >> On 24 October 2013 14:18, Gabriel de Perthuis wrote: >>> Hello, >>> I've written a tool to import Debian packages into Git: >>> >>> git clone deb::mypackage >> >> Is it compatible with Ian's dgit ? > > I only know what dgit does from reading the source code. dgit works > server-side and is only available to DDs; as I understand it it creates > a new, canonical repo, imports the current version and uses that as a > base for new uploads. It's useful as part of a maintainer's workflow. > My tool is useful to get a git view of any package, without waiting for > anyone to convert their repo. Yes, sure. But it starts off a repository by taking the latest .dsc file and generating a commit out of it. The cool thing about how it generates the commit, is that it's reproducible and generates stable SHA-1 id by setting GIT time variables & author variables from the .dsc. Such that it doesn't matter who/where/when runs the import as the commit tree / commit id will be the same (well sans parenting information, but that could be easily fixed with graft points) Regards, Dmitrijs. -- 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/CANBHLUgL7seZVFZV867JCLf05s5EkfPZRFS4KpWsKWfp1-h=g...@mail.gmail.com
Re: [ANNOUNCE] git-deb: a Git importer for Debian packages
On 24 October 2013 14:18, Gabriel de Perthuis wrote: > Hello, > I've written a tool to import Debian packages into Git: > > git clone deb::mypackage > > It does a faithful import of the package history from > snapshot.debian.org. There is some agressive caching built-in, and a > bit of logic to rebuild the history graph from changelogs. It is also > able to deal with most quirks in the upload history, like missing source > packages, missing .dsc files, and obsolete keys. > > On the git side, the --depth option is supported. Incremental imports > (both new releases and deepening the history) aren't yet, but the shared > cache helps rebuild branches faster. > > It's available here https://github.com/g2p/git-deb and on PyPI. Is it compatible with Ian's dgit ? Regards, Dmitrijs. -- 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/canbhluiaskvjt_x7qxw4qhwg2lrdxjd7fkvxqzz12ji2ctn...@mail.gmail.com
Re: systemd effectively mandatory now due to GNOME
On 24 October 2013 10:59, Adam Borowski wrote: > On Thu, Oct 24, 2013 at 09:11:30AM +0100, Jonathan Dowland wrote: >> On Thu, Oct 24, 2013 at 02:09:46AM +0200, Adam Borowski wrote: >> > And I for one heavily use vservers >> >> It's a professional shame of mine that we are still trying to get rid of >> some old vserver instances at $WORK. > > lxc is still nowhere close to vserver (or openvz) functionality. It lacks > even basics like "vserver enter" (you can't access a container more than > once other than via ssh or similar), not to speak about holding hostile > root. vserver probably is too heavily in maintenance mode to pretend to > satisfy this anymore, but not catching all intentional attackers doesn't > mean not stopping unintentional breakage -- or even intentional but > not sophisticated enough intruders. > http://linux.die.net/man/1/lxc-attach $ sudo lxc-attach --name mycontainer -- login if you wish to gain full login prompt. It has been around at least since 2012. And you can have multiple ones What do you mean by "holding hostile root." ? Regards, Dmitrijs. -- 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/CANBHLUiYf+GJ=e-OmXiRNA+nfvuw1vgGj=cghlb7qukfwav...@mail.gmail.com
Re: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))
On 11 October 2013 22:34, Ben Hutchings wrote: > On Fri, Oct 11, 2013 at 09:55:34PM +0100, Dmitrijs Ledkovs wrote: > [...] >> I'm not sure, but launchpad is running 64-bit machines even when >> compiling for the i386 architecture, and then launchpad supports PAE >> only and thus can get >4GB of address space. > [...] > > Which bit of 'Physical Address Extension' do you not understand? > ignore me, friday evening. the parts where virtual address space is limitted to 4gb per process none the less. Regards, Dmitrijs. -- 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/canbhlujadw1epezxg0f8oheb8ly_vy496l4ncwffgg-tmz+...@mail.gmail.com
Re: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))
On 11 October 2013 20:32, Steve Langasek wrote: > severity 726009 serious > thanks > > This remains a serious bug. Your package, which previously built on > multiple architectures, is now failing to build due to memory exhaustion. > While in some circumstances it is permissible to remove the old binaries and > drop support for an architecture, this remains a serious bug until this has > been done. (And anyway, your package won't reach testing in the current > state, so is de facto unreleasable.) > > On Fri, Oct 11, 2013 at 09:00:36PM +0200, Anton Gladky wrote: >> severity 726009 wishlist >> retitle 726009 Yade requires too much RAM for building >> thanks > >> thanks for bug-report. The problem is, that all build-failures are due >> to insufficient RAM on build-machines [1]. I do not really know how to >> "fix" that except of backlisting of some machines, as was suggested by >> Julien [2]. The same package builds fine on Launchpad's PPA. It seems, >> the package builds only on machines, where >4Gb RAM is available. > > This diagnosis is incorrect. The error you are hitting here is not that you > are exhausting the available memory on the machine, it's that you're > exhausting the *address space* on the machine. Adding more memory to the > buildd would have zero effect, because you're on a 32-bit system which has a > limit of 4GB of address space anyway. (In practice, I believe this is 3GB > for userspace and 1GB for kernel on i386.) > > The buildd almost certainly has swap already, giving it total available > memory in excess of 4GB, but that doesn't help if you have a single process > - in this case g++ - that needs more than 3GB all to itself. > > If this same package version built on Launchpad but is failing to build in > Debian unstable, then you should look at differences in toolchain versions > between the two. It's possible that Ubuntu has a compiler fix that isn't > yet available in unstable; it's equally possible that the successful builds > in Launchpad were done with an earlier toolchain, and that there's a more > recent regression in g++ memory usage. Either way, it's not the buildd's > fault. I'm not sure, but launchpad is running 64-bit machines even when compiling for the i386 architecture, and then launchpad supports PAE only and thus can get >4GB of address space. I think debian buildds are also all 64-bit apart from one (or something like that) thus it shouldn't be a problem there. Last time I spoke with Colin about yade FTBFS due to memory exhaustion, the recommendation he gave was to reduce translation units and thus to reduce the compiler memory usage. GCC memory usage can go very large and has regressed since 3.3 when templates are used http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850 It has been done before for some other packages, but i haven't yet had time to look more into yade. I think that's the best way to go for yade, to address it in the source-code / restructure it to use less memory at compile time. Regards, Dmitrijs. -- 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/CANBHLUj6+mjT2itJTdaMZtHFSuJdCVHHGC8Lpgp_5nFkicHK=q...@mail.gmail.com
Re: Call for Jessie Release Goals
On 18 September 2013 03:42, Mathieu Malaterre wrote: > On Wed, Sep 11, 2013 at 9:17 PM, Jonathan Wiltshire wrote: >> Release goals are areas of functionality which developers would like to see >> as an aim for the next release. They will not hold up the release, but >> allow the bugs opened for that goal to be of severity 'important'. > > I am not sure if this qualify as "Release goals". So I'd like to ask > first what people think of using C++11 in the next release. > > I know of a couple of C++ libraries which could be compiled with the > new gcc compilation option. And I have at least one application (no > shared lib) which requires C++11 to compile properly. Since C++11 > introduce an ABI incompatibility [*], this may not be a Release Goal > but simply a tech-ctte decision. > > Comments ? > I think I have replied about similar requests before (not sure if it was on these mailing lists). In essence, at the moment we do not have any compiler & stdlib with complete and stable ABI for C++11. It is expected that gcc4.8 will break C++11 ABI to further implement the standard. Other non-default compilers also are fully featured at the moment (w.r.t. C++11 compiler features). Thus at the moment we cannot consider switching. One can compile with C++11 enable where one must, but also one then gets to keep the ABI incompatibilities down the road (boost / template libraries especially). While one would want to start using C++11, it's not default at the moment and not feasible to make the default standard level C++11. Regards, Dmitrijs. -- 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/CANBHLUgYHMH6OymwjNc-b2O_ryuv6i_wKqDd=cnvmgzdb07...@mail.gmail.com
Re: Bug#723307: flash-kernel link with -L/usr/lib
please ignore this thread. I've now noticed these bug reports were raised to debian-devel in the " link with -L/usr/lib" thread. Regards, Dmitrijs. On 18 September 2013 02:54, Dmitrijs Ledkovs wrote: > Dear YunQiang Su, > > It looks like this class of problems is reported against a lot of > packages now. Did you consult on debian-devel before doing this mass > bug filing? > > Regards, > > Dmitrijs. > > > On 17 September 2013 11:34, YunQiang Su wrote: >> Package: flash-kernel >> Version: 3.11 >> X-Debbugs-CC: wzss...@gmail.com >> >> This package has one or more -L/usr/lib in its build system, >> which will make it ftbfs if there is libraries under /usr/lib, >> while is not the default architecture, mips* for example. >> >> On mips* systems, /usr/lib is defined as place to hold O32 >> libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. >> >> Beside the way, on the multiarch system like Debian, user may install >> libraries under /usr/lib by hand. >> >> Please use the default search path if you can, and please consider fix >> this. >> >> I will try to fix this bug, while if you can help to fix it, >> It will be very appreciative. >> >> The attachement is the buildlog of this package on mips64el platform. -- 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/CANBHLUhf=BO=u=6mknot2fcz8qwrdwkqahvfuuyiennctix...@mail.gmail.com
Re: Bug#723307: flash-kernel link with -L/usr/lib
Dear YunQiang Su, It looks like this class of problems is reported against a lot of packages now. Did you consult on debian-devel before doing this mass bug filing? Regards, Dmitrijs. On 17 September 2013 11:34, YunQiang Su wrote: > Package: flash-kernel > Version: 3.11 > X-Debbugs-CC: wzss...@gmail.com > > This package has one or more -L/usr/lib in its build system, > which will make it ftbfs if there is libraries under /usr/lib, > while is not the default architecture, mips* for example. > > On mips* systems, /usr/lib is defined as place to hold O32 > libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. > > Beside the way, on the multiarch system like Debian, user may install > libraries under /usr/lib by hand. > > Please use the default search path if you can, and please consider fix > this. > > I will try to fix this bug, while if you can help to fix it, > It will be very appreciative. > > The attachement is the buildlog of this package on mips64el platform. -- 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/canbhluibcrrhbelcyedxpdybzwse5gbzc1-ll5fqv2erwvj...@mail.gmail.com
Re: How git performs when you throw all of Debian at it
On 30 August 2013 20:55, Steven Chamberlain wrote: > Hi, > >> [...] using git instead of the file system for storing the contents >> of Debian Code Search. The hope was that it would lead to fewer disk >> seeks and less data due to gits delta-encoding > > Wouldn't ZFS be a more natural way to do something like this? > > A choice of gzip, lzjb and more recently lz4 compression; snapshots > and/or deduplication both reduce the amount of disk blocks and cache > memory needed. > > I've pondered before at this overlap in functionality between packing by > Git, and those features of the ZFS filesystem. They are doing much the > same thing but with different granularity. It would be neat if they > could work together better. I haven't finished packaging bedup - btrfs deduplication tool. Anybody have benchmarked that, if that's any good and/or comparable to zfs deduplication? lzo compression is also available. And well available in linux kernel. Regards, Dmitrijs. -- 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/canbhluibdvtshc5dbtwobf67xdexnjpumafcpvx1auj37te...@mail.gmail.com
Re: Less dinstall FTW?
On 29 August 2013 10:55, Luca Falavigna wrote: > 2013/8/29 Dmitrijs Ledkovs : >> Can dinstall be run every hour please? For me, if anything dinstall is >> not frequent enough. > > No, dinstall takes more than an hour to finish... > Ok. >> If it takes longer than hour to execute, can it be optimised and sped up? > > ... and even if it can be reduced, there are more problems this would > introduce (mirror pushes, snapshot pushes, ...) > Is incoming.debian.org mirrored? From my end (UK) it looks like it's hosted in the USA, well 17 hops away with a ~10% packet loss along the way (could be blocked mtr/pings) So I will not be pulling from incoming.debian.org. Since I usually aim to work << 12h a day coding, as a developer it means that at most I'll be able to see updates once a day. And my own upload only the next day. I don't want to build packages using local apt repository of uploads, since e.g. I don't want to upload something that was build against earlier uploaded $foo, which got rejected by ftp-masters for example. Currently, it's sometimes possible for me to see updates twice a day (e.g. my morning upload in the evening). Can incoming be mirrored on e.g. eu & jp UploadQueue boxes? Regards, Dmitrijs. -- 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/canbhluivckvjrzptj114bc2wse4cv_pn2pzw2xomldz+3ba...@mail.gmail.com
Re: Less dinstall FTW?
On 28 August 2013 21:58, Joerg Jaspert wrote: > Hello Debian world, > > there is currently a discussion within the FTP Team and we appear to > have two opinions on it. As we are open on the outcome and it basically > affects the whole project, we came up with the following summary to > solicit feedback, opinions and other ideas. > > The proposal at hand is: > * Lower dinstall frequency to two times a day. Can dinstall be run every hour please? For me, if anything dinstall is not frequent enough. If it takes longer than hour to execute, can it be optimised and sped up? > * Have incoming.debian.org be an apt-able location (actually the buildd >locations, so it is suite/archive specific, not one global queue)[1] No opinion, as I don't actually understand what that means. As in, will that enabled buildds to fetch/use packages from incoming.d.o? Regards, Dmitrijs. -- 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/canbhluhdkqak19sb4k-odegthlxveun3gjppzo7fvnk2snp...@mail.gmail.com
Re: UTF-8 in jessie
On 12 August 2013 01:51, Adam Borowski wrote: > > 3. all file names must be valid UTF-8 > Case in point errors from ubuntu UDD package importer: """ Packages containing non-UTF-8, non-ASCII filenames. This is a problem. It is unclear how to sensibly map these into Bazaar. anon-proxy aspell-is aspell-pt aspell-ro cvsnt dacco egroupware ewiki firebird2 fortunes-pl fslint glest-data gmoo ii-esu ispell-fo jpilot kdeedu liblingua-de-ascii-perl magyarispell mtink ooohg openverse phpgedview phpgroupware projectl qcad qdvdauthor tatan tuxpaint uae xblast-tnt xblast-tnt-levels """ Not sure how up to date this list is (it could be a historic package version that has non-UTF8/non-ASCII filenames.) Test & file bugs? Regards, Dmitrijs. -- 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/canbhlui_ch-z7y+ga4f2ui81if2gjog-cxccmfzuzumpzjf...@mail.gmail.com
Re: Introducing dgit - git integration with the Debian archive
On 25 August 2013 17:31, Steve Langasek wrote: > On Sun, Aug 25, 2013 at 12:51:31PM +0100, Dmitrijs Ledkovs wrote: >> I have maintenance access to UDD & have filed a few bugs about it, and >> all I can say is that dgit so far is getting a lot of things right: > > > >> 2) removing automatic importer >> forcing all the checks on the developer side & forcing VCS commit to >> match the src upload is a massive win. It means that one can actually >> trust the archive & VCS commits. And they will always match. (Well one >> can even verify that by unpacking the .dsc and comparing it to the >> Dgit: commit id) After all the archive will always be authoritative, >> as that's that gets GPG signature, is mirrored and gets deployed to >> the users. > > I don't think "removing the automatic importer" is an improvement at all. > If we want VCS branches for the whole of Debian that we can rely on, > something / someone needs to update them automatically when a package is > uploaded. > Under dgit: push = (git push + dput *.changes). Thus the failure mode is much sooner and in general it's more strict. For uploads done without using dgit, it can synthesise "upload granulaty" commits with reproducible / stable commit ids. Thus the branches are maintained up to date, without the need to rely on automatic importer. One can trivially add automatic importer for uploads done without dgit. > The problems with the UDD automatic importer have all been around its > failing to cope with any kind of manual changes to the bzr branch. I.e., > if even once the importer sees an upload before it sees the corresponding > commit on the bzr branch - because a maintainer did a bzr push --overwrite, > or because of a race between the upload and the branch propagation, or > because of a bug on the server - then that package is forever after in > "manual" import mode until someone with admin privileges can kick the > machine. This is a pretty bad failure mode; but it's a failure because the > importer can't cope with changes to the branch, not because automatic > importing was being done. > >> And one is free to push pristine-tar (if makes sense/easy to >> generate), and/or any other branches into the repository (git-dpm, >> git-quilt, etc) > > I would have expected dgit to support pristine-tar > directly/automatically/unconditionally. Any system that requires me to > download the same information (== the upstream source) both from a VCS > repository and the archive in order to get a fully-formed source package for > upload is a non-starter. > if pristine-tar can recreate the tarball, without size penalties. Since it's just a git repository, one can do $ pristine-tar commit and push that into the dgit repository. At the moment it's not a requirement. >> I am exited about dgit, as for the first time it will be possible for >> derivatives to centrally share history with Debian. > > I am as well! > >> In practice one doesn't actually care how far back the history goes, >> as the history that is interesting is where developers get to do >> intermediate commits between the two uploads to granulise the >> changes > > I don't agree with this at all. I have regularly made use of the UDD > branches to examine the history of packages (and not just the Ubuntu > history, but also the Debian history). Being upload-level granularity makes > it less useful than if it were at the granularity of a VCS branch being > committed to natively by the developer, but it's still *very* useful for > understanding the uploader's thought process at the time a change was made. > > The fact that git will allow us to graft the developer's own VCS on to these > dgit repositories in a way that UDD never did is an important improvement, > but as this is *optional*, not importing the package history from the > archive would make dgit much less useful for the common case than UDD is > today. > Ok. Given that we have snapshots.debian.org & graft points we can create "import level" history in retrospect. But I find merging existing history more interesting: either upstream, or existing git/svn packaging repositories. For new packages with dgit, I start my repository on top of upstream git reposity, which gives full history of the project in the dgit repository. Imho shared history with upstream projects is more interesting than debian packaging upload history. Ideally one would have both =) Regards, Dmitrijs. -- 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/canbhluhypp-aaq-k1oihougwok+itswxkq2fsjl0qdk9gmf...@mail.gmail.com
Re: Introducing dgit - git integration with the Debian archive
On 22 August 2013 20:52, Ian Jackson wrote: > I'm pleased to announce that dgit 0.7, which is a version of dgit > suitable for alpha and beta testers, is available in unstable. > I have now started daily PPA builds for dgit, for all supported Ubuntu releases. add-apt-repository ppa:xnox/dgit Since dgit dependencies are so simple, it should also be safe to use that PPA on any debian release as well, e.g.: deb http://ppa.launchpad.net/xnox/dgit/ubuntu precise main deb-src http://ppa.launchpad.net/xnox/dgit/ubuntu precise main With the following archive key 1024R/4031D287 2D9DF1E22F3416238D46F49F157951FE4031D287 http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x157951FE4031D287 Regards, Dmitrijs. -- 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/CANBHLUjGfENtc3ne+Cupwvgc4DtN3+_8kcJ=21oxxwzksd8...@mail.gmail.com
Re: Introducing dgit - git integration with the Debian archive
On 25 August 2013 12:04, Raphael Hertzog wrote: > Hello, > > On Thu, 22 Aug 2013, Ian Jackson wrote: >> I'm pleased to announce that dgit 0.7, which is a version of dgit >> suitable for alpha and beta testers, is available in unstable. >> >> >From the manpage: >> >>dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir] >>dgit [dgit-opts] fetch|pull [dgit-opts] [suite] >>dgit [dgit-opts] build|sbuild [build-opts] >>dgit [dgit-opts] push [dgit-opts] [suite] >> >>dgit treats the Debian archive as a version control system, and >>bidirectionally gateways between the archive and git. The git > > Basically, this is "Ubuntu Distributed Development" (UDD) but for Debian & > Git (instead of Ubuntu & bzr). > > Have you looked at UDD? They have been doing this for multiple years and > have much more experience than us here. I'm sure there a quite a few > things to learn from what they did to not redo the same mistakes. > Things to learn from UDD: 1) the fact that debian didn't have a _standartised_ VCS repository format, for UDD workflow all debian packages had to be imported, such that lp:debian/package can be merged into lp:ubuntu/package. 2) 3.0 (quilt) causes problems: - we had to go with committing .pc directory in the unpacked tree. As otherwise, new patch end up at the start of the quilt series and can cause the rest of series to fail to apply - debian/patches/series.$vendor is evil, often series.ubuntu were not updated/refreshed/rebased causing dpkg-source -x to fail with DEB_VENDOR=Ubuntu - Merging two quilt series is a pain, as there is no $ quilt merge. We end up unapplying both quilt series, merging the branches and throw conflicts in debian/patches/series at the developer and asking them to figure out what patches to apply and refresh quilt series themselves. - versioning .pc directory is a pain, especially when quilt is updated. E.g. newer versions of quilt added pointless .timestamp files in the .pc directory which where not present in the automatic lp:ubuntu/* and lp:debian/* branches which used older quilt - a valid git/bzr patch may not be a valid quilt patch, and it turn may not be a valid "patch" as considered by dpkg. It's getting better with patch(1) starting to support git format-patch style patches. Thus cherry-picking from upstream becomes a pain, I have multiple times applied upstream cherry-picked patch, only later find out that e.g. +x flag was not preserved, or fuzz is generated, or files are not renamed. - tarball inside tarball packaging is evil & must die 3) Automatic importer is part of the UDD workflow, only because there was no standartised developer created rich-VCS history on Debian side which fully matched the archive state. And basing ubuntu branches, on something that doesn't match debian uploads into the archive was a no-go. 4) automatic importer was necessory to import Debian history and well it was not perfect: http://package-import.ubuntu.com/status/, pristine-tar used to fail (importer was running on stable, now upgraded and much better), dpkg-source -x sometimes fails, operational issues (timeouts, OOM, etc), unreconcilable history (developer rebases old tags, and importer can no longer reconcile it's state), - history can be odd: UDD discovered where referenced uploads didn't happen, or experimetal got ahead & then behind sid and has a really hard time figuring out when, if ever, experimental got merged into sid. (sometimes it's just abandoned) I think james can give more examples. The best UDD workflow seems to work with native packages: As a highlight I can give example debian-installer. All debian-installer git repositories are homogeneous and follow the same layout. All of d-i projects are imported into bzr branches https://code.launchpad.net/d-i And then Ubuntu Installer team maintains branches where Ubuntu diverges, e.g.: lp:~ubuntu-core-dev/apt-setup/ubuntu which frequently merges in debian changes from lp:apt-setup In a similar manner packages which use 1.0 format without a patch system work really well with lp:ubuntu/* and lp:debian/* branches. I have maintenance access to UDD & have filed a few bugs about it, and all I can say is that dgit so far is getting a lot of things right: 1) round-trip tree guarantee same is required for UDD, and automatic importer can fail to get the state right when developers push different tree in the VCS vs what dpkg-source -x produces. Don't forget, e.g. git doesn't commit empty directories. I have seen a case where bzr-git was used to push commits without empty directories into lp:ubuntu/$pkg branches & then dpkg-source -x not matching the state of the vcs, resulting in the automatic importer failing. 2) removing automatic importer forcing all the checks on the developer side & forcing VCS commit to match the src upload is a massive win. It means that one can actually trust the archive & VCS commits. And they will always match. (Well one can even verify that by unpac
Re: Custom Reload command/signal in upstart
On 31 May 2013 22:44, Ondřej Surý wrote: > > It's pretty much equivalent with one exception – I need to send USR2 on > reload. Does upstart already have the support for custom reload signals? > Upstart 1.10 released today has the following new stanza thus you will be able to specify: "reload signal SIGUSR2" Once 1.10 is uploaded in Debian. Regards, Dmitrijs. -- 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/canbhluis2jp-bvv6g5p2o-br2-ci6+2v4yhz0ybuvbho5nm...@mail.gmail.com
Bug#720547: ITP: ocaml-estring -- Estring: OCaml development platform
Package: wnpp Owner: Dmitrijs Ledkovs Severity: wishlist * Package name: ocaml-estring Version : git snapshot Upstream Author : Jeremie Dimino * URL or Web page : https://github.com/diml/estring * License : BSD-3-Clause Description : Estring: OCaml development platform estring, which stands for `extended strings' is a syntax extension allowing to prefix string literals with a specifier to change their meaning. . This package used to be part of the batteries project. Regards, Dmitrijs -- 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/87a9k8lm4d@debian.org
Re: Introducing dgit - git integration with the Debian archive
On 23 August 2013 00:38, Charles Plessy wrote: > Le Thu, Aug 22, 2013 at 08:52:10PM +0100, Ian Jackson a écrit : >> I'm pleased to announce that dgit 0.7, which is a version of dgit >> suitable for alpha and beta testers, is available in unstable. >> >> >From the manpage: >> >>dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir] >>dgit [dgit-opts] fetch|pull [dgit-opts] [suite] >>dgit [dgit-opts] build|sbuild [build-opts] >>dgit [dgit-opts] push [dgit-opts] [suite] >> >>dgit treats the Debian archive as a version control system, and >>bidirectionally gateways between the archive and git. The git >>view of the package can contain the usual upstream git history, >>and will be augmented by commits representing uploads done by >>other developers not using dgit. This git history is stored in >>a canonical location known as dgit-repos which lives outside >>the Debian archive (currently, on Alioth). > > Thanks a lot for this development ! > > For the packages that I maintain with Git, I commit build logs (the local one > for the uploaded binary packages, plus the buildd ones) in separate branches. > In some cases I found it quite useful. Have you considered integrating logs > in > dgit ? In a somehow similar goal (finding difference between builds), have > you > also considered committing the contents of the unpacked binary packages in > other branches ? > Apart from designated release dgit branches, it's a normal git repository into which one can push whatever one wants: pristine-tar, various git/quilt patch management branches, build-logs, upstream branches et. al. Regards, Dmitrijs. -- 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/canbhluhxyz9qkbbbwsvejcbsre9azss5e5ymgpcnpqkxpie...@mail.gmail.com
Bug#720209: ITP: libinotify-kqueue -- inotify compatible implementation using kqueue
Package: wnpp Owner: Dmitrijs Ledkovs Severity: wishlist * Package name: libinotify-kqueue Version : upstream snapshot from 20120419 Upstream Author : Dmitry Matveev * URL or Web page : https://github.com/dmatveev/libinotify-kqueue * License : MIT/BSD Description : inotify compatible implementation using kqueue This package provides an implementation of sys/inotify.h using kqueue. This is kind of reverse of libkqueue package, as it allows to compile software on kFreeBSD which otherwise is using Linux specific inotify API. -- 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/87eh9py3tu@debian.org
Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs
On 13 August 2013 19:59, Julien Cristau wrote: > [why oh why are you breaking threading?] > > On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote: > >> We have build log analyzers running for the build logs. And the >> important compiler warnings (errors) fail the build. >> If we make this opt-in, we will fail to achieve this goal. As when one >> is debugging a failed build (e.g. the failure in the last hour of >> webkit/qt/libreoffice compile on armhf porter box, or by hand >> ./debian/rules build) that's when one would start caring & wishing to >> have the verbose output would have been set, but it would be too late. >> > I don't see how. Either dpkg-buildpackage -nc or re-running > debian/rules build with the option set would give you what you want. For well behaved build-systems that would only show flags for the yet to compile object, where the bug might be in the flags/libs used for the already compiled objects. (i don't have an example here, something like mixing with/without -fPIC but we get warnings which objects are at fault anyway) For less behaved build-systems this may cause a reconfigure and restart the whole build. Which is suboptimal. In the past there have been random bugs / build failures which are not reproducible on re-runs (but I've yet to see one which depended on build-flags, unless one gets different flags =/ on reruns which wouldn't know about) In controlled environments, one doesn't get to re-run a build, as the instances are stripped-down and destroyed on build failure E.g. all the jenkins instances running debian package builds, PPAs, auto-package-tests, automated cross-builders. One would have to modify each and every deployment of those... Somehow we lived fine with verbose build-logs, until automake silent rules and a few other build-systems started to become more silent. I can understand the appeal of silent builds for upstream developers, but it makes zero sense for a distribution or package maintainers or our downstream. Regards, Dmitrijs. -- 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/CANBHLUi1+Q8PVTJF2TvhGKBLQh-y=elhrzpuv-7ntjlypch...@mail.gmail.com
Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs
On 13 August 2013 14:36, Joey Hess wrote: > Dmitrijs Ledkovs wrote: >> Is there any reason this hasn't been applied yet? >> Can I NMU this, as debhelper is marked as LowNMU package. > > Not for reasons such as allowing patches like this. > Ok. > Making all builds verbose by default has both advantages and > disadvantages. > I agree, there should be a way to toggle this. > The disadvantages include making builds possibly so noisy that when one > runs them during daily work, once ignores all output. Including > important compiler warnings. > We have build log analyzers running for the build logs. And the important compiler warnings (errors) fail the build. If we make this opt-in, we will fail to achieve this goal. As when one is debugging a failed build (e.g. the failure in the last hour of webkit/qt/libreoffice compile on armhf porter box, or by hand ./debian/rules build) that's when one would start caring & wishing to have the verbose output would have been set, but it would be too late. The way I interpret this goal is to have the build logs verbose by default and/or opt-out. Making this opt-in, will need many machines modified - potentially all the builders / CI integration. It's not just about Debian buildd network, but anyone who rebuilds debian packages or derives from Debian. Including all the ways people integrate and build debian packages. > (This is the same reason why it's a bad idea to let a codebase > accumulate a lot of compiler warnings!) > > I'd be ok with DH_VERBOSE enabling the verbose behavior, and the buildds > could then enable it. > I'm against re-using DH_VERBOSE variable: * DH_VERBOSE has explicit meaning to control output of dh_* commands. DH_VEBOSE=1 should print how/what dh_auto_* commands invokes. It should not change the commands it invokes. * this debian goal is not debhelper/cdbs/etc specific, but helper/build-system agnostic. How about a new DEB_BUILD_OPTION="silent" which opts into silent build log? Does that sound reasonable. For a policy change, I am hoping to mandatory require verbose build by default, and optionally supporting DEB_BUILD_OPTION="silent". Regards, Dmitrijs. -- 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/canbhlujxxzznj6tbmwvosrgra4jbdaa2oxtqi6futyf7t7z...@mail.gmail.com
Re: jessie release goal: verbose build logs
On 17 June 2013 23:58, Dmitrijs Ledkovs wrote: > tags 680686 patch > thanks > > On 14 June 2013 12:35, Matthias Klose wrote: >> >> - Fix debhelper not passing --disable-silent-rules by default. >>#680686 >>I think cdbs already does this. > > Patch attached for autoconf dh build system. cmake dh build system > seems to be already enabling verbose makefiles. > Is there any reason this hasn't been applied yet? Can I NMU this, as debhelper is marked as LowNMU package. The patch itself is a trivial one-liner and fixes a Jessie release goal. The bug report itself was filed a little over one year ago. Regards, Dmitrijs. -- 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/canbhluij3-_x_fe0dq6v2nu7duma9gfsh_ze7yeogit9abf...@mail.gmail.com
Re: UTF-8 in jessie
On 12 August 2013 01:51, Adam Borowski wrote:
> On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote:
> I propose the following sub-goals:
>
> 1. all programs should, in their default configuration, accept UTF-8 input
>and pass it through uncorrupted. Having to manually specify encoding
>is acceptable only in a programmatic interface, GUI/std{in,out,err}/
>command line/plain files should work with nothing but LC_CTYPE.
>
> 2. all GUI/curses/etc programs should be able to display UTF-8 output where
>appropriate
>
> 3. all file names must be valid UTF-8
>
> 4. all text files should be encoded in UTF-8
>
What about locales though?
* C.utf8 locale should be always available
* C.utf8 locale should be the default/fallback locale
* utf8 locale variants should be default / available / preferred
(where appropriate)
(this is rough idea, adjust above as appropriate & feasible at this
point in time)
Regards,
Dmitrijs.
--
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/canbhluhz9rezyipz1ze5zrptb5zccrspmdf9aoaygqyjvk1...@mail.gmail.com
Re: C++11
On 6 August 2013 14:41, Pau Garcia i Quiles wrote: > Hello, > > I am the maintainer of Wt [1], a C++ web development library (think of Qt or > Gtk+ for the web) and web server. > > My upstream [2] sent me a mail asking about mixing C++03 and C++11. My > understanding is it is not possible for a variety of reasons, unless all > players take great care (see [3], for instance). > > The specific case upstream asked about is Boost.Signals2, which provides a > different and ABI-incompatible implementation [4] depending on whether Boost > was compiled as C++03 or C++11. I expect users and Wt to use more and more > C++11, to the point where Wt may not even be compilable as C++03. Given that > Wt depends on Boost, I can foresee a problem: > > - Application may be C++11 or C++03, depending on what the user is doing > - Wt would be C++11-only > - Boost would be compiled as C++03 in Debian > - Wt (C++11) would depend on Boost (C++03), which but this mix is broken > > I'm talking about Wt + Boost in this e-mail but this will arise as other > combinations for other packagers: log4cpp, Xerces, SOCI, ACE (which I > co-maintain), Gtkmm, ZeroC ICE, POCO, etc > > I have googled but so far I have found no clear conclusion about this for > Debian. What are we going to do with C++11? Are we goint to provide C++03 > and C++11 using multiarch (is that even possible?) ? Everything C++11? > Fingers crossed? > At the moment gcc-4.8 C++11 abi is still experimental and has not been declared stable. 4.8.1 did bring a few advances, but the stdlibc++ is still not C++11 complete. There are further ABI breakages planned to happen in 4.9, and hopefully with 4.9 it will become default. Currently the default boost version in Debian is 1.49, the transition to boost1.54 is planned soon. At the moment, compiling with C++11 enabled, will result in binaries which are not abi stable, since toolchain abi will change and all of those packages that use C++11 will have to be recompiled (a big pain). I guess one could use gcc-4.8.1 with libc++ from llvm project, but libc++ doesn't seem to have complete test-suite pass on linux (if their website results are the current ones) and libc++ doesn't support the complete range of support Debian architectures. In short, I am not expecting compiling with C++11 by default in Debian until after gcc-4.9 is default and libstc++ is api/abi stable for C++11. In practice, you can enabled c++11 but you get to keep the fallout from abi mismatches between said package, its dependencies and reverse depends / build-depends. (some packages started doing this in ubuntu, and it has been a pain > E. g Microsoft took a very pragmatic decision: C++11 is enabled by default > and it is not possible to disable it. > I'm not sure how that applies to linux distributions though. There is no package management per-se and one either depends on platform libraries from micrsoft or bundles their own copies. On Debian we need to ship something that works across 12 odd architectures and 30 000 packages. Some additional points: http://gcc.gnu.org/wiki/Cxx11AbiCompatibility Regards, Dmitrijs. -- 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/canbhlugygbouqwkvdhxewmdm_bexzazmdu+fwk172dsy9_s...@mail.gmail.com
Re: Status of deb(5) format support in Debian
On 1 August 2013 16:21, Adam Borowski wrote: > On Thu, Aug 01, 2013 at 03:52:38PM +0100, Dmitrijs Ledkovs wrote: >> On 1 August 2013 15:40, Adam Borowski wrote: >> > On Wed, Jul 31, 2013 at 06:24:32PM +0200, Guillem Jover wrote: >> >> [...] in preparation to add non-gzip compression support for control.tar >> > >> > May I ask why would you want that? >> > >> > There's a lot of extra complexity, incompatibility with existing tools, >> > added moving parts... and I'm not aware of any gain. >> > >> > xz, while vastly superior to gzip and bzip2 for bulk data, suffers from >> > slow start: for files a few tens of kilobytes or smaller, xz compresses >> > worse than gzip. Thus, control.tar.xz is hardly ever a good idea. >> > >> > On the other hand, control files compress pretty well, so you want _some_ >> > form of compression. For files this small, CPU costs are totally >> > negligible. >> > >> > Thus, with .tar.gz being either the best or very close to the best, >> > what would be the point of this change? >> > >> >> For debian-installer (et. al. components) at the moment control.tar.gz >> is often larger than data.tar.xz since "templates" are very long and >> include a lot of translations. > > Hmm... indeed, some udebs have monstrous control tarballs, the biggest one > being 1167360 bytes long (uncompressed). > >> So for that package group it's valuable to have control.tar.xz. > > Still, total gains for all udebs (jessie netinst amd64) are only 1.22MB. > Should I try this for regular debs? > libc6 compressed control.tar.gz is 66kB It has uncompressed 111kB symbols, 68.5kB templates. Regards, Dmitrijs. -- 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/canbhluifsouuw0s7vgghk4bvtw_rddu6yxxn9jysivoglm_...@mail.gmail.com
Re: Status of deb(5) format support in Debian
On 1 August 2013 15:40, Adam Borowski wrote: > On Wed, Jul 31, 2013 at 06:24:32PM +0200, Guillem Jover wrote: >> [...] in preparation to add non-gzip compression support for control.tar > > May I ask why would you want that? > > There's a lot of extra complexity, incompatibility with existing tools, > added moving parts... and I'm not aware of any gain. > > xz, while vastly superior to gzip and bzip2 for bulk data, suffers from > slow start: for files a few tens of kilobytes or smaller, xz compresses > worse than gzip. Thus, control.tar.xz is hardly ever a good idea. > > On the other hand, control files compress pretty well, so you want _some_ > form of compression. For files this small, CPU costs are totally > negligible. > > Thus, with .tar.gz being either the best or very close to the best, > what would be the point of this change? > For debian-installer (et. al. components) at the moment control.tar.gz is often larger than data.tar.xz since "templates" are very long and include a lot of translations. So for that package group it's valuable to have control.tar.xz. Regards, Dmitrijs. -- 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/CANBHLUgTASqMtq9w=iBsSo42Fqeo+DK7o0rfqpEB4-h1Ff=1...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 22 July 2013 10:17, Josselin Mouette wrote: > Le lundi 22 juillet 2013 à 10:45 +0200, Gergely Nagy a écrit : >> systemd being installed does not mean it will be used as init. The >> package happens to contain a few tools the GNOME Shell needs, that is >> all, to the best of my knowledge. It's a harmless dependency if you >> don't use systemd, one that is only "scary" on paper. > > If you don’t use systemd, logind will be non-functional, and you lose > all features that require the system to know who is logged on what. Such > as shutting down the system, mounting USB devices, and so on. > If packaged right, this is not the case. I am running my machine with logind and upstart as system & user session init. Most of upstream packages were modified to correctly check for logind presence, instead of systemd presence. (Many thanks goes to pitti). Regards, Dmitrijs. -- 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/canbhluialjedcgquy-7p5ii5bnrmp-x0erlosgm1qkrdc91...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 18 July 2013 21:14, Cyril Brulebois wrote: > Thomas Goirand (2013-07-19): >> So that brings me to ask: do you have an idea of how much work it would >> be to have Upstart ported to kFreeBSD or Hurd (even if that would mean >> loosing some of the functionality (obviously cgroups comes to mind))? > > Surely, you could have tried “porting upstart kfreebsd” in your favorite > search engine, and you would have found Scott's mail from 2009 addressing > that particular question. Right? > > http://lists.debian.org/debian-bsd/2009/07/msg00122.html > And this was pondered again not that long ago: http://lists.debian.org/debian-devel/2013/05/msg01227.html I see that 9.1 and 10 kernels are available in experimental so an upstart port to kfreebsd can be approached. Regards, Dmitrijs. -- 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/canbhluhukrq4ixxpptbvvhhgcqtf8jsk3pxi4ai7kgauffo...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 17 July 2013 17:04, John Paul Adrian Glaubitz wrote: > On 07/17/2013 05:38 PM, Marc Haber wrote: >> >> >> I would not have posted if that had been the first time I found Joss' >> advocacy offensive. It is, however, a repeated pattern. > > > From which I would infer you shouldn't take it as a personal offense. > He usually has a point, even though he is exaggerating sometimes. At > least he isn't swearing as bad as Linus [1] ;). > > And, really, you shouldn't take that too serious. > > Adrian > >> [1] https://lkml.org/lkml/2013/7/13/132 > Thanks for pointing out, but the way Linus interacts is not OK. And he has been called out on it. http://marc.info/?l=linux-kernel&m=137390362508794&w=2 Multiple people are retweeting/G+/resonating with Sarah's comments. Unlike LKML, Debian has actually accepted a Diversity statement [2] and I'd rather see Debian adhere & excel at what it calls for. [2] http://www.debian.org/vote/2012/vote_002 С уважением, Ледков Дмитрий Юрьевич. -- 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/CANBHLUhPvHueff7G0K8MY1ORaX65UTyVrM0xmjPiacCYT_um=w...@mail.gmail.com
Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports
On 16 July 2013 19:39, Roger Leigh wrote: > On Tue, Jul 16, 2013 at 06:38:18PM +0100, Dmitrijs Ledkovs wrote: >> On 16 July 2013 17:07, Roger Leigh wrote: >> > Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr >> > using that information. When init starts, /usr is therefore >> > available from the beginning. Note that the objective here isn't >> > to allow the initramfs to run binaries from /usr, but to ensure >> > that /usr is available at all times when the system is running-- >> > this means that all programs, libraries, modules, datafiles etc. >> > are available before init starts. >> > >> > There are some complicating details: >> > - we need to ensure that the modules needed to mount /usr are >> > available in the initramfs (copy the needed modules and >> > mount helpers into the initramfs) >> > - we can't fsck /usr when mounted, so this needs doing in the >> > initramfs (/ and /usr are fscked, with the appropriate >> > helpers copied into the initramfs) >> > - fsck's -R option updated to skip /usr as well as root. >> > - /etc/init.d/checkroot.sh updated to handle /usr as well >> > as root (e.g. remounting r/w). >> >> Up to here, all sounds good. >> >> Making the $mountpoints which above are treated / mounted in >> initramfs, makes sense. >> To be able to default to "/" only and change to "/ and /usr" if one desires. >> And even plugin in the feature below. >> >> > - using the same infrastructure, it's also possible to >> > mount /etc in the initramfs so that you can have e.g. a >> > separately encrypted /etc filesystem. This is a separate >> > feature though and can be split out. >> > >> >> Imho the overhead between having just "/etc" vs "/" encrypted is >> small, if "/var", "/usr", "/home", "/opt" are separate mountpoints. >> Thus to me, treating "/etc" separately is a misfeature, considering a >> mounted "/" assumes /etc must be present. >> At least, it would go against my expectation. > > This is certainly the case at present. The rationale for doing this > is that if you have / and /usr on a single filesystem, but you want > to encrypt the content of /etc, you can now encrypt just /etc. It > also means you can have the rootfs read-only with a writable /etc, > have /etc as a writable overlay or separate fs on a common image for > cluster environments, etc. For encrypting stuff, it's moving the > boundary from one of simple convienience (/usr) to where it's actually > needed. But I can accept that this won't have universal appeal. > Thinking about it more, it's possibly not the encryption case which might be most prominent here. I have seen containers / images made readonly, with /etc mounted using overlayfs to provide easily clonable machines (chroots, lxc-containers, "cloud-images"). Not sure, but probably, capser was used to do the mounting there. >> I haven't yet reviewed the 17 patches log patch series on [1]. But is >> "/etc" handling clearly separated in it already, or some >> rebasing/reshuffling needed? > > It's just patch number 11/17 with some minor documentation comments in > patch 12/17, so it can be easily dropped without problems (intentionally). > However, even if applied, it's a strictly optional feature that won't be > used by default unless you provide etc= options to match the root= > options on the kernel command-line. > Ok, thanks for the heads up. Regards, Dmitrijs. -- 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/CANBHLUjRojxuo7FmnRrQ76VugG29bjFP31eF=bawbpum_pz...@mail.gmail.com
Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports
On 16 July 2013 17:07, Roger Leigh wrote: > On Tue, Jul 16, 2013 at 05:37:09PM +0200, Paul Wise wrote: >> On Sun, Jul 14, 2013 at 10:38 PM, Roger Leigh wrote: >> >> > I don't think that we agreed on merging /usr at all. I have written >> > some patches for initramfs-tools to permit fsck and mount of /usr >> > in the initramfs in addition to the rootfs, but that's as far as this >> > has gone. There's no merging here, just changing where /usr is >> > mounted in the boot process. >> >> Is this implemented by just mounting /usr, by discovering which >> partitions need mounting for each binary that is to be run from the >> initramfs or by copying stuff from /usr into the initramfs too? > > Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr > using that information. When init starts, /usr is therefore > available from the beginning. Note that the objective here isn't > to allow the initramfs to run binaries from /usr, but to ensure > that /usr is available at all times when the system is running-- > this means that all programs, libraries, modules, datafiles etc. > are available before init starts. > > There are some complicating details: > - we need to ensure that the modules needed to mount /usr are > available in the initramfs (copy the needed modules and > mount helpers into the initramfs) > - we can't fsck /usr when mounted, so this needs doing in the > initramfs (/ and /usr are fscked, with the appropriate > helpers copied into the initramfs) > - fsck's -R option updated to skip /usr as well as root. > - /etc/init.d/checkroot.sh updated to handle /usr as well > as root (e.g. remounting r/w). > Up to here, all sounds good. Making the $mountpoints which above are treated / mounted in initramfs, makes sense. To be able to default to "/" only and change to "/ and /usr" if one desires. And even plugin in the feature below. > - using the same infrastructure, it's also possible to > mount /etc in the initramfs so that you can have e.g. a > separately encrypted /etc filesystem. This is a separate > feature though and can be split out. > Imho the overhead between having just "/etc" vs "/" encrypted is small, if "/var", "/usr", "/home", "/opt" are separate mountpoints. Thus to me, treating "/etc" separately is a misfeature, considering a mounted "/" assumes /etc must be present. At least, it would go against my expectation. I haven't yet reviewed the 17 patches log patch series on [1]. But is "/etc" handling clearly separated in it already, or some rebasing/reshuffling needed? Regards, Dmitrijs. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459 -- 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/CANBHLUhRPUcnhK11MstzuVTWY_=ttvt4onwrhbzrul90zwk...@mail.gmail.com
Re: abi-compliance-checker and abi-dumper to track API/ABI
On 10 July 2013 09:20, Paul Wise wrote:
> On Wed, Jul 10, 2013 at 4:08 PM, Andrey Ponomarenko wrote:
>
>> There is a simple Perl script to do that:
>
> Thanks, what about including this capability in a-c-c itself?
>
I'd take a patch to dh-acc ;-)
>> my $Version = `dpkg -s $Package|grep Version`;
>> chomp($Version);
>> $Version=~s/\AVersion:\s*//g;
>
> This would be better:
>
> dpkg-query -W -f='${Version}' $Package
>
> --
> 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/CAKTje6G1YemXb+tNYEUi_vZu-HSpRXQc98o=e5eX5=xt-p4...@mail.gmail.com
>
--
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/canbhluivgsonazfs-97pfrjkgnz-bqrw5x7kcrcoyogrpbx...@mail.gmail.com
Re: abi-compliance-checker and abi-dumper to track API/ABI
On 9 July 2013 10:18, Paul Wise wrote: > On Wed, Jul 3, 2013 at 4:24 PM, Andrey Ponomarenko wrote: > >> So it is no need to create any input XML descriptors and compile header >> files of a library anymore. >> >> However, this approach has some drawbacks. Perhaps the main drawback is the >> inability to perform some compatibility checks. For example, there is no >> possibility to check for changes in the values of the constants (defines as >> well as const global data), since their values are inlined at compile time, >> and not presented in the debug information of the binary ELF-object. In >> general, there can be checked about 98% of all compatibility rules. > > Is there any way to automatically generate the XML stuff from dpkg/apt > data so that these extra compatibility issues can be checked > automatically? One of the "library descriptors" that a-c-c supports is a list of includes/directories. Thus for $most packages just installing -dev package and pointing a-c-c at the list of: dpkg -L $pkg-dev | grep include lib should do the right thing (more or less) But I haven't gotten far enough to have this working automagically as dep8 tests. Regards, Dmitrijs. -- 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/CANBHLUgMDuoRWZfPVX+KMHLsK7bf+5wwuvGycNY=x44caia...@mail.gmail.com
Re: Pepper Flash for Chromium
On 7 Jul 2013 12:05, "Stéphane Glondu" wrote:
>
> Le 07/07/2013 08:39, Scott Leggett a écrit :
> >> you may not (and you may not permit anyone else to) copy, modify,
> >> create a derivative work of, reverse engineer, decompile or
> >> otherwise attempt to extract the source code of the Software or any
> >> part thereof, unless this is expressly permitted or required by
> >> law, or unless you have been specifically told that you may do so
> >> by Google, in writing.
> >
> > Specifically, downloading the chrome .deb from google and doing
> > anything other than simply installing it (like extracting the flash
> > plugin and copying it elsewhere) would be creating a derivative work
> > and is thus forbidden.
> >
> > Additionally, the EULA says this ('Services' here includes the
> > software itself):
> >
> >> Unless you have been specifically permitted to do so in a separate
> >> agreement with Google, you agree that you will not reproduce,
> >> duplicate, copy, sell, trade or resell the Services for any
> >> purpose.
>
> Has anyone considered asking Google to distribute separately the flash
> plugin?
>
I believe similar was requested before for the
adobe-acrobat-code-google-code pdf plugin that comes with chrome. Can't
find reference on my phone, but google engineers responded saying their
legal department didn't provide a response about mixing chromium with
chrome's binary plugins. (Was it on the bug tracker?!). Apart from
~="google doesn't distribute such combination at the moment". Having google
offer/ship binary plugins with/for nightly chromium would be a big win.
Regars,
Dmitrijs.
Re: Berkeley DB 6.0 license change to AGPLv3
On 2 July 2013 17:58, Nick Andrik wrote: > 2013/7/2 Russ Allbery : >> I don't believe the AGPL was ever intended to be used for libraries. >> Quite a bit of the license is very difficult to interpret as applied to a >> library. (For example, does that mean that every application using the >> library has to provide a URL to download the source of the *library*? Is >> the user interacting with the library directly over the network?) >> >> I think this one is all on Oracle. They're using a license that was never >> intended for a basic infrastructure library, quite possibly in an attempt >> to make it obnoxious and excessively onerous to use the open source >> version, or to create a situation where nearly all users of their library >> are violating some technical term of the license (or at least are close >> enough that a lawsuit wouldn't be immediately thrown out) and therefore >> can be shaken down for cash if Oracle feels like it. > > Since AGPLv3 is really similar to GPLv3 but mostly oriented for > webapplications, would it make sense to contact Oracle with the > concerns raised in this thread and ask for clarification and possible > consideration to change to license to GPLv3 instead? > > There could be some possibility that the choice of AGPL over GPL was > not well considered by their part with all the issues that raises. > > On the other hand, with Oracle one can never be sure, but at least > contacting them will make the problem more widely apparent and their > ittentions more clear. > Looking at db5.3 copyright file, I see copyright holders: INRIA, France Telecom The President and Fellows of Harvard University The Regents of the University of California Oracle So is the whole code base re-licensed? or only the changes that Orcale is making here-after? Regards, Dmitrijs. -- 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/canbhluiok18hp34xbvp+t9gq+p9n3yrzgee7o1+icruv4pk...@mail.gmail.com
missing-build-dependency dpkg-dev (>= 1.16.1~) Re: vtk_5.8.0-13.1_amd64.changes REJECTED
Dear all, On 30 June 2013 23:21, Debian FTP Masters wrote: > > > vtk source: lintian output: 'missing-build-dependency dpkg-dev (>= 1.16.1~)', > automatically rejected package. > vtk source: If you have a good reason, you may override this lintian tag. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > dpkg-dev is at 1.16.10 in stable, so above check is only relevant for security uploads for old-stable & squeeze[-backports[-sloppy]]. Can above check please be disabled for uploads to stable-p-u / unstable / experimental? Also I got above reject 5 days later, since I uploaded into delayed queue. This is not nice, since I could have reuploaded 5 days ago Regards, Dmitrijs. -- 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/canbhlujjzk_sjr4xe3gz_faj02hkfb78onqkitefdfq5vil...@mail.gmail.com
Re: Reporting 1.2K crashes
On 25 June 2013 19:21, Alexandre Rebert wrote: > Hi, > > On Tue, Jun 25, 2013 at 2:03 PM, Dmitrijs Ledkovs > wrote: >> From Ubuntu point of view, we'd also be interested in a similar >> analysis. Unlike Debian we provide automatically generated packages >> with debug symbols. >> Similar to debian, we would most interested for development series to >> be tested, currently saucy. At least main (~3000 packages) or universe >> as well (total size than ~ same as Debian) > > It's great to see some interest from other distributions. We would > love to run Mayhem on Ubuntu binaries as well. I'm wondering how > different Debian and Ubuntu packages are though (forgive my > ignorance). > > There are some issues (pointed out by Marc Harber [1]) about identical > bugs being reported bugs by multiple distributions that we need to > consider as well. Feel free to contact me directly so that we can talk > about this in more details. > There is a set of packages that are unique to debian and unique to ubuntu. Toolchain is slightly different, w.r.t. to security and hardening options (but that difference is becoming smaller) There are packagesets that are ahead or behind debian. Overall scanning ubuntu main should be small amount of packages and capture majority of above distro differentiating divergences. Regards, Dmitrijs. -- 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/CANBHLUjA_c_xYrahzhHwdJr=nfkejxsleogptcpjdamkj7h...@mail.gmail.com
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 21 June 2013 15:05, Chow Loong Jin wrote:
> On Fri, Jun 21, 2013 at 11:52:40AM +0100, Dmitrijs Ledkovs wrote:
>> On 21 June 2013 11:24, Chow Loong Jin wrote:
>> > On Fri, Jun 21, 2013 at 10:34:54AM +0100, Dmitrijs Ledkovs wrote:
>> >> On 20 June 2013 18:26, Russ Allbery wrote:
>> >> > Dmitrijs Ledkovs writes:
>> >> >
>> >> >> Thus in a bug report 712763 [4], included below, I instead propose
>> >> >> instead shipping slightly larger block of code in the upstart package
>> >> >> which is sourced by /lib/lsb/init-functions from init-functions.d
>> >> >> directory. Something along the lines of:
>> >> >
>> >> >> if init_is_upstart; then
>> >> >> upstart_job=/etc/init/$(basename ${0:-}).conf
>> >> >> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>> >> >> case "${1:-}" in
>> >> >> start|restart|force-reload)
>> >> >> exit 1
>> >> >> ;;
>> >> >> stop)
>> >> >> exit 0
>> >> >> ;;
>> >> >> esac
>> >> >> fi
>> >> >> fi
>> >> >
>> >> > Libraries, even shell libraries, should generally not call exit. It's
>> >> > very surprising behavior. The overall program flow should remain under
>> >> > the control of the main program.
>> >>
>> >> In general I agree, and I think this was one of points of including
>> >> helper-free check in the policy & including a helper in the
>> >> init-functions, which one can call as appropriate.
>> >>
>> >> Another fundamental question is: should direct invocation of
>> >> /etc/init.d/ be outright deprecated? and thus even stronger
>> >> safe-guards put in place (e.g. something at the scale of chmod -x
>> >> /etc/init.d/*)
>> >> or shall we allow people shooting themselves in the foot and allow
>> >> init.d scripts not to have upstart-safeguard if a maintainer does not
>> >> wish to include one? E.g. update-rc.d / incoke-rc.d
>> >> / service works correctly with sysv-init & upstart, but if one invokes
>> >> init.d scripts directly and they happen to be managed by upstart,
>> >> leave those users on their own? At the moment policy is a must: "SysV
>> >> init scripts for which an equivalent upstart job is available __must__
>> >> query the output of the..."
>> >
>> > I think printing out a noisy warning and allowing people to shoot
>> > themselves in
>> > the foot would be good. I reckon a significant number of legacy
>> > (custom/proprietary) scripts currently attempt to poke /etc/init.d/foo
>> > directly.
>> > Perhaps allowing the sysadmin to choose the desired behaviour via debconf
>> > would
>> > do..
>> >
>>
>> I'm not sure I understand you.
>
> I'm saying that some people may have custom scripts, cronjobs or whatnot
> calling
> /etc/init.d/ directly, and may not be very pleased about /etc/init.d/ scripts
> losing their +x permissions and breaking these scripts.
>
I see, ok.
> Hence, rather than completely disabling the init.d scripts, I'd rather that
> invoking an init.d script directly prints out a big fat warning on stderr that
> lets the admin know, while still doing something sane (starting the service
> anyway). Kinda like how Ubuntu's sysvinit.d scripts currently operate right
> now.
>
Unfortunately doing that is not possible, whilst also simultaneously
supporting sysvinit and upstart in the archive. Because as per policy
at the moment we must preserve fully working sysv init scripts.
>> > One point of concern that just occurred to me is that on an Upstart-booted,
>> > running system that was just upgraded to include this init-functions
>> > snippet,
>> > Upstart wouldn't know about init.d-started services, and wouldn't be able
>> > to
>> > stop them. Additionally, due to the `exit 0' that occurs if [ $1 = stop ],
>> > you
>> > wouldn't be able to stop the process using the traditional sysvinit script
>> > either. You'd end up needing to kill the service manually or trawl through
>> > the
>> > init script to figure out how to kill it properly.
>> >
>>
>> [...]
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 21 June 2013 11:24, Chow Loong Jin wrote:
> On Fri, Jun 21, 2013 at 10:34:54AM +0100, Dmitrijs Ledkovs wrote:
>> On 20 June 2013 18:26, Russ Allbery wrote:
>> > Dmitrijs Ledkovs writes:
>> >
>> >> Thus in a bug report 712763 [4], included below, I instead propose
>> >> instead shipping slightly larger block of code in the upstart package
>> >> which is sourced by /lib/lsb/init-functions from init-functions.d
>> >> directory. Something along the lines of:
>> >
>> >> if init_is_upstart; then
>> >> upstart_job=/etc/init/$(basename ${0:-}).conf
>> >> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>> >> case "${1:-}" in
>> >> start|restart|force-reload)
>> >> exit 1
>> >> ;;
>> >> stop)
>> >> exit 0
>> >> ;;
>> >> esac
>> >> fi
>> >> fi
>> >
>> > Libraries, even shell libraries, should generally not call exit. It's
>> > very surprising behavior. The overall program flow should remain under
>> > the control of the main program.
>>
>> In general I agree, and I think this was one of points of including
>> helper-free check in the policy & including a helper in the
>> init-functions, which one can call as appropriate.
>>
>> Another fundamental question is: should direct invocation of
>> /etc/init.d/ be outright deprecated? and thus even stronger
>> safe-guards put in place (e.g. something at the scale of chmod -x
>> /etc/init.d/*)
>> or shall we allow people shooting themselves in the foot and allow
>> init.d scripts not to have upstart-safeguard if a maintainer does not
>> wish to include one? E.g. update-rc.d / incoke-rc.d
>> / service works correctly with sysv-init & upstart, but if one invokes
>> init.d scripts directly and they happen to be managed by upstart,
>> leave those users on their own? At the moment policy is a must: "SysV
>> init scripts for which an equivalent upstart job is available __must__
>> query the output of the..."
>
> I think printing out a noisy warning and allowing people to shoot themselves
> in
> the foot would be good. I reckon a significant number of legacy
> (custom/proprietary) scripts currently attempt to poke /etc/init.d/foo
> directly.
> Perhaps allowing the sysadmin to choose the desired behaviour via debconf
> would
> do..
>
I'm not sure I understand you.
> One point of concern that just occurred to me is that on an Upstart-booted,
> running system that was just upgraded to include this init-functions snippet,
> Upstart wouldn't know about init.d-started services, and wouldn't be able to
> stop them. Additionally, due to the `exit 0' that occurs if [ $1 = stop ], you
> wouldn't be able to stop the process using the traditional sysvinit script
> either. You'd end up needing to kill the service manually or trawl through the
> init script to figure out how to kill it properly.
>
Only if both are present:
/etc/init/myservice.conf
/etc/init.d/myservice
The /etc/init.d/myservice, should exit/do nothing if and only if PID1
is upstart, since upstart is managing myservice via a native upstart
job.
If there is no equivalent upstart job (as I think is the case in your
example above), the init.d script must continue to function correctly
as per debian policy (including start/stop/restart).
Thus the init-functions.d snippet above does a check of if upstart is
PID1 and the '/etc/init/myservice.conf' exists, and only then adds the
appropriate exit 1/0. And in the case of upstart-booted system it will
indeed be managing "myservice".
Are you talking about a case where a package is upgraded from
sysv-init.d only to an upstart&sysv-init.d capable version? As per
current recommendations, such services are stopped in preinst (cleanly
via init.d script) & started in postinst (potentially by upstart). [1]
Maybe I didn't understand the scenario you described. Can you please elaborate?
[1] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
Regards,
Dmitrijs.
--
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/canbhlugvkssirjxadahg+bgycgtz1berqstyeyqkpyiub+m...@mail.gmail.com
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 20 June 2013 18:26, Russ Allbery wrote:
> Dmitrijs Ledkovs writes:
>
>> Thus in a bug report 712763 [4], included below, I instead propose
>> instead shipping slightly larger block of code in the upstart package
>> which is sourced by /lib/lsb/init-functions from init-functions.d
>> directory. Something along the lines of:
>
>> if init_is_upstart; then
>> upstart_job=/etc/init/$(basename ${0:-}).conf
>> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>> case "${1:-}" in
>> start|restart|force-reload)
>> exit 1
>> ;;
>> stop)
>> exit 0
>> ;;
>> esac
>> fi
>> fi
>
> Libraries, even shell libraries, should generally not call exit. It's
> very surprising behavior. The overall program flow should remain under
> the control of the main program.
In general I agree, and I think this was one of points of including
helper-free check in the policy & including a helper in the
init-functions, which one can call as appropriate.
Another fundamental question is: should direct invocation of
/etc/init.d/ be outright deprecated? and thus even stronger
safe-guards put in place (e.g. something at the scale of chmod -x
/etc/init.d/*)
or shall we allow people shooting themselves in the foot and allow
init.d scripts not to have upstart-safeguard if a maintainer does not
wish to include one? E.g. update-rc.d / incoke-rc.d
/ service works correctly with sysv-init & upstart, but if one invokes
init.d scripts directly and they happen to be managed by upstart,
leave those users on their own? At the moment policy is a must: "SysV
init scripts for which an equivalent upstart job is available __must__
query the output of the..."
Regards,
Dmitrijs.
--
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/CANBHLUgzgF+YvnsZXxv4hYvEx-jm4M_p=kTZv=yaqjuuq18...@mail.gmail.com
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 20 June 2013 16:32, Tollef Fog Heen wrote:
> ]] Dmitrijs Ledkovs
>
>> if init_is_upstart; then
>> upstart_job=/etc/init/$(basename ${0:-}).conf
>> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>
> Why the -L ?
>
! -L = not a symlink, upstart jobs cannot be symlinks. Above is a
very basic sanity check.
I haven't checked, but if above is implemented, the logic of checking
"equivalent upstart job is available" should match the one already
implemented in the update-rc.d / incoke-rc.d / service commands.
So consider above more of a working proof of concept, rather than
final code proposal.
Regards,
Dmitrijs.
--
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/CANBHLUgc0mNkGRej0w+ECmwrh-RfDw+eV=x=jrhdddox2bu...@mail.gmail.com
On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
Debian policy was updated some time ago [1] to include provisions for
supporting alternative init systems with a section specific to
supporting upstart init system. [2] In essence update-rc.d / incoke-rc.d
/ service commands must be used, as they properly understand and can act
upon init.d scripts or upstart job files as appropriate, regardless of
which init system is installed or currently in use at runtime.
But since both init.d scripts and upstart job files will be present
simultaneously, one should not invoke init.d script directly, especially
when a given service is instead managed by a native upstart job.
The section §9.11.1, thus requires for packages that ship both init.d
scripts and upstart jobs, to have conditional guards in the init.d
scripts to check if upstart is currently pid 1 and thus insure that
init.d script does nothing (exit with 1, or 0 for stop).
lsb-base 4.1+Debian3 and up provide a convenience function
init_is_upstart as part of the /lib/lsb/init-functions "library", thus
currently recommended way to implement upstart compatible init.d script
is by including a call to init_is_upstart [3]. More or less including a
block like this:
if init_is_upstart; then
case "$1" in
stop)
exit 0
;;
*)
exit 1
;;
esac
fi
Thus in a bug report 712763 [4], included below, I instead propose
instead shipping slightly larger block of code in the upstart package
which is sourced by /lib/lsb/init-functions from init-functions.d
directory. Something along the lines of:
if init_is_upstart; then
upstart_job=/etc/init/$(basename ${0:-}).conf
if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
case "${1:-}" in
start|restart|force-reload)
exit 1
;;
stop)
exit 0
;;
esac
fi
fi
Thus there is no impact on packages that have both sysv init and upstart
jobs, on system that are using sysv init. Since above snippet is not
present / not sourced by init-functions. But once upstart is installed
and running, those packages correctly integrate with upstart and all
init.d scripts that source init-functions execute above snippet.
I here would like to consult with Policy maintainers and the wider
Debian community if this is an appropriate and welcomed way to implement
Debian Policy §9.11.1, as shortly after starting to propose upstart
integration patches I was met with strong resentment with respect to
modifying existing init.d scripts.
I understand that there are packages that at the moment do not use
/lib/lsb/init-functions, and those packages should use the checks as
outlined by Debian Policy §9.11.1 [2] if they simultaneously ship
equivalent upstart job, or start sourcing /lib/lsb/init-functions.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791
[2] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-upstart
[3] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712763
Regards,
Dmitrijs.
Original Message
Subject: upstart: implementing Debian Policy §9.11.1
Date: Wed, 19 Jun 2013 10:58:38 +0100
From: Dmitrijs Ledkovs
To: Debian Bug Tracking System
Package: upstart
Version: 1.6.1-1
Severity: normal
Reading Debian Policy §9.11.1 [1] and the recommendations on
implementing it [2] results in a few undesirable properties:
* one needs to modify sysv init.d scripts
* the code in the init.d scripts does nothing when upstart is not
installer or not running
* the init.d scripts becomes less portable
But considering the fact that If upstart is not installed, initctl
will not be present in the $PATH and thus init_is_upstart will always
return 1, as well as the init-functions providing hooks directory
/lib/lsb/init-functions.d the debian policy can be implemented in an
alternative way:
* upstart package ships /lib/lsb/init-functions.d/70-upstart with
contents similar to the attached file
If upstart package is installed, all init.d scripts will continue to
work correctly or will abort with the appropriate status if upstart is
managing that particular job.
If upstart is currently PID 1, yet upstart package was removed, the
system is in flux anyway as upstart's binaries are gone and it will be
hard to do a clean shutdown.
No changes are required to init.d scripts and packages correctly
integrate with upstart, once upstart is installed. Unless init.d
script does not source /lib/lsb/init-functions, in that case one
either migrates to do so, or executes the check as per policy.
[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit
[2] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
Regards,
Dmitrijs.
signature.asc
Description: OpenPGP digital signature
On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
Debian policy was updated some time ago [1] to include provisions for
supporting alternative init systems with a section specific to
supporting upstart init system. [2] In essence update-rc.d / incoke-rc.d
/ service commands must be used, as they properly understand and can act
upon init.d scripts or upstart job files as appropriate, regardless of
which init system is installed or currently in use at runtime.
But since both init.d scripts and upstart job files will be present
simultaneously, one should not invoke init.d script directly, especially
when a given service is instead managed by a native upstart job.
The section §9.11.1, thus requires for packages that ship both init.d
scripts and upstart jobs, to have conditional guards in the init.d
scripts to check if upstart is currently pid 1 and thus insure that
init.d script does nothing (exit with 1, or 0 for stop).
lsb-base 4.1+Debian3 and up provide a convenience function
init_is_upstart as part of the /lib/lsb/init-functions "library", thus
currently recommended way to implement upstart compatible init.d script
is by including a call to init_is_upstart [3]. More or less including a
block like this:
if init_is_upstart; then
case "$1" in
stop)
exit 0
;;
*)
exit 1
;;
esac
fi
Thus in a bug report 712763 [4], included below, I instead propose
instead shipping slightly larger block of code in the upstart package
which is sourced by /lib/lsb/init-functions from init-functions.d
directory. Something along the lines of:
if init_is_upstart; then
upstart_job=/etc/init/$(basename ${0:-}).conf
if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
case "${1:-}" in
start|restart|force-reload)
exit 1
;;
stop)
exit 0
;;
esac
fi
fi
Thus there is no impact on packages that have both sysv init and upstart
jobs, on system that are using sysv init. Since above snippet is not
present / not sourced by init-functions. But once upstart is installed
and running, those packages correctly integrate with upstart and all
init.d scripts that source init-functions execute above snippet.
I here would like to consult with Policy maintainers and the wider
Debian community if this is an appropriate and welcomed way to implement
Debian Policy §9.11.1, as shortly after starting to propose upstart
integration patches I was met with strong resentment with respect to
modifying existing init.d scripts.
I understand that there are packages that at the moment do not use
/lib/lsb/init-functions, and those packages should use the checks as
outlined by Debian Policy §9.11.1 [2] if they simultaneously ship
equivalent upstart job, or start sourcing /lib/lsb/init-functions.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791
[2] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-upstart
[3] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712763
Regards,
Dmitrijs.
Original Message
Subject: upstart: implementing Debian Policy §9.11.1
Date: Wed, 19 Jun 2013 10:58:38 +0100
From: Dmitrijs Ledkovs
To: Debian Bug Tracking System
Package: upstart
Version: 1.6.1-1
Severity: normal
Reading Debian Policy §9.11.1 [1] and the recommendations on
implementing it [2] results in a few undesirable properties:
* one needs to modify sysv init.d scripts
* the code in the init.d scripts does nothing when upstart is not
installer or not running
* the init.d scripts becomes less portable
But considering the fact that If upstart is not installed, initctl
will not be present in the $PATH and thus init_is_upstart will always
return 1, as well as the init-functions providing hooks directory
/lib/lsb/init-functions.d the debian policy can be implemented in an
alternative way:
* upstart package ships /lib/lsb/init-functions.d/70-upstart with
contents similar to the attached file
If upstart package is installed, all init.d scripts will continue to
work correctly or will abort with the appropriate status if upstart is
managing that particular job.
If upstart is currently PID 1, yet upstart package was removed, the
system is in flux anyway as upstart's binaries are gone and it will be
hard to do a clean shutdown.
No changes are required to init.d scripts and packages correctly
integrate with upstart, once upstart is installed. Unless init.d
script does not source /lib/lsb/init-functions, in that case one
either migrates to do so, or executes the check as per policy.
[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit
[2] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
Regards,
Dmitrijs.
upstart-lsb.sh
Description: application/shellscript
signature.asc
Description: OpenPGP digital signature
Re: Default desktop for jessie Was: Re: Debian/Wheezy general rant ...
On 5 June 2013 23:42, Jakub Wilk wrote: > * Russ Allbery , 2013-06-05, 15:02: > >> udev sucks! Debian should hire a developer to replace all uses of CDBS >> with dh! Perl should be replaced with Python in essential! All packages >> need to switch to 3.0 (quilt)! Native packages should be banned! No one >> should ever be allowed to NMU anything ever if the maintainer says no! >> >> Did I miss anything? > > > The Freeze Was Too Damn Long! > The Unfreeze is getting long now as well. Are we freezing at Debconf? =) Regards, Dmitrijs. -- 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/canbhluhuj9ako2vdaz_oje-3wamw29ajt4hdltayjoqkz_u...@mail.gmail.com
Re: Default desktop for jessie Was: Re: Debian/Wheezy general rant ...
On 5 June 2013 23:02, Russ Allbery wrote: > Svante Signell writes: > >> Not everybody agrees to that, there is a split opinion about this. >> Please lift this discussion a little higher: Which would be the default >> desktop for jessie? > > Because we weren't having enough fun with systemd vs. upstart and the MTA > discussion. :) Maybe if we can start all the flamewars at once, we'll > get destructive interference! > > udev sucks! Debian should hire a developer to replace all uses of CDBS > with dh! Perl should be replaced with Python in essential! All packages > need to switch to 3.0 (quilt)! Native packages should be banned! No one > should ever be allowed to NMU anything ever if the maintainer says no! > > Did I miss anything? > Both Perl and Python should be replaced by C. Abolish concept of maintainership, simply all DDs have upload rights to all packages collectively. All packages must run dh_autoreconf, no more usage of upstream generated 'configure/config.*/Makefile.in'. Allow source uploads only. And I want hard candy merchandise with debian swirls. Regards, Dmitrijs. ps. every joke has at least a portion of a joke, the rest might actually be true. -- 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/canbhlugozlznr6fuehc1m_gf6vxysnbbnoeauag_odj3qzn...@mail.gmail.com
Re: systemd .service file conversion
On 24 May 2013 23:16, Игорь Пашев wrote: > 2013/5/23 Helmut Grohne : >> * stdout/stderr to syslog redirection >>This is possibly implementable, but needs more than a line of shell. > > In Solaris SMF each service has its own log file with SMF messages > *and* all stdout/stderr > > pashev@bok:~$ find /var/log/svc/ Ditto with upstart under /var/log/upstart/ Regards, Dmitrijs. -- 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/canbhlujicd-jtbpseaylxft2kcuwc6xqo6m_d61xohdcksx...@mail.gmail.com
Re: using upstart in Debian [was, Re: Debian systemd survey]
On 23 May 2013 10:37, Ole Laursen wrote: > Steve Langasek debian.org> writes: >> Sorry you ran into trouble with upstart. > > Not a DD, just a happy Debian user, hope you'll excuse me, but on the topic > of Upstart, I have some technical comments on why, surprisingly, I think it > may not be mature enough yet. > > A couple of years ago I was doing emergency consultancy work for a company > using Red Hat and upstart. The dev dude there was really on top of new tech > and had made Upstart scripts for starting his Python web apps (which I > thought was a great idea, this was back when Upstart looked like THE > alternative to sysvinit). > > However, when debugging it, we had some weird lock-ups from Upstart, > basically you'd ask Upstart for the status of the job and it would lock up > really hard (IIRC Ctrl-C wouldn't work). After much swearing, it wasn’t > immediately obvious why Upstart would be the culprit, I found this (at the > time) old bug: > > https://bugs.launchpad.net/upstart/+bug/406397 > > Upstart couldn't track the forks going on inside a started process reliably. > As one commenter notes: “I’m wondering why this bug has a importance of > “low”, as it renders using upstart for many daemons (including apache, > postfix and others) as impossible.” This bug doesn't appear to be fixed yet. > > So unfortunately, I don't think Upstart is ready for handling a server boot > with native job files. I had a look at the apache2 packages for Ubuntu > raring, and there’s a sysvinit file, but no Upstart job. > > I'm telling you the whole story here to explain that this isn't just a minor > problem for packages shipped with the distribution, it's also a potentially > big problem for ISVs. > Yes, it's a real bug and as clearly stated in the bug report comments above it is due to using ptrace to count/track forks. The best way to run daemons under upstart is in foreground, then correct PID is tracked and the complete stdout/stderr is properly collected and stored in /var/log/upstart/$job.log (even early boot output). How to establish fork counts & the consequences of getting it wrong are well documented in the upstart cookbook (see below). As far as I understand (correct me if I am wrong), systemd instead of counting/tracking forks uses cgroups to keep track of the started processes. > > Also on technical merits although more philosophically, with Upstart you're > expressing yourself in an event-based DSL rather than writing configuration > files. It's pretty generic. But unfortunately, that means it's also not > entirely straightforward, and, I believe, easier to get wrong. Scott had > some explaining blog posts before he left Canonical that I still find > confusing (from the POV of just getting a job file done): > > http://netsplit.com/2010/12/20/events-are-like-methods/ > http://netsplit.com/2010/12/03/event-matching-in-upstart/ > Since those blog posts were published a coprehensive documentation book was written and is constantly kept up to date. http://upstart.ubuntu.com/cookbook/ It actually guides & explains upstart concepts in a coherent and straight-forward manner with a very large section of examples on how to achieve various goals & tasks. > Lennart Poettering wrote in his initial blog posts on systemd about why he > thought this fundamental model of Upstart wasn't entirely spot on, and while > I thought this might have been NIH BS at the time I've later come to the > conclusion that he's probably right. Taking as much confusing logic as > possible out of the job files does seem like a win. > Blog posts are interesting to read, but at times I'd like to look up reference manuals which are more than bear minimal man pages. Whilst systemd ships manpages, the website has either incorrectly formatted wiki-pages and/or eventual links to lennart's blog posts. Where is systemd's documentation? Regards, Dmitrijs. -- 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/canbhluhbgvwkp8tsgicgmq2zermb61idbjgwd6261euohqn...@mail.gmail.com
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On 22 May 2013 03:32, Paul Tagliamonte wrote: > On Wed, May 22, 2013 at 01:16:29AM +0100, Dmitrijs Ledkovs wrote: >> I have signed Canonical's and Python Software Foundation's contributor >> agreements. >> But I have no intention to assign copyright to FSF at the moment, >> given it's past well documented bad practices at doing things for the >> sake of it, instead of benefit of the wider free software community. > > The FSF's end goal is Free Software[1], whereas Canonical's is cold, > hard, cash. Nothing wrong with that, but you have to admit that they > don't really care about ideology or ethics, but providing a distro > people will use (and buy services / devices / support for). > > I don't see how you can see the FSF as worse than Canonical in terms of > respecting your code and end user freedom. > > Relatedly, the PSF is great. > > I responded with my Ubuntu address to drive this point home clearly - I > support what Canonical and Ubuntu are doing; so much, in fact, I've > spent over 5 years of my life helping make that happen. > > That being said, I don't grok your argument. > > [1]: OK. Not Free Software as such, but Free Software as a means to an > end -- namely, free users. > My stance is reverse. IMHO Canonical has done more to promote free software among people, companies, businesses, non-for-profits, governments and NGOs than any other free software company or organisation. It can be seen from the amount of pre-installed machines shipped with Ubuntu from all Tier-1 hardware vendors and many other smaller hardware vendors. Oracle is a company with a "cold, hard, cash" goal. Canonical whilst striving to be self-sustaining, evidently spends most of its profits/money on new Research&Development be it Linaro, Unity, Juju or the SaaS offerings like U1 & Landscape suite of services. Some produce more open source software than others, and all of these will be ranked differently by each person differently, am I still yet to be screwed by Canonical's projects. Please correct me if I am wrong, but none of Canonical CA covered projects yet to (a) change their license or (b) go proprietary. Since Canonical's CA inception, it has been modified to grant less rights to canonical and counter keep more to the authors, thus adjusting the balance based on community feedback. And more and more software is released as open source. Contrast with what Oracle has been doing in the past years. FSF on the other hand: * GFDL fiasco - because clearly the world cannot live another day without RMS essay, and oh my one shouldn't generate GCC documentation from code comments * SSL licensing - the combination of gnutls going v3 & v3 still being incompatible with OpenSSL and/or v2 * Clang/LLVM - moving gcc to v3 & thus making Apple contribute/develop LLVM instead of continuing to use gcc (/me is on gcc camp, thus it's fsf's negative point. Others might cheer for this move, which gave the birth to Clang, eventually) * GNU Project mismanagement/micromanagement - (GnuTLS & sed & others) https://lwn.net/Articles/529522/ https://lwn.net/Articles/530460/ These are just a few grudges I have against FSF. I like FSF EU division though. As you say, "Relatedly, the PSF is great". So CA alone, is really not a cause or reason for one's actions. In general, I like CAs as it assigns liability to a 3rd party that can afford lawyers. Regards, Dmitrijs. -- 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/canbhluiawahrejt6mpr_4c2gjdixpbjw+cjiizthkdyhthu...@mail.gmail.com
Re: Upstart & kFreeBSD port for Debian
On 22 May 2013 03:09, Guillem Jover wrote: > Hi! > > On Wed, 2013-05-22 at 01:47:42 +0100, Dmitrijs Ledkovs wrote: >> On 22 May 2013 01:16, Michael Biebl wrote: >> > Am 22.05.2013 02:00, schrieb Dmitrijs Ledkovs: >> >> On 21 May 2013 21:53, Lucas Nussbaum wrote: >> >>> On 20/05/13 at 18:19 +0200, Michael Stapelberg wrote: >> >>> - Neither systemd nor upstart are likely to be ported to kfreebsd soon, >> >>> as they both rely on many Linux-specific features and interfaces. > >> >> Well, Colin Watson, Matthias Klose, Steve Langasek, James Hunt and I >> >> have discussed the state of the kfreebsd possibility a few times over >> >> the past year or so. > > I started porting libnih and upstart to GNU/kFreeBSD some months ago, > just for fun, whenever I had nothing else to do. But then I'm not > interested in assigning my copyright to a for-profit company that is > not employing me (and no, this is not a job request); so I didn't > post anything yet, because I don't use upstart, didn't want to promise > anything (still don't), and it would present as an _interesting_ > situation for the Debian upstart maintainers (either reject the > patches or carry them forever as a small fork...). > For libnih: fork it, push it, merge propose into https://github.com/keybuk/libnih As Steve already mentioned, Scott is the upstream for libnih. >> >> It boiled down to: if we have waitid & inotify it should be possible >> >> to have a reasonable stab at doing a kfreebsd port for the system-wide >> >> upstart init (with libnih and mountall). For session init we currently >> >> do use prctl to set subreaper, but one can still have session upstart >> >> init without that syscall. >> >> >> >> Was there something else needed? Or can anyone else spot other "big >> >> incompatible" chunks of code? >> > >> > https://lists.debian.org/debian-bsd/2009/07/msg00122.html > > I think I've posted this multiple times, whenever those items lists > are posted: > > <http://www.hadrons.org/~guillem/debian/ports/porting> > And somehow I have missed it up until now. Very nice guide. I like it a lot. Concise pointers =) Regards, Dmitrijs. -- 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/CANBHLUhwJQKsshXv+_5UkrH=8kyxbdr3vmpr1otl0hu-eij...@mail.gmail.com
Re: Upstart & kFreeBSD port for Debian
On 22 May 2013 01:16, Michael Biebl wrote: > Am 22.05.2013 02:00, schrieb Dmitrijs Ledkovs: >> On 21 May 2013 21:53, Lucas Nussbaum wrote: >>> Hi, >>> >>> On 20/05/13 at 18:19 +0200, Michael Stapelberg wrote: >>>> Hello, >>>> >>> - Neither systemd nor upstart are likely to be ported to kfreebsd soon, >>> as they both rely on many Linux-specific features and interfaces. >>> >> >> Well, Colin Watson, Matthias Klose, Steve Langasek, James Hunt and I >> have discussed the state of the kfreebsd possibility a few times over >> the past year or so. >> >> It boiled down to: if we have waitid & inotify it should be possible >> to have a reasonable stab at doing a kfreebsd port for the system-wide >> upstart init (with libnih and mountall). For session init we currently >> do use prctl to set subreaper, but one can still have session upstart >> init without that syscall. >> >> Was there something else needed? Or can anyone else spot other "big >> incompatible" chunks of code? > > https://lists.debian.org/debian-bsd/2009/07/msg00122.html > Going down the list: - inotify - internetz tell me kevents/kqueue is the way to go - waitid() - issue closed in FreeBSD in February 2013, is it usable? - epoll, eventfd, signalfd, timerfd - again internetz tell me kevents/kqueue can do all of this, better yet there is libevent that can do those portably across linux and bsd - ptrace - FreeBSD does have ptrace - differences in api/capabilities? I didn't know about either of these =) looks awesome. Need to look into how upstart is using those, to see how necessary those are and how to implement them on FreeBSD. - netlink proc connector - netlink udev interface > Nothing really happened since 2009, so I wouldn't hold my breath > regarding a *BSD port. > Apart from FreeBSD folks implementing just recently waitid()?! =))) That's huge. Regards, Dmitrijs. -- 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/CANBHLUj-bgXPfJ=uneDR4Nk=5jerSZOHzptvJ=hfcub731s...@mail.gmail.com
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On 13 May 2013 19:14, Russ Allbery wrote: > Philip Hands writes: > >> No matter what the technical merits, the inevitable flame war regarding >> copyright assignment seems very likely to render upstart a non-starter >> as an essential element of Debian. > > Debian already uses many packages as part of its essential set that > require copyright assignments. coreutils springs immediately to mind. I > realize some people see a distinction between assigning copyright to the > FSF and assigning copyright to Canonical, but I think the distinction is > relatively fine, and certainly not strong enough alone to make it a > non-starter, at least IMO. > I have signed Canonical's and Python Software Foundation's contributor agreements. But I have no intention to assign copyright to FSF at the moment, given it's past well documented bad practices at doing things for the sake of it, instead of benefit of the wider free software community. I'm sure there are people who hold a different opinion. Luckily Debian source package formats handle patches very well and all projects covered by above agreements are sufficiently open sourced for Debian main as per Debian's Social contract & DFSG. If one day I write a patch against an FSF project, my opinion might change depending on the value of the patch. But I am yet to write such a patch, FSF projects are quite good. But I don't see it being productive to measure "hypothetical unwritten patches" and automatically attribute those to copyright agreements. Regards, Dmitrijs. -- 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/CANBHLUjTVO0vjzkH0gh-oX=5_egcoyxfy-2j3c4c_sb2dj-...@mail.gmail.com
Upstart & kFreeBSD port for Debian
On 21 May 2013 21:53, Lucas Nussbaum wrote: > Hi, > > On 20/05/13 at 18:19 +0200, Michael Stapelberg wrote: >> Hello, >> > - Neither systemd nor upstart are likely to be ported to kfreebsd soon, > as they both rely on many Linux-specific features and interfaces. > Well, Colin Watson, Matthias Klose, Steve Langasek, James Hunt and I have discussed the state of the kfreebsd possibility a few times over the past year or so. It boiled down to: if we have waitid & inotify it should be possible to have a reasonable stab at doing a kfreebsd port for the system-wide upstart init (with libnih and mountall). For session init we currently do use prctl to set subreaper, but one can still have session upstart init without that syscall. Was there something else needed? Or can anyone else spot other "big incompatible" chunks of code? As it happens, waitid has been recently implemented in the FreeBSD 9.1 kernel [1]. While inotify is not-essential, it's still very nice to have and it can be reasonably & sufficiently be implemented for upstart's needs using FreeBSD's kqueue/kevent. It was also roughly felt that code base can be kept reasonably tidy by using weak symbols to encapsulate bsd/linux specific parts of the code base, not dissimilar from how other large projects sometimes choose to handle such portability. [1] If I am correct to trust http://www.freebsd.org/cgi/query-pr.cgi?pr=170346&cat= Not sure if it is or when it will be available in debian's kfreebsd port Regards, Dmitrijs. Ubuntu, Debian and Upstart Developer. -- 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/CANBHLUgm++e4185+a1J=rpy4cpdivvhtkx7uowx0ds66znc...@mail.gmail.com
Re: Switching default dpkg-deb compressor to xz
On 8 May 2013 01:46, Raphael Hertzog wrote: > Hi, > > On Tue, 07 May 2013, Guillem Jover wrote: >> As mentioned some months ago [0], I'm planning to switch dpkg-deb default >> compressor from gzip to xz, as there seemed to be consensus that was >> the way to go, and given the amount of already manually switched >> packages, or packaging helpers. :/ > [...] >> currently?). Otherwise I'll be doing the change with the dpkg 1.17.0 >> upload. > > I agree that we have such a consensus. > > There was a time where d-i was not ready, but nowadays udeb are compressed > with xz and busybox's xz is used in that context. > > Please go ahead with this change (unless some other valid concerns are > raised that is). > A while back I have raised a proposal on debian-devel, to include a facility to opt-out of compressing packages. As a DEB_BUILD_OPTIONS for example or via some other mechanism. Personally I have seen a great build-time reduction, whilst doing test builds (or "slow" builds on arm panda board / qemu), or whist doing a noopt & nostrip builds as all of these builds are usually local and one may just one to have the package simply sooner. I have spotted an independent implementation in an ubuntu's pkg-kde-tools (not sure if it's in debian one as well, at least it's not in the experimental upload) that defaults to xz, yet honours DEB_NO_XZ and DEB_NO_COMPRESSION environmental variables to disable such compression. Thinking more generically than last time around, would it be ok to propose ability to set / override dpkg-deb compression options via DEB_BUILD_OPTIONS? It would greatly simply rebuilding with no compression / alternative algos and settings. In particular it will ease to identify packages that do _not_ benefit from additional compression and/or perform better under non-default compression setting. I'm thinking of infamous openclipart, the one that has all images pre-compressed and a couple dozen of other similar packages. Should I open a bug and propose a change to debian-policy? Or do we need to bikeshed more about this? Last time around there was no significant arguments to not have such a facility. Regards, Dmitrijs. -- 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/CANBHLUjmD9Cf07Lm_WnioQnhJgAFUn_cOGqYGa6t-Ct5J=b...@mail.gmail.com
Re: jessie release goals
On 7 May 2013 05:38, Stephen Kitt wrote: > Hi Wookey, > > On Tue, 7 May 2013 03:04:50 +0100, Wookey wrote: >> (just a decision to leave arch-independent headers in /usr/include and >> move arch-dependent headers to /usr/include/triplet). > > Doesn't this limit us to cross-compiling only across Debian architectures? If > we go for a full /usr/include/triplet split (in the same way as for > libraries) we could support cross-compiling to anything with the same > structure - I'm thinking MinGW-w64 here of course, but I imagine it would > apply to other targets too, some of which are supported in Debian already > using the /usr/triplet/include directories. > I for one believe that MinGW-w64 should become partial architectures on debian (both 32 and 64bit variants... and arm?! =) ). Partial as it would use linux kernel + wine for runtime. Having mingw as an arch will greatly make it easier to provide an up-to-date archive of deb package that one would reasonably would want to cross-compile against. And with some luck and NSIS magic create .exe installers to redistributed compiled packages to Windows. I am patiently waiting for bug #606825 dpkg: Please add mingw to ostable and triplettable. To be fixed. As well there is interest in developing i686/x86_64-w64-mingw32 [1] port. And doko has also informally voiced support for such a triplet name at last debconf. [1] Yes, exactly these i686/x86_64-w64-mingw32 and not other proposed combinations. Regards, Dmitrijs. -- 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/CANBHLUi86xmNG=wwdqkx8b++vn2g5a3cwyzrvrywojoubz6...@mail.gmail.com
Re: Derivatives, MongoDB and freezes
On 22 April 2013 13:20, Jonathan Dowland wrote: > On Sat, Apr 20, 2013 at 07:22:05PM +0100, Dmitrijs Ledkovs wrote: >> I also posted on Debian Planet, how to find patches applied in Ubuntu >> via Debian PTS together with categories of useful fixes that are >> relevant to Jessie and may be already solved/patched in Ubuntu. [1] >> >> I perceived that blog post as a partial personal stab at me, by the >> way. Which I found unjust. > > Rogério Brito wrote his post on the 19th¹, and you wrote your post on > the 20th², so I fail to see how it could be a personal stab at you, or > at least in relation to your post. > My post was in response to his. I have been partially involved in mongodb work in Ubuntu. > I couldn't figure out how to comment on your post, because I wanted to > complain > about "Not uploading patches because they don't apply to Debian yet, is silly > as they will apply to Debian eventually", which I think is unfair. It seems > to me you want Debian people to make Ubuntu's life easier, whilst Rogério > wants Ubuntu people to make Debian's life easier. Not all Debian developers > have the time ot care about derivatives, and I'm the reverse is also true. > yes, I agree. Both stances are equal and opposite. I guess my post was more about promoting DDs to check PTS once in a while. And to promote and advertise my position =) Thank you for your feedback. I also got feedback that patches.u.c generates full-diff instead of debdiff which can be rather large. Regards, Dmitrijs. -- 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/CANBHLUjR_QeUGpo50D9Q6mPF=2xtwawhvv1ibjbkpa+3b9o...@mail.gmail.com
Re: Derivatives, MongoDB and freezes
On 20 April 2013 12:37, Daniel Pocock wrote: > > > I came across this on Planet Debian > > http://rb.doesntexist.org/blog//posts/lack_of_cooperation_from_ubuntu/ > > I'm guessing that Ubuntu may not have pushed the changes to sid because > of the freeze, that may well be the answer to Rogério's questions. > That is mostly correct. The other part is that packages & fixes not suitable for sid/wheezy were not applied & uploaded to experimental as aggressively as Ubuntu pace would want. I also posted on Debian Planet, how to find patches applied in Ubuntu via Debian PTS together with categories of useful fixes that are relevant to Jessie and may be already solved/patched in Ubuntu. [1] I perceived that blog post as a partial personal stab at me, by the way. Which I found unjust. > Nonetheless, with derivatives and Debian itself having different release > cycles, and wearing my upstream developer hat, I can't help wondering: > how can upstreams ensure that the freshest versions of their package > propagate to the derivatives without duplicating effort? > > For example, to respect the Debian release process, I've avoided > uploading the latest versions of my packages to sid, so it appears that > newer versions of those packages missed the boat when Ubuntu started > their freeze. This means that both Debian and Ubuntu will release with > versions of the packages that are old and don't have the latest bug > fixes and/or any manual effort to work around that takes away time that > could be spent on more bug fixes or features. You can look at glibc, gcc, python which all got packages in Debian VCS and/or uploaded into Ubuntu from Debian VCS or sycned/merged from Debian Experimental uploads. These workflows can be done, but require cooperation and are not automatic (e.g. sync-from-experimental is always manual and not automatic as e.g. syncing from sid or testing). Ideally, i'd like to see debian to branch or use t-p-u, such that sid can continue accepting new uploads and not freeze. E.g. something similar to how fedora operates. I vaguely recall that something like that has been proposed to debian in the past, and didn't get much traction, since developers can get distracted by continious uploads instead of working on releasing the frozen part of the archive. Regards, Dmitrijs. [1] http://blog.surgut.co.uk/2013/04/ftbfs-fixes-and-other-patches-available.html -- 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/canbhlujh1-g77ffrhruganszhmx06gjzuexn5zc6hmoh7np...@mail.gmail.com
Re: multiarch and interpreters/runtimes
On 18 April 2013 19:13, Sergei Golovan wrote: > Hi! > > On Thu, Apr 18, 2013 at 9:56 PM, Andrew Shadura wrote: >> >> Hello, >> >> >> By the way, have you contacted Sergei on this? > > I saw the bugreports and I'm planning to start working on them after > wheezy release. > Yeah there is no rush really. We pushed the patches to ubuntu, realised that it's silly to have tcl multiarched without tk, then had full archive rebuild noticed loads of things failing and hence tweaked up tcltk-defaults to provide "compat" Config.sh scripts (basically call dpkg-architecture and source correct default Config.sh from multiarch location). And even after that a few things still required manual patching. The package history in launchpad has all the debdiffs as usual, and debian pts should have links to those as well by now ;-) I'm sure a few things are still missing for the initial multiartification, but it did help cross-building a few reverse-(build)-depends already (which was the original wookey's driving intend). If there are any questions, or more cleanedup / rebased debdiffs required I am more than happy to help out. But somehow I am expecting loads of transitions to start early in jessie and a big havoc for a few months =) >> >> > Personally, I'm not yet convinced about this interpreter >> > multiarchification, but hey Debian is a Universal OS ;-) and I don't >> > see any reason to not do this. >> >> Well, it may make sense, but really there will be not many people >> running foreign interpreters at all, in my opinion. >> >> Is there a wiki page on Tcl/Tk multiarchification? > > Not yet. > I'm not sure we need one. Transition tracker setup in ben, might help though to track the transition to the multi-arched lib packages. >> >> To Sergei (added to Cc): I'd like to join the effort in packaging Tcl/Tk >> and stuff, as I said before; but as you've been the most active person >> on the team for quite some time I'm a bit hesitant about interrupting >> the process by committing things :) I guess, we need some >> co-ordination; also, in my opinion, the mailing list needs revival. > > There's pkg-tcltk-de...@lists.alioth.debian.org mailing list for that. > FYI, i'm not subscribed to that one. > Cheers! > -- > Sergei Golovan -- 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/canbhlugxpqvraw9gmldr-afxvdeg+6sxd57kysh3lmcnbfg...@mail.gmail.com
Re: multiarch and interpreters/runtimes
On 18 April 2013 15:55, Andrew Shadura wrote: > Hello, > > On 18 April 2013 16:41, Matthias Klose wrote: >> - Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches >>are available in Debian bug reports. >>Currently the shared libraries are split out into separate packages, >>and are co-installable. Not yet tested if this enough to run an >>embedded interpreter. > > Could I please have more info? :) > Well there are patches to move .so libraries from /usr/lib/tk8.*/ to /usr/lib/$(MULTIARCH)/tk8.*, same for tcl and matching tcltk-defaults package to have similar symlinks everywhere. And basically mark that package with .so's as multiarch:same. The interpreter packages are still not marked multi-arch anything. And as doko said, there wasn't anything else done e.g. test embedded interpreter use-case. Personally, I'm not yet convinced about this interpreter multiarchification, but hey Debian is a Universal OS ;-) and I don't see any reason to not do this. Regards, Dmitrijs. -- 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/CANBHLUg8ibjrY0p+A=VXk_mS=ne26i1ignypdxbcx6cuwcz...@mail.gmail.com
Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?
On 16 April 2013 13:29, Neil Williams wrote: > On Tue, 16 Apr 2013 16:11:24 +0400 > Игорь Пашев wrote: > >> 2013/4/16 Raphael Hertzog : >> > On Tue, 16 Apr 2013, Игорь Пашев wrote: >> >> I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH, >> >> and put them in first positions. >> > >> > Why? >> > >> > This modules tries to mimick ld.so's logic to find libraries as closely >> > as possible. >> >> /lib:/usr/lib was the default path, now it is >> /lib/:/usr/lib/, isn't it? > > > MultiArch in Debian is principally concerned with runtime paths, the > build-time paths and consequent cross-compilation support still has a > few wrinkles to resolve. (or dpkg-cross could have been removed from > Wheezy.) > Well, despite policy not settled people started to multi-arch enable -dev packages in a quite aggressively. Because well, it's convenient. I found 140+ dev packages on my system that do so. http://paste.ubuntu.com/5713071/ And well, since these are multi-arch same and presumably co-installable, that mean that .so symlink is not in /usr/lib/ any more for all of them. So we better figure out the Multi-arch-dev story sooner than later =) Regards, Dmitrijs. -- 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/canbhlui9b_pylrugdstjngmunzndx53exgmjotjb4t638...@mail.gmail.com
Re: failure to communicate
On 4 April 2013 20:47, wrote: > On Thu, 4 Apr 2013 19:09:04 +0200 > Christian PERRIER wrote: > >> This mail is a very good argument to confirm that overcomplicated >> methods to make your point will just fail. >> >> If you have a point to make it, make ti. Once. With facts. > > I supplied plenty of facts. I was not following this bug report but reading it, it reminds me of the Unit Policy [1] that got approved and is gradually implemented in ubuntu/debian packages. Looking at d-i the usage is mostly correct sans 'k' should only be used lower-cased with current base-10 units. The major problem with changing these is that same prefixes are accepted for pre-seeding and it would be ill-advised to change those, thus backwards compatability must be preserved in the values that can be preseeded as well as entered by the user. The default to base-10 units, is good as majority of the installer deals with HDD drives (not SSD) and not RAM. If I have 1TB drive and want half of it for one thing and 1/4 for this and 1/4 for that, no space should be left on the drive. Hence matching and using same units as disk-manufacturers is good. The case where we mix & match => e.g. making swap big enough (base-10) for RAM size (base-2) is tricky. And it's something to consider in the UI. I understand your frustration, but as it happens installer work/improvements becomes a hot topic post-freeze as this is when people start to use the installer, notice things and try to write features. And all of these features will only land for the next cycle with a release in ~= 2 years time. Tell me about bad timing, eh?! =) W.r.t. boundry alignments, I believe it its already aligning at 2048 by default and there is ongoing work to align with 4K boundries properly. But note that boundry alignment has little to do with user displaying/specifying amount of gigaheaps one wants to be allocated where. Everyone seems to agree to bring support to input/output Ki/Mi etc prefixes. That's a feature and can only go into jessie branches and or wait for wheezy release. Once that lands we can bike shed to death where to display what units and what to default to where going forward. [1] https://wiki.ubuntu.com/UnitsPolicy Regards, Dmitrijs. ps. there are disk manufactures that mix base-2 and base-10 units. E.g. using one to calculate "1MB" and then using the other multiply and gain GB/TB factors /o\ -- 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/canbhluhxq96h7ejrsfm7emomvmkdmuc7buyez1jgenrxpuq...@mail.gmail.com
Re: Splitting the devscripts package
On 2 April 2013 16:18, Reinhard Tartler wrote: > On Mon, Apr 1, 2013 at 4:45 PM, Ben Hutchings wrote: >> >> Apparently there are, but aside from that: should a 'bts' command on >> $DERIVATIVE interact with the Debian bug-tracking system, or the >> $DERIVATIVE bug-tracking system? > > This can/should preferably be configurable, defaulting to the Debian > BTS. Derivatives should be encouraged to override the defaults > accordingly. I think in ubuntu, at least reportbug had a failsafe guard "trying to report against ubuntu bts, which does not exist. Are you sure you know what you are doing?" typo of thing, and there is a config var to enable reporting to Debian. I expect similar for bts, on !Debian have a safe-guard against spamming Debian with derivative bugs. Yet allow derivative developers work with bugs.debian.org using those handy tools, when they actually know what they are doing and are politely educated when they push too much into Debian. Regards, Dmitrijs. ps. I has always developed Debian from Ubuntu host, mostly using pbuilder/sbuild and very rarely a VM (command-line). There are a few Ubuntu Developers that do reverse, fully develop from Debian host. -- 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/canbhluj0pnfnmw0qm-wpqosmwh1a+r3qzrilrdcvcgyb+go...@mail.gmail.com
Re: touchscreen support in Debian?
On 29 March 2013 20:03, Svante Signell wrote: > Hi, > > I recently purchased an Acer S7, having both a keyboard and a touch > screen. It is currently running Windows 8. Any chances of running Debian > GNU/Linux on that box? I've heard rumours that Ubuntu supports this > hardware, is that true? > I'm not familiar with that model, but yes it should be possible to run Debian on that machine and well any other typical machine that has windows 8. For ubuntu hardware support you can see this website: https://friendly.ubuntu.com/ which doesn't seem to have explicit support listed at the moment. While there is no fluid keyboard/touch interface combination as one gets with Window 8 Metro style UI, I would expect both to work in a dual screen like manner. You may want to consider a stylus for the touch screen (make sure to get a capacitive one). I'd recommend you to take further discussion about prospective hardware support to our Debian Users Mailing list: https://lists.debian.org/debian-user/ As this is not an on-topic discussion for debian-devel. > Thanks :) > No problem. Regards, Dmitrijs. -- 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/canbhlugvfkp0kjpum5ahoz_ea7ypuutffs7ed4y1atadn3j...@mail.gmail.com
Re: touchscreen support in Debian?
On 29 March 2013 22:44, Bjoern Meier wrote: > hi, > > > 2013/3/29 John D. Hendrickson and Sara Darnell : >> REALLY? you have 30 days to return it. if you want unix and touchscreen >> get an Apple. >> >> don't use debian haphazardously (without knowing full well what can happen / >> if it will work) thinking you'll save time or money. that's not what linux >> is for. doing so could easily leave you no-where, even with a computer you >> can't personally fix, after days. >> >> if you are worried about money return it get an (apple). if not, then of >> course they say, "hacking is no crime" :) (do they say that still?) > > Hell yeah, dig him to hell. How could he dare to think out of the box > and ask for a natural use of his own hardware. Fuck you! This is not > what we want, use our software as WE think of! Yes damn it, this is > not what linux is for. Shame on you to think that you could use it on > the way YOU want it. > > Seriously? "that's not what linux is for" What exactly is linux not > for? Jesus, I could vomit if I read this. Maybe or not Linux is - at > the moment - not capable for touch screens. Oh wait, Android is > capable to use touch screens. Which Kernel used Android again? Ah > sure, the Linux kernel 2.6. > > Man, I wished I was so close-minded, sometimes things were a little bit > easier. > Your abusive language and down-playing other people is also inappropriate, despite how right or wrong other participants in this tread are. If one has an urge to swear in an email, maybe it's not the email one should answer at that time. Your message is inappropriate conduct. Regards, Dmitrij. > Greetings, > Björn > > > -- > 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/cagmps54qgt-1y0gp82r6xxnvva298aww8umy9pq7ow8j5...@mail.gmail.com > -- 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/canbhluh1cakmf8p1nlxsx0wc7qbcp3m5zw8jeyqkz0aazbz...@mail.gmail.com
Re: touchscreen support in Debian?
On 29 March 2013 22:19, John D. Hendrickson and Sara Darnell wrote: > REALLY? you have 30 days to return it. if you want unix and touchscreen > get an Apple. > This whole email was very out of line, and it's not how I would like Debian Community to be viewed as. Debian is Universal OS and there is no reason for it not to support touchscreens as best as it can. For example Gimp and Inkscape have very great touch & pressure sensitive brushes. Debian is suitable for anyone to use even haphazardously, and reinstalling back to something else is fine. More appropriately I would have recommended to redirect this message to debian-user mailing list. Regards, Dmitrijs. > don't use debian haphazardously (without knowing full well what can happen / > if it will work) thinking you'll save time or money. that's not what linux > is for. doing so could easily leave you no-where, even with a computer you > can't personally fix, after days. > > if you are worried about money return it get an (apple). if not, then of > course they say, "hacking is no crime" :) (do they say that still?) > > > > Stephen M. Webb wrote: >> >> On 03/29/2013 04:03 PM, Svante Signell wrote: >>> >>> Hi, >>> >>> I recently purchased an Acer S7, having both a keyboard and a touch >>> screen. It is currently running Windows 8. Any chances of running Debian >>> GNU/Linux on that box? I've heard rumours that Ubuntu supports this >>> hardware, is that true? >> >> >> I can't say with absolute certainty because of the myriad patches and >> versions floating around, but squeeze *should* >> support the required multi-touch driver in-kernel and definitely has the >> XI2.2 protocol in the x.org server. It should >> just work. >> > > > -- > 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/5156137e.6070...@cox.net > -- 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/canbhluindpzvoyqyeth-nmrga5ypmbnjoayqbbnjfh1eoaf...@mail.gmail.com
Re: history transparency
On 15 March 2013 00:56, Philip Ashmore wrote: > On 09/02/12 08:58, Paul Wise wrote: >> >> On Thu, Feb 9, 2012 at 4:45 PM, Philip Ashmore wrote: >> >>> I think Debian needs a way to be able to pick a point in history and >>> obtain >>> at least the versions + patches of all the source packages that would >>> have >>> been installed / available to reproduce the Debian system running on the >>> users machine at the time they reported the bug. >>> >>> With more and more source packages becoming available under publicly >>> accessible version control, what needs to change in Debian to make this >>> possible? >> >> >> Nothing, it already exists: >> >> http://snapshot.debian.org/archive/debian/20091229T215155Z/ > > How do I work out which snapshot I have installed now? > I download from Sid. > Take the checksum of Packages from /var/lib/apt/lists and find a matching one on snapshots. It will be close, but not everything. A better way is to use apt-clone which will generate a more comprehensive state tarball. > Is there a micro-version file that stores this information or is it a time > stamp on some file? > How would that help at all? Given that it will never know the set of packages you have installed, or obsolete packages not-removed, modified conffiles etc. Regards, Dmitrijs. -- 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/canbhluhmbhhn+vlxjufhtdffrq3j9z2r9mx4w3phq3cnki6...@mail.gmail.com
Re: Bug#702607: make source code of all Debian projects visible (on gitweb) [DCS]
On 9 March 2013 02:11, Charles Plessy wrote: > Le Fri, Mar 08, 2013 at 08:52:43PM -0500, Yaroslav Halchenko a écrit : >> >> as for the combined search-engine through all source code (which is the >> closest to your original use case) -- there is a (still non-official) >> http://codesearch.debian.net/ > > By the way, the source code of codesearch is still not available... Hm?! https://github.com/debiancodesearch/dcs/blob/master/README -- 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/canbhluiyky4t89f908j+hqh6vjskn29ccvyqunaxoeaqj9r...@mail.gmail.com
Re: git dangerous operations on alioth
On 1 March 2013 10:54, Thomas Goirand wrote: > On 02/28/2013 06:07 PM, Stefano Zacchiroli wrote: >> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote: >>> Has anybody had experience controlling access to git repositories, for >>> example, to give users access but prevent some of the following >>> dangerous operations? >> Related to this, there is also the risk that a user will ssh on alioth >> and rm the repository (accidentally or not). Do we have any kind of >> protection against that? (e.g. backups we can access to without >> bothering the alioth admins, or a way to give git access but not ssh >> access, or...) > Do we have a backup at all? If so, how often is the backup made, and how > much days of history do we have? A backup of a git repository is a mirror that constantly does fetch and never performs garbage collection. In addition copying across push reflog and even keeping it committed into git as welll makes sense, this way one can establish when / what / how the repository got updated with broken changes. Regards, Dmitrijs. -- 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/CANBHLUiRM1B9fji2=gqk8fhfvrzrk8wbryqvv4outwgkpby...@mail.gmail.com
Re: Bulding 3.0.1 Under Ubuntu 10.04 i386
On 28 February 2013 20:03, Cristian Ionescu-Idbohrn wrote: > Please Cc:, not subscribed to the debian-devel@lists.debian.org list. > > Hi there! Linus Torvalds is highly involved in this project :) > > On Thu, 28 Feb 2013, Dirk Hohndel wrote: >> >> The problem is that our target audience are divers, not hackers. > > Agreed. > >> Someone who can build from those sources can just build from git > > Check. > >> But many people (even people running Linux) aren't comfortable building >> their own binaries. > > I wouldn't be that sure, but ok, check. > >> And for those I try to make their lives easier. > > Of course. Where do you get all that energy from? I'm impressed. > Really. > >> To me that means I need the Ubuntu packages - and those apparently can >> neatly be built with Launchpad (a couple of us are working on that right >> now). > > That's good. You say ubuntu, but how many ubuntu derivatives are there? > And who's ubuntu getting maintained packages from? > > Don't get me wrong. It's better with one alternative than no alternative > at all. > >> Debian? No non-hacker is running Debian, I guess :-) > > Not so. Both my wife and one of my dauthers (non-hackers, as you might > expect) are using debian ;) And they're happy with that too, AFAICT. > They got a choice and an offer they couldn't refuse, I guess. No support > at all, or all support they need. Hard to refuse ;) "Real men don't > click" (tm), I know, but they're not men, and definitely not hackers. > > Managed to get one debian maintainer involved, at some point, Cc:ed, but I > guess he can't live up to that honor we need so badly right now :( Yes, > I'm trying to provoke him. > >> So in reality it really is Ubuntu that I try to cover here. > > That's great. Sorry, I don't know if I can help much there but, by all > means, try me. > > In the meantime, I'll try to figure out some other way to get a debian > maintainer attracted. Attempting that right now. That'll make all debian > derivatives happier too. And that's the beauty of that. > > Are there more debian users and divers watching this list? > Could we join forces? Ideas? There might be things that could be > adjusted in the upstream source that may make distributions binaries > packiging more attractive and easier to maintain. I'm sure upstream will > try to accomodate. I think it's a shame for such a great distribution > (been using it for more than 15 years now) to miss such an opportunity. > I have only one dive of a whole 8m deep, but I am ubuntu & debian developer and can upload this package to debian/ubuntu and a ppa. Is there any packaging done so far? Point me to it, if not just file Debian RFP and CC me on it. Regards, Dmitrijs. -- 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/CANBHLUgEP4tBNPRGAXXMaTgsumE=yYLU=fd=mtauwxdhfxo...@mail.gmail.com
Re: git dangerous operations on alioth
On 28 February 2013 09:39, Daniel Pocock wrote: > > > There was recently some discussion in pkg-javascript about how to give > more people access to the VCS (e.g. keeping the git repositories > logically organised under the pkg-javascript tree, but making write > access available to all DDs + alioth guest users and not just those in > the pkg-javascript UNIX group) > > I generally agree with the principle of giving more people access, but > git access is `all or nothing'. This is not just true for alioth, it is > much the same with github hosting and many others. > > Has anybody had experience controlling access to git repositories, for > example, to give users access but prevent some of the following > dangerous operations? > > - prevent users pushing with the `--force' option > (from the man page for git-push: "This can cause the remote repository > to lose commits; use it with care.") > Alternatively gerrit and gitolite can limit that. > - ensure that users only push commits authored by themselves (email > address white list) > gerrit does this out of the box as well. But I do limit use in this. If i merge a patch from my friend, why can't I push it into the repository? I'd rather also look for Sign-off-by lines as well. > - prevent some users pushing tags (or only allow tags matching a pattern) > gitolite / gerrit can do that. > Github partially works around this issue by providing a convenient web > UI for managing pull requests: so you simply don't give people access to > do any commits at all, and you manually review each of their changes, > although it only requires a couple of mouse clicks to accept each patch. > Gerrit can provide both web & email interface to merge / review patches. It is used by projects like android and libreoffice to process a high velocity stream of incoming patches. Regards, Dmitrijs. -- 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/CANBHLUg2PwR9HWZsBuUrcjTae+p7_Vh6vF=bKiDR070B1y=d...@mail.gmail.com
Re: PIL/python-imaging becomes a python package and gets Python3 support
On 10 February 2013 16:54, Matthias Klose wrote: > There are 126 source packages needing updates. The list of packages > and maintainers is attached below. I'll file bug reports later (user: > d...@debian.org, tag: pillow). > I see that a few packages were identified to work out of the box by fedora folks and they have also started patching packages. There is some overlap so it's worth checking fedora trackers before doing our own patches: https://fedoraproject.org/wiki/Features/Pillow https://bugzilla.redhat.com/show_bug.cgi?id=894484 > > Debian HPIJS and HPLIP maintainers >hplip > > Matthias Klose >python-reportlab > Does this mean that hplip & python-reportlab are now have all their dependenices ported to python3 and hence can also be ported? \o/ Regards, Dmitrijs. -- 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/canbhlugyw1bnnnzsextrrndjqdetj02yaaz3x+vsazagrfk...@mail.gmail.com
Re: multiarch dependency hell. build amd64, can't install without also building i386
On 24 January 2013 04:56, Paul Johnson wrote: > This is a multiarch issue I had not considered before. Have you seen > it? I never wanted to be a "cross compiler", I really only want to > build amd64. But I have some i386 libraries for a particular program > (acroread). > I recently had to build packages that only build on i386, while having an amd64 host: $ mk-sbuild --arch i386 sid $ sbuild -d sid --arch i386 foo*.dsc Since amd64 cpu's can execute i386, it's not cross compilation, but a native one instead. Yes, it's a second build, but it's fairly trivial to do. Regards, Dmitrijs. -- 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/CANBHLUhHHX_=laqq1mjewxhtw-ij+m+2770bbd3hhz2zygf...@mail.gmail.com
Re: Go (golang) packaging, part 2
On 31 January 2013 08:25, Chow Loong Jin wrote: > On 31/01/2013 13:32, Jean-Christophe Dubacq wrote: >>> > >> Don't forget package.el for emacs! > > Wait, what? package.el uses Ruby, and not elisp? > How did we start a thread on go packaging and now mention TeX Live package manager (tlmgr) ?! Regards, Dmitrijs. -- 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/canbhluh3s9zgvr93jttprlzdaqhjnxqhvq8o+nh2kcpn_ev...@mail.gmail.com
Re: No native packages?
On 28 January 2013 18:17, Roger Leigh wrote: > On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote: >> Tollef Fog Heen writes: >> > ]] Gergely Nagy >> >> >> No, not really. I don't really care what tools one uses, as long as the >> >> result is reasonably easy *and* reliable to work with. Since VCS can be >> >> stale, and quite often does not include neither NMUs, nor backports, >> >> that fails the reliable requirement. >> >> > It sounds like you are arguing that we should just ship the the >> > repository in the source package, then. No chance of it ever getting >> > out of date, trivial to find the merge points and missing patches >> > between two packages and fits much better with a VCS-driven workflow. >> >> Yes, many of us would like that, which is why it's been repeatedly >> discussed at Debconfs, but no one has come up with a good solution to the >> fact that this requires reviewing the entire VCS archive for DFSG-freeness >> and rewriting history if any non-free code is ever introduced in it. (Or, >> well, changing the requirements we have around source package freeness, >> but that seems less likely.) > > Maybe I forgot the answer, but at least in terms of git and the dpkg > 3.0 (git) format, why can't we simply make use of shallow cloning? We How many revisions does one need to shallow clone to have an .orig. tree and a debian tree? As one commonly still wants to see what changes are applied if any. If the answer is 2 and git can diff them, than it's great. (Or 3 to include pristine-tar delta?! do we still care about pristine-tar at this point?!) Regards, Dmitrijs. -- 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/CANBHLUhmTL45FVNXkJe-DCwSr8E=nnmdvvem0yaadjpg1kc...@mail.gmail.com
Re: No native packages?
On 27 January 2013 18:32, Gergely Nagy wrote: > Jakub Wilk writes: > >> Dmitrijs Ledkovs wrote on his blog[0]: >> >>> Generally if software is useful in Debian Project it can be useful >>> for other debian-like and unlike projects. In particular native >>> packages do not offer the same patching flexibility as 3.0 (quilt), >>> thus forcing downstream distributions to inline modify packages >>> without DEP-3 >>> headers. This hurts us, when trying to merge useful stuff from >>> derivatives back into Debian, as changes are not split into >>> individual patches. >> >> I would tend to agree that we have too many native packages, though I >> doubt you'll find (m)any supporters of the idea of banning them >> completely. > > There are two native packages I maintain, and I've yet to hear a good > reason for making either of them non-native. Making it harder and much > much more inconvenient for downstream distributions to modify them is a > *goal* in these cases: to make it harder to diverge from one > another. > > As for no DEP-3? I do sincerely hope that by 2013, everyone's using a > VCS, and we can pick patches from there. > If only we all can agree on the VCS to use. A patch seems to be the common denominator. Also, there are a lot of caveats with DVSC. I have seen a lot of repositories where maintainers forgot to push commits and/or tags. Or obsolete Vcs-* headers, because repository got moved, yet there was no upload yet. And that's easy to do, since the thing you upload to ftp doesn't check/require for you to push anything. NMUs & security uploads are often also missing from Vcs-* repositories. Native packages is a social issue =) my view is that they set a bad example and introduce a lot of "do this, unless it's native package". Also some of the convenience stated, benefits Debian, but hurts dowstream. As any packaging change, triggers a new .orig.tar.gz with a new checksum. Regards, Dmitrijs. -- 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/CANBHLUjqBX8k=ddrlhpufddj_6q3dsfvmiaj_vc_xepvhf-...@mail.gmail.com
Re: Retrieving source package from repository without touching sources.list?
On 15 January 2013 04:46, Nikolaus Rath wrote: > # fancy-dget http://http.debian.net/debian/ experimental mypackage > > would download the newest mypackage source from experimental. Bonus > points if messing with the system wide sources.list is avoided entirely > and no root privileges are required. > It's called pull-debian-source $ pull-debian-source mypkg $ pull-debian-source mypkg experimental $ pull-debian-source mypkg 0.2.3-3.2 It uses the archive & snapshots to pull in historical versions. >From the ubuntu-dev-tools package available in stable and up. There is also equivalent pull-lp-source with same arguments to pull ubuntu packages instead of debian. I haven't seen similar tool for other derivatives. Regards, Dmitrijs. -- 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/canbhlugu9hxkqxbsv1+m4gqf0vcprnuph2kakrnys2mz5+i...@mail.gmail.com
Re: Knowing the release names in advance (was: Feedback)
On 2 January 2013 14:32, Simon Paillard wrote: > On Tue, Jan 01, 2013 at 10:56:53AM +0800, Paul Wise wrote: >> On Mon, Dec 31, 2012 at 7:18 PM, Dmitrijs Ledkovs wrote: >> > $ man debian-distro-info >> > >> > Debian OS provides API to query such information. >> > In addition, stable alias names are also provided (stable, testing, >> > unstable, experimental). >> > As a last resort you can also scrape archive mirrors dists (e.g. >> > ftp-master, snapshot, old-releases) and check the symlinks. >> >> That seems like a hack to workaround the fact that the archive doesn't >> provide this information in one file. > > Like a machine-readable http://http.debian.net/debian/dists/README ? > Maybe distro-info-data's csv file should be published on mirrors, to even provide historical names. http://anonscm.debian.org/gitweb/?p=collab-maint/distro-info-data.git;a=blob;f=debian.csv;h=ed3302e57d18f7697eec0b67fee259b904436684;hb=HEAD Regards, Dmitrijs. -- 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/canbhlujqqxjppjeqcxbkmqeqr9zzfprevl-y40eawb4trqg...@mail.gmail.com
Re: [RFC] Go (golang) packaging
On 1 January 2013 19:47, Michael Stapelberg wrote: > Hi Dmitrijs, > > Dmitrijs Ledkovs writes: >> What about multiarch? > I tried to address this on the wiki page, see > http://wiki.debian.org/MichaelStapelberg/GoPackaging#Multi-Arch.2Fcross-compiling > I was more concerned about future-proof, e.g. in debian we have distinct armel & armhf and currently with multiarch I can cross-compile binaries for either target from my amd64 build-machine. In debian we have far more ports than any other distros. It would be nice if go could use gnu and/or debian triplets instead of one more incomplete set for the same thing. > Essentially, I currently believe that multi-arch does not make sense for > go, since we are only dealing with static binaries. E.g. to run an i386 > program, you don’t need any additional libraries: > I understand that users running the resulting binaries typically do not need anything. My interest in multi-arch support is for fast cross-compilation, i.e. the same reason pre-compiled libraries are shipped for "native" compilation. I could use chroots, but having all those packages as "M-A: same" would be lovely... which brings the argument back into the circle that upstream doesn't define unique per-arch paths (at least not for arm*) reference: https://wiki.ubuntu.com/MultiarchCross Regards, Dmitrijs. -- 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/canbhlujnv-_h6+buolbwr-ae4+oispqw+q8epojupadwzbj...@mail.gmail.com
Re: [RFC] Go (golang) packaging
On 1 January 2013 15:44, Michael Stapelberg wrote: > Hi, > > I am co-maintainer of the golang package and spent a few hours on trying > to figure out how to best create Debian packages for libraries and > programs which are implemented in Go. > > I have documented my thoughts, conclusions and example packaging on: > http://wiki.debian.org/MichaelStapelberg/GoPackaging > > Essentially, I propose that /usr/lib/gocode is used on Debian to store > the “src” and “pkg” folders which contain the .go files and compiled > versions (respectively) of Go libraries. > What about multiarch? /usr/lib/gocode/ for sources /usr/lib/$triplet/gocode/ for compiled versions This assumes that sources are identical across all architectures. Regards, Dmitrijs. -- 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/canbhluhh_c35qr3hqkha2apkxhps-9rsqmgqbrqufx8xwt4...@mail.gmail.com
Re: Knowing the release names in advance (was: Feedback)
On 30 December 2012 19:23, Thomas Goirand wrote: > On 12/30/2012 04:26 PM, Thijs Kinkhorst wrote: >> Would it be an idea to publish the list of version numbers and associated >> code names a few releases ahead, say the upcoming three releases? Of >> course the prerogative of deciding on the names will remain with the >> release team, it would only be pulled forward a bit. > I have 3 things to say about this. Yes, then yes, and yes again. > > Not only this is good for our users, but this is also technically > needed for both upstream and us, doing the packaging. > > Let's say you have a software that somehow, installs Debian. > Then it might require the user to select which name of the > release to install. > > Currently, we knew about the name Jessie *after* the freeze, > meaning that we couldn't have written a software that would > debootstrap it without asking for an unblock. > $ man debian-distro-info Debian OS provides API to query such information. In addition, stable alias names are also provided (stable, testing, unstable, experimental). As a last resort you can also scrape archive mirrors dists (e.g. ftp-master, snapshot, old-releases) and check the symlinks. > I made that point very clear multiple times, and I haven't been > the only one doing it. Yet, it hasn't been heard, and I never > receive any technical argumentation as to why we shouldn't > know the release names well in advance. Maybe if there was > a greater number of DD insisting that this is necessary, this > could change. Please +1 to this if you agree. > -1. There is already multiple APIs provided to query such information in multiple ways as outlined above. Regards, Dmitrijs. -- 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/canbhlujfwh7su-yqulp8mcmavyh9kb2fcnulej7lphw3egd...@mail.gmail.com
Re: Ubuntu have done it again,
On 7 December 2012 23:36, Russ Allbery wrote: > Svante Signell writes: > >> this time installing surveillance code. > >> http://linux.slashdot.org/story/12/12/07/1527225/rms-speaks-out-against-ubuntu >> http://www.fsf.org/blogs/rms/ubuntu-spyware-what-to-do > >> Any reason Debian should be so closely linked to Ubuntu? > > We should make sure that people have to ask our permission before they use > our code for any other purpose! And make sure they can't do evil with it! > I totally agree! Anyone who uses debian source or binary packages should automatically phone to SPI. BTW, I am slightly confused is this debian-curiosa or debian-devel?! Regards, Dmitrijs. -- 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/CANBHLUipnbGErNTZm15fMiT8DswaSxNr+mHcjv=yzxfak0d...@mail.gmail.com
Re: GFDL in main
On 1 December 2012 15:42, Jean-Christophe Dubacq wrote: > On 01/12/2012 12:10, Jakub Wilk wrote: >> These packages include documentation licensed under GFDL with Invariant >> Sections or Cover Texts: >> >> bash >> binutils >> tar >> >> As per GR 2006-001 such works are not suitable for main: >> http://www.debian.org/vote/2006/vote_001 >> >> Any volunteers to file bugs? > > > Yes, exactly what we needed: file a RC bug against essential packages at > this point of release :) > Yes, this _is_ exactly what we need. "1. Debian will remain 100% free" [1] And we better not release until licensing problems in main are resolved. Documentation is usually not essential to execute and run the system, so there shouldn't be any dependency cycles to consider when removing the documentation or shipping it in non-free. [1] http://www.debian.org/social_contract -- 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/CANBHLUjQru+W288Ocf73bv4CENZ4yB6d0k3=4wjttjazmmy...@mail.gmail.com
Re: "Do not CC me"
On 26 November 2012 00:50, brian m. carlson wrote: > On Mon, Nov 26, 2012 at 12:19:18AM +0000, Dmitrijs Ledkovs wrote: >> If your e-mail processing machinery cannot handle duplicate messages >> (due to cross-postings and CC's), maybe you should get an a better >> email processing machinery. Receiving duplicate emails is inevitable, >> and trivial to deal with. > > Is it? I filter mailing lists into a separate folder for each mailing > list using procmail (using the RFC 2919 List-Id header). I also have > notifications on my cell phone (via my IMAP client) for mail in my inbox > and certain other folders, but not mailing lists. So if I receive the > CC first, and the mail from the list second, whatever de-duplication I > do, I've already been notified that I have a potentially important email > in my inbox. Please inform me how I am to go back in time and not > receive the notification on my cell phone, or please explain to me why > your mail to the list is so important that I should receive notification > of it wherever I am and whatever I'm doing. > I see. I went back to check my email archive. I have found two instances of debian-devel posts that did CC my @debian.org email address (I am also subscribed to debian devel via @debian.org). I only have one email. It is sorted correctly. I am still trying to decipher how come I don't have this problem. But in general with CC's to the mailing lists, both To: & Cc: headers have debian-devel & yourself in both messages and List-Id only in one of them. So surely you can filter one copy to /dev/null as appropriate?! BCC: is the evil one, cause then you have to look at Delivered-To. Regards, Dmitrijs. -- 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/canbhluhmxbwd8_yyfy4zv-0zrvxdaclrxe9ceoj7itbuh21...@mail.gmail.com
Re: "Do not CC me"
Hello there, On 25 November 2012 20:35, Karl Goetz wrote: > On Mon, 26 Nov 2012, 07:27:31 LHST, Игорь Пашев wrote: > >> Hi there! >> >> I see many note in this list like: >> "I'm registered to the list. So please *do not* Cc: me." >> >> So I'd like to note: >> >> 1. Some e-mail cleints make it hard not to CC. For example GMail has only >> two options: reply and reply to all. "Reply" will send email to the >> author, not to the list > > then people using those mail clients will need to take extra care to remove > CCs, just as i had to in replying now. > If your e-mail processing machinery cannot handle duplicate messages (due to cross-postings and CC's), maybe you should get an a better email processing machinery. Receiving duplicate emails is inevitable, and trivial to deal with. I have had many times "I didn't see your email, because it was filtered to mailing-lists instead of my higher priority mailbox, please CC me on important stuff". This is also especially true for people who read mailing lists via rss/nntp and not directly through their email. Also, since debian-devel is an open-post mailing list, there is no guarantee the posters are subscribed (although it's easy to spot the usual suspects). You may wish to CC me anytime you reply to my postings on debian mailinglists. I really don't mind. Regards, Dmitrijs. -- 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/canbhlugnsuysdzbmeuhyk3bqxj-_8z9rwg6n0ig2gxvorfs...@mail.gmail.com
Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On 20 November 2012 12:23, Henrique de Moraes Holschuh wrote: > On Tue, 20 Nov 2012, Dmitrijs Ledkovs wrote: >> I am sorry, if I was not clear. I am aware of the "last iteration", >> but I am not enquiring about the default policy within debian as to >> how we should upload by default. >> I am asking why, when I had a reason to do so, was not able to do a >> source-only upload. >> Is this a feature of dak, or a policy enforcement? > > Both. > Where is this policy documented? I have checked Debian Policy and ftp-masters mini-site faq/rejects sections. Regards, Dmitrijs. -- 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/canbhlujq19s9rvymg8_o6eireyh6fvhlhmzh6u5j-bv8_nc...@mail.gmail.com
Re: Something like nocompress DEB_BUILD_OPTION
On 20 November 2012 23:21, Guillem Jover wrote: > On Sat, 2012-11-10 at 13:52:22 +0100, Bastian Blank wrote: >> On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote: >> Okay. I did some tests with various packages. From binary only to text >> only. > > Thanks for the tests Bastian. It would still be nice to see a bigger > sample, if the tests only consisted of these 4 packages, though. > >> Package | gzip -6 | gzip -9 | gzip | xz -1 >> --+--+-+- >> libc6 | 4339010 | 4321933 | 0.5% | 2938132 >> perl-modules | 3874170 | 3822719 | 1.5% | 3248392 >> gnome-user-guide | 9217494 | 9172395 | 0.5% | 7589076 >> linux-image-3.2.0-4-amd64 | 32928159 | 3258 | | 25945856 >> >> "gzip -9" is always much slower then "gzip -6". It is at most 2% better. >> "xz -1" is usualy faster then "gzip -9" and much better. However most >> packages only needs seconds to compress, so the difference will no >> really matter. >> >> So instead of switching to gzip -6, a switch to xz -1 would make more >> sense in term of size and also speed. > >> So my proposal would be: >> - Don't do anything for Wheezy. >> Any change may break the CD creation. >> - Switch to xz per default for Jessie. >> xz -3 is often faster in compressing stuff then gzip -9. -6 needs a >> lot of memory, especially for compressing the files, so reducing the >> default to -3 may make sense and does not cost much. > > I've already mentioned in some other thread that for dpkg 1.17.x (that > is after wheezy), I'll be switching dpkg-deb to xz as the default > compressor, as that seemed the consensus; but that does not mean that > if the default compression level for gzip is suboptimal (as it seems > it is), that cannot be changed too. > > For changing xz default compression level I'd like to see the > implications on a wider dataset, also we should take into account that > compression is only done once, so I don't think that's such an issue, > if the time and memory are not really onerous. While I appreciate the discussions around default compression algorithms and their setting, I'd rather this thread to stay on-topic. Does the idea of providing a standard interface to disable compression make sense? In the approximately similar fashion that noopt and nostrip are justified? This should be a standard interface via DEB_BUILD_OPTIONS, because dh_builddeb / dpkg-deb is not the only way to build compliant binary packages. Please continue discussing default compression options, but please use another thread/topic. Just as I do now, I will continue to want the nocompress option regardless of current or future default/non-default compression algorithms and options. I'd like to gather consensus on how (in)sane this idea is though before submit a patch for debian policy. Regards, Dmitrijs. -- 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/CANBHLUh_y+X=bzga5rldy+fvvmcmso0gwhamibc28y+erga...@mail.gmail.com
Re: Fwd: procenv_0.9-1_source.changes REJECTED
On 20 November 2012 16:12, Luca Capello wrote: > Hi there! > > On Tue, 20 Nov 2012 14:35:08 +0100, Dmitrijs Ledkovs wrote: >> I did built in sbuild, but not a VM. Is there pbuilder/sbuild backed >> by qemu/kvm available anywhere to make that easier to do? > > There is, but I doubt the built package will be accepted, we already had > this problem in the past: > Just to be clear, I don't want to upload binaries. On the contrary, I have uploaded a source-only changes which got rejected. In the current instance, I want sid chroot on stable kernel. I will look into qemubuilder if it can do that. Thanks for that tip. > <http://lists.debian.org/20070214111517.gc25...@azure.humbug.org.au> > Seems like an old thread. I am on the side that binaries should be built on bare metal by a native compiler. Regards, Dmitrijs. > = > $ apt-cache search qemu builder > qemubuilder - pbuilder using QEMU as backend > $ apt-cache show qemubuilder > Package: qemubuilder > Source: cowdancer > [...] > Description-en: pbuilder using QEMU as backend > pbuilder implementation for QEMU. > . > qemubuilder create -- builds QEMU cow base image. > . > qemubuilder update -- updates QEMU cow base image. > . > qemubuilder build -- builds package inside QEMU cow base image. > . > Gives a pbuilder interface for emulated cross-building environments > using qemu. > . > pbuilder is a tool for building and testing Debian package inside a > clean chroot, and qemubuilder implements similar experience over > emulated CPUs. This tool allows building package inside emulated > Debian environment for different CPU architectures supported by qemu. > Homepage: http://wiki.debian.org/qemubuilder > [...] > $ > = > > Thx, bye, > Gismo / Luca -- 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/canbhlui7q2zkhmxutefmfjem0fsa1mp3bpybe0nwpauqmwq...@mail.gmail.com
Re: Fwd: procenv_0.9-1_source.changes REJECTED
On 20 November 2012 14:42, Thibaut Paumard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Le 20/11/2012 14:35, Dmitrijs Ledkovs a écrit : > >> What's this: lucatelli Kernel: Linux 3.2.0-0.bpo.3-octeon >> https://buildd.debian.org/status/fetch.php?pkg=llvm-3.2&ver=3.2~rc1-1~exp3&arch=mips&stamp=1353416035 >> >> Why is distribution (experimental) building on an out of date >> backported kernel? >> > > The buildd hosts are production machines, they're not guaranteed or > even supposed to run SID (packages are built in chroots). > > When your package fails to build due to a *buggy* kernel, you can > request for an upgrade on this buildd. > > Why does the running kernel matter for procenv build? Does procenv run > on another kernel than that of the machine it was built on? > Well the code in it's current form was discovered to rely on newer kernel features. Now I am trying to establish a baseline that could be reasonably relied upon and I have passed these details to upstream now. Currently it builts fine, but fails to run on an older kernel, upstream is working on fixing this runtime error. Regards, Dmitrijs. -- 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/canbhluihcgbvo_rczzwrqg0w5ktvjhrjqrzfr4utwg7o9k4...@mail.gmail.com
Re: Fwd: procenv_0.9-1_source.changes REJECTED
On 20 November 2012 14:28, Philipp Kern wrote: > Dmitrijs, > > am Tue, Nov 20, 2012 at 02:03:52PM + hast du folgendes geschrieben: >> To be clear both at build time & run time. So why the mipsel buildd >> above is running a much newer kernel, since this can be leak into the >> build packages...? Or is it a new port for wheezy or something? (e.g. >> no previous released stable available) > > sometimes buildds need newer kernels because certain bugs are fixed > there but not in stable or because the HW is unsupported with the stable > kernel. > > As Ben said the minimum kernel baseline is currently stable's, even > though it's possible that we run oldstable kernels for a while after the > next stable is release. > > The buildds might run any kernel version between stable's and > unstable's, mostly through backports. But for some new ports or machines > selfbuilt kernels are also possible. > Sure. Thank you for details. Regards, Dmitrijs. -- 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/CANBHLUjRqJ_OSaUVSUXmuAH5doH1G7xcznYP74KyEC=nd5j...@mail.gmail.com
Re: Fwd: procenv_0.9-1_source.changes REJECTED
On 20 November 2012 13:47, Ben Hutchings wrote: > On Tue, 2012-11-20 at 12:37 +0000, Dmitrijs Ledkovs wrote: >> On 20 November 2012 11:45, Jon Dowland wrote: >> > On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote: >> >> I currently do not have facilities to build the package in question >> >> with the host running Debian's kernel. >> > >> > So how can you prove that the package builds? >> > >> >> I can give you my sbuild log I did before uploading, but that does not >> prove anything. >> It turns out that for the package in question, fails to build on older >> kernels & my machine has a newer kernel than buildds. > > It's a bit ironic that a program that tries to tell you everything about > its run-time environment, depends on such details of its compile-time > environment. > It is ironic in an amusing way. The maintainer is fixing this. >> Is there any current facility to find out about buildd hosts >> configuration, e.g. kernel versions? >> E.g. at lest the minimal version available _across_ all architectures? > > The minimum version should be whatever is in stable, i.e. 2.6.32. This > is also the minimum version it needs to run on (think partial upgrades). > To be clear both at build time & run time. So why the mipsel buildd above is running a much newer kernel, since this can be leak into the build packages...? Or is it a new port for wheezy or something? (e.g. no previous released stable available) Regards, Dmitrijs. -- 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/CANBHLUhnkjLUs4=xzhaxvk4nwcptn_0dxb_n1gycbuo12wa...@mail.gmail.com
Re: Fwd: procenv_0.9-1_source.changes REJECTED
On 20 November 2012 13:03, Thibaut Paumard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Le 20/11/2012 13:37, Dmitrijs Ledkovs a écrit : >> On 20 November 2012 11:45, Jon Dowland wrote: >>> On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs >>> wrote: >>>> I currently do not have facilities to build the package in >>>> question with the host running Debian's kernel. >>> >>> So how can you prove that the package builds? >>> >> >> I can give you my sbuild log I did before uploading, but that does >> not prove anything. > > That's why we currently require a binary together with the source. It > tautologically proves that you successfully built it. > Sure it proves that _I_ built it, but it doesn't prove that it will build on the buildds. Hence, my point that in real terms neither debs nor sbuild logs prove anything. See the case about the minimal expected kernel. > Furthermore, maintainers should build their packages is a clean sid > chroot. Note that you can very well build in a virtual machine running > Debian if your host is not Debian and you want to make sure to use a > Debian kernel during build. > I did built in sbuild, but not a VM. Is there pbuilder/sbuild backed by qemu/kvm available anywhere to make that easier to do? >> It turns out that for the package in question, fails to build on >> older kernels & my machine has a newer kernel than buildds. >> >> Is there any current facility to find out about buildd hosts >> configuration, e.g. kernel versions? E.g. at lest the minimal >> version available _across_ all architectures? >> > > I don't know of any summary for this information, but you can find out > from build logs on https://buildd.debian.org. Of course you need to > find a recent build log. > Ok, I will look at it. > > On Barber: > Kernel: Linux 2.6.32-5-amd64 amd64 (x86_64) > > On Brahms: > Kernel: Linux 2.6.32-5-amd64 amd64 (x86_64) What's this: lucatelli Kernel: Linux 3.2.0-0.bpo.3-octeon https://buildd.debian.org/status/fetch.php?pkg=llvm-3.2&ver=3.2~rc1-1~exp3&arch=mips&stamp=1353416035 Why is distribution (experimental) building on an out of date backported kernel? Also MIPS is ahead of x86_64 =) Regards, Dmitrijs. -- 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/CANBHLUgoUnAy+uAQCd0O4JmehEbEtWd+JUM7kzw6vDp=wf-...@mail.gmail.com
Re: Fwd: procenv_0.9-1_source.changes REJECTED
On 20 November 2012 11:45, Jon Dowland wrote: > On Tue, Nov 20, 2012 at 11:10:37AM +0000, Dmitrijs Ledkovs wrote: >> I currently do not have facilities to build the package in question >> with the host running Debian's kernel. > > So how can you prove that the package builds? > I can give you my sbuild log I did before uploading, but that does not prove anything. It turns out that for the package in question, fails to build on older kernels & my machine has a newer kernel than buildds. Is there any current facility to find out about buildd hosts configuration, e.g. kernel versions? E.g. at lest the minimal version available _across_ all architectures? Regards, Dmitrijs. -- 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/canbhlujxk0gx97izifouhpi0cdpwbcamzuxf-a1fkxrzwpj...@mail.gmail.com
