unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
* build broken packages handling
@ 2021-03-29 20:02 Andy Tai
  2021-03-30  2:45 ` Julien Lepiller
  0 siblings, 1 reply; 2+ messages in thread
From: Andy Tai @ 2021-03-29 20:02 UTC (permalink / raw)
  To: help-guix

Two questions:

1.  When submitting an updated package definition, is there an easy
way to check if other packages may be broken by this update?   Right
now it is easy to check if a package builds with updated package
definition; but it is not easy to see if committing it will break
others.

2. If a package is not building in guix, should a bug be filed against
it?  Ot there is a way, a CI web interface or something that shows all
existing packages whose builds are broken?

Thanks

-- 
Andy Tai, atai@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat: andytai1010
Year 2021 民國110年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: build broken packages handling
  2021-03-29 20:02 build broken packages handling Andy Tai
@ 2021-03-30  2:45 ` Julien Lepiller
  0 siblings, 0 replies; 2+ messages in thread
From: Julien Lepiller @ 2021-03-30  2:45 UTC (permalink / raw)
  To: help-guix, Andy Tai



Hi Andy,

Answers below.

Le 29 mars 2021 16:02:37 GMT-04:00, Andy Tai <atai@atai.org> a écrit :
>Two questions:
>
>1.  When submitting an updated package definition, is there an easy
>way to check if other packages may be broken by this update?   Right
>now it is easy to check if a package builds with updated package
>definition; but it is not easy to see if committing it will break
>others.

I can't check right now, but I think the contributing section in the manual describes this. You might want to have a look :)

To list leaf packages that are affected by a change (and the number of packages affected, including non-leaf), you can use guix refresh:

guix refresh -l foo

Will tell you which leaf packages are affected if you modify foo. Build them all if the number is low. If the number of dependents is high enough to qualify for staging or core-updates, then checking only some of them is ok.

>
>2. If a package is not building in guix, should a bug be filed against
>it?  Ot there is a way, a CI web interface or something that shows all
>existing packages whose builds are broken?

Yes, if the package is important to you, please file a bug report with details about the failing build, to bug-guix. Don't bother upstream :)

We have ci.guix.gnu.org, which is our build farm. You can use the search box to look for failing builds.

If you manage to fix some of them, definitely send a patch!

>
>Thanks


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-03-30  2:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-29 20:02 build broken packages handling Andy Tai
2021-03-30  2:45 ` Julien Lepiller

unofficial mirror of help-guix@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-user/0 guix-user/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-user guix-user/ https://yhetil.org/guix-user \
		help-guix@gnu.org
	public-inbox-index guix-user

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.user
	nntp://news.gmane.io/gmane.comp.gnu.guix.user


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git